[kstrauser]

Android's right on this one (and I don't own an Android device that I know of, so this isn't me fanboying them). TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup.

[zrm]

Users have poor leverage over ISPs. A lot of them still don't support IPv6 out of unmitigated laziness. If they provide it but violate the standard there isn't much you can do about it, so what the standard is really doing is preventing you from mitigating it.

The standard requiring an entire /64 for SLAAC is also just a poor design.

Suppose your ISP is doing the right thing and giving you at least a /56. You have a complex network with your own subnets and you're not sure how many you'll need in the future, but the spec says you only have to give each one a /64 and that seems like plenty, so the person setting up the network does that. Time passes and you get devices in various subnets with fixed addresses you need to stay fixed. Then you want to hook up a VM host or anything else that wants to further subdivide the address space, but the spec says you can't even though there are still scads of addresses. And for what, so they can use EUI-64 which in practice is only 48 bits anyway and is effectively deprecated because it's a privacy fail?

[0x457]

Wait, what's not standard about /64?

[hylaride]

Strictly speaking, it's perfectly standard and you can subdivide it (manually). However, for a variety of reasons subnetting smaller than a /64 is difficult and not supported at all via SLAAC (because the host portion is derived from the MAC which is already 48 bits, plus other overhead). So if you want to split up a /64 from your ISP, you're limited to manual configuration, DHCPv6 (and no android support), or other ways:

https://version6.ru/en/dividing-the-indivisible

If you're just dealing with a single network at home, a /64 is otherwise fine. But there's a reason the recommended handout from ISPs is a /56; the inventors of IPv6 (or more specifically SLAAC) just didn't take into consideration how intransigent big telecoms would be.

[0x457]

I understand that, but what I'm replying to says: "TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup."

[hylaride]

RFC6177 specifically recommends a /48 to /56 because future security measures may require subnetting, even on home networks (eg having IoT devices on a secure DMZ).

Basically, giving out a /64 is the modern equivalent to ISPs saying "you have to pay extra to have more computers on the internet and you're not allowed to use NAT" that was actually a thing up until the mid 2000s.

The frustrating this is that there's no reason to do a /64 as IPv6 was literally designed to hand out huge IP ranges.

[0x457]

Well, per RFC2119:

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Not following recommendation from RFC6177 by allocating a perfectly valid /64 (it being inconvenient to some is another story) is not "violates the documented standards"

[kstrauser]

RFC 3177[0] says:

"In particular, we recommend:

- Home network subscribers, connecting through on-demand or always-on connections should receive a /48.

- Small and large enterprises should receive a /48.

- Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's.

There was some walking that back in later RFCs, arguing that home customers could get by with just a /56.

[0] https://www.rfc-editor.org/rfc/rfc3177.txt