Jun-ichiro itojun Hagino wrote:
I'm not arguing for changing *all* of IPv6 away from EUI-64.
I'm arguing *for* *allowing* choices of II format of EUI-64 *or* any
other suitable unique II specific to the layer 2 medium.
making the host ("interface ID" in IPv6-speack) to be fixed length,
with bigger bitwidth, makes IPv6 address independent from the hardware
interface layer.
I think we agree in principal on the objective. Where we don't agree on,
is the scope of the solution.
Currently, the II spec is fixed regardless of medium.
I argue that there his benefit to expanding the II spec on a per-medium
(family) basis, on a permissibility basis.
Example:
Any II can be EUI-64.
Or, an II for anything that has L2 addressing with MAC-48 / EUI-48, can
use MAC-48 / EUI-48 for its II.
The "flexibility" of which I speak, is not user-defined.
It is only extending the II format on a per MAC/media basis.
It happens to be more forward-thinking than even using EUI-64 as a
required II format.
E.g. If EUI-72 were to come out, it would automatically just work, ie.e
be supported by the RFCs and protocols.
This variation still avoids the problem you describe:
today, i see the following horror story a lot:
- use like /28 or something for an IPv4 subnet
- there are 15th computer installed, no room for the new computer
- renember and get /27
- repeat it with (prefix length + 1)
- repeat it with (prefix length + 2)
- ...
today the most expensive cost is the human labor cost. one less IT
guy = happier management level.
Autoconf would still guarantee uniqueness, and numbering would only
change for a device if the NIC or medium-type were to change.
What this buys is, for Ethernet types, the ability to deploy networks
with autoconf using /80, which in turn
affects the *ability* to globally allocate to end-user sites, smaller
blocks than /48 or /56 (which are common
denominators today).
Today, autoconf *requires* /64, with no other choices.
And to make one other point clear:
The distinction of differing II between media type, does not impose any
compatibility problem.
I'll go into detail here; ignore it if you don't care about the details,
but please read if you want to
disagree with the assertion immediate above this, about no compatibility
problem.
Generally, for hosts on a subnet to speak directly, they need to be able
to speak at L2 - which means
they have to have compatible frame formats and L2 addresses.
Even if, hypothetically, bridging together two different media types
were possible, if they had different
sizes of L2 addresses, there would be no way for the short guys to
disambiguate the long guys. At best,
there would need to be some kind of proxy that would need to do L2 DAD
(!!!). And for IPv6, even
with EUI-64, that would break autoconf, unless the bridge was L3 IPv6
autoconf-aware. At which
point it is basically a NAT or router.
Notwithstanding even *that*, if two hosts with different MAC sizes were
talking via autoconf on IPv6,
the only way they could talk is if the RA sent a prefix short enough for
autoconf to work on the biggest
MAC. At which point, the smaller MAC would just pad its II, and
everything would still work.
Which means, this works independent of the prefix size, and independent
of the L2 formats, with no
address collisions between hosts using EUI-48 and EUI-64. (The IEEE has
assigned OUIs in such
a way as to ensure this - no FFFE in OUI-24 or even OUI-36 exists.)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
