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 Joel M. Halpern wrote: > As I understand it, the original intent with the U bit was to provide > an easy way to create IID that were highly likely to be distinct from > all other IIDs (on the link). As IEEE reserves the G bit, we marked > that as special as well when the U bit was set. > > Changing the meaning of U=1, G=0 seems a major chane with no > particular benefit. > > When we defined it, we were unclear about the U=1, G=1 case. Given > the way the U bit is defined, U=1, G=1 can not occur in the normal > course of events. We can ignore it. we can define it. We can > reserve it and thn sit on our hands. But given taht we have text > already, and that text is ambiguous, it seems like we should at least > clear up the ambiguity. > > Yours, > Joel > > On 12/18/2012 7:35 PM, Fred Baker (fred) wrote: >> Why do we care about u and g in the first place? Is there code in an >> IPv6 router or host that interprets them? >> >> On Dec 18, 2012, at 3:50 PM, Joel M. Halpern wrote: >> >>> In reading the discussion,a nd trying to think through what I >>> understand to be correct, it seems that there is an unforeseen >>> ambiguity in the way the current documents about IPv6 IIDs are written. >>> >>> I think that there are two possible meanings, ad we should decide >>> explicitly which one we want. >>> >>> 1) u=1 means that the IID is derived from an IEEE OUI (of some >>> form). With that meaning, u=1, g=1 is clearly some sort of >>> multi-entity identifier. And we should say that somewhere. >>> >>> 2) u=1, g=1 was unforeseen, and we don't know what it means. In >>> that case, we ought to figure out how we want that portion of the >>> IID space used, and write it down clearly. It seems to me that >>> allowing this space to be used for special-semantic IIDs (with >>> suitable care so that the entire ecosystem is not affected by them) >>> is a very reasonable path. >>> >>> It seems unlikely that there is actual practice in the wild with >>> u=1, g=1 under either interpretation. We do now have a request to >>> start using it (4rd). So we should decide. >>> >>> Yours, >>> Joel >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially. >> - Marshall McLuhan >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
