2012-12-23 09:14, Brian E Carpenter <[email protected]> : > Ray, > > That is about an IEEE EUI-48 and we are talking about an IETF Modified EUI-64.
True, but the same RFC 5342 says, in its EUI-64 section, "As with EUI-48 identifiers, the OUI has the same Group/unicast and Local/Global bits." > I think we can say whatever we like about the bits in an IETF Modified EUI-64. > > Brian > > On 22/12/2012 20:48, [email protected] 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, It does (IMHO). Thanks for this reference. Regards, RD >> RayH >> >> Quoting Rémi Després <[email protected]>: >> >>> Ray, >>> Please see inline. >>> >>> 2012-12-21 à 14:03, Ray Hunter <[email protected]> : >>> ... >>>>> 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 >> [email protected] >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
