IPv6 for the remotely interested | Hacker News Reader

IPv6 for the remotely interested

ssg.dev

63 pointssedatk35 comments

> IPv6 provides no benefit to end users

The benefit to end users is that the whole internet protocol stack finally disappears into the fully transparent realm it belongs. End users should not have to mess with IP addresses at all; IPv6 makes it possible to have devices that really just work, in the literal sense: They acquire addresses on their own, they negotiate on their own—ideally, you just don't need to care about that part of connectivity at all, ever again.

It brings complexity for network operators, sure—but that's where the complexity belongs!

Edit: I just wish DNS would follow suit, somehow, and everything just got names automatically. That's a whole different problem, however.

Like mDNS?

Like mDNS. But widely available, with a healthy portion of well-known names, quality of life features, and configurability thrown in. I consider this available when I can ping `router.local`, `my-machine.home-network`, `iphone`, or `coffee-maker.devices.floor-5.office` wherever I am, from any of my devices, without any additional configuration required. A liberation of the whole naming business is overdue, in my opinion; domains should be assignable to things securely and automatically, without any involvement of IP addresses or even IT specialists.

> brings complexity for network operators

> I just wish DNS would follow suit

Technically, this is super-easy. Just select an anycast IP that would always go user's ISP's DNS - just like any other anycast DNS front-end IPs (1.1.1.1, 8.8.8.8, et al.) go to a nearest PoP of CF/google/etc.

Just to reiterate - there is no reason why an anycast IP has to be held by the same entity globally. "Federated" anycast IP, where each user reaches their local ISP would work just as well. Then make it an internet standard. Once that standard gets implemented in end-devices, there no longer any need to negotiate DNS server IP, same one works across different ISPs, always going to the nearest one. Still complex, but all the complexity is now on ISP side.

Practically, this is overwhelmingly unlikely to happen. There is a significant momentum among internet users to actively distrust their ISP, and mechanisms to cloak DNS traffic from user's ISP (DoH, DoT, ...) are somewhat popular, based on that exact motivation, in part.

Another great benefit is not having to share an IPv4 address, so many issues with IPv4 only servers rate limiting CGNAT addresses, or even worse someone is hosting a Tor relay or exit node and suddenly hundreds of people have to deal with WAF rules all over the internet.

The benefit IPv6 brings of giving routed IPs to every device is not something to scoff at. All the other benefits may not integrate in the future but simply the quantity of addresses in and of itself is massive.

The internet can be decentralized as a result.

> IPv6 has no subnet masks

What? no...

I _think_ I see where the author is coming from, but the assumption that your ISP will hand out a single /64 is evidence of IPv6/NAT-style thinking.

The minimum an ISP _should_ hand out to a customer is a /48 <https://www.ripe.net/publications/docs/ripe-690/>. Out of this, a customer router should advertise a /64 on each interface, for devices on networks that only want a single address, and hand out /56s or /60s via DHCPv6 IA_PD for devices that want more (e.g, a developer who wants to give a /64 to each of the virtual networks on their laptop for VMs/containers to use).

> IPv6 provides no benefit to end-users

God no. Getting rid of hole punching, port forwarding and source-address-obscuring masquerading _are_ benefits.

Damn that's terrifying.. I rather obfuscate my traffic inside my network down to a single node at home.

Indeed, I believe most end-user devices should use RFC 8981 (Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6) to avoid pervasive monitoring. However you must bear in mind that this does nothing to prevent web browser fingerprinting, so the effective loss of privacy if temporary addresses are not in use is arguably pretty minimal.

The should is the problem. I've not looked into this in a couple years but I've read plenty of stories of people getting some weird stuff, down to just 1 ipv6

Indeed, regulators need to take so-called ISPs to task and mandate provision of at least a /48 to each customer.

Isn't router already a NAT? The profit is that it's a configurable NAT unlike draconian CGNAT.

No. NAT should be non existent (or purely optional) in IPv6.

In IPv6 the idea is your computer's local IP address is globally routeable.

