What about IPv6 right here on earth? [LWN.net]

What about IPv6 right here on earth?

Posted Jan 27, 2011 22:49 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

You're entitled, in this context, to explain what could have been done during IPng (which began in 1992). Just not to go back and fix IPv4 so that it makes your job easier. Otherwise "obviously the addresses should have been wider from the outset" is the tedious answer to everything (except maybe "would IPv4 have still taken off, with such baggage?"). Any time estimates should be real world, so for example, having begun planning in 1992 you will be too late to make an impact on the project Microsoft are jokingly calling "Windows 93" and which will eventually ship as Windows 95.

Surprisingly little has changed in IP, except in cases where two peers can identify that the other implements some newer feature. Most of what gets done in the stacks is optimisation, taking advantage of features that exist in the specification already. And sometimes even that fails - just because the specification says you can do something, does not mean it always actually works in the real world. Life is full of disappointments.

Yes, there will be a mess. That is not a new observation. We have no useful prior experience to judge exactly how big the mess will be. Some of the things we've been doing to try to give ourselves more time will, as with NAT, contribute to the mess.

FWIW Options 1 and 3 are the only ones that look reasonably likely. Option 3 is really bad, but only in the same way that widespread private ownership of motor vehicles was really bad. It didn't bring about the end of civilisation or anything, and it made our culture what it is, for better or worse.

Option 2 basically won't happen NOW (even in the unlikely event you can come up with a better alternative in our "What if?" scenario) because it would be too late to the party. Achieving even IPv6's tiny penetration will take an alternative decades.

Option 4 won't happen because people like captioned images of kittens. An expensive, inefficient network that continues to deliver cat pictures is still enough to keep the lights on at the ISPs. I'm being flippant, but millions of people are now used to having this service and paying for it. Address exhaustion doesn't make that demand go away. Of course "as we know it" could be construed to include Option 3 in some ways. A network without end-to-end is not the Internet we thought we knew and loved.

What about IPv6 right here on earth?

