2012-12-19 16:58, Brian E Carpenter <brian.e.carpen...@gmail.com> : > On 19/12/2012 14:44, Bless, Roland (TM) wrote: >> Hi, >> >> On 19.12.2012 14:21, Rémi Després wrote: >>> Could we limit the 6man discussion to the question asked by Softwire, >>> i.e. whether new IID types can be defined, using u=g=1, with a first >> ^^^^^^^^^^^^ >> Sorry, I'm not yet aware of a concept called IID _types_? >> 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."
As is, the sentence misses that IIDs that have u=1 are expected to be universally unique. (This uniqueness is key to ensure that, as long as a site has a stable IPv6 prefix, its statelessly auto-configured hosts can have stable addresses if so desired.) The sentence becomes completely accurate if limited to to local-scope IIDs and to the 63 bits other than the u bit. Ensuring IID universal uniqueness for new types of universal-scope addresses is the subject at hand. It can fortunately be dealt with because we know that, today, all u=1 IIDs must also have g=0. > then perhaps we could move forward. Today, the u and g bits are the > only ones that make the previous statement untrue for N=64, I believe. > > 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. Creating an additional RFC referenced in RFC 4291 as updating it seems to me a good approach. It would state that universal-scope IIDs other than that defined in RFC 4291 itself (i.e. in its Appendix A) are possible. Their formats are defined in specific RFCs, which are listed in an IANA registry. This registry indicates, for each of these RFCs, which bit pattern in IIDs determines its applicability. RD > s/required/recommended/ might be enough. Why is it "required" anyway? > > Brian > >> >>> If the answer is positive (as it seems it can be), restarting a >>> discussion on the 4rd design is unnecessary. That is only if the >>> answer is negative that Softwire will have to restart working on the >>> subject. >> >> Obviously, this question has further implications, so I >> think it's legitimate to ask whether the proposed solution >> is really a reasonable way of solving the problem. >> >> Regards, >> Roland >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
