Why IPv6 is so complicated • Hacker News Board

Re: Why IPv6 is so complicated

#361

Post by simfree » Sat, May 02, 2026, 7:57 PM UTC

Fabricio20 wrote: post #359

Personal experience that I see noone talk about with IPv6 is how much more expensive hardware that handles it correctly is for datacenters. On IPv4 your usual unit of allocation is a /32 for customers - that means a simple hashmap `1.1.1.1=destination mac` works wonderfully and is cheap (single memory lookup), but for ipv6 your usual unit is a /64 so its longest prefix match instead, which requires parsing the addres…

Never mind the actual performance issues that I keep seeing in production deployments.

We have large networks that are essentially rolling on autopilot totally unmanaged, like Lumen'e recently sold Quantum Fiber asset that is now owned by AT&T holding company Forged Fiber 37 LLC

No native IPv6 still on this forgotten about network, 6RD keeps having weird routability issues, but if you just disable IPv6 everything works fine.

Re: Why IPv6 is so complicated

#362

Post by PaulKeeble » Sat, May 02, 2026, 7:58 PM UTC

dreamcompiler wrote: post #336

I almost wish NAT had never been invented. It's a kludge that effectively added 16 bits to the IPv4 address space and delayed IPv6 as a result.

CGNat even more so because its added ~16 more bits and taken away full functioning connections form the ISP customers to do it.

Re: Why IPv6 is so complicated

#363

Post by imoverclocked » Sat, May 02, 2026, 8:00 PM UTC

Fabricio20 wrote: post #359

Personal experience that I see noone talk about with IPv6 is how much more expensive hardware that handles it correctly is for datacenters. On IPv4 your usual unit of allocation is a /32 for customers - that means a simple hashmap `1.1.1.1=destination mac` works wonderfully and is cheap (single memory lookup), but for ipv6 your usual unit is a /64 so its longest prefix match instead, which requires parsing the addres…

NAT requires remembering every connection pair (IPv4:port for both internal and external sides of the NAT)

You don’t need more than the /64 to know where to send traffic, all of the bits required are still just in the prefix. One route per customer… the edge deals with addressing issues.

Re: Why IPv6 is so complicated

#364

Post by simfree » Sat, May 02, 2026, 8:01 PM UTC

kstrauser wrote: post #360

Fabricio20 wrote: post #359

Personal experience that I see noone talk about with IPv6 is how much more expensive hardware that handles it correctly is for datacenters. On IPv4 your usual unit of allocation is a /32 for customers - that means a simple hashmap `1.1.1.1=destination mac` works wonderfully and is cheap (single memory lookup), but for ipv6 your usual unit is a /64 so its longest prefix match instead, which requires parsing the addres…

Why on earth would you ever want to route something smaller than a /64? At the ISP level, you'd only be concerned about your customers' /48 or maybe /56 networks.

OP seems to want to route /64 or larger to each customer, but can only have 3000 total entries larger than /128 in the expensive routers his firm owns.

Essentially the hardware doesn't support scaling a /64 or /56 to each customer, leaving OP in a terrible position when it comes to proper IPv6 deployment.

When you look at Ziply Fiber, they seem to be ripping out these types of Enterprise grade routers left and right in favor of a simple Linux box doing routing. I think a large portion of why they're doing this is due to limitations like what OP is experiencing

Re: Why IPv6 is so complicated

#365

Post by Fabricio20 » Sat, May 02, 2026, 8:02 PM UTC

kstrauser wrote: post #360

Fabricio20 wrote: post #359

Personal experience that I see noone talk about with IPv6 is how much more expensive hardware that handles it correctly is for datacenters. On IPv4 your usual unit of allocation is a /32 for customers - that means a simple hashmap `1.1.1.1=destination mac` works wonderfully and is cheap (single memory lookup), but for ipv6 your usual unit is a /64 so its longest prefix match instead, which requires parsing the addres…

Why on earth would you ever want to route something smaller than a /64? At the ISP level, you'd only be concerned about your customers' /48 or maybe /56 networks.

Both of which are LPM and cause the issue I just mentioned! It's not about "routing lower than a /64" its about LPM vs Exact Match memory bank usage (and for some reason, how much more expensive good hardware that handles LPM is).

Re: Why IPv6 is so complicated

