Hacker News new | ask | show | jobs
by NoZebra120vClip 1049 days ago
For an IPv6 advocate, this guy sure set up a lot of NAT. And while he claimed he's going IPv6-only, he set up public access via IPv4. That won't convince anyone to switch or upgrade.

I understand that he's building a usable service and just trying to git 'er done, but it's a lot of hacks, so I'm glad they're documented in this here blogpost.

I hope that he can continually probe the edges to find out when real IPv6 support becomes available, and can gradually remove the hacks for a purer experience.

4 comments

The nice thing about NAT64 is you only NAT when you're talking to a v4 only client, otherwise you still have pure v6. This leaves no hacks to remove for a pure IPv6 experience it just means you can have single stacked IPv6 devices instead of needing to dual stack or wait for the entire rest of the world to also configure IPv6 too.

I.e. it allows you to push IPv4 to your internet edge only in a way that doesn't downgrade anything about actual IPv6 capable connections. For a single server that probably does seem pretty silly but once you have multiple it can make more sense.

When the day comes that I have to shift to IPv6, I think I still want to NAT, though. I could be (and probably am) misunderstanding things, but I don't see how I can eliminate my need for it.

What I want it for is so that I can have services exposed through my domain name, but operated on different internal servers.

What you're asking for here is port forwards/DNAT, i.e. applying NAT to redirect an inbound connection. When people say "NAT", they're usually talking about SNAT/MASQUERADE, i.e. NATing outbound connections.

If you want to NAT inbound connections, you can do it without NATing outbound connections. Essentially: you don't need to NAT, you just need to port forward.

Honestly, I think you should just suck it up and use different hostnames for different services, because running all of your services on one IP is really bad for security since it makes it much easier to enumerate every service you're running -- it only takes scanning 65k ports on one IP to find them all, rather than 65k ports on 2^64 IPs. That's the difference between megabytes and yottabytes of port scan traffic.

If you NATed outbound connections to also come from this IP then things get even worse because every outbound connection any of your machines make would immediately inform the server of the IP needed to make an inbound connection to you. That's a completely unnecessary security sacrifice.

But if you're gonna do it, you can do just that, without trying to run the network on some local IP range too.

It's not uncommon to load-balance or NAT over fe80:: link-local addresses for internal service delivery for your use case. Some services are nicer, allowing DNS SRV records or the like, but many require the middle-man.

Some ask "why bother with IPv6 if I'm still going to do that then?" and generally the two key advantages are the fe80:: address co-exists with the unique public address of each box so you don't need outbound masquerade NAT pools and the fe80:: address space is enormous+interface specific so you don't have to worry about unique internal space or conflicts with other networks. Or, if you have a static IPv6 assignment in a more "proper" hosted deployment instead of a dynamic home deployment, you can of course just do stateless NAT to the public addresses without worrying about IP scarcity.

There are some services that have a different resource record in DNS like email (MX) or use SRV records like XMPP but else yes you are forced to either use a different hostname (like www. and ftp. and mail.) or do it port based with NAT like you used to.
At that point you just use a much simpler reverse proxy, I think? NATs have to be stateful to operate, but in IPv6 you can do a lot with simpler stateless reverse proxies.
NATs in this inbound scenario are most often stateless 1:1 static mappings of the port.
For several services, you're probably right. But not all of them. I think.
What would you suggest they have done?

I feel like excluding IPv4 folks is a large reason why IPv6 continues to fail. I feel like this is a pretty good compromise between pushing IPv6 and not being an IPv6 hermit in the IPv6 desert.

At this point, I feel like the onus should be on IPv4-only clients to adapt to an IPv6 world, by enabling proxies and translators that enable them to access IPv6 sites until their support comes up to speed.

This could be done on the ISP/enterprise level, but it is more counterproductive to tell IPv6 adopters and promoters that we need to bend over backwards and hack in NAT and purchase/rent/lease public IPv4 addresses, when this is not our problem anymore.

I feel like the more juicy services that are IPv6-accessible-only, the more it will drive consumer demand, and will light a fire under people who are responsible to update the support and ensure that IPv6 works, even when IPv4 doesn't.

This is sort of happening. Consumer "demand" is already showing IPv6-first usage in part because the (non-evil/braindead) consumer ISPs to avoid CGNAT scenarios have been moving to IPv6-first or IPv6-only with NAT64 gateways. This is especially the case in US mobile carriers who are generally some of the largest ISPs at this point by volume of US consumer traffic.

It's mostly the Enterprise level that has failed to get the message and is failing the IPv6 internet. Even just the examples in this article: It makes zero sense that GitHub still has no AAAA records (and is increasingly slow and lethargic on mobile carriers via NAT64 gateways; it is not just that their mobile app is only so-so, it's also their networking is slow). It makes zero sense that Docker put its AAAA records on weird secondary domains instead of their main domains.

Now that all of the major cloud providers are charging for IPv4 address space on a per-hour scale that might see reflection in bottom lines in IT budgets, maybe there will be a fire finally lit under Enterprises to consider using more and better IPv6.

I would suggest letting v4 users keep their existing v4 addresses when going to v6.
I mean my intention was to go pure, hence finding the Docker IPv6 registry and doing the IPv6 stuff with the bridge interface.

My hope is folks know of workarounds and I’ll do them and update the post.

> And while he claimed he's going IPv6-only, he set up public access via IPv4. That won't convince anyone to switch or upgrade.

This is the major flaw. Sites can't go ipv6-only. In reality we will have parallel ipv4/6 networks in place until the wheels fall off