4 ms·

It really would be nice for all ISPs to provide /56 (or shorter) prefixes by default instead of /64's so that we could properly subnet our internal LANs without

It really would be nice for all ISPs to provide /56 (or shorter) prefixes by default instead of /64's so that we could properly subnet our internal LANs without having to resort to "solutions" like NAT (or just sticking with IPv4-only forever).

Macha 2y ago
This is already the recommendation from bodies like RIPE etc., and I have to say most fixed ISPs I've dealt with do.
- ls65536 2y ago
  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.
- sedatk 2y ago
  not AT&T or Comcast.
Latty 2y ago
I've been with three ISPs in the UK, and once they did support IPv6, they all gave me a /56.
- wrboyce 2y ago
  Zen issue a /48, highly recommend them too; I have been with them for a good decade or so.
Veliladon 2y ago
Most of the /64s being allocated are to mobile devices and almost all mobile deployments coming online are IPv6 only and support IPv4 only through something like 464XLAT. Even when they are dual stacked they're only through CGNAT. It's almost impossible to get a publicly routed IPv4 address on a mobile connection.
taskforcegemini 2y ago
I'm still surrounded by ipv4 only (employer as well as privately). unless you are using it for mail, how does a /64 not have enough addresses?
- viraptor 2y ago
  It does in theory. But in practice most standard software does not let you manage smaller subnets. For example dnsmasq dhcp config: > The minimum size of the prefix length is 64. In practice, you can patch it and it should work fine. But almost everyone else is against you here. I hope enough ISPs are doing stupid assignment for the limit to be removed one day by default. There's really no sane use for /64 per node.
- icedchai 2y ago
  Technically, it does. However, various other IPv6-related standards (like SLAAC, the stateless auto config protocol, often used on local networks instead of DHCP) will break with anything longer than a /64. If you are able to go with an all static configuration, you might be able to get away with longer prefixes.

Macha 2y ago

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

ls65536 2y ago
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.
sedatk 2y ago
not AT&T or Comcast.

Latty 2y ago

I've been with three ISPs in the UK, and once they did support IPv6, they all gave me a /56.

wrboyce 2y ago
Zen issue a /48, highly recommend them too; I have been with them for a good decade or so.

Veliladon 2y ago

Most of the /64s being allocated are to mobile devices and almost all mobile deployments coming online are IPv6 only and support IPv4 only through something like 464XLAT. Even when they are dual stacked they're only through CGNAT. It's almost impossible to get a publicly routed IPv4 address on a mobile connection.

taskforcegemini 2y ago

I'm still surrounded by ipv4 only (employer as well as privately). unless you are using it for mail, how does a /64 not have enough addresses?

viraptor 2y ago
It does in theory. But in practice most standard software does not let you manage smaller subnets. For example dnsmasq dhcp config: > The minimum size of the prefix length is 64. In practice, you can patch it and it should work fine. But almost everyone else is against you here. I hope enough ISPs are doing stupid assignment for the limit to be removed one day by default. There's really no sane use for /64 per node.
icedchai 2y ago
Technically, it does. However, various other IPv6-related standards (like SLAAC, the stateless auto config protocol, often used on local networks instead of DHCP) will break with anything longer than a /64. If you are able to go with an all static configuration, you might be able to get away with longer prefixes.