Hacker News Reader

Comment by welterde | Hacker News Reader

That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients. This is just not possible.

Most of the other criticism is not relevant anymore, since we now have a lot of transition technologies that allow IPv6 clients to interoperate with IPv4 servers (this way around is possible since IPv6 is a superset of IPv4). Overall we are now much further into the IPv6 migration than djb ever envisioned.

View on HN

That document is not a proposal, it is a problem statement. It goes without saying that IPv4 only clients - every single one of them - would need to be upgraded in some fashion to support a larger address space. The issue is how to do that while remaining incentive compatible.

The only way to remain incentive compatible is to remain administratively compatible, and that is where IPv6 as presently constituted fails dramatically by requiring two independent network configurations to be maintained for the better part of a century, without giving anyone an incremental incentive to maintain the second one, leading to a hold out problem.

The public switched phone network has gone through major upgrades and yet at no point did someone say we are going to throw out all your existing phone numbers and require you to get new ones, or require you to have two independent and incompatible phone numbers that you put on your business cards, have two phones on your desk, or a phone with a mode selection button depending on whether you wanted to call a new style phone number or an old style phone number.

And that - from an administrative point of view - is the fundamental problem with the deployment of IPv6 as we know it. Dual stack now and for decades to come. Dual stack anything is not incentive compatible and should never have been done. The proper solution is single stack everything with capabilities that are dormant until they are deployed on a global level as part of the normal upgrade process in an administratively compatible fashion so that no large scale administrative intervention is required now or at any time in the future.

This is a really nice explanation, especially with the phone number analogy, thanks for writing it.

In the UK in the 1990s, all landlines phone numbers were prefixed with a 1, to create space for mobile phones and do on.

Other changes were made in the early days, like the introduction of dialing, then long distance dialing.

IPv6 is adding lots of complexity IPv4 never have to deal with.

SLACC, interface-specific link-local address both look good in paper but cause lots real life headache.

When it works, it works; when it don't, you have to unlearn and relearn everything network before you could possibly understand the problem, let alone fixing them.

You can use DHCPv6 instead of SLAAC. Plenty of people seem to find SLAAC preferable... and interface-specific link-local addresses are key to making it work so...

> That document has been going around for ages and is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients.

Let me summarize my understanding of what he's saying, because I don't quite see why/how you disagree. I think you (or I) might be misunderstanding his claim.

Imagine this topology: C (client, IPv4-only) <=> R (intermediate router) <=> S (server)

My understanding of djb is he's saying that IPv6 could have been designed such that S could still serve C via only simple software updates -- this means, crucially, without the need for S to separately obtain a public IPv6 address through R, because its IPv4 address would be automatically valid for IPv6.

How can this work? Well, there are two scenarios:

1. If R is IPv4-only, then S could figure that out during some startup/negotiation process, and send only IPv4 packets to R. R only lets IPv4 clients connect to S anyway, so any response (even from IPv6 applications) on S must be going back to an IPv4 address. So the kernel can transparently translate those IPv6 addresses into IPv4 before passing them along to R, and vice-versa.

2. If R supports IPv6, then R can do the same thing S would've done in the previous^ scenario. (In fact, I think S could become IPv6-communication-only in that case, reserving IPv4 for just address leasing? I'm not sure, but in any case, I don't think that matters here.)

Notice that all of this is almost completely stateless. (I think the only state S needs to track here is 1 bit, indicating whether R supports IPv6 or not.) So, S and R can be independently and (importantly, rather trivially) upgraded to support the IPv6 protocol, without losing the ability to talk to any clients within the IPv4 address range.

This is easy and requires no explicit leasing of IPv6 addresses. That step can be implemented and have support for it added later, whenever S is ready to serve clients beyond the IPv4 address space.

Does this make sense? If so, then it seems to show how IPv4-only clients could talk to IPv6 servers without modification. If not, then I'd love to see where I'm mistaken (I very well might be).

The issue is not how can we enable IPv4 C talk to IPv4 S, since that already works. The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only. Thus if the server does not have a IPv4-address how does a IPv4-client send packets to it?

The inverse situation (IPv6-only client but IPv4-only server) is not really an issue, since for that situation NAT64 works, since you can embed IPv4 addresses into IPv6.

