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

[James Carlson <[e-mail]>]

Olivier Vautrin wrote:
> 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.

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.

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

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

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

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.

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