Hacker News Reader

Comment by Macha | Hacker News Reader

This is already the recommendation from bodies like RIPE etc., and I have to say most fixed ISPs I've dealt with do.

I couldn't find any such recommendation published by ARIN (the RIR for the US, Canada, and a few other countries nearby), though maybe I haven't searched hard enough yet. I have no experience with ISPs in other places around the world, but perhaps the lack of such a recommendation from ARIN contributes to why I've mostly seen only /64's here.

I'm a dude with an ASN under ARIN, they actually just link to the RIPE best current practices on the matter rather whenever it comes up as having an article just to put the ARIN name on something saying the same thing isn't worth it. E.g. they do it when talking about it here https://www.arin.net/vault/blog/2017/06/19/12-steps-enable-i.... When registering my first IPv6 block with ARIN they actually denied the request and said "Denied, but request again with a (16x in my case) larger block and it will be approved" to make sure I wasn't ever worried about being stingy on downstream allocations. At the my previous employer we got a /32 assignment from ARIN (enough for 4 billion /64s or 16 million /56s) without hassle and they weren't even an ISP. All that is to say, it's really more work to go out and not have enough space and not just use a standard DHCP-PD config than it is to get it right. Some ISPs still mess that up somehow... but they are thankfully a minority of those actually supporting (real, not tunneled) IPv6 in the first place.

It's important to note your router must explicitly ask for more than a /64. Just because the ISP will give you up to a /56 (or /60 sometimes) does not mean every router is just going to receive a flat /56 out of the box. If you don't send the hint then you don't get the delegations and it'll look like the ISP is only giving you one /64 because that's all you asked for.

Thanks for sharing those insights!

I found this in a RIPE document on IPv6 best practices [0], and it's indeed worded quite strongly (emphasis theirs):

"Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs. With a single /64, the end customer CPE will have just one possible network on the LAN side and it will not be possible to subnet, assign VLANs, alternative SSIDs, or have several chained routers in the same customer network, etc."

[0] https://www.ripe.net/publications/docs/ripe-690/#4-2-3--pref...

> "Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs. With a single /64, the end customer CPE will have just one possible network on the LAN side and it will not be possible to subnet, assign VLANs, alternative SSIDs, or have several chained routers in the same customer network, etc."

Am I the only one who thinks that IPv6’s design gets this wrong? Address bits are not free, and IPv6 added 96 bits of address for nowhere near a 2^96-fold expansion of usable space. Instead we end up with a bunch of /48 and /56 prefixes, which honestly seem a bit uncomfortably limiting. With 128-bit addresses, there ought to be an absurd amount of space to go around, and there sort of isn’t.

Beyond that, IPv4 does pretty well being minimally constrained in how networks are laid out. IPv6 makes everything awkward as soon as anyone goes off the beaten /64 path, and I’ve never seen any actual benefit derived from having supposedly stable interface IDs.

A /48 means every possible MAC address can be assigned to have its own block of 65,536 /64 subnets. We haven't come close to exhausting the MAC address space and if we did we could do so 65,000 times and still not have actually needed more than 1 client per subnet. A /32 means an IPv4 worth (4 billion) of ISPs can have an IPv4 worth (4 billion) subnets assigned to customers.

I've actually seen similar arguments that IPv6 addresses should actually have been made shorter based on how ridiculously scalable the number of subnets is. Personally I think it's the right pick - a 64 bit int covers the routed portion and a 2nd 64 bit int covers the subnet portion all with no "extra" bits to fiddle.

On the ISP side, you get a ton of space. As a consumer on residential broadband, you get a limited amount of space. I have a /40 and assign down to a /127 for Point to Point links in a datacenter. IPv6 is still an older standard and a lot of assumptions were built in about a /64 being the smallest subnet. Some routers didn't support a /127 for PtP until recently even though it was an RFC in 2010. I think even NAT66 was discouraged until everyone realized you cann't have a dual-wan setup with two different prefix delegations or everything breaks when one wan goes down and everyone has to get a new DHCP address.

Going smaller than /64 often has hardware consequences beyond just assumptions from old RFCs. E.g. in most all of Broadcom's line of ASICs you can do /127s but doing so requires initializing the ASIC on boot in a way that it has a decent chunk less table space because the IPv6 entries all have to be 128 bits now instead of just 64 bits. Many vendors expose this as a config item but default it to off kind of like the non-standard "allow routes more specific than a local subnet" option. On the software side of lower end gear it can depend on how exactly they implemented the dataplane.

NAT66 (or just NPTv6 in this scenario) is still discouraged today even though sometimes it's easier to just throw hands in the air for dual-wan setups like that. Some still have hopes of a rosy multipath client future but honestly if you know you aren't going to be able to use your own PA space or connecting your SD-WAN to a CDN/Cloud to do the same isn't viable for the use case then it's definitely an "eh, yeah not a great setup but not the end of the world" kind of solution just as bad as the remaining options at this point.

2^56 prefixes seems like plenty. Every person on earth could have millions of them! Also, only 2000::/3 is actually allocated to global unicast, not the entire IPv6 space. If what we're doing today is "wrong" we have several more chances to fix it.

not AT&T or Comcast.

Reply on news.ycombinator.com