> Rémi Després <mailto:[email protected]> > 19 December 2012 10:45 > Hello, Ray, > > 2012-12-19 09:57, Ray Hunter <[email protected]> : > ... > > The proposal is precisely to use the only remaining unused pattern > (u=g=1) as an escape mechanism FOR ALL future IID formats. > (Among IIDs having u=g=1, 4rd is proposed to reserve only IIDs > starting with 00000011, i.e. 1/64th of the left space.) > > In my understanding, this exactly what you are looking for in view of > constraints of compatibility with past decisions. > > Note that, with the 4rd specification as is, the 4rd reserved pattern > could even be 0000001100000000, i.e. 1/16384 of the left space. > > Hoping it clarifies, > Regards, > RD > I already understood this [I do read all posts on this list, even if I don't post replies].
My points are: 1) I am not comfortable with the IETF overloading IEEE semantics: the semantics of g & u bits aren't exclusively ours to assign. The combination g=1 u=1 is not unused as you state: that's IEEE OUI assigned multicast. It is only in combination with IETF IPv6 unicast address space that they are deemed "ambiguous". 2) They may be used for something else in the future (and potentially by the IEEE without reference to the IETF) You want to use the using the existing (ambiguous) combination u=1 g=1 EUI-64 and IPv6 unicast to statelessly map IPv4 over IPv6 unicast (or as an escape for other IID formats). Given that large scale deployment of multicast in general (and multicast IPv6 routing in particular) is still very much in its infancy, someone might well want to map the whole IEEE EUI-64 multicast addresses statelessly also using u=1 g=1 into unicast IPv6. And any use by 4rd would likely prevent that mapping unless 4rd is assigned it's own OUI. I understand that the base requirements for 4rd are that 1) every node has to have the potential to be able to easily assign an identifier for terminating a 4rd tunnel from existing IPv6 space if possible 2) stateless 4rd gateways have to be able to easily recognise 4rd traffic (without explicitly configuring a tunnel or IPv6 address space in advance) 3) IPv4 space (potentially overloaded with RFC1918) has to be mapped transparently, symmetrically, and easily, over the 4rd tunnel at the 4rd endpoints and the 4rd gateways. I see no requirement that *all* of the above requirements need to be encoded directly into the IPv6 IID. Existing nodes that do not process 4rd at all do not need 3) Hence my suggestion to investigate using an alternative of an IEEE assigned OUI for 1&2 together with standard IPv6 SLAAC (without changing any existing standards at all) and add an additional 4rd header for 3) to add any additional information that is 4rd specific. I don't think that would fundamentally change your existing ID at all, just how the specific bits are packaged into an IPv6 unicast packet. This also having the advantage that if ever there was an 4rdv2 you'd have a lot more to play with in your 4rd specific header. regards, RayH > Ray Hunter <mailto:[email protected]> > 19 December 2012 09:57 > 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. > > 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. > > regards, > RayH > ------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