#366

Post by kstrauser » Sat, May 02, 2026, 8:03 PM UTC

Plasmoid wrote: post #330

djha-skin wrote: post #292

Earlier quoted context omitted.

Everyone I've talked to with this opinion are typically mobile devs thinking about cell phones. Ipv6 works great there, but NATs are often used in corporate networks for isolation and in particular obfuscation. You can't tell what's behind a NAT by inspecting traffic coming from inside it like you can with no NAT networks. Some of the networks I administrate are contractually obligated to be so isolated.

> I administrate are contractually obligated to be so isolated Yeah, I've seen those contracts. They just reference a SeCuRiTy doc that's 20+ years old, and has never been re-evaluated. Things are secure because they follow the doc, not because they have actually evaluated the reasonable attack space. I've fighting customers for years on their ideas of proper TLS usage and it's always the same thing. They've got a se…

Ah-yup. The equivalent in my world is contracts that insist we make our employees rotate their passwords every 2 months or whatever, which was a popular (but still dumb) idea 20 years ago and is strongly recommended against today.

Re: Why IPv6 is so complicated

#367

Post by torginus » Sat, May 02, 2026, 8:09 PM UTC

My personal opinion of having worked with all layers of networking for my job without developing a comprehensive understanding, is this:

We as consumers see and use the highest level, which is often https or friends, and due to the layered nature of the OSI stack, as often happens in software, if a layer is lacking in something, it gets fixed 1 or 2 layers up. If then said thing is then implemented on the layer its supposed to, its often unwelcome and just causes issues.

TCP/IP has already acknowledged this (haha) by offering UDP, on top of which you can build the network protocol of your dreams.

And people have. It's called QUIC or HTTP3. It does everything one could ask of a network protocol, with QoS, NAT punchthrough, packet based low latency/overhead comms, etc. etc.

And QUIC doesn't assume any sort of advanced mechanisms beneath, it works happily with IPv4.

And once you have everything figured out for you on the level you like to work, there's not really a need for the lower layers to pick up the slack, as long as they work reliably.

Re: Why IPv6 is so complicated

#368

Post by imoverclocked » Sat, May 02, 2026, 8:12 PM UTC

zadikian wrote: post #319

johncolanduoni wrote: post #310

Earlier quoted context omitted.

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

Underneath the hood, you are talking about v4 mapped addresses:

IPv4-mapped IPv6 addresses (prefix ::ffff:0:0/96)

Network stacks do allow this today.

Re: Why IPv6 is so complicated

#369

Post by arjie » Sat, May 02, 2026, 8:14 PM UTC

I have a /56 at the datacenter and Google Fiber gives me something like a /64 or something so I have full IPv6 connectivity everywhere. For the most part this is fine, but I've noticed the Internet is 'less reliable' on IPv6 and so in my head I still feel like it's a little iffy. There are times where a AAAA record points to an IP that doesn't respond, but the A record responds and so on. I just think it's the same as my blog's Gemini protocol server. I don't use it and offer it for fun but it's a best-effort basis. If it went down for months I wouldn't notice.

Re: Why IPv6 is so complicated

#370

Post by johncolanduoni » Sat, May 02, 2026, 8:22 PM UTC

zadikian wrote: post #319

johncolanduoni wrote: post #310

Earlier quoted context omitted.

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

This already exists in two forms, and has for basically the entire history of production dual stack deployments. The first are IPv4 mapped addresses (of the form ::ffff:x.x.x.x) which instruct the local machine’s network stack to use a local IPv4 address to communicate to the server. This still requires each machine to have a routable IPv4 address (though not necessarily a public one - it can be used with a NAT44 router).

If you don’t want the local machine to have a routable IPV4 address at all (which is a common practice on mobile networks), you can do something similar with a different prefix (usually 64:ff9b::/96) called NAT46. In this case the local machine’s network stack exclusively emits IPv6 packets, and the upstream router/network detects the prefix and performs stateful NAT using its own IPv4 address(es), just like NAT44. Depending on the use-case, the local machine doesn’t even have to understand what you’re doing at all. Instead you just have the local network’s DNS server return fake AAAA records with the corresponding 64:ff9b::x.x.x.x addresses when some particular domain doesn’t have native IPv6 support.