Support individual IPv6 inside list

Website, Application, Performance
1

Follow-up of

and

Suggesting using /64 (banning 18446744073709551616 IP addresses) instead of banning IPv6 individually doesn’t sound acceptable and is not a behavior susceptible to improve IPv6 connectivity in the long run. I don’t want to ban a whole datacenter or mobile-provider just because one of its IP address is misbehaving.

It shouldn’t be hard to allow individual IPv6 or allow granular IPv6 in lists.

3

An IPv6 /64 is a single host, not a datacenter or mobile provider. An individual device is allocated a /64, and many operating systems rotate the actual addresses used rather than using just one address. The usual practice for home connections is for the ISP to allocate a /56, providing the customer the ability to have multiple network segments, each with a /64.

Prefixes larger than /64 aren’t meant to be used for network segments. Blocking an individual IPv6 address will prove useless as the next connection from a device could come from a different address in that /64.

3 Likes
4

Hi @Raphd, your topic has a solution here.

Let us know what you think of the solution by logging in and give it a :+1: or :-1:.

Solutions help the person that asked the question and anyone else that sees the answer later. Login to tell us what you think of the solution with a :+1: or :-1:.

5

Quoting RFC 3177, assignments are to be made using the following guidelines:

/48 in the general case, except for very large subscribers.
/64 when it is known that one and only one subnet is needed by design
/128 when it is absolutely known that one and only one device is connecting.

We do have real-world scenarios were a host is allocated a single IP-address. Blocking a /64 would affect unrelated neighbors on this /64.

To give one precise example (among multiple others), OVH (EU hosting provider) VPS are allocated a /128. If one of them misbehave, we definitely don’t want to block the 18446744073709551615 others.

I maintain that the prefix is something to be decided by the user without any (wrong) assumptions from Cloudflare on IPv6 allocation (which is a decision of each LIR)

6

Quoting RFC 6177:

This document obsoletes RFC 3177, updating its recommendations in the following ways: 1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site, by definition, implies multiple subnets and multiple devices.

Customers of that provider are definitely going to have to deal with that, especially with email. It’s trivial for a spammer to use a new IPv6 address for every message, so blacklists block at the /64 level.

Yes, this is a reasonable argument, but with people still in an IPv4 mindset, if Cloudflare did this, many customers would block by individual IPv6 address because that’s what you do with IPv4 addresses. This would be ineffectual and would create many complaints.

Even now, blocking individual IPv4 addresses can be problematic because many of them are shared among a large number of unrelated users. This already causes problems, but there’s not much you can do since IPv4 is exhausted but people still insist on using it for some reason.

So while it’s not an unreasonable request (it could come with a warning in the UI, for example), I don’t think it’s as obvious as it sounds.

2 Likes
7
  1. It no longer recommend, but doesn’t advise against either, so it should be assumed /128 may still be assigned (to individual machine)
  2) RFC 3177 specifically recommended using prefix lengths of /48,
     /64, and /128.  Specifying a small number of fixed boundaries
     has raised concerns that implementations and operational
     practices might become "hard-coded" to recognize only those
     fixed boundaries (i.e., a return to "classful addressing").
     The actual intention has always been that there be no hard-
     coded boundaries within addresses, and that Classless Inter-
     Domain Routing (CIDR) continues to apply to all bits of the
     routing prefixes.

Next section of said RFC is even more interesting, they removed /128 and others to avoid hard-coding which was not their intention and that **Classless Inter-Domain Routing (CIDR) continues to apply to all bits of the routing prefixes.

So they are not removing /128 in order to hard-code /64, they are removing all hard-coding so that no-one (including Cloudflare) makes (wrong) assumptions about prefixes.
This tend to re-enforces my perception about hard-coding a /64 in Cloudflare list.

It’s their problem. But a warning could be indeed be the right approach to the problem.

8

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.