On 30-mrt-2006, at 6:26, Anthony G. Atkielski wrote:
We currently have 1/8th of the IPv6 address space set aside for global unicast purposes ...
Do you know how many addresses that is? One eighth of 128 bits is a 125-bit address space, or
42,535,295,865,117,307,932,921,825,928,971,026,432
addresses. That's enough to assign 735 IP addresses to every cubic centimetre in the currently observable universe (yes, I calculated it). Am I the only person who sees the absurdity of wasting addresses this way?
When I first learned about IPv6 I felt strongly that 128 bits was too much, especially since all those bits have to be carried in every IP packet twice, once as a source address and once as a destination address. 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).
... with the idea that ISPs give their customers /48 blocks.
Thank you for illustrating the classic engineer's mistake. Stop thinking in terms of _bits_, and think in terms of the _actual number of addresses_ available. Of better still, start thinking in terms of the _number of addresses you throw away_ each time you set aside entire bit spans in the address for any predetermined purpose.
The trouble is that you need to build in space for growth. Unfortunately, at the time IPv6 was created variable length addresses weren't considered viable. (In theory CLNP has variable length addresses, in practice that doesn't really work out.) And for some strange reason, apparently only powers of two were considered as address lengths. So the choice was either 64 bits, which is a lot, but it doesn't allow for any innovation over the 32 bits we have in IPv4, or 128 which does cost 16 extra bytes in every packet, but gives us stateless autoconfig and SEND. Now you can argue that 64 or 48 bits and continuing current IPv4 practices would have been better, but given the choice for 128 bits, the current way of using the address space makes sense for the most part.
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. For instance, the cell phone as a router example I talked about earlier. A /64 and a single address, or two /64s which would be a /63 would be more useful there. The idea that we'd use up too much address space by giving out /48s doesn't seem like a real problem to me, but on the other hand most people don't need a /48 so some choice thats < /48 and > 64 makes sense. But a /56 as suggested by some people is suboptimal: people with growing networks will at some point need more than 256 subnets but at that point they already have very many subnets so renumbering then is painful. Making the choice between /60 and /48 makes much more sense: just give everyone a /60 rather than a /64 just in case they need a handful of subnets, which is adequate for 99% of all internet users. People who need more than a handful of subnets can get a /48 and won't have to renumber at an inconvenient point in the growth curve.
Yes, I know this will use up sixteen times the number of addresses for people who really only need a single subnet, but it saves a factor 4096 for the people who need 2 - 16 subnets and would have gotten a /48 or a factor 16 for the people who would have gotten a / 56. The extra wasted address space from giving people who really only need one subnet a /60 is made up for by the people who would have gotten a /48 but can now get by with a /60 if the ratio of one-subnet to <17-subnet users is 1 : 4000 or less. (Making the choice /64 vs / 56 saves even more as long as the ratio is lower than 94 : 6 but doesn't have the desireable near-onesizefitsall quality.)
If you want exponential capacity from an address space, you have to assign the addresses consecutively and serially out of that address space. You cannot encode information in the address. You cannot divided the address in a linear way based on the bits it contains and still claim to have the benefits of the exponential number of addresses for which it supposedly provides.
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. (But you'd be giving up the autoconfiguration advantages.)
Also, when the time comes to create the next version of IP, we won't have to worry about all of this to a noticeable degree because IPvA or IPvF or whatever can have a different addressing structure that can still be expressed as an IPv6-like 128 bit number for backward compatibility with IPv6, which isn't possible today because IPv6's 128 bits can't be expressed as an IPv4-like 32 bit number.
It's generally accepted that an HD ratio of 80% should be reachable without trouble, which means we get to waste 20% of those bits in aggregation hierarchies.
No. It's not 20% of the bits, it's 99.9756% of your address space that you are wasting.
I'm not a huge fan of the HD ratio either, because it substitues a rule of thumb for actual knowledge. But the point is that EVEN if you waste 99.9756% in this way we STILL have enough addresses to give every person living on the planet when the population hits its peak several /48s which are wasteful in their own right.
So while I wouldn't want to take away your right to begrudge the way all of this is done in IPv6, I must object to your conclusion that we'll run out of IPv6 soon, for any reasonable value of "soon".
Do engineers really study math?
Just the simple stuff.
That's another problem of engineers: they think they can predict the future, and they are almost always wrong.
I hope good engineers don't think that, but it's certainly true that as a rule, the future doesn't match what was predicted earlier. Engineers should build stuff that still works reasonably well even if they get their predictions wrong.
Unfortunately the people who want non-aggregatable provider independent addressing can't seem to understand that.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf