2012-12-19 23:01, Roger Jørgensen <[email protected]> : ... > if you read RFC4291 and section 2.5.1. you'll see the following two paragraphs > > IPv6 nodes are not required to validate that interface identifiers > created with modified EUI-64 tokens with the "u" bit set to universal > are unique.
That's precisely why uniqueness of such addresses must continue to be ensured. > > The use of the universal/local bit in the Modified EUI-64 format > identifier is to allow development of future technology that can take > advantage of interface identifiers with universal scope. 4rd IPv6 addresses are universally unique because: - Each one contains a public IPv4 address - If this IPv4 address is shared between several sites, checksum-neutrality preserver fields of their IIDs are different. (They depend on subnet prefixes of these sites, which differ by the few bits of their port-set IDs.) This is fully in scope of the sentence you have quoted (even if such an application wasn't anticipated when RFC 4291 was adopted). > First it say no hosts are required to validate it, only routers as I > read it. Any that really do that? > Second say it's open for the future to redefine the usage of the "u" bit. > The "g" bit ain't IETF's to play with as I read it - but all of this > is in EUI-64 context. > > > All in all, nothing prevent 4rd to use u and g set to 1, Agreed. > however: > >> Besides, who will guarantee that the IEEE won't come up with some future >> use for u=1 g=1? I'm not even sure the IETF should define these semantics. >> So in response to Joel, I'd humbly suggest defining u=1 g=1 as reserved >> for future use (to be defined in conjunction with the IEEE). >> >> To me, an alternative for consideration for 4rd would be either to use a >> dedicated IEEE-defined special-purpose OUI (together with an additional >> rd4 specific header for any remaining bits that cannot be encoded >> directly in the IID/IPv6 address), or to use locally assigned IIDs >> starting with binary 000 and ensure no other locally assigned IIDs are >> running on this particular scope. That should avoid changing any other >> standards or existing implementations. > > this sum it up, it's not "fair" for 4rd to start using these two bits > as they ask for, it block for future usage of them. As already explained, reserving for 4rd a particular IID pattern having u=g=1 (as needed to avoid confusion with EUI-64-based addresses having u=1), doesn't block "future usage" of these two bits. On the contrary, it opens the path for new patterns using them, while no conflict with current usages has been identified (including ILNP). > However, we should define for future how we want "u" and "g" set to 1 > being used. > But as other have stated, why should we keep them? Not understood what is meant by "why should we keep them?". RD > > > -- > > Roger Jorgensen | ROJO9-RIPE > [email protected] | - IPv6 is The Key! > http://www.jorgensen.no | [email protected] > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
