There are two sets of issues here.
One is that routing tables take up space, so even if you allocate in /64 units
you are going to end up running out of silicon before you run out of address
space.
Another is this fetish with stateless allocation of network addresses etc. It
might have been a workable proposal when it was made but is almost certainly
irrelevant to any real world IPv6 network that is actually deployed and managed
as such.
In the real world network devices are going to have to authenticate to the
network before they are allowed to ship packets about. So eliminating the need
to maintain state in DHCP is irrelevant, the network authentication layer is
going to require rather more than 8 bytes of state, a MAC address and a session
key at the least. So recording the IP address suffix that was assigned is not
gong to be an issue.
Folk can debate whether or not default deny will happen and there will be
strong policy enforcement at every layer in the network as I propose. But
802.1x is a fact of life for many corporate users today. If home users are
going to run wireless networks of any size they are going to need to go the
same route.
Nor do I see the reason to obsess about keeping the DHCP table stateless. Its
not like a network with 64K hosts is going to be hanging off a single DHCP
server anyway.
Given that we have the space issuing a /64 and allowing folk to simply map
EUI64 addresses via some sort of cryptographic one way function (e.g. encrypt
with a 64 bit block cipher and a common network key) makes sense. But then
insisting on allocation of extra bits for subnetting strikes me as applying
1980s networking approaches in an environment where they no longer make sense,
something some people seem to be against.
I think that we will find that there are 2 sets of user. Most users will never
subnet at all and be entirely happy with a /64.
Folk who are using 'subnets' are most likely to be doing so in order to
implement security mechanisms that encode network authorization data into the
IP address. This is already quite common in the enterprise security world. Here
16 bits is not likely to be enough, 32 is more like it. Anyone playing this
game is nopt going to be using the EUI64 mapping trick either.
I don't find the idea that everyone needs a /48 is likely to apply to either
group. And if people find they need more than one /64 they can always get more.
Its not like they have to be contiguous.
________________________________
From: Thomas Narten [mailto:narten(_at_)us(_dot_)ibm(_dot_)com]
Sent: Tue 28/08/2007 4:13 PM
To: John C Klensin
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: IPv6 addresses really are scarce after all
Hi John.
Let me suggest a slightly different perspective on this.
First, the decision as to how large to make the IPv6 address
space is, and was, an architectural decision. We could have
chosen a longer length, we could have chosen a shorter one, we
could even have made it variable length (with or without a
fixed-length or maximum-length network part). As others have
pointed out, we could have taken explicit measures to separate
IP-level addressing from routing as a fundamental part of that
architecture. All of those options were considered (although
some a lot more carefully than others).
Whether it is obsolete or not, and, if it is, whether because of
hardware or security considerations, the belief that local
networks needed to have 64 bits available for MAC address
mapping were also part of that picture. Again, certainly an
architectural decision rather than "pure policy".
Whether it was explicit or not, assumptions about the effective
size of that address space -- how many sites or "networks" it
could serve -- were also part of those architectural decisions.
I remember a whole series of discussions about whether N bits
(for various values of N) were enough under various scenarios.
We might not have gotten those decisions right, but they were
IETF decisions and decisions made as part of determining what
IPv6 looked like.
Agreed.
But I think there was a lot more discussion about this in the very
early days, when 128 bits was chosen, and when stateless address
autoconfiguration assumed that the Interface Identifier part of an
address was 48 bits, leaving 64+16 bits for routing.
Then, we made the decision to make Interface Identifiers 64 bits,
shrinking the routing part to 64 bits.
I agree completely that the /64 boundary was/is architectural. For
better or for worse, stateless address autoconfiguration (as currently
specifies) only works on links that have a /64 assigned to them.
But the /48 boundary is not. We had a long discussion about that in
the IPv6 WG, and our specs were carefully cleansed to make sure there
were no real dependencies on such a boundary. Think Randy Bush saying
"your reinventing IPv4 classful addressing" about a thousand
times. :-)
Indeed, even though the official IETF party line is that links have to
have 64 bits of subnet addressing assigned to them, a number of
operators screamed loudly that for internal point-to-point links, that
was horribly wasteful and they weren't going to stand for it. So,
products do indeed support prefixes of arbitrary length (e.g., /126s
and the like), and some operators choose to use them. This is one of
those situations where the IETF specs seem to say one thing, but the
reality is different. And we pretend not to notice too much.
Second, the notion that RIRs set addressing policy is one that
has not been in place forever. Indeed, it has evolved very
slowly and mostly by assertion by the RIRs that they have that
authority --assertions that, in other contexts, might look a lot
like either filling a vacuum or turf grabs depending on one's
perspective. While they have always (since there have been
RIRs) had broad discretion within their own regions, and it has
always been recognized some coordination discourages
forum-shopping and other bad behavior, global address policy was
historically set by IANA in conjunction with the IAB, not by the
RIRs (although I assume their advice was certainly welcomed).
Understood. But I think the reality today is that we have the world we
live in and serious suggestions to overturn the current world order
better have a strong and compelling motivation.
I'm sure you've also noticed, but IANA's recent position seems to be
more like "IANA doesn't make policy, IANA does what the community asks
of it".
Without taking any position on whether the ARIN decision is a
reasonable one, I believe that the IETF has had, and continues
to have, a role in the general design of addressing
architectures and hence in allocation strategies. I also
believe that the RIRs have some obligation to consult the IETF
before making a major policy change and to pay careful attention
to anything rational the IETF has to say. I also believe that
things are seriously out of joint if we need to worry about
whose toes are being stepped on before opinions are expressed.
I think that has mostly been happening, though it could always be done
better. The proposed changes to the HD ratio and /48 boundary were
certainly discussed in the IPv6 WG when they took place. And there are
folk that participate in both the IETF and the RIR communities.
Thomas
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf