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

["Manfredi, Albert E" <[e-mail]>]

-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Philip Homburg

> I'm not attached to any particular term. However, I think it is
> important that the reader of rfc4291bis gets a clear under standing of
> the difference between an IID as used for SLAAC. Which has a lot of
> properties, including that it is generated locally on the node and is
> used for address configuration.
>
> And on the other hand, what I called 'host part' which in general
> doesn't have any properties.

So let's look at this. The properties of the SLAAC IID, according to RFC 4862 anyway, are that it must be whatever the IPv6-over-foo RFC tells us it must be. "Properties" would include the length, in principle not constrained to 64 bits, and for Ethernet, in accordance RFCs 2464, 4291 and 4862, an exact, predictable value, EUI-64. In the newer implementation of SLAAC, we have said that the IID for SLAAC must be a random 64 bits. And RFC 4291-bis wants to stipulate this aversion to EUI-64.

For LLAs, same deal. IID must be EUI-64 for Ethernet. We may prefer to modernize that to a random sequence, same considerations as in SLAAC.

For ULAs, RFC 4193 requires IIDs to be as defined in RFC 3513, so there too, EUI-64, exactly like SLAAC according to RFC 4862, and LLA according to RFC 2464. With our new sensitivities, probably the ULA IIDs should also be randomly chosen. I suppose SLAAC can also be used with ULA prefixes. I don't see any difference in properties so far?

The IID used in DHCPv6 can be predictable, like 1, 2, 3, etc. But theoretically, EUI-64 or a random sequence can also be applied to DHCPv6. The same considerations apply as in the previous two examples, in terms of properties we might or might not care about. In principle, even using DHCPv6, we might care not to make IIDs too obvious.

Statically assigned IIDs, much the same, except they're going to have long lifetimes.

> In my opinion rfc4291bis should not be a random collection of true
> statements that have to be assembled by the reader.

Agreed, but RFC 4291-bis should be consistent and logical. The properties we worry about for IIDs are not necessarily different, in any of these address assignment schemes, that I can tell, and it doesn't make a lot of sense to give "IID" a different name for every address assignment scheme? That would get too confusing.

Bert