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
--------------------------------------------------------------------

Reply via email to