Prefix Length Internet Standard Proposal

At a recent IETF meeting, I shared an update on the "prefix length" internet draft, which is joint work I’ve done with Randy Bush at IIJ Research & Arrcus, Massimo Candela at NTT, and Russ Housley at Vigil Security. The motivation behind this draft is straightforward: service providers often need to understand how much IP address space is allocated to a given customer. This information is useful for situations like blocklisting, throttling, rate limiting, and CAPTCHAs.

Imagine a scenario where a neighboring IP address gets blocked, and you get caught in the crossfire simply because you're in the same /24 or /21 prefix. It’s a frustrating issue. Our proposed solution introduces prefix length files, a lightweight, structured way to declare the size of an IP allocation made to a customer.

Much like geofeeds (used to map IPs to geographic locations), prefix length files help reduce this kind of collateral damage. By signaling how IP space is subdivided, they allow systems to apply more precise filtering, improving both security and user experience.

What Do These Files Look Like?

Prefix length files are published in CSV format. 

Without CGN

When ISPs assign IP prefixes directly to end-users without Carrier-Grade NAT (CGN), the prefix length file includes the prefix in the first field and the assigned prefix length in the second field. The third field (number of end-sites) is optional and defaults to 1.

2001:db8::/32,56,

192.0.2.0/24,32,

With CGN

To indicate CGN usage, the third field is used to specify the number of end-sites sharing the IP space. If the second field is empty, the count applies to the full prefix; if filled, it applies to the subprefix.

Examples:

• Full /24 prefix with 4000 CGN end-sites:

 192.0.2.0/24,,4000

• Each /26 subprefix with 1000 end-sites

 192.0.2.0/24,26,1000

Omitting Prefix Lengths

If both second and third fields are empty, no prefix length information is disclosed. This overrides any inherited data from broader prefixes.

192.0.2.0/28,,

Longest Prefix Matching

When overlapping prefixes exist, the longest (most specific) match takes precedence in parsing.

2001:db8::/32,120,

2001:db8:abcd::/48,64,

Publishing Prefix Length Files

As with geofeeds, these files are published via the WHOIS database under the inetnum class. We currently propose two approaches:

1. Using the remarks field to link to the prefix length file.
2. Introducing a dedicated attribute or a generic metadata scheme for external references (future-friendly).

This mechanism is also compatible with RDAP, and an optional authentication layer using RPKI can be applied for data integrity.

Thanks to Massimo, we already have a prototype prefix length finder, a tool similar to the geofeed finder, which crawls the WHOIS to discover these published files.

Security Considerations

We’ve expanded the draft's security section based on community feedback. Some key concerns include:

• Trust: Only ingest prefix length files from known and trusted networks.
• Abuse potential: Attackers could use this data to refine DDoS targeting or scanning campaigns by knowing exact customer boundaries.
• Misleading data: Files could be incorrect, intentionally or not, so validation and caution are advised.

These considerations should be seen as guideposts for safe implementation. They’ve been added to help operators understand what’s at stake when implementing the draft.

What’s Next?

Since the last IETF, the draft has been officially adopted as a working group draft. We've refined the language, added security detail, and fixed typos. The draft is currently under review within the working group and will then be submitted for review to the IETF Security Directorate.

If you're a network operator, security engineer, or service provider, we encourage you to review the draft and consider how prefix length files could improve the granularity and safety of your IP-based policy decisions.

We welcome feedback, either via the IETF mailing list or directly. Thanks for your interest and engagement!