A new IETF document, RFC 9977, has been published as a Proposed Standard, and we wanted to share what it does and why it matters. We are especially glad to see it reach this stage, as our colleague Oliver Gasser is one of its co-authors, alongside Randy Bush, Massimo Candela, and Russ Housley.
The problem it solves
When someone visits your website, you see their IP address. What you do not see is how many other people share the same block of addresses.
That gap causes real, everyday headaches:
- Blocking and throttling. If you try to block a single troublemaker, you might accidentally affect innocent neighbors who happen to sit in the same block. Aim too narrowly instead, and you can miss the target entirely.
- Rate limits and CAPTCHAs. The same uncertainty means unrelated users can get lumped together, hit a shared limit, and end up blocked or stuck solving CAPTCHAs.
- Geolocation. Guess the block size wrong, and you either group together people in different places or fill your database with redundant entries.
The root cause is simple: there has been no easy way to learn how big a chunk of addresses a provider assigns to each customer.
“But isn’t this already in WHOIS?”
A fair question, and a common one. The answer is: partly, but not at the level you need.
WHOIS tells you the large block a provider was given, for example that an ISP holds 2001:db8::/32. What it does not tell you is how that provider then slices that block up among individual customers, whether each home gets a /56, a /64, or something else. That internal subdivision is the missing piece, and it is exactly what this standard adds. As the RFC notes, this data can carry finer detail than the WHOIS entry that points to it.
It also fills two other gaps:
- Shared-NAT information. A provider can now signal something like “this block has 4,000 customers sitting behind one NAT,” which is very helpful for setting fair rate limits. WHOIS has no field for that.
- A clean, consistent format. WHOIS data varies across the five regional registries. This standard uses a single, simple format everyone can read the same way.
Importantly, the new system does not replace WHOIS. It rides on top of it: the WHOIS record is where you go to find the link to the new file.
How it works
The standard introduces a small, spreadsheet-style file (a CSV) called a prefixlen file. Each line lists a block, how that block is divided among customers, and, where relevant, how many customers share it behind a NAT.
Discovery happens through the registries that already track who owns which addresses. A provider adds a reference in their registry record pointing to the file’s location. Anyone who needs the detail can follow that link.
There is also an optional signing step. A provider can digitally sign the file using RPKI, so that anyone reading it can confirm it genuinely came from the legitimate holder of the address space and was not tampered with.
What the file looks like
The format is intentionally simple. Each line has three comma-separated fields: the prefix, the prefix length given to each end-site within it, and the number of end-sites where shared NAT or proxies are in use. Lines use UTF-8 text, anything after a # is treated as a comment, and blank lines are ignored. A couple of short examples:
2001:db8::/32,56,1 # each customer gets a /56, no shared NAT
192.0.2.0/24,24,4000 # 4,000 customers share this block behind NAT
Leaving the last two fields empty is a valid way to say “we prefer not to disclose this.”
How the data is checked
The standard sets out clear rules so consumers can trust what they read:
- Format checks. Each non-comment line must have exactly three fields. Entries that do not parse correctly are skipped and logged, and processing continues with the rest of the file.
- One entry per prefix. A prefix appearing more than once is treated as an error, so there is no ambiguity about which value applies.
- Most specific wins. When prefixes overlap, longest-prefix matching decides which entry applies, the same principle used in routing.
- Stay in your lane. A consumer ignores any data that falls outside the address range the registry record actually points to, which prevents a publisher from making claims about space they do not hold.
- Signature validation. If a file is signed, the RPKI signature is checked against the address holder’s certificate before the data is trusted. A signed file is preferred over an unsigned one for the same range.
How it relates to geofeeds
If you have worked with geofeeds (RFC 9632), this will feel familiar. The two are companions:
- Geofeeds tell you where addresses are located.
- Prefixlen files tell you how addresses are divided among end customers.
Together, they give operators and content providers a clearer, more accurate picture to work from.
Why we care
More accurate, openly published information about address space benefits everyone: fewer innocent users caught in broad blocks, fairer rate limits, and better geolocation. We are happy to have contributed to this effort and look forward to seeing adoption grow across the registries.
You can read the full standard at the RFC Editor.
We would like your comments
This is an area we are actively working on, and your input would be valuable. If you publish or consume address-space data, we would like to hear from you: Does the file format fit how you work? Would you consider publishing prefixlen files for your own ranges? Are there processing or validation details you would like us to cover in more depth? Please share your thoughts in the comments below.