see inline:
On Wed, Dec 19, 2012 at 9:57 AM, Ray Hunter <v6...@globis.net> wrote: > OK I'll bite. All IMVHO. > > In answer to Fred's question, to me the current problem is on the end > hosts and not on existing intermediate devices. > > There are many different ways to assign IPv6 addresses, including manual > assignment, that can all run simultaneously on the same interface/link > and the same /64 prefix. New IDs are still being generated on address > assignment even today e.g. > https://datatracker.ietf.org/doc/draft-gont-6man-stable-privacy-addresses & > 4rd https://datatracker.ietf.org/doc/draft-ietf-softwire-4rd/. I'm sure > there'll be many more in the future. > > Some of those ID's do put additional semantics into the IID. Others don't. > > Some of those that use semantics in the IID sometimes do not rely on DAD > to detect assignment clashes. > > It seems to me with the benefit of hindsight that a fundamentally better > approach would have been to reserve many more bits in the IID, or in RA > PIO, to create mutually exclusive subspaces per assignment mechanism or > per class of assignment mechanism, but that train has probably left the > station long ago, and that now assigning a huge block of space for u=1 > g=1 exclusively for a tunnel protocol like 4rd is fundamentally unfair > and restrictive for future assignment mechanisms. Also having addresses > assigned without performing DAD would seem a bad move to me on any > prefix with more than one address assignment scheme running. For most people, there are only two way of seting and IPv6 addresses, either through RA/DHCPv6, or manual. In either case not many really care about u/g bit, or know about it. 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. 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. 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, 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. 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? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
