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

[Brian E Carpenter <[e-mail]>]

On 18/07/2017 20:04, james woodyatt wrote:
> 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. 

Hmm. Let's consider a case in which the last-hop route to a given LAN has a prefix of
length, say, /80. What is the name of the bit-string from bits 81 through 127 of the
host address? If they aren't called the "IID" what are they called?

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

In what respect does draft-ietf-6man-rfc4291bis-09 fail to be such a minor revision?
I'm unaware of any single place that anyone would need to modify their code
if that text was published as an RFC. That's a major part of the criteria for
Internet Standard.

    Brian