Hacker News Reader

Comment by MartijnBraam | Hacker News Reader

Which is why you make stuff dualstack first. Except most ISPs don't even seem to get that far...

The problem being that dualstack is worse in every way than IPv4, and worse in every way than IPv6.

The very fact that IPv6 adoption actually requires dual-stack IPv4+IPv6 adoption first is the very reason that adoption took such a hugely long time. If IPv6 could have been made backwards compatible somehow (it's probably mathematically impossible) then adoption would have been much faster (just look at HTTP -> HTTP2 -> HTTP3 already).

From a backwards compatibility perspective, HTTP2->HTTP3 is really very similar to IPv4->IPv6. HTTP3 isn't really backwards compatible with HTTP2. The client just establishes a lower version connection and then the server (which must implement both versions) adds a header to the response telling the client they can establish a HTTP3 connection if they want to. In IP land you get to skip the lower version initial connection because you've already figured it out from DNS, but other than that pretty much the same deal. In both cases both clients and servers that use a new version are dual-stacked because there are plenty of both clients and servers that only support the lower version.

Yes, that was a poor example.

Thinking about it more, the salient difference is that HTTP->HTTP2->HTTP3 is not a network-level problem to a similar extent (apart from clients and servers, you do have proxies and CDNs that need to support both, but these are far fewer actors, and it's much easier to switch CDN to one that supports HTTPx than it is to switch ISP as a server operator), that is the reason why adoption was much faster.

There were proposals at the time (1992!) for a backwards compatible version but they were rejected in favour of a clean slate approach.

https://dl.acm.org/doi/pdf/10.17487/RFC1385

It eliminates NAT traversal for peers that are also IPv6. I think the most relevant consumer usecase is probably gaming.

Well, you still need firewall traversal, so you still can't do peer-to-peer connections, something still needs to allow you to punch a hole in the firewall.

The only advantage that IPv6 with public IPs behind a firewall has compared to NAT is that each host can use the same port behind the firewall, you don't need a unique port for each host. I don't see this as a major advantage for an end-user (though it is helpful for large internal networks).

Firewall traversal for mediated PtP through basic stateful firewalls is simple - both sides start sending UDP packets to each other and outgoing packets open hole in firewall for incoming packets.

The same approach does not work reliably with NAT, mainly because you do not know translated port numbers. It also may fail if both sides are behind the same NAT, as NAT pinning is sometimes not implemented.

So is UDP hole punching the only modern way to traverse firewall?

Which is a very hacky way. I wouldn't rely on it for anything serious as it might break at any time.

Why? It seems like simple, reliable and trivial.

It is not hacky, it is essentially how stateful outgoing-only firewall is supposed to work for UDP.

IPv6 clients can be backward compatible, servers aren't.

There shouldn't really be any rush to move servers into IPv6, it's end users' ISPs that should. Somehow things are happening completely backwards.

> There shouldn't really be any rush to move servers into IPv6, it's end users' ISPs that should.

The problem is people who run servers typically pay for their IPs, while people who run clients typically don't. So, as an end-user, I don't care if I have an IPv4 or an IPv6. As someone running a server, I might.

As an ISP, I of course care if I need to acquire more IPv4's to cover all my clients. But, if all the world's servers are IPv4, I still need to provide IPv4 IPs to my clients, even if I run dual stack, so IPv6 is at best an extra cost, it doesn't save me any money.

> IPv6 clients can be backward compatible, servers aren't.

Not sure what you mean. How would an IPv4-only server send a reply packet to an IPv6-only client? There is CGNAT of course, but there we're again in dual-stack territory.

> But, if all the world's servers are IPv4, I still need to provide IPv4 IPs to my clients

That's the incorrect part. You don't need it. You can translate 6 to 4, it's not exactly CGNAT but it appears exactly the same for the IPv4 servers. That will save you from getting an address to any of your users, only the translation servers need it.

Can you provide any docs or technology name? I still don't understand how the routing devices can tell which IPv6 to route the reply to if they receive two reply packets from the same server to the same IPv4 address. With CGNAT they would assign a TCP/UDP source port in the outgoing request, and use that to route based on destination port in the incoming reply, with all the disadvantages that brings.

Can it be done without stateful connection tracking?

It's literally called 6to4. And yes, it's stateful.

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

6to4 doesn't allow an IPv6 host to send a packet to an IPv4 address. It only allows IPv6 packets addressed to IPv6 hosts to be routed by IPv4 routers. An IPv4-only TCP/UDP server receiving such a packet would not know what to do with it, as the payload of the IPv4 packet is an IPv6 packet, not a TCP/UDP packet.

On the other hand, 6to4 is stateless, so it has that going for it.

There are IPv4aaS methods that use IPv6 to deliver IPv4 connectivity along with IPv4 address sharing. MAP-T for example, does this statelessly:

https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-trans...

Why put in the effort to give users IPv6 if there's nowhere for them to go?

I recall that DJB made pretty much this argument in the distance past when he predicted IPv6 would fail.

We basically needed ipv5 what would have been literally ipv4 but with 128 bit address-safe.

How exactly would have that solved anything? It would have exactly the same transition issues IPv6 has, since the main issue is that IPv4-only hosts cannot communicate with IPv6-only hosts. And there is no way around that - for any alternative proposal.

DJB did have a proposal called AutoIPv6 which had both interoperability between v4 and v6: https://web.archive.org/web/20021017164820/http://cr.yp.to/p... . So in theory it's doable, but in practice I don't think the technologies used worked out.

Ultimately tunnelling and anycast is the way to do interoperability.

It doesn't really solve the main issue here in that IPv4-only hosts (which are not aware of IPv6-anything, have no 6to4, AutoIPv6, anything) cannot talk to IPv6 hosts.

For the inverse direction there is the DNS64+NAT64 combo which works fairly well.

I don't really see the issue to worry about IPv4-only hosts that are not IPv6-aware. Virtually all TCP/IP stacks connected to the Internet have IPv6-capabilities.

But if IPv6 is disabled or are not using 6to4/6rd if no native connectivity is available are they really IPv6 capable?

By making the transition from ipv4 to ipv5 as painless as possible and more like the switch from 32 bit to 64 bit addressing in CPU architectures. At some point everything is 32 byte safe by default and then it’s just working.

IPv4 to IPv6 is nowhere as simple, IPv6 brings tons of new baggage along with it.

Switch of CPU architecture is only a local problem.

Switching the communication protocol is a local, remote and all the parts in between problem.

Even if they go with dualstack, they do DS-Lite instead (public IPv6, CGNAT-ed IPv4). For customers that have already public IPv4, that's negative incentive to even consider switching to it, thus the IPv6 ranks are not growing, even if they could.

Reply on news.ycombinator.com