Why IPv6 is so complicated • Hacker News Board

Re: Why IPv6 is so complicated

#281

Post by LambdaComplex » Sat, May 02, 2026, 4:40 PM UTC

djha-skin wrote: post #271

Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at ever…

What purpose do you have for NAT other than putting it where you should actually be putting a firewall?

Re: Why IPv6 is so complicated

#282

Post by api » Sat, May 02, 2026, 4:40 PM UTC

dgoodell wrote: post #279

api wrote: 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.

IPv4 + all the other stuff you need to actually make it work in the real world actually seems more complicated than IPv6 to me. Maybe they’re comparing the minimal implementation on a home network. But even then I’m not sure the claim holds up. People learned IPv4 when they were younger in a more incremental manner and take it for granted now.

V4 plus one or more layers of NAT and all that junk objectively is more complicated, but it’s the devil people know.

Re: Why IPv6 is so complicated

#283

Post by Veserv » Sat, May 02, 2026, 4:44 PM UTC

djha-skin wrote: post #271

Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at ever…

1. IPv6 does have NAT [1], NAT66.

2. NAT is totally orthogonal to IP and addressing.

3. NAT (as in transparent packet modification to rewrite addresses) is utterly idiotic. Ephemeral, anonymous address allocation with inbound filtering is smart, but transparently rewriting packets to do that is one of the dumbest possible ways prone to horrible compatibility and ossification issues as has been proven empirically.

[1] https://www.ietf.org/archive/id/draft-mrw-nat66-00.html

Re: Why IPv6 is so complicated

#284

Post by vlovich123 » Sat, May 02, 2026, 4:44 PM UTC

djha-skin wrote: post #271

Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at ever…

What stops you from using NAT66 (full NAT) or NPTv6 (prefix translation)?

Re: Why IPv6 is so complicated

#285

Post by zadikian » Sat, May 02, 2026, 4:44 PM UTC

djha-skin wrote: post #271

Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at ever…

You can do it, it's just not default, which does matter too

Re: Why IPv6 is so complicated

#286

Post by convolvatron » Sat, May 02, 2026, 4:45 PM UTC

api wrote: 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.

the intent behind the ipv6 spec was to remove dhcp as a requirement for establishing layer 3 connectivity. there was a generalized notion at the time that other service discovery (dns) would be handled by a more graceful multicast protocol. that was a very reasonable position to take.

but operational inertia got in the way. I don't think people really wanted to think about what a dhcp-less world would look like, even if it removed the requirement to manage a central service and the associated configuration.

this was kind of ok. but then things got ugly. people wanted to be able to get assigned prefixes dynamically from their upstream provider that they could subnet themselves. because we don't think about these issues architecturally anymore, someone put that function on dhcp. and since we don't think about these issues architecturally anymore no one really realized that that would require _another_ protocol on the inside of that boundary to manage assignments in the providers space.

and now we don't even have the option of depreciating dhcp gracefully.

Re: Why IPv6 is so complicated

#287

Post by djha-skin » Sat, May 02, 2026, 4:46 PM UTC

djha-skin wrote: post #271

Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at ever…

I am reading about ipv6 nat. I guess it's possible but discouraged?

This contention point confuses me. I consistently get downvoted for this opinion, and I've seen contrarian voices online, but I have yet to meet an actual datacenter network admin who disagrees with me.

Re: Why IPv6 is so complicated

#288

Post by hackthemack » Sat, May 02, 2026, 4:47 PM UTC

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

Re: Why IPv6 is so complicated

#289

Post by alfons_foobar » Sat, May 02, 2026, 4:47 PM UTC

djha-skin wrote: post #271

Article does not address the elephant: there is no ability to NAT with IPv6. Sure, absolutely, you shouldn't have to NAT, but in my datacenter, NAT is a feature, not a bug. The article specifically asks "did the ipv6 designers go mad" and then they list features I've never heard of or use to prove they didn't. Those features are not why I think they went mad. The inability to create a NAT is. For this reason, at ever…

NAT is a crutch to circumvent the problem of "there are not enough addresses for each device".

I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).

Re: Why IPv6 is so complicated

#290

Post by Plasmoid » Sat, May 02, 2026, 4:49 PM UTC

hackthemack wrote: post #288

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