[crote]

> With IPv6 on the other hand, it is trivially easy to get a new IP

OpenSSH already seems to take that into account by allowing you to penalize not just a single IP, but also an entire subnet. Enable that to penalize an entire /64 for IPv6, and you're in pretty much the same scenario as "single IPv4 address".

I think there's some limited value in it. It could be a neat alternative to allowlisting your own IP which doesn't completely block you from accessing it from other locations. Block larger subnets at once if you don't care about access from residential connections, and it would act as a very basic filter to make annoying attacks stop. Not providing any real security, but at least you're not spending any CPU cycles on them.

On the other hand, I can definitely see CGNAT resulting in accidental or intentional lockouts for the real owner. Enabling it by default on all installations probably isn't the best choice.

[janosdebugs]

IPv6 has the potential to be even worse. You could be knocking an entire provider offline. At any rate, this behavior should not become default.

[aftbit]

FYI it's pretty common to get a /48 or a /56 from a data center, or /60 from Comcast.

[dheera]

I can never remember whether /x means "the last x bits are 0" or "the first x bits are 1"

People should write 80/48 or 48/80 to be clear

[immibis]

It's not about how many bits are 1 - it's about how many bits are important. And the first bits are always most important. So it's the first x bits.

If you have a /48 then 48 bits are used to determine the address is yours. Any address which matches in the first 48 bits is yours. If you have a /64, any address which matches in the first 64 bits is yours.

[patmorgan23]

It's about how many bits are 1, in the subnet mask.

[immibis]

The number of bits that are important is the number of 1 bits in the which bits are important mask, yes. I thought you couldn't remember how that mask worked.

[aftbit]

/48 is netmask of ffff:ffff:ffff:0:0:0:0:0. `sipcalc` can help with this.

  $ sipcalc ::/48
  -[ipv6 : ::/48] - 0
  
  [IPV6 INFO]
  Expanded Address - 0000:0000:0000:0000:0000:0000:0000:0000
  Compressed address - ::
  Subnet prefix (masked) - 0:0:0:0:0:0:0:0/48
  Address ID (masked) - 0:0:0:0:0:0:0:0/48
  Prefix address  - ffff:ffff:ffff:0:0:0:0:0
  Prefix length  - 48
  Address type  - Reserved
  Comment   - Unspecified
  Network range  - 0000:0000:0000:0000:0000:0000:0000:0000 -
       0000:0000:0000:ffff:ffff:ffff:ffff:ffff

I remember how this works because of the IPv4 examples that I have baked into my head, e.g. 10.0.0.0/8 or 192.168.1.0/24. Clearly the first 24 bits must be 1 for that last one to make any sense.

I recently found a case where an "inverted" netmask makes sense - when you want to allow access through a firewall to a given IPv6 host (with auto-config address) regardless of the network that your provider has assigned.

[merlincorey]

> I can never remember whether /x means "the last x bits are 0" or "the first x bits are 1"

> People should write 80/48 or 48/80 to be clear

The clarity is found implied in your preferred example.

- "80/" would mean "80 bits before"

- "/48" would mean "48 bits after"

[dheera]

... and this is the opposite of the other 2 responses

[patmorgan23]

/x is almost always the number of network bits (so the first half). There are some Cisco ISO commands that are the opposite but those are by far the minority.

99/100 it means the first bits.

[hot_gril]

Maybe the only equivalent is to penalize a /32, since there are roughly as many of those as there are ipv4 addresses.

[janosdebugs]

That may be true mathematically, but there are no guarantees that a small provider won't end up having only a single /64, which would likely be the default unit of range-based blocking. Yes, it "shouldn't" happen.

[dfox]

You cannot reasonably build an ISP network with single /64. RIPE assigns /32s to LIRs and LIRs are supposed to assign /48s downstream (which is somewhat wasteful for most of kinds of mass-market customers, so you get things like /56s and /60s).

[janosdebugs]

As I said, "should". In some places there will be enough people in the chain that won't be bothered to go to the LIR directly. Think small rural ISPs in small countries.

[hot_gril]

What if it uses NAT v6 :D

[1oooqooq]

i cannot tell if facetious or business genius.

[hot_gril]

Right. It's analogous to how blocking an ipv4 is unfair to smaller providers using cgnat. But if someone wants to connect to your server, you might want them to have skin in the game.

[janosdebugs]

The provider doesn't care, the owner of the server who needs to log in from their home internet at 2AM in an emergency cares. Bad actors have access to botnets, the server admin doesn't.

[hot_gril]

Unfortunately the only answer is "pay to play." If you're a server admin needing emergency access, you or your employer should pay for an ISP that isn't using cgnat (and has reliable connectivity). Same as how you probably have a real phone sim instead of a cheap voip number that's banned in tons of places.

Or better yet, a corp VPN with good security practices so you don't need this fail2ban-type setup. It's also weird to connect from home using password-based SSH in the first place.

[Sanzig]

Well, allocating anything smaller than a /64 to a customer breaks SLAAC, so even a really small provider wouldn't do that as it would completely bork their customers' networks. Yes, DHCPv6 technically exists as an alternative to SLAAC, but some operating systems (most notably Android) don't support it it all.

[tsimionescu]

There are plenty of ISPs that assign /64s and even smaller subnet to their customers. There are even ISPs that assign a single /128, IPv4 style.

[patmorgan23]

We should not bend over backwards for people not following the standard.

Build tools that follow the standard/best practices by default, maybe build in an exception list/mechanism.

IPv6 space is plentiful and easy to obtain, people who are allocating it incorrectly should feel the pain of that decision.

[cereal_cable]

I can't imagine why any ISP would do such absurd things when in my experience you're given sufficient resources on your first allocation. My small ISP received a /36 of IPv6 space, I couldn't imagine giving less than a /64 to a customer.

[aftbit]

My ISP has a /28 block, so if they chose to penalize my /32 for some reason, that would include 1/16th of the customers of my ISP. Just guessing based on population and situation, that might include on the order of 50000 people.

[adraenwan]

related: https://adam-p.ca/blog/2022/02/ipv6-rate-limiting/