ietf
[Top] [All Lists]

Re: 128 bits should be enough for everyone, was: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)

2006-03-30 20:45:37
Thus spake "Anthony G. Atkielski" <anthony(_at_)atkielski(_dot_)com>
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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>