Brian E Carpenter wrote:
Choosing EUI-64 format was a strategic decision taken from
a very long term (many decades) viewpoint. I see no case
for changing that choice.
Let me make the case very simple:
IF an RA advertises a /80 prefix:
- EUI-64 autoconf WILL fail
- EUI-48 autoconf WILL succeed (the proposed extention to autoconf II
construction)
This does not REQUIRE that all II be EUI-48, or even that ALL interfaces
support EUI-48. Clearly neither of those makes any sense.
I am proposing ONLY that AUTOCONF be extended in cases where it
otherwise would fail, to construct an alternate II based on whatever MAC
happens to be on the interface.
NB:
This is actually very much analogous to what is done on Link-Local.
If you recall, Link-Local does *not* specify EUI-64 for II, nor does it
specify even the *size* of the II. It is II-agnostic, other than number
of bits maximum in an II not exceeding 55 bits (/9 prefix)
It merely says, to build a LL address, take "FE80::/9" and bit-wise OR
it with the II.
(End NB comment)
I am suggesting similarly, take the RA prefix, and bit-wise OR it with
whatever alternative for II (i.e. MAC address) is used, and do this ONLY
for prefix other than /64.
Per the INT AD's message today, please indicate:
(a) if you feel this will cause harm
(b) if you only are reluctant to have the RFC changed
(c) if you actively oppose this on grounds other than (b)
If (c), please voice your *specific* concerns. Again, this is II used
only for autoconf, and only when presented with an RA of something other
than /64.
Brian Dickson
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
