Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-mlppp-id-00.txt

[Olivier Vautrin <[e-mail]>]

Hello James, thanks for your feedback please see below.

Yes, I think this document should be a WG document. I thought 6man WG would be the right place, but I guess PPPext WG makes more sense.

/Olivier

> -----Original Message-----
> From: James Carlson [mailto:[e-mail]]
> Sent: Friday, August 13, 2010 12:36 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-
> mlppp-id-00.txt
> 
> >     Title           : Multi link PPP Support for an ipv6 address
> class
> > identifier
> >     Author(s)       : O. Vautrin, B. Lourdelet
> >     Filename        : draft-vautrin-6man-ipv6-mlppp-id-00.txt
> 
> In general, I like the idea, but I'd like to suggest a few amendments
> (or at least points for consideration):
> 
> - Some IPv6 addresses are probably not as suitable for use as others.
> In particular, using a link local is unlikely to be a good idea because
> of the greater risk of duplication.  We glossed over this issue with
> IPv4 in RFC 1990, mostly because link-locals are so 'rare' there, but
> it
> seems more important to call out in the context of IPv6.

[Olivier - ] Yes, a unique Ipv6 address should be used. But in the IPv6 case, the link-local is very rarely non-unique as it is supposed to use the Interface-ID which is usually a unique ID. Perhaps we could just say that it would be the responsibility of the operator to use unique Ipv6 address without more details?

> - A "privacy" address, or any other "changes frequently" address, may
> be
> a problem operationally.  If a PPP system establishes one link, and
> then
> later (perhaps on demand) establishes another link that's intended as
> part of a bundle, that second link will need to use the same endpoint
> discriminator.  If the address has changed, the bundle will fail.
> Implementations likely need to "sample" a locally-available IPv6
> address, and then keep using that address for all future links until
> the
> bundle itself is terminated -- regardless of the current status of that
> address on the system.

[Olivier - ] - I guess this issue exist also on IPv4. Do you think this draft is the right vehicle to clarify this for both IPv4 and IPv6?

> - As a nit, I don't think it's wise to duplicate the existing RFC 1990
> values for Class in this document.  Instead, just the new value and
> semantics should be included.
> - Wow.  The new boilerplate makes a visual mess of otherwise nice,
> simple proposals like this.  :-<

[Olivier - ] This was a way to clarify the document especially because of the boilerplate ;) But, yes, I will remove the duplicate part of RFC1990.