Le 2012-12-19 à 11:20, Ray Hunter <v6...@globis.net> a écrit : >> Rémi Després <mailto:despres.r...@laposte.net> >> 19 December 2012 10:45 >> Hello, Ray, >> >> 2012-12-19 09:57, Ray Hunter <v6...@globis.net> : >> ... >> >> 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].
Well, this was to answer your statement that (upper cases added) "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". > > 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". IEEE isn't concerned with what uses IETF makes, at the IP layer, of IEEE-specified link-layer formats. In this context, IETF problems, if any, can and must be solved in IETF alone. > 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. If you have a specific idea about a format you would like to see for multicast, it can be looked at but, in any case, it won't change the fact that no RFC-compliant unicast address has u=g=1. In IETF, rather than being "ambiguous", u=g=1 is simply UNUSED (no meaning at all so far). (*) An assigned OUI wouldn't be sufficient because the IID wouldn't have enough free bits for an IPv4 address plus a checksum-neutrality preserver. It was already explained in an answer to Bob) Besides, even if a reserved OUI would work, it would need to involve IEEE, which isn't necessary. > 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) The fact that SOME nodes need it is sufficient for the need to exist. > 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. See (*) above. Regards, RD > > regards, > RayH >> Ray Hunter <mailto:v6...@globis.net> >> 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
