2013-02-07 15:04, Ole Troan <[email protected]> : > I think our understanding of the IPv6 addressing architecture is incompatible. > there are no unused subset or unused ranges of interface-ids in IPv6.
1. If you interpret RFC 4291 as already permitting to set u=1 in some IIDs other than derived from IEEE MAC addresses, yes, we differ. Note that, concerning the u/g bit significance, RFC 4291 is not the only RFC that avoids u=1 in IIDs that aren't IEEE derived, and to avoid u=1 in IEEE derived addresses that are unicast: - RFC 3972 requires, in CGA IIDs, "setting bits 6 and 7 (i.e., the "u" and "g" bits) to zero". - RFC 4941 requires, for privacy-extension IIDs, "set bit 6 (the leftmost bit is numbered 0) to zero. This creates an interface identifier with the universal/local bit indicating local significance only." - RFC 6740 requires that "ILNP Identifiers have the same syntax as IPv6 interface identifiers [RFC4291], based on the EUI-64 format [IEEE-EUI]... If they have global scope, they SHOULD be globally unique... For both ILNP node Identifiers and also IPv6 interface identifiers, this Group bit is set to 0." 2. In http://www.ietf.org/mail-archive/web/ipv6/current/msg16982 you mentioned a particular use you know of a local-scope IID having u=g=1, namely ffff:0:0:1. Reason why its u bit isn't 0 is so far unclear but, assuming there is a reason, this IID can be reserved too in the IID-range registry, or one of its prefixes. As already noted, there isn't conflict between this IID and the 4rd range. No need to change either one. Conclusion: if you need some IIDs having u=g=1 for some identified use, let's document this use. We will thus avoid an unnecessary controversy. Regards, RD -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
