Summary

  • RFC 9977 gives operators a way to publish end-site prefix lengths and, for CGN or proxy use, a count attached to a declared prefix length.
  • Its own security section warns that a publisher can falsely claim CGN to evade legitimate throttling. A signed file is therefore evidence with a boundary, not a rate-limit order.

The number that catches the eye is 4,000. In RFC 9977, it is an example of how a Carrier-Grade NAT prefix can say that 4,000 end sites sit behind a /24. The document's purpose is practical: content providers otherwise struggle to know how finely an ISP or cloud operator assigns address space. Prefix grouping affects blocklists, throttles, CAPTCHAs and geolocation. The example explains a CSV field. It does not report a real network, certify a population, or prescribe a content provider's policy.

What the file says

Each non-comment row has three fields: a prefix, an end-site prefix length, and—where CGN or a proxy is relevant—the number of end sites per such prefix. A publisher can explicitly withhold both latter fields. Consumers must then discard a covering prefix's information for that more-specific range. They must use longest-prefix matching, regard duplicate prefix rows as errors, skip erroneous rows and continue.

Those are valuable limits. They say that a prefix file is not a single global truth table. It is a scoped publication, interpreted against a particular address range and parsing discipline. The prefixlen: reference is intended for an RPSL inetnum object; during migration, RFC 9977 also permits a case-sensitive remarks: Prefixlen URL. HTTPS protects the fetch. It does not, by itself, authenticate IP address-space assignment.

What an optional signature adds—and does not

RFC 9977 permits an RPKI-backed signature over the file. The signer certificate must cover every listed range, and a validator checks the certificate path, manifest, CMS signature and the expected content type. RFC 6481 describes a resource certificate as binding a public key to enumerated address blocks and AS numbers; the subject can demonstrate holding those enumerated resources by signing.

That is a useful answer to a narrow question: did a credentialed resource holder sign this file, and do its covered ranges fit the file? It is not an audit of the end-site count, a proof that this request came from one of those sites, a promise that the state is current, or a service entitlement. RFC 9977 makes the distinction unusually concrete. Its security considerations say a network operator can publish bad data deliberately, including a false CGN annotation to get around legitimate blocking or throttling. It also warns that extreme specificity or huge files can exhaust consumers.

The local decision remains local

The standard says a service provider can use a CGN signal so rate limits are adjusted. “Can” matters. A consumer still owns the evidence it needs: the signed-file validity; the prefix range; freshness and cache state; data-quality and abuse controls; the request's own behavior; the applicable policy; the action; and its observed result. A file can open a review. It cannot close the decision.

Heng Lu's distinction is useful here without being an IETF rule: a common, machine-readable artifact should remain a common artifact. Publishing it does not move a content provider's risk budget, customer duty or enforcement authority into the publisher's CSV. Treat it as a precise input; keep the consequential choice with the system that will bear it.