Stephen Sprunk writes: > An IPv4/6 address is both a routing locator and an interface identifier. And so engineers should stop saying that n bits of addressing provides 2^n addresses, because that is never true if any information is encoded into the address. In fact, as soon as any information is placed into the address itself, the total address space shrinks exponentially. > 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. Then we need to make predictions for the longevity of the scheme based on the exponentially reduced address space imposed by encoding information into the address. In other words, 128 bits does _not_ provide 2^128 addresses; it does not even come close. Ultimately, it will barely provide anything more than what IPv4 provides, if current trends continue. > 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. Or simply stop trying to define policies for an unknown future, and thereby avoid all these problems to begin with. > 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. As soon as you chop off 64 bits for another field, you've lost just under 100% of it. > Variable-length addresses only work if there is no maximum length. Ultimately, yes. But there is no reason why a maximum length must be imposed. > 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. Telephone engineers make the same mistakes as anyone else; no natural physical law imposes E.164, however. > 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. Maybe the problem is in trying to make addresses do both. Nobody tries to identify General Electric by its street address, and nobody tries to obtain a street address based on the identifier General Electric alone. > The difference is that in IPv6, it's merely a convention ... Conventions cripple society in many cases, so "merely a convention" may be almost an oxymoron. > 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. Sometimes the most important design criterion is ignorance. In other words, the best thing an engineer can say to himself in certain aspects of design is "I don't know." _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf