Thus spake "Anthony G. Atkielski" <[EMAIL PROTECTED]>
Iljitsch van Beijnum writes:
However, since that time I've learned to appreciate
stateless autoconfiguration and the potential usefulness of having
the lower 64 bits of the IPv6 address as a place to carry some
limited security information (see SEND and shim6 HBA).
Once it's carrying information, it's no longer just an address, so
counting it as pure address space is dangerous.
An IPv4/6 address is both a routing locator and an interface identifier.
Unfortunately, the v6 architects decided not to separate these into separate
address spaces, so an address _must_ contain routing information until that
problem is fixed. It doesn't seem to be likely we'll do so without having
to replace IPv6 and/or BGP4+, and there's no motion on either front, so
we're stuck with the locator/identifier problem for quite a while.
Building in space means not allocating it--not even _planning_ to
allocate it. Nobody has any idea what the Internet might be like a
hundred years from now, so why are so many people hellbent on
"planning" for something they can't even imagine?
That's why 85% of the address space is reserved. The /3 we are using (and
even then only a tiny fraction thereof) will last a long, long time even
with the most pessimistic projections. If it turns out we're still wrong
about that, we can come up with a different policy for the next /3 we use.
Or we could change the policy for the existing /3(s) to avoid needing to
consume new ones.
If IPv6 is supposed to last 100 years, that means we have ~12.5 years to
burn through each /3, most likely using progressively stricter policies.
It's been a decade since we started and we're nowhere near using up the
first /3 yet, so it appears we're in no danger at this point. Will we be in
50 years? None of us know, which is why we've reserved space for the folks
running the Internet then to make use of -- provided IPv6 hasn't been
replaced by then and making this whole debate moot.
Unfortunately, at the time IPv6 was created variable length addresses
weren't considered viable.
Variable-length addresses are the only permanent solution, unless IP
addresses are assigned serially (meaning that all routing information
has to be removed).
Variable-length addresses work very well for the telephone system, and
they'd work just as well for the Internet, if only someone had taken
the time to work it out.
Variable-length addresses only work if there is no maximum length. E.164
has a maximum of 15 digits, meaning there are at most 10^15 numbers. Here
in +1 we only use eleven digit numbers, meaning we're burning them 10^4
times as fast as we could. That's not a great endorsement.
Also, telephone numbers have the same locator/identifier problem that IPv4/6
addresses do. In fact, IPv6's original addressing model looked strikingly
similar to the country codes and area/city codes (aka TLAs and NLAs) that
you're apparently fond of.
Even OSI's "variable length" addresses had a maximum length, and most
deployments used the maximum length; they degenerated into fixed-length
addresses almost immediately.
The only thing I'm not too happy about is the current one address /
one subnet / /48 trichotomy. Ignoring the single address for a
moment, the choice between one subnet and 65536 isn't a great one, as
many things require a number of subnets that's greater than one, but
not by much.
It's a good example of waste that results from short-sightedness. It
happened in IPv4, too.
The difference is that in IPv6, it's merely a convention and implementors
are explicitly told that they must not assume the above boundaries. In
IPv4, it was hardcoded into the protocol and every implementation had to be
replaced to move to VLSM and CIDR.
Conventions are for human benefit, but they can be dropped when it becomes
necessary. Folks who use RFC 1918 space almost always assign /24s for each
subnet regardless of the number of hosts; folks using public addresses used
to do the same, but instead now determine the minimum subnet that meets
their needs. Hopefully the conventions in IPv6 won't be under attack for a
long time, but if they need to go one day we can drop them easily enough.
The thing that is good about IPv6 is that once you get yourself a /
64, you can subdivide it yourself and still have four billion times
the IPv4 address space.
It sounds like NAT.
Not at all. You'd still have one address per host, you'd just move the
subnet boundary over a few bits as needed. With the apparent move to random
IIDs, there's no reason to stick to /64s for subnets -- we could go to /96s
for subnets without any noticeable problems (including NAT).
The RIRs could also change policies so that /32 and /48 are not the default
allocation and assignment sizes, respectively. That is also another
convention that we could easily dispense with, but it saves us a lot of
paperwork to abide by it as long as it doesn't cause problems.
Engineers should build stuff that still works reasonably well even if
they get their predictions wrong.
Engineers don't like to think that they've left anything out or that
they are less than omniscient in assessing what must be done, so many
of them are allergic to anything that is simply "reserved for future
use." I had the same trouble when I first started in computers, but I
grew out of it.
The folks who designed IPv4 definitely suffered from that problem. The
folks who designed IPv6 might also have suffered from it, but at least they
were aware of that chance and did their best to mitigate it. Could they
have done better? It's always possible to second-guess someone ten years
later. There's also plenty of time to fix it if we develop consensus
there's a problem.
S
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
