Hacker News Reader

I don't think this is inherently a problem. It's good for home routers to have sensible defaults. Blocking incoming IPv6 connections is such a thing. Opening a port in the firewall shows the same kind of intent as forwarding a port with NAT. The burden is on the router manufacturers to expose these options in a sensible way. My router for example has a similar UI to forwarding a port with IPv4 and opening the port for IPv6.

Using NAT as a firewall might work but it brings it's own problems. I find the IPv6 way better.

> I don't think this is inherently a problem. [...] My router for example has a similar UI to forwarding a port with IPv4 and opening the port for IPv6.

Glad to hear that you don't have a problem with your router, but how does that relate to GPs problems with theirs?

It isn't. But It's also not an answer to GP.

The solution for them is "get a better router" because the problem is not the IPv6 protocol. Opening a port is not harder than creating a NAT forwarding and if your hardware can't do it then it's bad.

Exactly, and “there are a lot of bad v6 implementation CPEs out there” is an important data point worth acknowledging.

> There was a time when the designers believed that you'd use your 48 bit MAC address as part of this. Now we know that's a PII nightmare and nobody does it.

Nobody includes their MAC address in their public IPv6 addresses anymore, but every IPv6 setup that I've seen still gives every device a unique globally-routable IPv6 address, with no NAT at all.

> One of my favorite is the decision to default to /64 blocks.

The nice thing is that a /64 is big enough that clients can just randomly pick any address, and it will almost certainly be available, meaning that you don't need DHCP. This is actually widely implemented, and is known as SLAAC [0].

> Yet we're still stuck with the 128 bit addresses that came from that.

The extra address space only adds 16 bytes to every packet, and it ensures that we will never run out of addresses like we did with IPv4.

[0]: https://en.wikipedia.org/wiki/IPv6#Stateless_address_autocon...

With current addressing scheme we only have 2^13 times more site addresses than IPv4, which is plenty in absolute numbers, but not necessarily enough for more coarse aggregation, and definitely not infinitely future proof.

Crucially though, if we change it, we just have to change how addresses are allocated, not change the protocol again.

> Crucially though, if we change it, we just have to change how addresses are allocated, not change the protocol again.

Yup, and only less than an eighth of the total IPv6 address space has been allocated [0] [1], so there's still plenty of room to expand, even if we have to throw every current address out and start from scratch.

[0]: https://www.iana.org/assignments/ipv6-address-space/ipv6-add...

[1]: https://datatracker.ietf.org/doc/html/rfc3513#section-4

> but every IPv6 setup that I've seen still gives every device a unique globally-routable IPv6 address, with no NAT at all.

Mine all have link-local addresses (I do have a real static IPv6 address block from my ISP, at great expense…) - so I’m not sure what I did wrong in my Ubiquiti gear.

A link-local address is required with IPv6, so your devices probably just have that in addition to a globally-routable IPv6 address. This isn't a problem though, since devices have no problem having lots of different addresses on the same interface [0].

[0]: https://news.ycombinator.com/item?id=44773981

> Now we know that's a PII nightmare and nobody does it. Yet we're still stuck with the 128 bit addresses that came from that.

Randomizing the local address doesn't mean it isn't useful. You can't scan a /64 so that's already a major improvement. The fact that randomly selecting a number is effectively never going to collide greatly simplifies automatic network configuration.

The major issue is that the /64 isn't mandatory from a technical perspective. Being merely a subset of the larger address it's nothing more than a convention. In the end not all providers make it available to you even though supposedly they ought to.

If we're going to complain about anything it should be the godawful notation that so easily breaks parsers. Or the fact that the width is massively excessive which creates a usability nightmare due to normal humans not being able to readily recall 128 bit numbers (let alone how long it takes to type them in).

The point of local networks of a minimum size of 64 bit isn't only to have MAC-based addresses (48 bit would have been enough for that, fwiw), but in general to support non-coordinated/probabilistic self-assignment schemes with negligible collision probability.

Picking a random local address (which is very important for privacy, as you've mentioned) is much easier if you don't have to do an elaborate dance of listen, announce, listen for collisions etc. first (practically that still happens, but collisions are the absolute exception).

> So is the bigger address range better?

Yes, because consider the alternative of re-doing all of this again in a future in which IP usage for some reason jumps by a few orders of magnitude again.

Due to hardware getting better over time, the per-packet cost of a few extra bits is going down all the time, while the cost of rolling out a future IPv7 increases with every new deployed host.

The best thing about SLAAC is that it forces your ISP to give you at least 64 bits. Otherwise you know Comcast would only give out a /128 and charge you for more, so you'd use NAT at home just like IPv4.

Unfortunately SLAAC doesn't force upstream to provide a /64 universally.

Some ISPs are reportedly giving out a /128, and SLAAC works adequately with a router performing IPv6 NAT, so those ISPs don't see a problem.

Mobile phone as WiFi access point is another common way people access the net nowadays. I've occasionally seen permanent installations, with a phone taped to a window. I've never seen a mobile phone AP offer IPv6 to clients, but if they do they have to use SLAAC-compatible IPv6 NAT in that situation.

> Some ISPs are reportedly giving out a /128, and SLAAC works adequately with a router performing IPv6 NAT, so those ISPs don't see a problem.

Wow, that’s diabolical. Presumably these routers are some custom CPEs then? I don’t even know whether regular home routers support NAT66.

> I've never seen a mobile phone AP offer IPv6 to clients

I’ve only even seen it work without NAT when there was any v6! Usually the phone gets a /64, and there is a bit of trickery involved to make that shareable to other devices (NDP rewriting), but it works pretty well.

> I've never seen a mobile phone AP offer IPv6 to clients, but if they do they have to use SLAAC-compatible IPv6 NAT in that situation.

iPhone does that, and I’m pretty sure I’ve seen Android doing the same. The phone keeps a single /128 from the /64 assigned by the mobile network on its mobile interface and the re-assigns the /64 on the WiFi interface. No NAT is involved.

Well, my phone as access point grants an IPv6 public IP without NAT. There's a stateful firewall somewhere in the chain though.

Thats why android supports dhcpv6-pd for a /64, but not assigning a /128 from dhcpv6

> IPv6 doesn't have that intent, which forces home router makers do block addresses by default because you don't want most PCs on the Internet such that an external agent can scan your PC. You may end up with an unintended service on the open Internet.

Every residential router already has PCP (RFC 6887) and UPnP IGD to deal with the NAT44 non-sense that is the status quo, and both protocols support IPv6 hole punching, so IPv6 default deny as a policy is hardly an issue in the residential space.

MiniUPnPd, which many Linux-based CPEs use, has supported IGDv2 (needed for IPv6) since 2012 (as well as PCP).