6 ms·

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 e

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.

zamadatix 2y ago
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-ipv6-isp-network/ 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.
- ls65536 2y ago
  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--prefixes--longer-than--56 https://www.ripe.net/publications/docs/ripe-690/#4-2-3--pref...
  - deleted 2y ago
    [deleted]
  - amluto 2y ago
    > "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.
    - jabart 2y ago
      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.
      - zamadatix 2y ago
        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.

zamadatix 2y ago

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-ipv6-isp-network/ 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.

ls65536 2y ago
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--prefixes--longer-than--56 https://www.ripe.net/publications/docs/ripe-690/#4-2-3--pref...
- deleted 2y ago
  [deleted]
- amluto 2y ago
  > "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.
  - jabart 2y ago
    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.
    - zamadatix 2y ago
      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.