Hacker News Reader

Comment by voidmain | Hacker News Reader

Assign 2^96 addresses to each IPv4 address. The original address is now a.b.c.d.0 and there are lots more a.b.c.d.x. When sending a packet over an IPv4 link, translate packets with .0 destinations to v4 packets and embed others in a special v4 protocol. When receiving a packet do the reverse. Now you need a v4/.0 address only if you are directly connected to a v4 peer, and an upgrade is useful even for a single computer behind a NAT.

I came up with this idea in like 5 minutes so I'm sure it is flawed. But i think that if we had a realistic design we could have been done with the transition in early 00s.

View on HN

It's actually not that flawed, you've more or less invented 6to4. Every v4 address has an associated v6 network (basically 32.2.a.b.c.d.*), and you can send packets to that network by crafting packets that use protocol 41 ("6in4"). It only gives 2^80 addresses per v4 address but that should be enough for anybody.

But uh... it doesn't seem to have helped as much as you're thinking.

Also, you didn't address how v4-only devices or software would talk these bigger addresses (how can you fit >32 bits into a sockaddr_in struct?). That's one of the big difficulties of v6 deployment and it won't go away no matter how you design v6.

The key point is that all v6 addresses are owned by v4 addresses and therefore tunnelable, and that tunneling support is mandatory. There is no external prereq to having an individual device be able to open connections to v6 addresses, and only support at the router (with a public address) is needed to receive connections from any v6 address.

There is no way around upgrading end devices. But the problem with v6 adoption isn't the number of end devices from before 1995.

Basically the adoption plan could have been:

1. Get end OSs to have v6 support. They gain the ability to make outgoing connections to v6 addresses right away. There's no reason, from the beginning, for this not to be enabled by default with zero configuration from the beginning.

2. Get NAT routers at the edge to have v6 support. Gains the ability to publish services from inside without awkward port forwarding etc (and increases the benefit of 1)

3. Slowly make v4 addresses expensive so that consumers make do with less than a /32. They need v6 capable endpoints but can communicate as clients with anyone, and as servers with anyone who has adopted v6

4. Eventually v4 addresses are so expensive, and the number of machines running browsers that don't support v6 so small, that small time web sites stop taking a /32

etc. it doesn't really matter when the network backbones upgrade, it just saves a few bytes on the wire and they internalize the cost of that

This just doesn't seem like what happened in our timeline.

Tunnels cost money to run. In Step 3 the companies that own IPv4 addresses have even more reason to pass those costs directly on to their downstream consumers, plus a little extra to earn a bit of profit.

IPv4 address owners get to be landlords collecting rent on anyone downstream. It benefits those with massive early IPv4 allocations and few other people.

In that case there seems like less reason to upgrade major network interconnects from v4 because that would "ruin" some IPv4 landlord's "rent" (and profit).

It only takes a few v4 addresses to make enough v6 addresses for everyone, so there is no long term rent once all edge devices are v6. v4 addresses being temporarily "rentable" helps push the system towards that end goal (because the key is to fix the edges, and the edges are the ones getting screwed paying for v4 addresses if they want them). It doesn't matter if major interconnects upgrade - if they want to shuffle v4 packets tunneling v6 packets, and have enough addresses to do it, it's their problem.

I still think there are technical flaws in my proposal - for example, probably the tunnel should use udp so that it can traverse totally clueless NAT - but I think the basic idea of trying to upgrade the edges while fully interoperating is incentive compatible in a way that the idealistic v6 approach just isn't.

We have CGNAT and NAT46 and NAT64 and all sorts of tunnels today. It doesn't take a lot of current experience to imagine how much a v6 dependent on v4 and tunneled through v4 solution feels bad for the edges.

The problem with IPv6 deployment has never had anything to do with lack of tunnels, "temporary" or otherwise, we've had that technology all along.

It does matter if the major interconnects upgrade. We've got decades of data now if you want to science it.

In your scheme if you aren't mandating every v4 address be a NAT "forever", then you've at best got huge sections of "dark" addresses that can't properly be used without some traffic accidentally blackholed. If you do mandate it you run the risk of bad actors taking advantage of it and toll bridging the chokepoints at the tunnels. (Which is also in theory a massive man-in-middle security risk.) Either way you are locked into the whims of IPv4 address owners and the mistakes of past IPv4 allocations (including all the early /8s that went to big companies just because they asked the right year and the fact that the large continent of Africa has never had anywhere near enough address space, and a fraction in comparison to Europe and the Americas).

I really don't see the economic incentives that would have made that addressing system better than the IPv6 we got, but I certainly see a lot of them that would have made things much worse.

Reply on news.ycombinator.com