Ray, That is about an IEEE EUI-48 and we are talking about an IETF Modified EUI-64.
I think we can say whatever we like about the bits in an IETF Modified EUI-64. Brian On 22/12/2012 20:48, v6...@globis.net wrote: > After some searching, I've finally found a reference in an IETF BCP > document that to my mind does demonstrate that u==1 && g==1 && unicast > IID = "currently unused" > > http://tools.ietf.org/html/rfc5342 > > Quote: "Two bits within the initial 3 octets of an EUI-48 have special > significance: the Group bit (01-00-00) and the Local bit (02-00-00). > OUIs and IABs are allocated with the Local bit zero and the Group bit > unspecified. Multicast identifiers may be constructed by turning on > the Group bit, and unicast identifiers constructed by leaving the > Group bit zero." > > Hope this helps, > RayH > > Quoting Rémi Després <despres.r...@laposte.net>: > >> Ray, >> Please see inline. >> >> 2012-12-21 à 14:03, Ray Hunter <v6...@globis.net> : >> ... >>>> The basic question is whether reserving for 4rd a specific 8-bit IID >>>> is "compatible with the IPv6 addressing architecture" as currently >>>> specified. >>>> Besides some expressed FUD, which isn't illegitimate in face of >>>> anything new, no such conflict has been identified by those who >>>> checked carefully. >>> You may call it FUD, but could you please point the WG members to the >>> text in either the IPv6 addressing architecture (RFC4291) or SLAAC >>> (RFC4862) that says that the g bit MUST be overridden to 0 before >>> creating an IID (and thus link-local and global IPv6 unicast addresses >>> when they are appended to a /64 prefix)? >> >> I hope I never suggested that any RFC says that g must always be set >> to 0. >> On the contrary, g can clearly be either 0 or 1 for local-scoppe IIDs >> (i.e. having u=0). >> >> Now, if u=1, RFC 4291 specifies in its Annex A one way to build IIDs, >> and which happens to imply g=0 (a consequence of the IEEE rule for >> individual addresses). >> AFAIK, this is so far THE ONLY IID specified by IETF with u=1, so >> that u=g=1 REMAINS AVAILABLE for new IID formats. >> >> OK? >> (If I missed another RFC specifying an IID format with u=1, thank you >> for giving a reference.) >> >>> It may be sensible, but where is it *defined* in an IETF standards track >>> RFC that automatic address generation based on an EUI-64 seed MUST NOT >>> use g=1? >> >> Nowhere (see above). >> >>> I think we both agree that being able to guarantee unique addresses on a >>> link is pretty fundamental to correct operation of IPv6, especially >>> considering the 4rd proposal as documented in your published ID would >>> not appear to use DAD, and failing DAD in existing nodes currently >>> causes an interface to cease processing IPv6 packets. >>> >>> The only text I can find is in the Ethernet specific encapsulation >>> (RFC2604) which states "The Interface Identifier [AARCH] for an Ethernet >>> interface is based on the EUI-64 identifier [EUI64] derived from the >>> interface's built-in 48-bit IEEE 802 address." And even then it's not >>> specific that if a manufacturer decided to burn in an EUI-48 into their >>> NIC with g=1 (e.g. for a technology that multicasts by default for >>> multi-channel television distribution) and this address is from within >>> their IEEE -assigned OUI space, whether that would be illegal for use >>> with IETF IPv6 standards. >> >> Not using a group address at the link layer for an IP unicast address >> is obvious enough for not needing an RFC to say it. It is AFAIK >> reflected by what manufacturers do. >> If you would have evidence of the contrary, I agree that it should be >> looked at. >> >> >>> Also not everything is Ethernet. >> >> Agreed. >> (But AFAIK it doesn't change the above.) >> >> Regards, >> RD >> >> >> >> > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
