Re: <draft-ietf-6man-rfc4291bis-09.txt>

[james woodyatt <[e-mail]>]

On Jul 17, 2017, at 23:42, David Farmer <[e-mail]> wrote:
> 
> I've begun to think there are two real problems here;
> 
> 1.  RFC4291 categorically says architecturally IIDs are 64bits, and seems to imply this is the case for all components of IPv6. While it is the case for several components of IPv6, it is not the case for other important components. Neighbor Discovery, DHCPv6, and Routing, etc... are not architecturally based on 64bit IIDs at all, in fact they are clearly based on IIDs of any length. 

Those other components aren’t based on IIDs at all. They’re based on IPv6 addresses and routing prefixes, but they’re not based on IIDs. That RFC 4291 still has this obsolescent concept of an IID that comes from embedding Modified EUI-64 transformations of MAC addresses isn’t actually causing any real problem that I’m seeing stated anywhere. It seems perfectly safe to me to promote to Standard a minor revision of RFC 4291 that retains the existing definition of the IID in the architecture.

> 2. The fact that some components of IPv6 are architecturally based on 64bit IIDs doesn't mean that operationally IIDs are always required to be 64 bits. Rather than implying that operationally IID are required to be 64bits, how about simply stating that operationally 64 bit IIDs are recommended. This eliminates the need to enumerate all the exceptions, which probably isn't something an architectural document should be doing.

See above.


--james woodyatt <[e-mail] <mailto:[e-mail]>>