Hello, I think your link to ripe-690 is wrong. This document primarily has a different purpose, different audience - as described in introduction. Also, in AUP [1] you talk about limits related to "IP address", not about limits per "user site". So you even don't follow terminology... those are two totally different things. This applies also to FAQ you linked [2], there's nothing like "your colleagues in your LAN performed too many queries" (which is exactly what happens). It seem you use ripe-690 like "each desktop computer obtains /64", but that's not a common use-case for IPv6 addressing. IP address is exactly defined technical term. It's meaning is the same for both IPv4 and IPv6. There's *no* mention about user site in AUP. I have to ask why NCC implements something other than its own docs says? As mentioned by Gert, "end user site" is bad metric here. As has been said already, there's no problem with blocking subnets as an escalation procedure in case of deliberate address changes with the aim of bypassing the AUP. But the first step should be to block IP address (as described in AUP), not blocking whole user site. - Daniel [1] https://apps.db.ripe.net/docs/RIPE-Database-Acceptable-Use-Policy/#limits [2] https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den... On 8/5/24 10:27 AM, Edward Shryane wrote:
Hello Daniel,
On 2 Aug 2024, at 13:24, Daniel Suchy via db-wg <db-wg@ripe.net> wrote:
Hello,
On 5/15/24 1:28 PM, Edward Shryane via db-wg wrote:
But of course you could also switch IP address and continue to query, it's difficult to prevent this if the queries are anonymous. We account by /32 prefix for an IPv4 address and by /64 prefix for an IPv6 address.
I think this is bad approach. Why on IPv4 you block only single host, but on IPv6 whole subnet?
We account by smallest end user site, which can be a single user, i.e. /32 for IPv4 or /64 for IPv6.
The argument that the source address can be changed is equally valid for IPv4 and IPv6.
But in the case of IPv6, you're blocking the entire subnet with multiple stations, even if only one address is problematic.
We account for queries on a /64 because that's the smallest size of an end-user site, which could be a single user: https://www.ripe.net/publications/docs/ripe-690/
A downside of accounting more specific than a /64 is that it's straightforward for a user to change their IPv6 address to work around the accounting.
That's real issue I faced past days - my own script on my workstation hit due to programming error AUP limits. As I use IPv6, whole /64 subnet was blocked and not even colleagues in same subnet could use whois at that time. This would'nt happen with IPv4.
This can also happen for IPv4 as we account by /32 prefix size, e.g. a single user or many (NAT) can be behind a single IPv4 address.
If a user is temporarily blocked (for the rest of the current day), we do return an error on every subsequent query:
ERROR:201: access denied for <IP address>
Queries from your IP address have passed the daily limit of controlled objects. Access from your host has been temporarily denied. For more information, see https://apps.db.ripe.net/docs/FAQ/#why-did-i-receive-an-error-201-access-den...
The "more information" link explains how to avoid getting blocked in the future, i.e. use the "-r" flag to not receive associated contact information.
A user can also contact RIPE NCC support for assistance.
We could also change the default behaviour so that referenced objects are not returned, so a user must make a subsequent query for contact information. This change needs discussion and consensus by the community.
This is even not good for promoting IPv6, treat IPv6 differently than IPv4 and in a way (rules) that are actually worse for IPv6.
Please review this and treat both IPv4 and IPv6 in the same manner.
We account the same by smallest end user site, both for IPv4 and IPv6.
Regards Ed Shryane RIPE NCC
- Daniel ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/db-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/