> Out of this, a customer router should advertise a /64 on each interface, for devices on networks that only want a single address, and hand out /56s or /60s via DHCPv6 IA_PD for devices that want more[...].

That said, support for this in the type of router you see on small networks is non-existent. My Ubiquiti EdgeMAX EdgeRouter, for instance, is perfectly capable of requesting a prefix, and assigning a /64 out of the assigned prefix to each other interface for clients to use. But there's no support for, for instance, splitting the prefix up into subprefixes and handing _them_ out via DHCP6 IA_PD; the generated dhcp6c configuration file has a hardcoded sla-len value of 8.

And even if there was, and devices on my network were able to get their own /56s, east/west traffic would have to go via the router instead of being switched directly to the device hosting the virtual network; or the device would have to transmit its own RAs for the delegated prefix, which is a bad idea for security... a lot of assumptions about how we build networks need to be re-visited.

(Sadly Ubiquiti's Unifi line has even worse support for IPv6... and I can't in fairness find documentation suggesting that Mikrotik is any better in this regard... any other suggestions please make them!)

Correction, Mikrotik might support this after all if I understand https://wu.renjie.im/blog/network/ros-dhcpv6/#enable-dhcpv6-... correctly!

Specifically push notifications provide a nice use case for server to client connections, for which you currently need to use an additional service that also inspects and censors your notifications for your safety.

Also how should I secure the vms? VirtualBox provides NAT and port forwarding settings, but not firewall settings, and I guess it bypasses the host firewall, so I should configure guest firewall?

Not following the point for push notifications sorry.

Securing VMs: if your hypervisor is now routing packets between your virtual networks and your physical network then you need a packet filter on the hypervisor AND a packet filter on the guest (belt and braces).

> IPv6 has no subnet masks

