Hacker News Reader

Comment by hackthemack | Hacker News Reader

I think this is the kind of the topic that can be endlessly debated because you can not easily go back in time and test out alternate hypothesis. I will say that I do not like ipv6 because it tried to fix multiple accumulated problems. I know! How contrarian! How can you be against trying to fix things. But all of those issues made ipv6 a dual stack solution that replaced ipv4.

Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization.

Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized

Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).

View on HN

> keeping backward operational compatibility

It is not possible to be backwards compatibility with a larger address space

And yet 50% of the internet is using CGNAT just fine. The extra bits are just in a different place.

Yes, but CGNAT is an inherently stateful system and as a result will always be more expensive to operate per packet than a stateless router. The reason we are seeing steady (if slow) growth in native IPv6 is because the workarounds for IPv4 exhaustion cost money, and eventually upgrading equipment and putting pressure on website operators to support IPv6 becomes cheaper than growing CGNAT capacity.

You are right that a 32 bit ipv4 stack can not understand a 64 bit packet format. The thing I am trying to get at is not native compatibility, it is operational compatibility via translation. I know, I know, you will probably say that is what ipv6 bridges do.

But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.

Your proposal (translation) is addressed as point 3B in the article.

I went and re-read point 3B. I agree that some hypothetical ipv42 faces a translation problem.

But it does not follow that address design is irrelevant. The structure of the address space directly determines whether translation can be stateless and alogrithmic.

In a hypothetical ipv42 design that preserves a deterministic embedding relationship between old and new addresses, translation at the edges could be largely stateless and mechanically reversible, to reduce coordiation overhead between operators and it makes reachability more predictable.

In our world ipv6, the transition seems to require a mix of dual stack, nat64, dns64, tunneling aproaches. The mapping between ipv4 and ipv6 is not uniformly deterministic across all deployment contexts.

Also, there is just a human factor. The mental gymnastics that go on. The perception of what is the way forward? With ipv6, it feels like everyone has to go get their ipv6 stack in order. With a hypothetical ipv42, where the ISPs and backbone providers can throw in the translation layers, it feels like, to me, they would have gotten on board much more quickly. Yeah, I know, it is just a feeling.

I agree with you about the embedded addresses, and I don't understand why the space was moved to all zeros to a bunch of other mappings.

but the utility of this isn't that high. we already know how to handle 4-4 and 6-6 traffic just fine. but if a 4 host wants to talk to a 6 host, it just doesn't have the extra bits in order to describe it, so this just doesn't facilitate 4-6 endpoint communication at all. this is true even you substitute v6 with any other layer 3 with a larger address space.

where it does help is in a unified routing backbone, that would allow v4 prefixes to be announced in the v6 routing system. which is arguably useful.

> But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space

IPv6 supports that, but it ended up not getting used very much.

See https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...

I remember reading about that a long time ago. I wonder why it never really caught on?

I think part of the problem is not so much a technical one, as a coordination issue. Who are you more likely to get on board? ISP and backbone providers. What is the path forward? Here is the recommended path forward, kind of thing.

I don't see how it matters we forced people into ipv6 as well. Who cares. It's more about the difference in mental models that prevented adoption especially among those who run the services that are on the internet.

We have that, it's called ipv6. A section of the v6 address space is sectioned off to hold all v4 addresses

The embedding I believe you are referring to is not a part of the global routing model. (maybe I am wrong?) What I am describing is making that kind of declaration central to the system in a deterministic, network wide mapping of ipv4 to the larger ipv6 space. The translation in ipv6 ended up being handled by a mix of mechanisms after the fact, rather than a single, uniform mapping model that tied directly to the address structure. I think part of the problem is they did not put that front and center, at the beginning, when doing the initial specification.

How would an embedding handle the other 99.999999999999% of addresses not embedded?

At least at first, you wouldn't, you'd embed all of them. Cloudflare has 1.1.1.1, so they get 1.1.1.1:: too.

Not doing that was one of the key points of starting fresh with IPv6. Doing that would mean that you could end up with billions of routes to consider.

One reason for large address space is that those with networks could be placed sparsely and left room to grow. Thus allowing less routes in general.

