Ignatios Souvatzis wrote:
On Mon, Sep 17, 2007 at 10:16:04PM -0700, Christian Huitema wrote:
That was, and still is, the official IEEE line. IEEE 802 is very
concerned that 48 bit is not quite enough.
Let me add that IEEE1394 is using 64 bit addresses - and yes, it's in
occasional use here:
This comment actually make clear why one size isn't necessarily appropriate:
"Occasional use".
Compare that to deployed networks with hosts world-wide for MAC-48 (i.e.
802.*) of >> 10^8 devices.
IPv4 networks in the DFZ numbering >>200,000 even with CIDR aggregation.
There is a need to deploy IPv6 into the global Internet to handle the
IPv4 space exhaustion.
The routing infrastructure of the combined IPv4+IPv6 needs to survive
the addition of IPv6, and handle
the dual routing via dual-stack, for a minimum of 3-10 years. This means
not only supporting all of the
existing devices, but handling the continuation of exponential growth,
ideally with a minimum of additional
routing slots eaten up on the devices in the DFZ.
The question I raise is:
Do we feel so strongly about universally supporting oddball cases, that
we will not accommodate operator
need when it is presented?
From what I have seen so far as responses, the counter arguments are:
- there are these wonky things that maybe a few dozen research sites are
playing with that use 64-bits for MAC
- changing the spec would require, like, actual work. Let's just leave
it alone
IMHO, those arguments don't hold water.
And, in fact, I'm talking about *relaxing* some of the requirements, in
a permissive sense, where existing
implementations would not be out-of-spec. So, anyone who is lazy, can
continue to use old code.
What I'm talking about, is adjusting the specs, so that those who see a
need for new code, can do the
work, and have it continue to be considered valid as far as the RFCs are
concerned.
As for prefixes, the RA stuff never actually was constrained to be only
64 bits of network.
It was only that, for autoconf to work, the announced prefix had to mesh
with the II exactly.
Relaxing *that* has no impact on the RA's, or old code. Nothing prevents
an RA using /64, which
will continue to support EUI-64 with autoconf (old code).
What it *does* do, is allow for new code with flexible II of MAC-48 +
padding, to work with arbitrary
prefixes announced by RA when doing autoconf.
Which, in turn, supports real-world use of autoconf on /80's, permitting
global assignment
policy which will support real-world growth over the next decade or two,
while protecting
the DFZ from prefix explosion caused by allocation "squeeze" effects.
tiger# ifconfig fwip0
fwip0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:11:06:00:00:00:6a:21
inet6 fe80::211:600:0:6a21%fwip0 prefixlen 64 scopeid 0x1
I note that all of the examples sent have link-local addresses only.
And, since each such network will include only similar devices, all with
MAC-64, the addressing
used for those networks has no impact on the addressing for networks
running Ethernet framing
and MAC-48.
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
