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

From: James Carlson <[email-masked]>
Date: Fri, 13 Aug 2010 14:59:34 -0400

Subject: I-D Action:draft-vautrin-6man-ipv6-mlppp-id-00.txt
Date: Thu, 12 Aug 2010 16:30:02 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    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
    Pages           : 5
    Date            : 2010-08-12

This document specifies a new multi link protocol address class
identifier.  This new class will be able to contain an ipv6 address.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-vautrin-6man-ipv6-mlppp-id-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: James Carlson <[email-masked]>
Date: Fri, 13 Aug 2010 15:36:25 -0400

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

---

From: Eswaran Srinivasan <[email-masked]>
Date: Sun, 15 Aug 2010 22:42:24 -0700

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:
> _______________________________________________
> Pppext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pppext

---

From: James Carlson <[email-masked]>
Date: Mon, 16 Aug 2010 07:42:05 -0400

>     Should we rephrase the sentence (if you agree)?

It's RFC 1717 that deprecates Class 1 ... before even RFC 1990.  It was
born deprecated.

The proposed draft is not changing this, so I think this discussion
might be a bit off-topic for the draft itself.

> trying to understand the logistics behind doing it.

There's no specific time limit nor prohibition against using it.

I think the original fear with Class 1 was that since there's no defined
way to ensure uniqueness among bundle heads, there could possibly be
duplication of values -- which would cause (at least) link failures.

As I read it, and perhaps someone else here remembers more about it, the
force of the "deprecation" is that it's not the recommended practice for
new systems, because the other defined mechanisms are believed to be
better and just as easy to use, and that there's the possible threat
that it may be removed entirely from future specifications.

However, if it is indeed in common use, then that'd be a good reason to
document those usages and perhaps create a new document that removes the
"deprecated" status rather than removing the feature.  Do you have
pointers to any additional information?

---

From: Olivier Vautrin <[email-masked]>
Date: Mon, 16 Aug 2010 11:22:36 -0700

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:[email-masked]]
> Sent: Friday, August 13, 2010 12:36 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Pppext] new draft published: draft-vautrin-6man-ipv6-
> mlppp-id-00.txt
> 

[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?

> bundle itself is terminated -- regardless of the current status of that

[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?

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

---

From: Olivier Vautrin <[email-masked]>
Date: Mon, 16 Aug 2010 11:24:30 -0700

Thanks Eswaran for your comment, I will rephrase the sentence about Class 1.

/Olivier

> From: Eswaran Srinivasan [mailto:[email-masked]]
> Sent: Sunday, August 15, 2010 10:42 PM
> To: James Carlson
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: James Carlson <[email-masked]>
Date: Mon, 16 Aug 2010 15:59:45 -0400

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

OK; thanks.  Consider it done.  You'd need our group's approval anyway
to modify the IANA registry for the new E-D Class value.

> [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. Perhap…

For IPv6, the only operational uniqueness requirement is that the
address is unique on a given subnetwork.  Since one of the main things
we're trying to do here is distinguish unrelated remote systems -- ones
that may well be on completely different networks -- there's not as much
that guarantees it.

Yes, I agree that "most" link-locals are created using EUI64 values and
are thus guaranteed to be unique.  However, I do know of at least one
virtual server solution that conjures up link-locals out of thin air
(and that thus relies on DAD to do the rest).

Anyway, what I was suggesting here was text of the form:

  "Using a statically-assigned global IPv6 address to form this
identifier is RECOMMENDED."

> [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?

The privacy extensions (RFC 4941) are a bit different, and don't appear
to apply to v4.  In the implementation I've used (Solaris), the v6
addresses with privacy enabled change fairly frequently, and would
represent a significant challenge to use with this mechanism.

There are two underlying suggestions here:

  1. If the address is known (for whatever reason) to be one that might
     vary over time, then it'd be less preferred for use here than one
     that doesn't (or isn't expected to) vary.  (This is the same issue
     as above; static global would be best.)  That's not to say "can't
     use" autoconf or some other address, but if you have something
     more stable, and you know the difference, it'd be good to choose
     that.

  2. Implementations that may see addresses come and go should consider
     choosing an address to be used when the bundle head is created,
     and continuing to use that same address until the bundle head is
     torn down.  They should do so regardless of the state of the
     address itself on the machine; if the address is deprecated and
     removed, that should not affect the bundle head using it for
     identity.

The same issue, more or less, could apply with IPv4, but in practice
does not.  The systems that use an IPv4 identifier are typically ones
that have a static IPv4 address.  There are just more viable options
with IPv6.

For others, where the address may end up wandering between systems
(e.g., DHCP), it would probably be unwise to use either feature, and the
existing magic number block or even opaque identifier might well be better.

As a deployment note, this draft relies for interoperability with
existing implementations on the idea that a well-designed RFC 1990
system will treat all classes (and associated data) as effectively
opaque and will not attempt to "validate" the peer's reported class
number, except in comparison to other E-D data during bundle formation.
 One benefit of adding and deploying this feature is that it may end up
identifying implementations that are not that robust.

Bottom line, though, is that I was asking you to consider adding some
advice for implementors, not insisting that you do.  If you feel it's
truly unnecessary to do that, I'll just shrug and go along, because I
don't think these are substantial issues.