What about IPv6 right here on earth?

Posted Jan 26, 2011 7:49 UTC (Wed) by bojan (subscriber, #14302)
In reply to: What about IPv6 right here on earth? by tialaramex
Parent article: LCA: Vint Cerf on re-engineering the Internet

> Depends how you define "without any reconfiguration".

Like this. I have my DNS configured now. I have my DHCP configured now. I have my static hosts configured now. I have my firewalls configured now. I have my services configured now. Without touching any of that (i.e. configuration), can I talk to IPv6 hosts out there? I'm guessing the answer to this question is probably no.

What DJB pointed out is that deployment of new software on all computers in existence is surprisingly easy (in fact, it happens all the time with updates). Deployment of new configuration is hard (each admin has to figure out their new addresses, firewalls, DNS, tunnels etc.). Ergo, IPv6 should have embedded IPv4 in itself. And because it didn't, we have the current interoperability disaster where hosts with IPv4 addresses cannot talk to hosts with IPv6 addresses natively.

Sure, eventually all this will be overcome and we'll all end up being on IPv6, but the plan was not very good.

What about IPv6 right here on earth?

Posted Jan 26, 2011 8:10 UTC (Wed) by dlang (guest, #313) [Link] (15 responses)

and in case you are still missing it, the issue isn't about having a machine with an address in the first 32 bits talking to a machine with an address that's larger than 32 bits.

the issue is having a transition while everyone still has addresses that fit in 32 bits that would allow some machines to be on IPv4 and some machines to be on IPv6, all talking togeather, and it would only be as machines started to use addresses that didn't fit into 32 bits that there would be any incompatibility.

If this had been done, most of the systems out there would be running IPv6 now, and talking to IPv4. but since IPv6 was made completely incompatible with IPv4, running IPv6 became a significant effort rather than a transparent upgrade. As a result, almost nobody is running IPv6 except as a showpiece or hobby.

What about IPv6 right here on earth?

Posted Jan 26, 2011 8:48 UTC (Wed) by bojan (subscriber, #14302) [Link]

Case in point: my home network. I have to acquire an IPv6 capable DSL router. This will give me connection to IPv6 world. I also have to figure out new firewall rules, new DNS config and services configuration, so I can be found from the outside for IPv6 hosts.

I already have all this for IPv4, so doing this duplicative work is really idiotic. If DJB's suggestion was followed, my various OSes would already have been upgraded to understand 16 byte long addresses and it would just work.

PS. And I am actually interested in making a transition. Many large companies don't see anything being done related to IPv6 for the next few years at least. Simply too much hassle for no immediate benefit.

What about IPv6 right here on earth?

Posted Jan 26, 2011 16:10 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (13 responses)

OK, this has been dissected lots of times, I hope I get all these right (I am rusty)

1. IPvDlangA is deployed on some boxes. This hypothetical protocol is just 100% compatible with IPv4 so these boxes can talk directly to IPv4 boxes.

IPvDlangA is junk - it doesn't get us anywhere we weren't with IPv4 so it doesn't matter if its deployed or not.

2. IPvDlangB is deployed on some boxes. This is a very sophisticated hypothetical protocol. It uses some magic IPv4 flag bits to detect other IPvDlangB boxes and when talking to them it embeds enhanced 128-bit addresses, with the top 96 bits cleared. To transit over the IPv4 network the packets must of course all have valid IPv4 headers too.

Everybody who gets IPvDlangB sees slower performance AND less bandwidth because IPvDlangB is wasting a lot of both. So every smart individual or organisation disables or avoids IPvDlangB. No uptake.

3. IPvDlangC does protocol conversion. It probes next hop routers (good luck with that) and if they also do IPvDlangC it speaks IPvDlangC otherwise it converts every packet to IPv4 and strips 96 bits of address. When receiving packets from such routers, it adds 96 bits of zeroes, and converts to IPvDlangC.

IPvDlangC is very resource-intensive, far more than mere IP routing. It would be tremendously expensive to deploy in core systems. This expenditure will never be authorised. In terms of development effort, code footprint, attack surface etc. it's much the same as the dual-stack solution today except without any of the benefits.

Do you have more options? We can look at those too (I can't promise to be swift, I have lots of real work to do)

What about IPv6 right here on earth?

Posted Jan 26, 2011 20:45 UTC (Wed) by dlang (guest, #313) [Link] (12 responses)

in a world where people tunnel everything of HTTP, and use thing like PPPoE, the overhead of a few more bytes in the header of each packet would not bring things to a screaming halt.

you could have left the existing 32 bits of addressing where they are in the packet header and set an option flag to enable additional addressing bytes later in the header.

If you did something like this, the 32 bit addresses would route you to the ISP that handles the 'full' address, and that ISP could have a router that implemented NAT by just grabbing the bottom 24 bits of the expanded address space and using the 10/8 network with these addresses internally (or a different class A could have been allocated for this purpose)

this would have allowed the address space to be transparently extended from 32 bits to 56 bits without any existing routers needing to be changed at all (including home routers), the client endpoints would need new software to send the extended headers, and the ISPs that run out of addresses would have to have new routers to move the bits from one point in the headers to the other (which is a _very_ cheap thing to do, much cheaper than current NAT where the router needs to maintain a table of translations, time them out, etc).

systems with the new 'extended' IP addresses would have trouble initiating connections outside their ISP to endpoints that did not include these additional headers in their response packets, but all that would take is 'if you see this flag and extra info in the headers of a packet that comes to you, include them in the response', and that's a pretty simple thing for the OS vendors to do.

I'm not worried about network vendors doing this for the network gear, as that should not have to be maintained across ISPs

What about IPv6 right here on earth?

Posted Jan 27, 2011 12:21 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (11 responses)

OK, IPvDlangD, not very well specified, but good enough to dissect

First of all you've moved the legacy 32-bits from a suffix, in one corner of the address space, to a prefix. So you don't actually fix the exhaustion problem, because now there are far more addresses, but they're still all allocated to someone already. So your whole plan just wastes everybody's time. Ouch.

And your "pretty simple thing for the OS vendors to do" needs to be done in every IP stack deployed, which realistically means it needs to be in IP itself, or in one of the very early tweaks. By the 1990s it's just too late to make a difference. (IPng working groups were created in 1992 or so)

FWIW Solutions that require time travel (e.g. to go change the IPv4 standard before it was widely deployed) are cheating. Sorry, try again?

What about IPv6 right here on earth?

Posted Jan 27, 2011 18:55 UTC (Thu) by dlang (guest, #313) [Link] (8 responses)

in 1990 there would have been time to do this, in 2011 there isn't. part of this discussion is the compalints that the 'migration plan' was horrible, to which peopel are responding claiming that it's not horrible, it's the only possible way to do things. As a result people like me are pointing out things that people could do.

and the IP spec has been changed over time to include new features. there are reserved feature bits in the header that could be used to indicate the presense of these changes.

this is just plain going to be a horrible mess. there are few possible outcomes

1. we have a long period of using NAT and then move to IPv6

2. we have a long period of using NAT and then move to something else (probably at least as painful in the meantime as the move to IPv6)

3. extensive use of NAT becomes permanent

4. the internet as we know it collapses (extremely unlikely in my opinion)

What about IPv6 right here on earth?

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

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] (6 responses)

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] (5 responses)

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] (4 responses)

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] (3 responses)

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] (1 responses)

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 (guest, #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.

What about IPv6 right here on earth?

Posted Feb 8, 2011 18:45 UTC (Tue) by daniel (guest, #3181) [Link] (1 responses)

<quote>you've moved the legacy 32-bits from a suffix, in one corner of the address space, to a prefix. So you don't actually fix the exhaustion problem, because now there are far more addresses, but they're still all allocated to someone already. So your whole plan just wastes everybody's time. Ouch.</quote>

Wait, could you back up and step through that again for me? I fail to see why more addresses is not a step in the right direction, even if they are "already allocated to someone". Reallocate, maybe? Share maybe?

I'm labelling your argument "bifuraction" for the time being.

What about IPv6 right here on earth?

Posted Feb 8, 2011 23:56 UTC (Tue) by dlang (guest, #313) [Link]

by making the address space larger I allow all the entities that have IP addresses to have a lot more.

yes, my plan favors the established ISPs who have IP addresses as each IP address they currently have becomes a class A network (or larger), but in practice you have to get the established ISPs agreement anyway before you can use any IP addresses (they have to agree to peer with you and accept your advertisement), so I don't see this as a major problem

What about IPv6 right here on earth?

Posted Jan 26, 2011 12:24 UTC (Wed) by drag (guest, #31333) [Link] (7 responses)

> Without touching any of that (i.e. configuration), can I talk to IPv6 hosts out there? I'm guessing the answer to this question is probably no.

Yeah. Nobody in IPv4 can talk to you unless you have a IPv4 address. In my case I will still use the IPv4 NAT firewall for that.

But if your running commercial services then you can use a IPv4 compatible IPv6 address.

Most commercial routers besides home consumer kits have been IPv6 for a long time now. Probably most stuff sold to businesses since 2005 or so has IPv6 support. Most corporations are going to have IPv6 aware devices on their network right now. My Android phone supports IPv6 access points.

It's going to be a security issue for a lot of networks... if I use IPv6 I can bypass most restrictions in most networks. Just because your not using IPv6 on your network, doesn't mean that somebody else isn't. :P

I'd say that most corporate networks deployed in 2006 or so is probably IPv6 ready now... or nearly so. They just have to turn it on.

There are enough reasons to use IPv6 besides just the bigger IP space that people are going to look back and say "WTF didn't we do this earlier?"

What about IPv6 right here on earth?

Posted Jan 26, 2011 14:23 UTC (Wed) by bojan (subscriber, #14302) [Link] (6 responses)

I think your post illustrates what is wrong with this transition. If the transition was planned properly, your answer would have been "yes" or even "why do you ask?"

What about IPv6 right here on earth?

Posted Jan 26, 2011 15:20 UTC (Wed) by drag (guest, #31333) [Link] (5 responses)

How would it be possible for IPv4 systems to be able address a system that they were never designed to address?

What about IPv6 right here on earth?

Posted Jan 26, 2011 16:11 UTC (Wed) by bojan (subscriber, #14302) [Link] (4 responses)

You should really read DJB's text. Software would be upgraded over the years so that they could (this is how we got dual 4/6 stacks anyway). However, the existing addresses and setups would stay the same.

In other words, systems would be upgraded to IPv6 in place, with no additional configuration required. Networks, dns, firewalls, services, routers etc. would keep working as usual.

We would have had almost 10 years for all this. More than enough. Too late now.

What about IPv6 right here on earth?

Posted Jan 26, 2011 19:27 UTC (Wed) by johill (subscriber, #25196) [Link] (3 responses)

I don't think it would have happened that way -- the vendors would still have bought the cheaper router that is aware only of 4-byte address matching (in silicon).

You're assuming that it's all software, and that upgrading your stack to a hypothetical IPv6 that is fully backward compatible with IPv4 would essentially have been free. Neither of those is true. Vendors would simply have offered to sell new, improved revisions of their existing, "legacy", IPv4-only devices -- without adding the more expensive silicon that is aware of the new, longer address matching.

What about IPv6 right here on earth?

Posted Jan 26, 2011 22:18 UTC (Wed) by bojan (subscriber, #14302) [Link] (2 responses)

> I don't think it would have happened that way -- the vendors would still have bought the cheaper router that is aware only of 4-byte address matching (in silicon).

And that's fine. If they don't want to route new, IPv6, hosts. Ever.

However, people connected to their network would automatically start asking for this routing. Because they would already be on IPv6. Without doing anything. Any new host they wished to access that had a real IPv6 address (i.e. not legacy IPv4) would be out of their reach. This would create a lot of complaints (hey, my friend can see this cool new site and I can't), which would either get rid of idiotic ISPs or force them to upgrade. Without the need to tell customers that they need to do something special to see IPv6 hosts.

What about IPv6 right here on earth?

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

They would "start asking for this routing" ? Like they're asking for IPv6 right? Even better, why should I care that Joe Blogs on the other side of the world wants me to spend millions of dollars upgrading my network? He's not _my_ customer.

What about IPv6 right here on earth?

Posted Feb 3, 2011 14:43 UTC (Thu) by farnz (subscriber, #17727) [Link]

We already have the situation you're discussing - I have today's IPv6 and IPv4, and can get to any cool sites that exist on IPv6 only.

Problem; there are no cool sites that are available on IPv6 and not IPv4. The reason? If I'm available on IPv4, close to 100% of my target market can get to me; if I'm not, only a tiny fraction of a percentage point can get to me. The economics are simply not there; in your hypothetical "IPv4++" world, the idiotic ISP would respond with "you need to do this very complex thing (at least as complex as deploying IPv6 is in today's world) to get access - it's the site's fault for using IPv4++". Net result? Everyone continues to use plain IPv4, ignoring the extended addresses possible in IPv4++, because you haven't solved the chicken and egg problem.

Note also that thanks to buggy systems, it's not safe to dual-stack your hosts by default. There are machines out there which think they have working IPv6 routing, but don't - about 0.1% of Google users last time I looked for the figures. So, real world experiments tell us that even co-existence of two protocols doesn't work properly; this leads to a thought experiment. How exactly does IPv4++ handle the case of two IPv4++ hosts with an IPv4 only segment in the middle, such that you can successfully talk IPv4 but not IPv4++?

Any answer that assumes that IPv4++ can transit the IPv4 segment has failed already - IPv6 can transit over IPv4 segments, yet we still see brokenness. Any answer that implies that an IPv4 only host cannot distinguish IPv4++ traffic from traditional IPv4 traffic has failed already - the most common form of brokenness in the IPv6 world is IPv6 in IPv4 tunnelling, where the IPv4 network deliberately blocks protocol 41, and there would have to be some similar indication that this is IPv4++ traffic.