Hacker News Reader

Comment by djha-skin | Hacker News Reader

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 every shop I've ever worked at, the intranet is ipv4, often with ipv6 disabled, with dual stack on the load balancer for ingress traffic. Note, I do not set it up that way: it comes like that when I've arrived.

View on HN

You can do NAT on IPv6. I've personally done so with both ip6tables and pf.

Its not just NAT, it's also DHCP. Somehow the nerds creating IPv6 decided to not only add bytes (which is what people wanted), but also "fix" DHCP and NAT, which nobody asked for.

> Its not just NAT, it's also DHCP.

I'm not sure what you mean by "fix" DHCP and NAT, but FYI: RFC 3315 was published in 2003.

As far as NAT goes, it looks like iptables added IPv6 support to the MASQUERADE, SNAT, and DNAT targets in kernel version 3.7, released in 2012. IDK when other OSs added such support.

> I'm not sure what you mean by "fix" DHCP

SLAAC was part of IPv6 since the original RFC, its a horribly over engineered stateless replacement of DHCP. Nobody asked for that.

> Nobody asked for that.

I wasn't around for the discussions at the time, but I would have asked for it if I was. SLAAC is IPv4LL, except that you usually get a globally-routable IP address from it. It's great. It's also quite a bit simpler than DHCP... "If the advertised prefix permits autonomous addressing, generate a host part in the non-fixed part of the prefix, run DAD on the generated address to ensure it's not in use, and start using it if it's not.".

> SLAAC was part of IPv6 since the original RFC...

An attentive reader notices that RFC 1883 and RFC 1971 are separated by nearly a year.

> Nobody asked for that.

I mean thats not true. SLAAC is great for public/untrusted networks where you just let the clients figure that shit out.

the only thing thats a bummer is not being able to map DNS records to addresses, which is kinda the point, for privacy.

this is still kind of possible, by doing neighbour discovery and querying the host for its hostname with mdns.

In my opinion, this automatic mapping of DNS names to addresess is not part of the IP protocol, and shouldn't be.

> ...mdns

"use MDNS for name resolution" works until your machine is reattached to your LAN and your MDNS server thinks your hostname is "in use" and sticks a "-N" at the end of it to "avoid hostname collisions". Though, it might just be Avahi that has this particular bit of brain damage... I haven't paid attention to the behavior of the Macs that I've been obligated to use over the years.

Few people are more sad about this behavior than I am.

When ipv6 was first created DHCP and NAT were new and not widely deployed. They weren't trying to "fix" them, they solved the same problems independently.

And if you need NAT or DHCP, there isn't any reason you can't use them with ipv6. DHCP6 had been around for a long time.

that's not at all true. DHCP was very much part of the operational canon of the internet at the time, which is why it persisted as a model. V6 really wanted to back that out so that networks 'just worked' without depending on an administrator to manage that local service.

NAT was already in use, and a substantial motivation for the IPv6 work was to provide an alternative before it got too entrenched, which sadly failed.

The RFC for dhcp was published in 1997, two years after the first RFC for IPv6, and three years after work on IPv6 started.

it was first published in 1993. I know it was in common use because I got into into argument with one of the authors, Greg Minshall, in 1995 about how basing it on bootp was really a useless idea. and I used it at my first job which I left in 1992. I sat in on the v6 working group, and remember the discussion about what to do about it. Steve pretty much just drove the consensus as usual and no one had any real objections.

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

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 security doc that never changes and has never evaluated any of the trade-offs. Almost to the point that the people who wrote them choose things that increase downtime and KTLO work without helping security.

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.

Yep. I get real tired of adding a month and year to the same base password every time I need to rotate it.

On week one of my current job, I turned that off for the whole company. Here's the citation you can give your security department to show them why they're doing it wrong.

NIST Special Publication 800-63B, the July 2025 version, section 3.1.1.2, says:

"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."

The previous version from June 2017, section 5.1.1.2, says:

"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."

So 9 years ago, NIST said to stop requiring that. Last year, they clarified that to say, no, really, freaking stop it. Any company still making people do that today is 9 years out of date, and 1 year out of compliance.

There isn't any reason you can't set up a NAT like that with ipv6.

I am not a mobile dev :D

I am aware that NAT is often used in corporate networks, but it does not automatically make any more sense there - the isolation is achieved by the firewall, not by NAT.

NAT (address or port translation) and a firewall (allowing traffic from/to those addresses or ports) are orthogonal concepts.

You can do NAT on IPv6, if you so desire.

It _should_ make no difference whether any adversary knows "what's behind a NAT", because it is your firewalls job to block any unwanted traffic.

Relying on "nobody knows what is inside our network so it can't be attacked" is not a viable strategy.

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

Obfuscation. By inspecting packets coming from my network now you can tell what MAC addresses are in my network and also internal network topology. It's part of the reason your cell phone feels the need to randomize its MAC.

This concern is addressed in RFC 4941 (IPv6 privacy extensions).

> my network now you can tell what MAC addresses are in my network

only if you're using EUI-64, but I don't think many things use that anymore. I think the only thing is cisco shit. but even then I suspect that they have RFC7217 on by default at least.

Ok, now let's translate to Important Meeting Language:

"something ipv6 something something you may be vulnerable if you buy network gear from a normal vendor"

"Ok, let's not do that ipv6 thing"

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

What exactly do you need NAT for with IPv6? Presumably, if you are operating an actual datacenter, you have a /48 or more.

NAT for IPv4 is a workaround for the scarcity of publicly routed addresses, nothing more. It bought us decades.

NAT for IPv6 does exist, but it's more often done with network prefix translation. If you want "security", you set up a firewall.

https://www.juniper.net/documentation/us/en/software/junos/n...

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

Are you a network engineer?

A network engineer would know how to NAT in IPv6, and wouldn't say an untrue statement like "there is no ability to NAT with IPv6".

Are you a network engineer?

I wouldn't advertise my title as "network engineer" but having a strong understanding networking and network design has been a big part of my jobs for the last 20 years or so.

I engineer and design network device drivers and network protocol stacks.

NAT is a terrible network protocol. The correct protocol would have been a DHCP extension giving you a 49-bit address where your IPv4 address constitutes a /32 with a 17-bit unique local address.

Fascinating. Would love to know more if you have a link.

No ability to NAT in V4 either - it was hacked on top. And you can run hacky NAT in V6 too. If you really, really, really want to.

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

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.

I am one, also disagree with you. Ipv6 nat is possible. I dont find nat particularly useful inside a network and dont use it unless strictly required to solve a problem like shared internet access or overlapping IP addresses. Isolation is best handled with separate physical networks, vlan or firewalls.

Facebook uses IPv6 virtually everywhere. They have NAT for ipv4 in dual stack (usually only on certain desktop machines), but not for IPv6 as that defeats the usefulness of it.

virtually all the datacentre is exclusively IPv6. they kinda have NAT in the sense that all the web proxies at the edge terminate the IP connections with the outside world, but thats higher up the stack rather than on the IP level.

However I never dealt with the edge stuff, as that was far away from what I was doing.

It's totally possible and it's totally discouraged. We are not the internet police on HN, and neither is the IETF. If you want to do weird stuff on your own network, you can and you get to keep both pieces.

but why do you want NAT? to hide whats in the datacentre?

I mean thats what reverse proxies are for, if you're that worried.

NAT doesn't give you anything useful, apart from the veneer of security. Sure it feels like your safe because there isnt a direct routable link between host A and the outside world, but thats not actually true.

If you want that, then you need firewalls and reverse proxies, even in IPv4.

Reply on news.ycombinator.com