From Internet Draft to RFC: Prefix Length Files Become an Internet Standard

A little over a year ago, I wrote about a proposal our team had been developing: a simple way for network operators to publish how they assign IP address space to their customers.

I'm pleased to share that work has reached an important milestone.

The specification has now been published as RFC 9977, making prefix length files an official IETF Proposed Standard. I'm grateful to have worked on this alongside Randy Bush, Massimo Candela, and Russ Housley, as well as everyone in the IETF Operations and Management Area Working Group who reviewed and improved the document along the way.

Publishing an RFC doesn't mean the work is finished, but it does mean the Internet community now has a common, documented way to solve a problem that has existed for years.

The Missing Piece Between WHOIS and Reality

For decades, we've known who owns an IP address block. What we've generally not known is how that organization divides the block among its customers.

An ISP might receive a /32 IPv6 allocation, but does each customer receive a /48? A /56? A /64? Is an IPv4 block assigned directly to one customer, or shared by thousands of subscribers behind Carrier-Grade NAT?

Those details matter because many operational decisions depend on understanding the boundary between one customer and another. Without that information, security systems often have to guess.

That guess affects everything from blocklists and rate limiting to CAPTCHAs and abuse handling. Guess too broadly and legitimate users become collateral damage. Guess too narrowly and malicious activity slips through.

RFC 9977 introduces a straightforward way for operators to publish that missing context.

A Small Addition With Broad Benefits

One of the things I appreciate most about this standard is that it builds on existing Internet infrastructure.

Like geofeeds, prefix length files are simple CSV files that operators publish themselves. Existing WHOIS and RDAP records simply point consumers to those files. Optional RPKI signatures provide an additional layer of authenticity for operators who want cryptographic verification.

The result is a lightweight mechanism that is easy to publish, easy to consume, and compatible with existing operational workflows.

For operators that consume IP intelligence, this additional context enables more informed decisions without requiring new protocols or major infrastructure changes.

Better Decisions Across the Internet

Although the motivation came from operational networking, the applications extend well beyond that: 

• Security teams can make more precise blocklisting and abuse mitigation decisions.
• Content providers can apply fairer rate limits by understanding whether thousands of users share the same public address space.
• Geolocation providers can model customer assignments more accurately, reducing unnecessary duplication while improving precision.
• Researchers gain a better understanding of how address space is deployed across different networks.

In many cases, the information has always existed inside the provider's network. RFC 9977 simply creates a standardized way to share it when operators choose to do so.

A Community Effort

Standards are rarely written in isolation. Since the first version of this draft, we've incorporated extensive feedback from operators, registry experts, implementers, and security reviewers throughout the IETF process.

That feedback strengthened the document considerably.

The final RFC includes clearer processing rules, additional guidance around security considerations, support for authenticated publication using RPKI, and more precise recommendations for consumers validating published data.

This collaborative review process is one of the strengths of the IETF. The resulting document is significantly better than the original draft because so many people contributed their expertise.

What Happens Next

Publishing an RFC is an important milestone, but adoption is where the real value appears.

The next step is seeing network operators publishing prefix length files, software vendors adding support for consuming them, and content platforms/CDNs/security companies actually consuming them.

As happened with geofeeds, adoption will likely grow incrementally. Tooling will mature, operational experience will accumulate, and the ecosystem will evolve as more organizations recognize the value of sharing this information.

We're already seeing early implementations emerge, including discovery tools that locate published prefix length files through registry data. I expect the ecosystem around the standard to continue expanding over time.

Why This Matters to IPinfo

At IPinfo, our goal is to help people better understand how the Internet actually behaves.

Standards like RFC 9977 make the Internet itself more transparent. They allow network operators to publish authoritative information directly instead of leaving others to infer it.

That philosophy aligns closely with how we think about internet data: wherever possible, decisions should be grounded in directly published or directly observed information rather than educated guesses.

I'm excited to see where the community takes this next, and I hope RFC 9977 becomes another useful building block for making Internet operations more accurate, fair, and reliable.

If you're interested in the details, I encourage you to read the full RFC and consider whether publishing prefix length information could benefit your own network, or whether consuming it could improve the systems you already operate.