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

[Eswaran Srinivasan <[e-mail]>]

Hi Olivier,

The draft looks great to me in general.  However, I have a question to
you.

    The section 1 says that the IPv6 class is introduced since the
    class 1 (Locally Assigned Address) is deprecated.  I am thinking
    that having a IPv6 class is useful even if class 1 is not deprecated.

    Should we rephrase the sentence (if you agree)?

Hi Jim,

I can still see the usefulness of class 1 and I have heard about a lot
of deployment scenarios with this.  So, what does 'deprecated' mean here?
Is there any time limit?

Basically, I am inclined towards making it 'non-deprecated' and I am
trying to understand the logistics behind doing it.

Thanks
-Eswaran

On Fri Aug 13, 2010 at 12:36:25PM -0700, James Carlson wrote:
> >     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]>
> _______________________________________________
> Pppext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pppext