Live data from Hacker News

Why IPv6 is so complicated

github.com

311–320 of 519 posts

Re: Why IPv6 is so complicated

#311

I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it: Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The practical use would'v…

they have no point. some random aesthetic aspect of a standard is not why it does or does not get adopted. it's an evolutionary standard that offers no direct incentives for adoption.

the real obstacle was enterprise sales, that is, someone had to pay Microsoft, Google, Amazon, etc. as a major customer of theirs to implement correct IPv6, which takes time. the people at Microsoft working on ipv6 for customers, they're only going to implement the parts that customers need, they're not going to proactively discover all the bugs and fix everything. this is true about everything, i'm not saying anything that unorthodox, except...

the reason we're talking about ipv6 now is, in a post LLM world, it is now possible to take a well written and thoughtful spec like ipv6 and Just Do It. you don't have to wait for a customer relationship to do it.

Re: Why IPv6 is so complicated

#312
The problems of IPv6 deployment are ones of incentives, not design.

Increasingly, the vast majority of services are accessed via the service cone of various CDNs and IAAS providers directly at edge servers local to them, and at some point it may be that the industry decides that it's not worth providing ordinary internet users the ability to talk to each other directly at all. At which point, we might just as well have stuck with IPv4. I don't particularly like that outcome, but it's possible.

Re: Why IPv6 is so complicated

#313
post #268

It’s not. It’s IPv4 with more bits and some changes to Ethernet level lookup. The SLAAC vs DHCPv6 mess is not really a problem with the core V6 spec.

SLAAC and DHCPv6 actually make a ton of sense, along with the other features of IPv6. I think you need a lot of experience in both networking and applications, at many scales, to understand the design decisions and appreciate how useful they are in which contexts. That said, you could publish a clear playbook for an ISP of residential Internet for ipv6 adoption, it wouldn't change much, because they are not deciding to adopt ipv6 based on either its aesthetics or its technical merits.

Re: Why IPv6 is so complicated

#314

> Just adding bits to the address isn't as simple as it seems. They said the same in Y2K, and turned out that people were able to extend their date fields and the systems ran just fine.

You can add bits to your own systems fine. When you want your packets to work on other people's routers, it stops being fine.

If that means those other people cannot reach the internet, then I'm sure those people will fix that faster than anything ever fixed before.

Re: Why IPv6 is so complicated

#315

I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it: Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The practical use would'v…

> But instead, the default way of using v6 was those new addresses, also SLAAC and no NAT...

Well, the good news is that we've had DHCPv6 and IPv6 NAT for at least like 25 years. It's true that these weren't standardized in 1995, but I always wonder how long things need to be fully supported [0] before people stop acting like they don't exist.

It took something like a decade for IPv4 to get DHCP, and I don't know how long for it to get NAT, and yet I don't hear people saying that IPv4 has no default mechanism for address autoconfiguration or network address translation.

[0] ...by everyone except Android, of course...

Re: Why IPv6 is so complicated

#316

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 scala…

> keeping backward operational compatibility It is not possible to be backwards compatibility with a larger address space

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.

Re: Why IPv6 is so complicated

#317

Earlier quoted context omitted.

> 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.

Re: Why IPv6 is so complicated

#318

I installed a new bare metal server from a european cloud provider this week. Both my clean Debian and the rescue system couldn’t reach internet through IPv6 despite getting an address through DHCP. I immediately permanently disabled IPV6. I usually do that pretty late in my installation scripts anyway. I understand the perfect solution didn’t exist and still doesn’t exist, but it’s frustrating. I wish IPv6 could wor…

You could have spent a bit of time on debugging the issue. This would have been a great learning opportunity.

Re: Why IPv6 is so complicated

#319

I disagree that it would've been just as hard anyway. The people who say "I just wanted v4 with more bits" have a point that most of these arguments completely ignore, but this one touches on it: Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The practical use would'v…

How would this have worked in practice, in a way that the NAT464/NAT64 schemes that most mobile operators use haven’t? Would IANA have dedicated some blocks of IPv4 to be used for IPv4-compatible IPv6 addresses on the public internet?

Copy-paste the v4 blocks into v6 space under a common prefix, let's say 4::. Routers and software add ipv6 support (as they already have), but you only use 4::. Now once a user wants to switch, it looks the same. I'm still on NAT and DHCP. If I'm hitting Google.com on ipv6, I still use DNS4 and get 142.251.214.110, it actually sends to 4::142.251.214.110 takes the exact same route.

Time has to pass for all users to switch to v6. DNS6 and DHCP6 are in-place upgrades to the existing ones, not alternatives, so now they support longer fields. Once that's done, Google.com can say hey actually we're 142.251.214.110.1 now, and probably my ISP also gives me x.x.x.x.1.1 and leases x.x.x.x.2.2 to someone else.

You can also do all the above without the 4:: prefix. The point of that was to keep the possibility of offering all-new routes under the other v6 /8s, but that has its own friction.

Re: Why IPv6 is so complicated

#320
> Any address length greater than 32 would create all the coexistence and transition problems we have experienced since 1994

This is the author’s assumption and not a conclusion. Why did the other designers even bother if this was the case?

Post reply on HN