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

[James Carlson <[e-mail]>]

>     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.

- 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.

That is, I believe the document should explicitly _encourage_ the use of
IPv6 addresses in this one context past the point where the system is
otherwise still "allowed" to use the address.  If that can't be done
(e.g., if the IPv6 folks believe that this usage is somehow a problem),
then addresses that are expected to change need to be avoided.
(Personally, I don't see how it could be a problem, unless you're
prepared to tear down the whole bundle when the address becomes invalid,
but I guess I'm unsure here.)

- 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.

- I think this ought to be a standards-track document that updates RFC
1990, and (with your agreement, of course) should be a wg document.
(See RFC 3818; the Class numbers are "IETF Consensus.")

- Wow.  The new boilerplate makes a visual mess of otherwise nice,
simple proposals like this.  :-<

-- 
James Carlson         42.703N 71.076W         <[e-mail]>