2 ms·

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): "Assig

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.
- icedchai 2y ago
  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.
- zamadatix 2y ago
  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.

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.
icedchai 2y ago
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.
zamadatix 2y ago
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.