3 ms·

There is a lot of assumptions that are broken if you try to allocate something smaller than /64. It would be like trying to re-assign the multicast address spa

There is a lot of assumptions that are broken if you try to allocate something smaller than /64. It would be like trying to re-assign the multicast address space for unicast. But running out of space on IPv6 is seriously not a concern. Even a "paltry" 64 bits of address space is an absurdly large number of addresses. Humans need to have colonized the entire galaxy before it becomes an issue.

mortenlarsen 5y ago
Yes, 64 bits is the same amount of space as an entire IPv4 Internet NAT'ed behind every IPv4 address on the current Internet. Actually more if you take multicast and reserved addresses into account.
immibis 5y ago
I believe the current allocation plan allows for 2^45 "customers" getting a /48 each. While we don't have 2^45 humans get, it's not too hard to imagine having more than one "customer" per human especially due to corporations and multi-homing, and there will be unused space due to hierarchical allocations, and I'd say that with 128 bits available, probably more than 10 of them should be devoted to future-proofing. If each customer were to get a /64 or a /60 or perhaps a /56 by default, that would leave plenty of room for inefficient hierarchical allocation and future-proofing. But that doesn't leave many bits for subnetting. To my knowledge, the only thing that breaks in subnets smaller than /64 is automatic address assignment, i.e. SLAAC and privacy addresses, which are in no way required, merely convenient.
- Arnavion 5y ago
  Nothing breaks irrevocably in subnets smaller than /64, including SLAAC and privacy addresses. You just need NDP proxies between them.
  - jandrese 5y ago
    There are plenty of second order effects though. Like IPv6 blacklists operating at the /64 level or higher. Sharing a /64 is like being behind the same natted IPv4 address as a bad guy.
    - Arnavion 5y ago
      Right, I wasn't saying that giving end-users something smaller than a /64 should actually be done. Not only does it require more effort but also it breaks higher-level things as you said. I was just saying that there's no technical breakage that would occur, especially not SLAAC or privacy addresses.
    - oarsinsync 5y ago
      > Like IPv6 blacklists operating at the /64 level or higher Several blocklists I'm aware of block at /48s, not at /64s, on the basis that customer allocations (per the spec) are supposed to be /48s. Not enough people use IPv6 right now, so the level of complaints from this is low->zero.
      - Arnavion 5y ago
        RFC6177 (2011) obsoleted the recommendation (which is all it was to begin with, not a "supposed to") that end users should get /48s.
oarsinsync 5y ago
> There is a lot of assumptions that are broken if you try to allocate something smaller than /64. It would be like trying to re-assign the multicast address space for unicast. Can you go into some details as to what breaks? I ran a dual-stack network with /112s for host subnets, and /124s for ISLs (prefix lengths chosen to make life easier for the network operators) and I wasn't aware of any problems. Certainly, you can't use (formerly known as) class D address space in IPv4 as the major IPv4 stacks will balk if you do, and you're never gonna get into class E space either for similar reasons, but ... to use a longer prefix length than /64 in IPv6? I'm unaware of any implementations that fall over, but it's been a few years since I paid any real attention.
- zamadatix 5y ago
  For what breaks: a lot. This has a decent start of the list https://datatracker.ietf.org/doc/html/rfc5375 https://datatracker.ietf.org/doc/html/rfc5375 > Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. SLAAC is part of that as well. > I ran a dual-stack network with /112s for host subnets, and /124s for ISLs (prefix lengths chosen to make life easier for the network operators) and I wasn't aware of any problems. Easiest for network operators is to act like IPv6 doesn't have different subnet mask at all, assume every subnet is always /64 and never have to remember funny patterns. Even a point to point is most often best done as a /64 instead of a /127. Most switching hardware prefers this as well actually, by ignoring the last 64 bits of the address in routing the hardware scales significantly better in terms of TCAM usage.

mortenlarsen 5y ago

Yes, 64 bits is the same amount of space as an entire IPv4 Internet NAT'ed behind every IPv4 address on the current Internet. Actually more if you take multicast and reserved addresses into account.

immibis 5y ago

I believe the current allocation plan allows for 2^45 "customers" getting a /48 each. While we don't have 2^45 humans get, it's not too hard to imagine having more than one "customer" per human especially due to corporations and multi-homing, and there will be unused space due to hierarchical allocations, and I'd say that with 128 bits available, probably more than 10 of them should be devoted to future-proofing. If each customer were to get a /64 or a /60 or perhaps a /56 by default, that would leave plenty of room for inefficient hierarchical allocation and future-proofing. But that doesn't leave many bits for subnetting. To my knowledge, the only thing that breaks in subnets smaller than /64 is automatic address assignment, i.e. SLAAC and privacy addresses, which are in no way required, merely convenient.

Arnavion 5y ago
Nothing breaks irrevocably in subnets smaller than /64, including SLAAC and privacy addresses. You just need NDP proxies between them.
- jandrese 5y ago
  There are plenty of second order effects though. Like IPv6 blacklists operating at the /64 level or higher. Sharing a /64 is like being behind the same natted IPv4 address as a bad guy.
  - Arnavion 5y ago
    Right, I wasn't saying that giving end-users something smaller than a /64 should actually be done. Not only does it require more effort but also it breaks higher-level things as you said. I was just saying that there's no technical breakage that would occur, especially not SLAAC or privacy addresses.
  - oarsinsync 5y ago
    > Like IPv6 blacklists operating at the /64 level or higher Several blocklists I'm aware of block at /48s, not at /64s, on the basis that customer allocations (per the spec) are supposed to be /48s. Not enough people use IPv6 right now, so the level of complaints from this is low->zero.
    - Arnavion 5y ago
      RFC6177 (2011) obsoleted the recommendation (which is all it was to begin with, not a "supposed to") that end users should get /48s.

oarsinsync 5y ago

> There is a lot of assumptions that are broken if you try to allocate something smaller than /64. It would be like trying to re-assign the multicast address space for unicast. Can you go into some details as to what breaks? I ran a dual-stack network with /112s for host subnets, and /124s for ISLs (prefix lengths chosen to make life easier for the network operators) and I wasn't aware of any problems. Certainly, you can't use (formerly known as) class D address space in IPv4 as the major IPv4 stacks will balk if you do, and you're never gonna get into class E space either for similar reasons, but ... to use a longer prefix length than /64 in IPv6? I'm unaware of any implementations that fall over, but it's been a few years since I paid any real attention.

zamadatix 5y ago
For what breaks: a lot. This has a decent start of the list https://datatracker.ietf.org/doc/html/rfc5375 https://datatracker.ietf.org/doc/html/rfc5375 > Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. SLAAC is part of that as well. > I ran a dual-stack network with /112s for host subnets, and /124s for ISLs (prefix lengths chosen to make life easier for the network operators) and I wasn't aware of any problems. Easiest for network operators is to act like IPv6 doesn't have different subnet mask at all, assume every subnet is always /64 and never have to remember funny patterns. Even a point to point is most often best done as a /64 instead of a /127. Most switching hardware prefers this as well actually, by ignoring the last 64 bits of the address in routing the hardware scales significantly better in terms of TCAM usage.