Should distributors disable IPv4-mapped IPv6?

Posted Jun 8, 2016 23:00 UTC (Wed) by nybble41 (subscriber, #55106)
In reply to: Should distributors disable IPv4-mapped IPv6? by paulj
Parent article: Should distributors disable IPv4-mapped IPv6?

I understand what you're saying, and even agree that making IPv6 addresses an extension of existing IPv4 addresses might have had certain advantages—in the short term. However, in most respects it would fall well short of the overall goal of modernizing the IP protocol. Maintaining compatibility with existing core routers (including their brain-dead mishandling of non-standard protocols and option extension) would have kept us stuck with something like IPv6-over-UDP-over-IPv4 indefinitely. Not only would it be impossible to raise the minimum MTU to 1280 bytes, it would have been necessary to reduce it further relative to IPv4 due to encapsulation overhead. Moreover, it would mean inheriting the fragmented IPv4 routing tables; even upgraded, native-IPv6-capable routers which never handle IPv4 traffic would need the same bloated tables used to route IPv4 (made even worse by longer addresses) rather than the much smaller tables made possible by the separate, hierarchical IPv6 space. The fragmented prefixes could be expected to linger on long after the last IPv4-only router was excised from the network.

And in the end all you get out of this scheme is the ability to avoid upgrading a few core routers to handle the new protocol natively—you still have to update all the endpoints and application software, and place dual-stack routers at the border of each IPv6 "enclave". In other words, most of the actual hard work that's held up IPv6 adoption would remain unchanged.

In terms of actually getting everyone to move to using the new protocol natively, without tunneling via IPv4, I think IPv6 has been rather successful. More so than if significant compromises had been made to retain compatibility with IPv4, at any rate.

> Existing mapping/rendezvous services (e.g. DNS) do not need anything fancy, other than to be able to support the new format of address.

This is exactly what was done for IPv6. Support for new addresses takes the form of AAAA records. "A" records with longer addresses would not have been any different from a technical point of view, and reuse of the name would just have created confusion given the necessarily incompatible binary format.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 9:42 UTC (Fri) by paulj (subscriber, #341) [Link] (10 responses)

"might have had certain advantages—in the short term.", like being useful and deployable before complete v4-address-crunch /forced/ upgrades? :)

AAAA is exactly what I was referring to as the straight forward approach. Note that things like 6to4 require /more/ than just DNS in order for IPv6 hosts generally to be able to communicate with each other. Because of the two different types of address space, 6to4 requires an additional special service to allow one class to reach another. Because one class of the 'new' address space (the non-6to4 space) has no connection at all to the 'old' there is no function from labels in that 'non-6to4' space to a routing label in the 'old' space. And because of that you need a special route and special mapping routers, and commercial interests in providing these things don't align (a provider interested in IPv6 will deploy the 'non-6to4' space and may not bother with relays for customers). So the whole things becomes a whole lot less straight-forward than just using simple-extension of existing address databases, using the address found, and *any* router later being guaranteed to be able to carry out a trivial f(IPng-ID) -> (IPv4 routing label) function based solely on the packet header if needs be and re-use existing routing tables to forward...

But hey.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 9:49 UTC (Fri) by farnz (subscriber, #17727) [Link] (9 responses)

You don't need the special service if you already have IPv4 of your own - it's a trivial configuration on a dual-stack router to route 6to4 over IPv4, and to route native over IPv6. The special service (the anycast relay) existed to allow people without legacy addresses (and thus legacy routes) to route to people using 6to4.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 10:42 UTC (Fri) by paulj (subscriber, #341) [Link] (8 responses)

In a world where the primary transition strategy was to assign 'new' labels from a space completely disconnected from the 'old', and then later bring in 'new' labels that were connected to the 'old', the relays and the inefficient routing (terribly so, given the old space is dominant) are unavoidable, between the two types of 'new'.

Can routing between 'new extended from old' and 'new disjoint' be efficient if you have fully native networks between them? Sure! Routing between them over 'old' networks sucks though, especially while the 'old' network is still relatively large.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 10:47 UTC (Fri) by farnz (subscriber, #17727) [Link] (7 responses)

The relays are completely avoidable. If I have native IPv6 and native IPv4, I can add an additional 6to4 address to my service, and then I'm using (as per RFC 3484) 6to4 to people who are only doing 6to4 thus far, and native IPv6 when I'm communicating with people on native IPv6.

Even if I don't want to go that far, if I, as a dual-stack user, put in a 6to4 special route at the v6v4 router, I only pass through a relay when a 6to4 user tries to contact my IPv6 address not knowing what my IPv4 address is. Once I've responded once, they've got a cached route via the 6to4 direct mechanism that they can use.

And again, if this is so important to deployment, why didn't it happen? Why hasn't any significant IPv6 service advertised both native and 6to4 addresses, so that I can use routing over IPv4 if I have no native IPv6?

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 10:53 UTC (Fri) by paulj (subscriber, #341) [Link] (6 responses)

Again, 6to4 is crippled by the fact the primary transition strategy was to build a logically new Inter6net. Because of the existence of pre-existing non-6to4 new space, it started out facing sucky, inefficient routing to that space - and no one wanted to use it.

I can fully understand why no one wants to build stuff on 6to4.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 10:59 UTC (Fri) by farnz (subscriber, #17727) [Link] (4 responses)

But I'm not talking about building stuff on 6to4; I'm talking about doing the bare minimum to give 6to4 users an efficient way to route over IPv4 to you, instead of over native IPv6.

Obviously, in the current deployment, native is better if you can get it - but if routing over v4 is so important, why is nobody doing anything to make it even possible for people to use 6to4?

I suspect the answer is that if you have native IPv4, but no native IPvN, there's always a penalty (no matter how slight) for using IPvN instead of IPv4 - so the only people who care about IPvN are the people who can't get decent native IPv4 connectivity. In turn, these are the people who cannot make IPvN over IPv4 routing work reliably - they have no access to the IPv4 routers. And so, you end up in a situation where no-one can be bothered to deploy, because there's no reason to for as long as IPv4 works for you (while there em is a cost to IPvN connectivity, in terms of the increased threat surface if nothing else, thus encouraging people to block IPvN).

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 12:21 UTC (Fri) by paulj (subscriber, #341) [Link] (3 responses)

"why didn't it happen? Why hasn't any significant IPv6 service advertised both native and 6to4 addresses"

That read to me like an argument rooted in the "completely logically-new Internet as primary transition strategy, later 6to4" world. And :

"but if routing over v4 is so important, why is nobody doing anything to make it even possible for people to use 6to4?"

You're having a completely different argument to the points I made. I don't disagree at all that 6to4 sucks in the world as it developed. Indeed, that's fundamental to my argument! 6to4 sucks *BECAUSE* of the chosen primary transition strategy, which meant there was a significant disjoint v6 space, meaning you could never get good routing in v6 generally using the extension approach. Which led to much unhappiness, even with 6to4.

Never the less, many people *did* do it - they got "disjoint space" v6 connectivity via tunnel brokers, even before 6to4 (intrinsically going to suck). It was the 'cool' thing to do amongst the circle of networky geeks I knew in the early 00s anyway - as part of getting ready for the imminent IPv6 utopia (which I was a devoted believer in back then).

So, if you want to seriously discuss this, stop referring to arguments based on how things work when there's a large chunk of disjoint 'new' space. Cause, no argument there - extension then sucks. Let me quote one of my earliest comments in this article again, and highlight it:

"No, *6to4* is not an 'extension' approach. It's *the intrinsically inefficient and problematic* "bridge-the-gap" transition mechanism you're left with *once you have created a second Internet address space that is completely divorced from the existing* and (still, to this day, /decades/ later) dominant address space."

I am *fully* aware of how 6to4 sucks and why it was unattractive.

And again, if you don't believe extensions are possible, note that the Internet - *en masse* - *CHOSE THE EXTENSION APPROACH*. Faced between the 'clean' way of IPv6, and the horrid, backward way of IPv4 PNAT, the Internet went with PNAT. Except, large networks have exhausted even the extra bits that port space gives (which is effectively less than 16 due to TCP timeouts and other practical considerations). So now, now that IPv4 really is completely out, and we use so many apps that even the crappy-extension approach of "CG"-PNAT stops working for large providers, now we're seeing some non-trivial IPv6 at last.

Success? Really? :)

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 12:35 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

And my argument, which you are consistently and dishonestly misrepresenting, is that the problems with 6to4 that I faced between three hosts under my control are emblematic of why no extension approach that requires support at more than one point in the network can succeed. If I can't reliably operate any extension method between three hosts that I'm willing to make arbitrary changes to in order to make it work (short of treating IPv4 as a wire, and running something like L2TP over it), what makes you think that it'd work better if that was the only option?

PNAT is not an extension approach - it's a way for a network to unilaterally expand, whether or not anyone else in the ecosystem wishes to co-operate with them; there is no way for you to tell whether 81.187.250.192 is a NAT router, or a host, from the information I'm giving you here.

While 6to4 is not an extension approach, many of the problems people face with it are exactly the same problems you would face with an extension approach; if 6to4 had succeeded, while native IPv6 was still taking ages to roll out, then I would be less skeptical of your claims.

And, FWIW, I believe that faced with the choice of IPvN, or NAT44, people would still choose NAT44 - everything that works in pure IPv4 can be made to work in a NAT44 world, while there are immediately hosts that are inaccessible if you try to grow with IPvN. As long as NAT44 enables you to grow in the IPv4 world, ignoring end to end comms, you have zero incentive to do anything to go to IPvN - after all, if I'm on IPvN only, but LWN.net is still on IPv4 only, there's no way for me to communicate with LWN, other than NAT44, and if I have to have NAT44, why would I do the extra work to have IPvN too?

And yes, success, really. IPv6 rollout is taking about the same amount of time as IPv4 rollout did, and yet IPv4 gave people entire new capabilities that did not exist before they moved from pre-IP protocols to IPv4. We've got another 5 to 10 years before IPv6 is slower than IPv4; and they're both rolling out faster than the replacement of in-band signalling with out-of-band signalling in the PSTN.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 13:41 UTC (Fri) by paulj (subscriber, #341) [Link] (1 responses)

PNAT uses additional bits from beyond the original IPv4 header for routing purposes. That makes it something of an extension approach. A very limited and poor one, for various reasons, but still... using additional bits... from beyond the original IPv4 header... to make routing decisions at intermediate nodes to route packets to hosts that do not/can not have distinct labels in the 'old' space.

"While 6to4 is not an extension approach, many of the problems people face with it are exactly the same problems you would face with an extension approach; if 6to4 had succeeded, while native IPv6 was still taking ages to roll out, then I would be less skeptical of your claims."

My issue is some of the problems you've listed are problems caused by the pre-existence of the disjoint v6 address space. Which is exactly congruent with my point. The existence of that disjoint space creates routing problems for extension approaches. That's a mathematical fact grounded in the theory of routing in graphs.

Had we gone with an extended space first, that would have allowed the new protocol to gain a foothold much more easily, because it could have re-used the existing routing state of IPv4. The 'new' packets would have been routable across IPv4 networks just as PNATed packets and 6in4 packets between 6to4-space v6 hosts are. With that foothold, it would have been much easier for applications to use IPv6. We needn't have had OS vendors de-prefer v6 addresses to v4 ones in SAS algorithms, cause if v4 was working then 'new' should have worked too - routing wise at least. Native links and native routing might have been easier to justify building earlier as there'd have been more applications using v6. The natively routed 'new' network would perhaps have been bigger with exhaustion, and so any relays needed post-exhaustion would have been closer to the networks actually dependent on them.

I'll grant you middle-boxes and the difficulty of getting new protocols across the modern Internet however:

1. This problem was a lot less worse in the mid-90s than ten years later. Had an extension approach via an IPv4 protocol been baked into RFCs in 1995, it may have fared a lot better than an IP pre-amble which is inconsistent past the first version field and completely unforwardable by 'old' hardware, and even 'new' hardware that hasn't been configured to be part of the logically new Inter6net.

2. Even if 1 was an issue, you still can just use an existing IP protocol, e.g. UDP have a normal looking UDP header before your extension. E.g., you can just dual-specify the UDP source port as the flow-label for your extension header beyond (so you don't need another flow-label; as a number of other IPv4 encapsulation protocols do, e.g. VxLAN).

3. Even if 2 is an issue, cause UDP is blocked, you can still use TCP. And there are TCP extensions to be able to use TCP in a data-gramme mode precisely of this issue.

Is that aesthetically pleasing, no. It might have been more pragmatic though.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 13:58 UTC (Fri) by farnz (subscriber, #17727) [Link]

PNAT is a local-only approach - my use or not of PNAT is transparent to the Internet at large, as long as I control the PNAT I sit behind. With 6 billion people, and only 4 billion IPv4 addresses, this is not an approach that scales out, as not everyone can control their own PNAT (hence CGNAT).

I have consistently cited two problems with 6to4:

In the presence of the public networks I used between 1999 and 2004, traffic other than protocol 1, 6 and 17 was dropped, apparently at random, as was traffic with IP options, and TCP reassembly took place on some connections (meaning that you can't use TCP in datagram mode, because the packet boundaries change). This makes any extension approach a non-starter - you have to treat UDP/IPv4 as a wire to get past the router ACLs I was facing. Once you're doing this, you gain very little from making the address space inside the wires a derivative of the address space on the outside - just as there's very little gain from mandating that your network card's MAC48 or EUI-64 is part of all addresses that you use on the wire.
If I have a choice of old, well-understood protocol, and new protocol, human nature is to block the new protocol until there is a reason to unblock it. This is a catch-22 for any global expanded address space, regardless of how you do the expansion, because, given an IPvN that used a VxLAN style header, the same admins who block protocol 41 traffic will also block IPvN traffic. Until such point as there's something they can do with IPvN that they cannot do with IPv4 (and NAT44 means that "more addresses" is not enough for anyone but the biggest users of IP space), they will maintain that block.

An extension header does not address either of these problems; instead it addresses a problem that I don't think we faced (that of convincing networks that don't filter traffic to pass IPvN traffic - you could already run 6to4 or 6in4 tunnels over those networks, and 6to4 tunnels even had autodiscovery of endpoints). I think the deeper problem is that IPvN, no matter how you do it, is a solution to a non-problem for the majority of networks, and (definitionally) creates new potential problems (even if all it does is permit traffic through that an IPv4 only IDS or firewall did not properly inspect).

I don't see how making IPv4 space a strict prefix of IPvN space solves either problem; arguably, the extension method makes it worse, by making it more probable that people have actual security incidents traceable to not correctly blocking IPvN when they need to, thus triggering early overblocking.

Should distributors disable IPv4-mapped IPv6?

Posted Jun 10, 2016 17:51 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> Again, 6to4 is crippled by the fact the primary transition strategy was to build a logically new Inter6net.

Let's say I agree with you on this point. The reason for this is not that the designers of IPv6 were stupid or short-sighted, it's that they didn't want tunneling over UDP/IPv4 to become entrenched as the new de facto standard, which is the logical end result of the address extension approach. End-to-end connectivity was not the only problem they were trying to solve. That's why 6to4 tunnels were positioned as a temporary transition mechanism and not a long-term solution. Extending IPv4 addresses in a way compatible with IPv4-only core routers would have made something like 6to4 an essentially permanent fixture, which would lead to suboptimal routing and stand in the way of various other efficiency improvements.

Basing the IPv6 address space on the massively fragmented IPv4 space would have been a major mistake in the long term, even if it initially resulted in faster adoption. The only practical way to fix the fragmentation issue was to start over from scratch.