Subject: Re: [Softwires] draft-toutain-softwire-point6box-00.txt

From: Francis Dupont <[email-masked]>
Date: Sun, 05 Feb 2006 21:59:38 +0100

In your previous mail you wrote:

=> it seems I forgot to post these answers...

   Here are my comments on it.
   
   Philosophical:
   
     - it might be useful to describe (e.g., in an appendix) the most important
       design choices you made; e.g., why L2TP?  would some other mechanism have
       been acceptable as well, or did you require some specific L2TP features?
   
=> there were two main reasons to use L2TP: the first one was we already had
experiences with L2TP over GSM/GPRS environments, the second was L2TP was
heavily used here by ADSL ISPs so it should be easily accepted.

     - while the approach could be workable, I'm having difficulty seeing practical
       deployment.  I doubt many users want to add (yet another) box to their
       network for the sole purpose of IPv6.  Many users would probably be happy
       by having a host act as a v6 router.  That wouldn't require getting and
       installing a new box that's going to be retired (hopefully) as soon as
       possible in any case, while the prefix could still be stable.
   
=> in the softwire problem statement, hubs & spokes section, you can see
three cases. The point6box is usually the third case but can be the first
when you can replace the HGW. The associated PE6 supports the case 2 too.
So even if I agree a native and integrated IPv6 is the best solution
your comment is more about the whole softwire hubs & spokes solution
than the point6box one...

   4) Security considerations section is inadequate.  You should analyze 
   how/whether the manner in which you use the existing protocols exposes 
   you to security issues (for example, you don't seem to have any server 
   authentication, I guess someone on the wire could steal the user 
   credentials?)
   
=> you can do server authentication with CHAP. The idea is the existing
protocols already provide all the security tools you can need so the
point6box document is neutral. Of course you can misuse the security
features but unfortunately this can't be fixed by an IETF document...

       [ID.delegated]
                  "RADIUS Delegated-IPv6-Prefix Attribute".
   
=> oops, I believed this one was fixed.

       [RFC4057]  Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
                  June 2005.
   
   ==> not referred to in the draft, can be removed?  (are there others like
   this?)
   
=> it is the only one reported by xml2rfc.

       o  deploy the IPv6 in a private network.  A company specialized in
          digital signages has to install display devices in hotels, shops
          and supermarkets.
   
   ==>"signages" ?
   
=> try google on it (:-)!

Regards

[email-masked]

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires