On 19.12.2012 16:58, Brian E Carpenter wrote: >> Do we really have such a thing "IID types"? > > I think that's an important point. If we could make a statement like > > "The IID consists of N bits that have no meaning; the only constraint > is that they must be unique within the scope of a given link and > routing prefix." > > then perhaps we could move forward. Today, the u and g bits are the
Yep. > This would require formally updating RFC 4291, which says: > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > s/required/recommended/ might be enough. Why is it "required" anyway? Yes, but I guess that we have enough examples where it's not useful to construct IIDs according to Modified EUI-64 format (privacy extensions, CGAs and the like). Indeed, the IID has to unique within a link-local scope, which is normally ensured by DAD. However, if one uses a globally unique scheme such as a Modified EUI-64 to derive an IID, the IID will be unique with very high probability within the subnet scope. But that's IMHO the whole point and RFC 4291 is maybe a little bit too restrictive. Regards, Roland -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