Indeed doing it this way would keep the fragmentation, or at least delay fixing it. That's what these articles always overlook, the goal of ipv6 wasn't to just add more bits, it was also to defrag the routes.

I think instead of 1.1.1.1::, you could do 4:1.1.1.1::, wait for v4 to be gone, then start building new topologies in the other /8s. Not sure how hard that is, but it seems easier than what they're trying to do now.

Would it help at all? You can't just send IPv6 packets down the equivalent IPv4 path because that bext-hop router probably xoesn't understand IPv6 packets. In fact there could be no IPv6 path at all between you and the destination, so knowing where they are still wouldn't help you forward packets. If it understood them, it would have given you an IPv6 route anyway. Updating BGP to support IPv6 routes wasn't an actual problem.

There are lots of services I can't send v6 to, not because some router in the middle only understands v4 but because the service operator decided not to deal with v6.

So the idea is to surreptitiously install software on the service operator's machines that they can't disable?

It's already a bit like that, but they can and do disable it. You can see the other comments in this thread: many people disable IPv6 upon any sign of a networking problem.

No, the idea is you can turn v6 on/off, but doing so only changes the packet format and nothing else at first. There's no separate place to configure v6-specific settings because there are none. You use the same address, routes, DHCP, NAT, DNS, etc as v4, but you're limited to 32-bit addrs at first. The point is to just get people off v4.

Once v6 has reached enough adoption, you can turn off v4. Those who want to keep the addrs from v4 can, except now they get way more addresses under those too. Others can start building a clean new topology under the other prefixes without worrying about compatibility.

I don't see why anyone would change all the bits you actually need to change for some nebulous future gains. Still have to deal with new sockets and new routing decisions at least. To not really gain much from new features.

To me it looks like something that would have gained nearly no actual adoption outside some toy examples. Later you will need to anyway get new DNS, DHCP(or alternative) and so on.

That's a legit concern. If that's not interesting enough to the kind of user that wants all-new v6, instead start from today where some users are on the new v6 network, and say they added the 4:: prefix as a way to pick up the kind of user that doesn't want to change much. They'd still be compatible eventually. Though the reason I was thinking 4:: from the start would've been attractive enough is, a lot of people did use 6to4 and other halfway measures despite having no immediate gain.

Today's DNS6 DHCP6 etc are totally incompatible with v4. 4:: buys backwards-compatibility. Each can be updated to support longer addrs without caring whether you use it with v4 or v6.

> At least at first, you wouldn't, you'd embed all of them. Cloudflare has 1.1.1.1, so they get 1.1.1.1:: too.

Everyone with an IPv4 address automatically got an IPv6 allocation:

> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.

> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.

* https://en.wikipedia.org/wiki/6to4

What does it mean to have an /48? Well, a IPv6 subnet is /64, so that's 16 bits for subnets. In IPv4 land, if you take a subnet to be /24, an allocation with 16 bits worth of subnets would be a /8.

So basically, with 6to4, every person with an IPv4 address got the equilvalent of a Class A in IPv6.

This is a fake argument. Noone is arguing for backwards compatibility.

But there was also no necessity to demand reshaping networks and changing address assignment in a way that made migration extremely work intensive and hard to deploy in parallel.

How would you do it?

I wouldn't try to reinvent DHCP, kept NAT and generally attempted to keep the overall shape of a v6 network the same as v4 networks to ease transition of large deployments.

Ipv6 now has most of that - after years of resistance - which results in a mixed mess of "several ways to do it" approaches spiced with clients and equipment supporting a random set of them.

How you would have implemented backward compatibility? I am interested to hear the general technical details of how this could have been possible.

I am mostly interested in two basic scenarios. With expectation that only on one side is any changes made. Host from new addressing scheme connecting to old one and receiving data back. Host from old addressing scheme connecting to one in new one and receiving data back.

There was a proposal called SIP that mostly focused on increasing address length (it got published as a historic RFC eventually): https://www.rfc-editor.org/rfc/rfc8507

It still had the problem that it made it harder for middleboxen (compared to IPv4) to look at port numbers.

Reply on news.ycombinator.com