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