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