Re: IIDs, u and g bits, and 4rd

[[e-mail]]

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 <[e-mail]>:

> Ray,
> Please see inline.
>
> 2012-12-21 à 14:03, Ray Hunter <[e-mail]> :
> ...
>>> 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
>
>
>
>