The only way C (ipv4-only) could communicate with S (ipv6-only) is by either allocating a dedicated ipv4-address to S (doesn't have to be directly connected to S - it can be sent to some translation box that does SIIT) or by upgrading C to support ipv6 and tunneling it (6to4, 6rd, teredo, etc.).

> The problem is how would C (ipv4-only) send a packet to S (ipv6-only) in the first place? It doesn't know how to deal with non-ipv4 packets, since it's ipv4-only.

If S is IPv6-only, then either the address is from the IPv4 range, or it's not. If it is, then R can translate between them. If not, then they can't connect. I don't see him suggesting otherwise anywhere.

Even ignoring translation possibility, his point here isn't to claim its magically possible for a server outside the IPv4 address range to talk to an IPv4 client. His point is that this can move everyone to IPv6 for communication, without ISPs also having to deal with leasing addresses outside the IPv4 range, which he believes would help adoption.

Thank you thank you. I feel like this primary point in the post got lost it some of the strawmen of "There is just no way an ipv4 stack could talk to an ipv6 address!"

It seems like this is the same world as we're currently in. IPv4 hosts can contact each other and can't contact IPv6 hosts. Hosts which are dualstack can be contacted over either stack.

The problem is the incremental effort (not just software wise, but administrative as well) needed to achieve this outcome. This comment explained it much better than me: https://news.ycombinator.com/item?id=37555424

I understood djbs article differently then you. What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses. They also don't allow public IPv4 addresses to send packets to public IPv6 addresses. Public IPv6 addresses can only exchange packets with each other."?

But maybe I should reread the article a bit more generously and less literally, maybe he is actually advocating for the IPv6 we have today? Because there are transition technologies like NAT64, SIIT, 6to4, 6rd, etc. that sort of allow some of the things he suggested? "If the IPv6 configuration isn't automatic, it won't happen." sounds like he is actually advocating SLAAC to me?

You're picking a brief and vague 1-sentence summary he wrote, and missing everything that came after it that explained in detail what he's talking about.

> What else could he have meant with "In other words: The current IPv6 specifications don't allow public IPv6 addresses to send packets to public IPv4 addresses."

He could've meant "making IPv6 work means much more than upgrading software. Every administrator of a server on a public IPv4 address has to go to extra effort to acquire and enable a public IPv6 address."

You cannot read this and miss the fact that his frustration is with the need for administrators to acquire separate IPv6 addresses.

> maybe I should reread the article a bit more generously and less literally

No need to do either. Just read all of it, instead of 1 or 2 sentences that might sound like amateurish mistakes when you remove several pages of context and then extrapolate without them.

I have read all of it and I don't agree with you. But lets roll with your interpretation.

Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.

All those other things you would still have to take care of even if you magically could keep using the IPv4 address in IPv6 (however that would work). Never mind that servers don't statically sit around forever, but one has to set up new servers all the time.

So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).

> I have read all of it and I don't agree with you. But lets roll with your interpretation.

You don't need to agree with me on what he's saying. The quote "...extra effort to acquire and enable a public IPv6 address" is a directly copied from his own page. It doesn't make sense to read that and claim that's not what he's saying, or to claim I'm "interpreting" it to mean that. That quote is what he's saying.

> even if you magically could keep using the IPv4 address in IPv6 (however that would work)

It's not magical, I explained it in [1]. And he himself started to explain it when he wrote "The specifications could have [...], but they didn't", but he didn't finish the thought, and just left the reader to figure out the rest of it. (Which, again, I explained in [1].)

> Adding the address to the server is the easiest part of the whole process.

The issue isn't "adding the address to the server". The issue is obtaining said address to be able to add it to the server in the first place. This requires both you and your ISP to set up and manage/maintain an entirely independent parallel network with an entirely separate configuration. It's an administrative hurdle, not merely a technical one. I can't explain it better than this user did, so just read his comment [2].

In any case, it's fine if you disagree that this is actually a significant hurdle; I'm not trying to argue that point. My goal here was to portray what djb is saying accurately, not to agree or disagree with it. So if you disagree with it, that's mission accomplished (for me anyway).

[1] https://news.ycombinator.com/item?id=37553377

[2] https://news.ycombinator.com/item?id=37555424

> Adding the address to the server is the easiest part of the whole process. Upgrading the software is probably the biggest hurdle with people just hardcoding things to 32-bit left and right (and some badly designed APIs which do either IPv4 or IPv6 but not both in a transparent fashion). And next is actually setting up ipv6 connectivity.

Funny, because the reality is that the software has for the most part been written and the hard part is acquiring v6 addresses. The problem is it isn't just a matter of acquiring a v6 address, it's also supporting the software that the v6 address runs on, and having it work the exact same way as v4.

    The answer is that I'm actually talking about a huge number of IPv4 sites. There's nothing special about my site. When the same situation is repeated at N sites, the code is written only once, while the trivial requests and the trivial configuration changes are repeated N times.
    .
    .
    .
    Well, I'm looking at a much larger group of users, and most of them aren't putting even five seconds into IPv6. They have better things to do. If the IPv6 configuration isn't automatic, it won't happen.

> So why not go for the inverse approach for new servers? Only give the servers IPv6 addresses and for those servers that still need to be reached via the public IPv4 internet (most internal ones probably have no need of this) can be accessed via SIIT, which performs stateless mapping between IPv4 and IPv6 (for example IPv4 1.2.3.4 gets translated to IPv6 2001:db8::1.2.3.4 and vice versa).