Posted Jan 29, 2011 7:48 UTC (Sat) by butlerm (subscriber, #13312) [Link]

I think you are forgetting option 5: Everyone gradually comes to the realization that abandoning the IPv4 numbering plan and network configuration on a global basis is never going to happen in this century, so the IETF goes back to the drawing board and designs an IPv4 upgrade that is compatible with those addresses. Something like TP/IX, which was proposed by Robert Ullman in 1993, nearly a decade before DJB made the same argument. See RFC1475.

Then NAT reigns supreme for several years while this IPv4 plus protocol gradually disseminates through software and hardware upgrades and ten or so years later the extended IPv4 plus addresses are actually routable across the public Internet.

What about IPv6 right here on earth?

Posted Jan 29, 2011 15:08 UTC (Sat) by cesarb (subscriber, #6266) [Link]

Isn't that the same as option 2 (a period of NAT followed by a move to something which isn't IPv6)?

What about IPv6 right here on earth?

Posted Jan 29, 2011 16:53 UTC (Sat) by butlerm (subscriber, #13312) [Link]

I guess so. It is just that so few people would know that this "move" was actually occurring, that it wouldn't be much of a move at all. More like a silent transition.

I like a plan where a.b.c.d address format is changed to an administratively compatible format where each of the four components is a 16 bit number represented in text format in decimal form.

In binary form the IPv4 address C0 A0 20 01 would become 00C0 00A0 0020 0001. All existing address prefixes would be preserved, except in expanded form when represented in binary. In text format the address would be 192.160.32.1 in both cases. Then one day about ten years later, addresses like 300.278.22.1 would become publicly routable. Or even addresses like 6700.45320.658.33781.

A straightforward expansion would allow a variable number of components where the number varied from 4 to 8 or so. That way everyone with an IPv4 style 4 component address could add publicly addressable sub networks without getting a new allocation. The network core would generally only do routing on the first four components (64 bits) for economic reasons, but hardware routers with 128 bit prefix capability would eventually be come common, starting at large edge networks. Trailing zero bits would be implied.

Existing configurations would be preserved, although alternative netmask indicators would eventually have to be added, because a current "/24" would in actuality be a 48 bit prefix, and if you want to specify netmasks that end on any of the inserted bits a different syntax would need to be used. "//48" style perhaps.

One of the other advantages of a variable length addressing scheme like this is that most addresses would only be 64 bits, not 128, significantly reducing the overhead for small packets like those used in VOIP, especially on lower bandwidth connections. Who really wants their MAC address broadcast all over the Internet anyway? For servers, it is practically useless. For individuals it is a privacy nightmare.

TP/IX and similar plans

Posted Jan 30, 2011 15:15 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

You can't make things compatible by sheer force of will. TP/IX isn't really compatible with IPv4, the RFC leaves you in no doubt whatsoever about that if you ignore the repeated but unfounded assertions to the contrary. The "compatibility" advertised for TP/IX is the same compatibility delivered by dual-stack, in fact it _is_ dual-stack by another name. Everyone must speak both protocols if they want to participate on the Internet.

It's a huge sprawling mess, far more invasive than the eventual IPv6. I can only say that I'm indebted to whoever persuaded its author that his entirely new routing protocol and algorithms deserved their own "informational" RFC alongside this one, so that people asked to read about one needn't waste their time reading the other.

The economics (remember, that's why IPv6 has a fraction of a percent of penetration, rather than say 80%) are if anything worse. First you must get enough people to deploy "version 7". Your ten year estimate seems optimistic when you realise that although this costs a lot of money it delivers no immediate benefit whatsoever. Far more so than deploying IPv6 today, deploying "version 7" would have been a leap in the dark, trusting that some day we'd get the wider addresses working and it would be for the best. But then they must upgrade _again_ to have wider addresses. In fact they might have to do so repeatedly.

Ullmann's plan reserves 75% of addresses, rationalising that they can be used if the initial proposal turns out to be a bad idea. A similar strategy was chosen in IPv6. But Ullman reserves the wrong bits. An experienced engineer would know that if you leave the top few bits empty, some clown will either use them for a purpose you didn't intend meaning they can never be put into production, or they will confuse signed and unsigned terms and drop the top bit, again rendering it useless in practice. IPv6 was careful to use those top few bits for something obligatory, so implementers would notice and correct such bugs. [ For another example look at the way x86-64 handles virtual addresses ]

There are also numerous technical errors in the specification. e.g. Like some earlier LWN comments it assumes that DNS records are just arbitrary text strings so changing to a system where 'A' answers are sometimes too long for IPv4 is fine, everything will just work. Leaving aside the naivety of imagining that no-one would inadvertently rely on something that's been true for as long as the system has existed the simple technical answer is: No, can't do that, DNS unambiguously defines A records as exactly 32-bits. Hence the existence of 'AAAA' records.

TP/IX and similar plans

Posted Feb 5, 2011 16:46 UTC (Sat) by butlerm (subscriber, #13312) [Link]

First, no one would have to dual stack. Same stack, larger address space. Routers would do wire format conversion where necessary. Second, technical errors in the TP/IX RFC have no bearing on the merit of the principle described. The IETF was just incredibly short sighted on that point, preferring a start over from scratch design to one where the transition would be practically seamless.

In short, the counterargument here has to be not against the weaknesses of a seventeen year old network proposal per se, but rather against the entire idea of preserving the existing address space on a long term basis without renumbering.

TP/IX and similar plans

Posted Feb 9, 2011 14:21 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

"Same stack, larger address space"

Reality isn't interested in proof by assertion, if I call a frog a bird it will not make it fly. TP/IX is a completely new stack. "Just" widening the address field (which is not what TP/IX does) is like "just" adding an extra floor to the middle of every house in the country.

"no one would have to dual stack"

"routers would do wire format conversion"

Do you even read what you're writing? In order to "do wire format conversion" the routers not only need to have both stacks, but they have to be able to convert from one to the other, a major additional expense. Worse, for TP/IX (and any alternative I can imagine) this is stateful. So the plan becomes "instead of buying an expensive IPv4 and IPv6 router, buy an even more expensive IPv4 and TP/IX router-converter" and you've made things worse, not better.

"technical errors in the TP/IX RFC have no bearing on the merit of the principle described. The IETF was just incredibly short sighted"

Of course, how stupid of me. It doesn't need to actually work, someone who needs things to work is being "short sighted". I can't address problems in a non-existent alternative and neither can the IETF.

Fortunately thanks to such "short sighted" people we have a plan, not a painless or easy plan, but one that will work. Now it remains to be seen if everyone will implement it, and how long that will take.

TP/IX and similar plans

Posted Feb 9, 2011 17:21 UTC (Wed) by daniel (subscriber, #3181) [Link]

<quote>DNS unambiguously defines A records as exactly 32-bits. Hence the existence of 'AAAA' records</quote>

For the proposal at hand, which as I understand it is to extend the IPv4 address space by 16 bits on the right, an 'AA' record will do and only needs to be implemented at the edges of the classic IPv4 space. In other words, at points under complete control of participants in the experiment.

An 'AA' record would sensibly be defined with the classic IPv4 space in the middle four bytes, the IPv4++ bytes on the right, and the two remaining bytes on the left reserved for future expansion.