It definitely does (although they're called prefix lengths). /64 just happens to work well with SLAAC.

> IPv6 has no NAT

Nor does IPv4 "have NAT". It's a technology that routers can implement, and of course that's possible in IPv6 as well.

Linux implements it, for example, and NAT on IPv6 can be essential if all you have is a single IPv6 address, e.g. when you get one assigned from your local network and you want to run a VM on your machine.

> IPv6 addresses are self-configured

Sometimes they are, sometimes they aren't. There's also DHCPv6 and static configuration.

> It’s impossible to memorize IPv6 addresses

So what? I have no interest in memorizing IPv4 addresses, phone numbers etc. either.

> IPv6 provides no benefit to end-users

I'm an end user, and they provide a ton of benefits to me:

- Firewall traversal (i.e. "hole punching") is so much more predictable and so much more likely to succeed than NAT traversal. Things like VoIP, Tailscale etc. all have a much higher chance of success with IPv6 than behind one or more layers of NATs.

- All of my home devices get public addresses that I can optionally expose for incoming connections via firewall rules on my router!

- More direct routing on mobile networks, leading to lower latency. (IPv4 often gets routed to a bank of expensive, stateful CG-NAT devices, which aren't present in every place my mobile ISP has IPv6 interchange.)

I got IPv6 working on my home network. My only issue with it was privacy. And not the privacy addresses that theoretically randomize the host portion of the address.

On IPv4, when I do a geoip lookup on my IP, I see a dot about a mile away from me indicating the part of town I'm in (already creepy).

On IPv6 the dot was on my block.

So I scrapped IPv6 mostly, and have ProtonVPN on my computer with only gaming bypassed.

I think MullvadVPN has IPV6 support.

My whole city is behind NAT (IPv4), it's like small tor. I think IPv6 was supposed to work the same: the whole city should be in a single /64 network, otherwise address randomization doesn't provide k-anonymity.

I feel like we're past the point where IP address randomization practically provides reasonable privacy: Unless you use a new address per connection or at least site visited, data brokers will just collate your data on their backends.

Solutions providing per-flow privacy like MASQUE seem like a more promising approach.

Using a common IP address is laundering your traffic with everyone else's, which makes that IP data less valuable. I refresh my connection several times a day.

But serveral times per day is not enough if you visit at least one site that both knows who you are and is willing to sell your data to a data broker.

Then all other sites that you've browsed to anonymously can buy the information "who had IP x on day y" and still know who you are.

That is just a difference in geolocation. Maybe because IPv4 addresses tend to change more frequently than IPv6 because there are fewer of them.

There is little practical difference in privacy, with IPv4 leak the address for house, with IPv6 leak the prefix for the house. Address randomization means that can't track devices inside the house over longer periods. The privacy addresses happen by default, you would have to disable them deliberately.

The geoip depends on how much your ISP discloses as far as I know? I see one of three answers for my IP addresses (V4 or V6):

- The capital city of the country I live in

- The town my ISP's head office is in

- null, null

I don't live in any of these locations :)

The latter is actually increasing a lot. I wonder if I turn adblock off will I get ads for singles in null island

  1. one data point: my verizon fios gives out /56, my openwrt takes a slice /60 out of it for lan and then my linux box gets /64
  2. there is nat and you can use it in linux.

majority of home users does not need a public ip address so ipv6 for home is not that useful.

It's not usually required, but having a routable public IP is helpful for any sort of P2P connections, which between games/voip does come up for normal users.

> your devices can be fingerprinted and tracked individually

True. About decade ago, happened scan of whole IPv4 ports with some botnet, owner unknown, purpose unknown.

Sough, this is enormous volume of machine-hours, but not impossible.

I'm not a network guy, so I appreciate this write up.

I've been working in a few different areas of IT for the past 19 years, and IPv6 has always been present in conversations with colleagues, but it seemed to me like it was always some kind of meme, or something too farfetched to be taken seriously... Even today when I try to deploy a VM somewhere (Linode, Vultr, etc) IPv6 is the unticked boxed at the end of the page...

Are we anywhere close force-adoption? is this something that can even happen at this point? Is the complete depletion of IPv4 address-space the only driver for change?

I recently moved to West Virginia (fairly rural state) where there's only one real choice for broadband ISP at my house (Spectrum), and it supports IPv6.

AWS just started charging for IPv4 addresses in February of this year, though in practice, I think this pushed people to "hoard IPv4 less" rather than "use IPv6 more."

I know it's far more common for mobile / cellular ISPs, and I know Apple's been pretty strict about IPv6 compatibility in apps for quite some time for that reason.

Seems like a slow march in the right direction, at least from what I can tell.

I think we'll see a long tail of IPv4-only services for a long time, but as IPv6 availability of services ramps up (in turn incentivized by a drastic increase in dual stack or v6-plus-v4-NAT eyeballs), v4 fallback solutions will probably be scaled down proportionally, and quality will degrade with it.

"IPv6 is only useful if everybody has it" was conventional wisdom for a long while, but it turns out to not really be true anymore: IPv6 is incrementally useful.

nice, what does NAC look like if v6 can self address. I've been low-teching DHCP whitelists. I have an audit problem not a security problem.

Assuming anyone can send a DHCP request and the IPs handed out by the DHCP server are added to the allowlist, what does your audit data look like? Something like:

    2024-04-16 12:15:01 ac:de:48:00:00:01 uses address 192.168.2.255 for the next 72 hours

or is there more to it?

Regardless, you _can_ tell clients to _not_ use SLAAC, and you _can_ tell clients to use DHCPv6 to obtain addresses.

If you use the DHCPv6 server to control an allowlist then some clients who ignore the second request will be unable to use your network, but that's a problem for Android users. :)

Not much more, it's more inverted, I'm told out-of-bad the MAC to allow. But I didn't know you could disable SLAAC from an RA

To be precise, the prefixes advertised within an RA message have an 'autoconfig' flag; if you unset this flag then hosts won't do SLAAC.

So if you set the M-flag on your RAs, and unset the A-flag then hosts will have to use DHCPv6 to obtain addresses.

Of course, this won't stop hosts from unilaterally deciding to transmit packets using any source address that they choose to, but this is no different than with IPv4.

Reply on news.ycombinator.com