I'm unfamiliar with SIIT, but I bet it doesn't get us closer to the "magic moment" or we would be flocking to IPv6 addresses:

    The magic moment for IPv6 will be the moment when people can start relying on public IPv6 addresses as replacements for public IPv4 addresses. That's the moment when the Internet will no longer be threatened by the IPv4 address crunch.

In this scenario, R sends packets to S over IPv4 only. So S must have an IPv4 address? If S has an address that is larger than 32 bits, what goes in the "destination IP" field in the IPv4 packet that R is capable of sending? If S has an address that is guaranteed to be less than 32 bits then we're just in the IPv4 world.

How are R and S negotiating when R cannot even name S on the network? Its stack only allows for 32-bit addresses and S can't have a 32-bit address.

See my reply here, I think it addresses your question: https://news.ycombinator.com/item?id=37556857

> Overall we are now much further into the IPv6 migration than djb ever envisioned.

That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.

> is based on the same fundamental misunderstanding that one somehow can extend IPv4 in a way somehow, but remain compatible with IPv4-only clients

I'm not a network engineer, but I've seen loads of commentary from knowledgeable sources that it would have been quite possible to have extended the ipv4 address space without requiring 2 completely separate network stacks.

I think the simple fact that ipv6 includes so many other parts beyond just extending the address space shows what a foolish endeavor it was in the first place. I'm not saying the other bits aren't good ideas, but the only immovable factor that has people wringing their hands about ipv4 is the address limitation. If they had just focused on that, we probably wouldn't be in a situation where we're still running 2 network stacks virtually everywhere, and will be for the foreseeable future. The famous XKCD "Standards" meme says it best: https://xkcd.com/927/

I have yet to read any IPv6 alternative that can theoretically work or is not just IPv6 in disguise (or something that is implemented in IPv6 in a slightly similar fashion).

It may sound like a great plan as long as one doesn't look too closely at the details. IPv4 has fixed 32-bit addresses and one cannot cram more than 32-bit of information into a fixed 32-bit field. But one would need to do that for it to be forward compatible, since how would a IPv4-only client open communications with a expanded address space server?

One idea is to only upgrade the client and server and tunnel the expanded address space packets over IPv4. IPv6 has that - that's how it was bootstrapped before native IPv6 connectivity was a thing.

I don't feel strongly about it, but my reading of the complaint is that the implication is it should've been something like an address in 240.0.0.0/4 plus more bits. Then to IPv4 it looks like a reserved for future use address (and we declare we're done with IPv4 now, there will be no (other) future use) but to (this hypothetical variant of) IPv6 it's a longer address.

I think what annoys people is everything else that changed with it, if DHCP (I know), subnets, NAT if you wanted it, etc. was all just the same, if the model was the same the IPs were just longer now, that they wouldn't really complain.

I'm not even sure it would be necessary to put it in unaddressable v4 block, since it would be too long and a different version anyway. Obviously people have thought about this a lot more than me so know a lot more about it, I'm not naïve about that.

It's not clear to me how 240/4 would have helped anything. Or how it would have even be different from a tunneling approach on a high level.

I believe the claim is that, IF IPv6 had been a much more minor modification of IPv4, including just a change to the packet structure to have a larger address field, it would have seen more adoption more rapidly than the current version of IPv6 which also changes everything else about the L2-3 stack. Sure, you would have still needed new devices and that would have taken some years, but as long as the network architecture remained the same, it wouldn't have required a quarter century to get to 30% adoption.

I don't know that I believe this claim at all, but it is at least coherent and possible (unlike claims that N-bit addresses could have been added to IPv4 in a backwards compatible manner). Perhaps SLAAC, the focus on routable end user devices etc were indeed major distractions that pulled focus away from a move to a new larger address space - which is the only thing people actually wanted from IPv6.

> which is the only thing people actually wanted from IPv6.

I'm not sure this is true. There's a lot of warts in the way IPv4 was put together (ARP is a tire-fire of badness for example), and the opportunity was taken to implement those in a better way. Lots of network engineers are very happy about that.

Good thing they can benefit from those changes, now that we’re decades in! Can you imagine if they had to manage ARP still?

> That post was written 20 years ago. I would hope that the migration would be more than "much further along", I'd have hoped it had been completed, like a decade ago.

https://www.google.com/intl/en/ipv6/statistics.html

Yes, the IPv6 migration has taken much longer than anyone expected. But this argument would have made more sense in 2015 when we were looking at 5% IPv6 deployment and very erratic growth. But it's not, we've been looking at 10% of the market gaining IPv6 support for the last 3 years and are now at 45%. Now granted, this is likely to be largely "new" devices, e.g. in mobile networks and in countries like India where these were hidden behind CGNAT before. But these are exactly the type of devices that an IPv4 extension header couldn't have reached either.

Reply on news.ycombinator.com