Contextual IP Prefix Semantics (CIPS)

3.1. The Short-Term Plan That Endured

[RFC1338], published in June 1992 under the title "Supernetting: an Address Assignment and Aggregation Strategy", proposed a short-term response to IPv4 address depletion and routing-table growth. It expected the strategy to remain viable for at least three years while a longer-term architecture was deployed.¶

[RFC1519], published in September 1993, gave CIDR its established name and obsoleted RFC 1338. [RFC4632], published in August 2006, obsoleted RFC 1519 and observed that the original three-to-five-year plan had far outlasted its anticipated lifetime. The temporary response had become a durable part of Internet architecture.¶

The enduring contribution was not the slash character. It was a related set of invariants and operations:¶

• prefix boundaries are explicit rather than inferred from address classes;¶

• a prefix length counts contiguous bits from the most-significant end;¶

• address space can be assigned hierarchically;¶

• reachable destinations can be aggregated; and¶

• forwarding can select the longest matching prefix.¶

Classlessness remains necessary, while classful allocation is now historical. [RFC4291] defines an IPv6 prefix length as the number of leftmost contiguous bits comprising the prefix. [RFC6177] warns against hard-coding a small set of IPv6 prefix boundaries, and [RFC7608] requires IPv6 forwarding to support prefix lengths through /128 in one-bit increments.¶

These principles remain the mathematical foundation for the diverse uses of prefixes described in this document. Their application across operational roles requires preserving both the shared prefix semantics and the context that gives each object meaning. That continuity does not imply that context was absent from earlier assignment and routing practice.¶

3.2. Terminology Index

• CIDR means Classless Inter-domain Routing as specified by BCP 122. Its expansion and underlying classless semantics remain unchanged.¶

• CIPS means Contextual IP Prefix Semantics, the analysis model defined by this document.¶

• Semantic forms are address, canonical prefix, address with prefix context, and prefix selector, as defined in Section 4.2.¶

• Operational context comprises the namespace, role, matching semantics, associated attributes, authority or provenance, and lifetime described in Section 4.3.¶

Operators often use "a CIDR" colloquially to mean any written IP prefix. That usage does not by itself claim BCP 122 prefix semantics or preservation of CIPS semantic form and context.¶

4.1. Foundational CIDR Prefix

A canonical CIDR prefix consists of:¶

CIDRPrefix =
    AddressFamily
  + SignificantPrefixBits
  + PrefixLength

PrefixLength counts contiguous significant bits from the most-significant end of an address. Its valid range is 0 through 32 inclusive for IPv4 and 0 through 128 inclusive for IPv6. Bits after the prefix boundary are zero in the canonical form. A non-contiguous IPv4 mask does not describe a CIDR prefix and cannot be represented by a prefix length.¶

Figure 2 shows examples of canonical IPv4 and IPv6 prefixes.¶

IPv4: 192.0.2.0/24 (binary)
             Significant prefix bits             Non-prefix bits
                     24 bits                         8 bits
+-----------------------------------------------+---------------+
|          11000000 00000000 00000010           |   00000000    |
+-----------------------------------------------+---------------+

IPv6: 2001:db8:1234::/48 (hexadecimal)
 Significant prefix bits             Non-prefix bits
         48 bits                         80 bits
+-----------------------+---------------------------------------+
|    2001:0db8:1234     |       0000:0000:0000:0000:0000        |
+-----------------------+---------------------------------------+

These examples show canonical prefix representations; addresses covered by each prefix may have nonzero bits after its prefix boundary.¶

A prefix denotes a power-of-two-sized address set. An arbitrary closed address range is a different mathematical form; [RFC3779] demonstrates that a range can require multiple prefixes even though every prefix can be expressed as a range.¶

CIPS applies semantic form and operational context to this shared CIDR prefix mathematics (see Figure 1). This is an analysis model, not a required wire structure.¶

4.2. Semantic Forms

An address retains all bits of one IPv4 or IPv6 address. It denotes an address-sized value rather than a prefix-shaped set. A scoped IPv6 address can additionally require a zone identifier. Address is included here as an adjacent form because confusing it with a prefix is a common source of semantic loss.¶

A canonical prefix retains the significant leading bits and a prefix length. Bits after the prefix boundary are zero in this form and do not distinguish its identity. 192.0.2.0/24 is a canonical prefix.¶

The writing 192.0.2.123/24 has non-zero bits after length 24. Those bits do not, by themselves, determine the form. In an address-with-prefix value they are part of the identity, defined next; obtaining 192.0.2.0/24 from that value is a lossy projection onto a different form, not a restatement of the same object. In a canonical-prefix value the same bits are insignificant; writing them as zero is representation canonicalization of that prefix, not a form change. Which of those applies is determined by the containing field, type, or other declared semantics, not by the writing.¶

An address with prefix context retains a complete address and an associated prefix length. 192.0.2.123/24 can identify an interface address and the prefix used to interpret its attachment.¶

In a context that expects a canonical prefix and accepts a slash-less writing, 192.0.2.123 denotes the singleton prefix 192.0.2.123/32; an IPv6 address is treated correspondingly as a /128. The family-maximum prefix length makes every address bit significant. Section 3.1.2 of [RFC9164] specifies this interpretation for its CBOR Address Format when used where a prefix is expected. Under the same convention in textual interchange, completing the writing is representation normalization: it makes the implied length explicit. Conversely, omitting a family-maximum length preserves singleton coverage and permits reconstruction of the same canonical prefix when that interpretation remains established. Neither writing alone establishes an interface assignment, route, policy match, or other operational role. By contrast, 192.0.2.123/24 in an address-with-prefix context preserves both the complete address and its associated length; omitting that length loses prefix context.¶

A prefix selector denotes a set of prefixes or a matching relation. Its identity can include a base prefix, an inclusive or exclusive relation, and minimum or maximum prefix-length bounds. A selector is not equivalent to its base prefix. For example, each ROAIPAddress entry in a Resource Public Key Infrastructure (RPKI) Route Origin Authorization (ROA) combines a base prefix with an optional maxLength; the ROA binds the resulting authorization to an Autonomous System (AS); see [RFC9582].¶

[RFC9164] defines distinct Address, Prefix, and Interface Formats in Concise Binary Object Representation (CBOR); they correspond respectively to address, canonical-prefix, and address-with-prefix semantics here. [RFC9911] likewise defines separate YANG types for ip-address, ip-prefix, and ip-address-and-prefix. An ip-address-and-prefix value is one object: a complete address together with a prefix length. The length is associated context for that address. The containing canonical prefix is a different type, ip-prefix. Treating ip-address-and-prefix as if it were ip-prefix is a lossy projection onto a different form, not a restatement of the same object.¶

An ip-prefix value is a canonical prefix: unused bits are zero and are not identity. [RFC9911] requires that type to accept a writing such as 192.0.2.1/24 and to return the canonical prefix 192.0.2.0/24. That return is representation canonicalization of the prefix-typed value, not construction of an address-with-prefix object. This document does not require every encoding to accept non-zero unused bits; [RFC9164] Prefix format requires those bits to be zero on the wire. If prefix-typed input is accepted, the value is the canonical prefix. ip-address-and-prefix retains the full address. A value that preserves host bits is therefore not a store for a canonical prefix. These distinctions are semantic, not merely representational, and appear in standardized encodings and data models.¶

4.3. Context Qualification

Context qualification is orthogonal to the base forms rather than an additional peer form:¶

IPValueForm =
    Address
  | CanonicalPrefix
  | AddressWithPrefixContext
  | PrefixSelector

CIPSValue =
    IPValueForm
  + OperationalContext

CIPS centers on prefix-bearing forms but includes address as an adjacent form. Context such as an IPv6 zone or an anycast role can be necessary to identify an address correctly and to keep it distinct from a prefix-shaped value.¶

Operational context can contain:¶

OperationalContext =
    Namespace
  + Role
  + MatchSemantics
  + AssociatedAttributes
  + AuthorityOrProvenance
  + Lifetime

Not every context uses every component. These names are analytical vocabulary for kinds of information that can be lost when a richer object is collapsed into a bare prefix or string. They do not define a schema or require every implementation to store every field.¶

• Namespace is the address realm in which the prefix bits are interpreted. The same bits in two routing tables, VRFs, Route Distinguishers, tenants, or other isolated realms are not the same object. For example, 10.0.0.0/8 in one tenant is not 10.0.0.0/8 in another.¶

• Role is the operational job of the value: what kind of assertion it is. The same writing can be an allocation, an interface assignment, a route destination, a filter operand, an origin authorization, or a telemetry key. For example, 192.0.2.0/24 as a registry assignment is not the same object as 192.0.2.0/24 as a BGP destination.¶

• Match semantics is how the value is applied as a predicate: what it matches and by which relation. Address-set membership, exact-prefix equality, more-specific selection, longest-prefix match, and bounded length ranges are different match semantics. For example, 203.0.113.0/24 used as an exact prefix-list entry is not the same match as that prefix used as orlonger or as an ACL address-set. When the relation and length bounds are part of the value itself, the value is a prefix selector (see Section 4.2) rather than a bare prefix plus separate match-semantics context.¶

• Associated attributes are companion fields that are not the prefix but that the operation needs in order to be meaningful. Examples include BGP path attributes and next hop, ACL direction, action, and rule order, interface identity, and on-link or autonomous-configuration flags. For example, 192.0.2.0/24 with one AS_PATH is not interchangeable with the same prefix carrying a different AS_PATH.¶

• Authority or provenance is who asserted the value, on what basis, and where it came from. Examples include a Regional Internet Registry (RIR) allocation [RFC7020], a ROA and its issuing trust anchor, an IRR object, local configuration, or a looking-glass snapshot. For example, collapsing a ROA to the base prefix discards the authorized origin AS and the authority that signed it.¶

• Lifetime is the interval during which the assertion is intended to hold. It is not the prefix length. Examples include allocation or lease validity, SLAAC preferred and valid lifetimes, a ROA validity window, and the age of telemetry. For example, a prefix that was authorized last year is not interchangeable with a currently valid authorization for the same bits.¶

A route might therefore require a routing-table namespace, a destination role, longest-prefix or policy match semantics, path attributes, and a source of the route. An allocation might require a registry namespace, an allocation role, authority, parentage, and validity. An access-control-list operand might require source or destination role, address-set or prefix-match semantics, direction, action, and rule order.¶

4.4. Composition of Roles

Distinct contextual objects can participate in a common operational purpose. The operator or containing system declares that purpose and explicitly associates the participating objects. Matching prefix bits or the presence of particular roles does not establish the relationship. Composition relates objects; it does not introduce another semantic form.¶

For example, providing and operating numbered IPv4 point-to-point connectivity between two routers may involve:¶

• Allocation: A record reserving 192.0.2.0/31 for the connection.¶

• Interface assignments: Two address-with-prefix objects, one per end:¶

  • Router 1 (R1): 192.0.2.0/31 assigned to its interface toward R2.¶

  • Router 2 (R2): 192.0.2.1/31 assigned to its interface toward R1.¶

• Routing: Routing state associated with the intended reachability, such as a connected route for 192.0.2.0/31 on each router. These routes can result from the interface assignments while remaining distinct contextual objects.¶

• Reverse DNS (optional): PTR records associating each interface address with a diagnostic name ([RFC1035], Section 3.5):¶

  • R1: 0.2.0.192.in-addr.arpa. IN PTR r1-to-r2.example.net.¶

  • R2: 1.2.0.192.in-addr.arpa. IN PTR r2-to-r1.example.net.¶

  Traceroute can display these PTR target names when reverse lookup is enabled and succeeds for those response addresses. These per-address mappings are distinct from reverse-zone delegation.¶

These are participating objects, not mandatory sequential steps or a requirement to advertise the /31. The assignments share the containing canonical prefix 192.0.2.0/31, but each object retains its identity and relevant context. A shared purpose does not merge forms, transfer authority between roles, or imply identical lifetimes. The records alone do not prove that the intended connectivity is working.¶

Figure 3 summarizes the participating objects in this example. IPAM denotes IP address management.¶

Declared purpose:
Provide and operate numbered IPv4 point-to-point
connectivity between R1 and R2.

Participating objects, explicitly associated by the operator:

                   +---------------------------+
                   | Allocation record (IPAM)  |
                   | 192.0.2.0/31              |
                   +---------------------------+

+-----------------------+                 +-----------------------+
| Router 1 (R1)         |                 | Router 2 (R2)         |
+-----------------------+                 +-----------------------+
| Interface assignment  |    Intended     | Interface assignment  |
| toward R2             | point-to-point  | toward R1             |
| 192.0.2.0/31          +------link-------+ 192.0.2.1/31          |
+-----------------------+                 +-----------------------+
| R1 routing table      |                 | R2 routing table      |
| Connected route:      |                 | Connected route:      |
| 192.0.2.0/31          |                 | 192.0.2.0/31          |
+-----------------------+                 +-----------------------+

                      Optional naming records

+-----------------------+                 +-----------------------+
| PTR record for        |                 | PTR record for        |
| 192.0.2.0             |                 | 192.0.2.1             |
+-----------------------+                 +-----------------------+

The allocation and connected-route objects use the canonical-prefix form. The interface assignments use the address-with-prefix-context form, retaining each complete interface address and its prefix length. In particular, R1's assignment and the allocation share the writing 192.0.2.0/31, but differ in semantic form and contextual identity.¶

The connecting line represents the intended point-to-point link, not verified connectivity. Grouping shows participation in a shared purpose, not provisioning order or shared authority. The optional PTR records use the complete owner and target names given in the example text.¶

Five questions help reviewers examine the composition at system level:¶

• Who: Who asserted the information, according to its provenance, and who authorizes the relevant action?¶

• What: What semantic form and operational role does each object have, and which operation applies to it?¶

• When: When is each assertion valid, and when was any supporting state observed? Observation time and validity are distinct.¶

• Where: In which namespace or address realm, at which attachment, and in which relevant deployment context does the object apply?¶

• Why: Which declared purpose or intended outcome relates these objects?¶

These are review questions, not mandatory fields on every prefix. They examine a composed deployment, whereas the support claims in the following section describe an implementation's capabilities. The containing system can supply the context and associations. Following those associations helps identify dependencies and consuming operations that a change could affect. Preserving this information supports accountability, safe action, and auditability; it does not guarantee them. Authorization, execution controls, and retention of evidence and history remain responsibilities of the containing system.¶

[RFC9315], Sections 3.1, 3.2.1, and 5, provides related terminology for intent, service models, and the realization and assurance of desired outcomes. A declared purpose here need not be an intent expression as defined there. CIPS vocabulary can support such systems by preserving the meaning of their prefix-bearing objects, without defining intent translation, orchestration, or assurance. CIPS remains independently useful; it is neither a formal subset nor a required dependency of that model.¶

5.1. Worked Support Statement

The following language-neutral example is non-normative. It illustrates a complete support statement but does not define a required syntax, schema, certification level, or capability-negotiation format.¶

• Address families: IPv4 and IPv6.¶

• Accepted input representations: IPv4 text uses four decimal octets without leading zeros. Every valid unzoned IPv6 text representation defined by [RFC4291] is accepted. Fields explicitly designate address, canonical-prefix, or address-with-prefix form, and prefix-bearing forms include a decimal prefix length. In canonical-prefix fields, input with non-zero non-prefix bits is rejected. Zone-qualified input is unsupported and rejected.¶

• Produced output representations: IPv4 output uses four decimal octets without leading zeros, and IPv6 output follows [RFC5952]. Prefix-bearing output appends the decimal prefix length after a slash. Canonical-prefix output has all non-prefix bits set to zero. Address and address-with-prefix output retain the complete address.¶

• Supported semantic forms: Address, canonical prefix, and address with prefix context are supported. Prefix selectors are unsupported and are rejected rather than reduced to their base prefixes.¶

• Supported relations and operations: Form-value equality, address membership, prefix containment, and overlap are supported.¶

• Conversion behavior: Projection from address with prefix context to canonical prefix is available only as an explicitly lossy operation.¶

• Operational context and preservation: No operational contexts are supported. Input carrying operational context, including a zone-qualified address, is rejected rather than silently stripped.¶

In this example a canonical-prefix field rejects input 192.0.2.129/25. The same input in an address-with-prefix field retains the complete address 192.0.2.129 and prefix length. This implementation could emit the canonical prefix 192.0.2.128/25 only through an explicit lossy projection of that address-with-prefix value. Slash parsing / prefix-length writing alone cannot determine the behavior without surrounding context.¶

By contrast, an implementation that stores 192.0.2.32/24 as an address with prefix context and offers an operation that returns 192.0.2.0/24 as a derived writing or as another address value is projection only. That operation does not preserve canonical prefix identity and does not constitute canonical-prefix support as described here, even when the derived bits are correct.¶

5.2. Selector Mathematics: RPSL as Example

The following is a worked example of selector mathematics, not an RPSL profile.¶

Routing Policy Specification Language (RPSL) provides a concrete example of selector semantics. Let P be a canonical prefix of length L in an address family whose width W is 32 for IPv4 or 128 for IPv6. For any integer k, define:¶

S(P,k) = {
    Q | Q is a canonical prefix,
        length(Q) = k, and
        addresses(Q) is a subset of or equal to addresses(P)
}

S(P,k) is empty when k < L or k > W. For integers n and m satisfying 0 <= n <= m <= W, the RPSL range operators defined by [RFC2622] can then be described as:¶

P       = { P }

P^+     = union S(P,k), for k from L through W

P^-     = union S(P,k), for k from L+1 through W

P^n     = S(P,n)

P^n-m   = union S(P,k), for k from n through m

P^+ is inclusive of the base prefix; P^- contains only proper more-specific prefixes. Consequently, /32^- for IPv4 and /128^- for IPv6 denote empty sets, while the corresponding ^+ selectors contain the base host-length prefix.¶

Range operators applied to prefix sets distribute over the members of those sets. Directly following one range operator with another is erroneous; [RFC2622] separately defines how an outer operator applies to a set whose members already contain ranges. [RFC4012] applies the same range-operator model to IPv6 prefix ranges.¶

The same selector relations appear under other syntaxes. For the base prefix P of length L, RPSL P^+ is the inclusive more-specific match commonly written orlonger or le of the family width; P^- is the exclusive more-specific match commonly written longer or ge L+1. A bounded length range P^n-m is commonly written prefix-length-range /n-/m or ge n le m. The upto /m match type is the special case P^L-m: lengths from L through m, inclusive of the base. It is not an arbitrary P^n-m. For example, 192.0.2.0/24^26-28 excludes /24 and /25, whereas 192.0.2.0/24 upto /28 includes them. An exact prefix-list or route-filter ... exact entry is the singleton {P}. Writings that denote the same bounds name the same selector relation. They are not interchangeable with P as a canonical prefix.¶

This example illustrates why selector conformance cannot be inferred from prefix parsing. A base prefix, its covered addresses, and the set of route prefixes selected by ^+, ^-, or a bounded length range are different mathematical objects.¶

6.1. Address Governance, Allocation, and Planning

Prefixes describe administratively controlled address space in:¶

• IANA, RIR, Local Internet Registry (LIR), and downstream allocations and assignments;¶

• address transfers and reservations;¶

• IP address management (IPAM) pools, sub-pools, and exclusions;¶

• subnetting, supernetting, and address plans;¶

• customer, infrastructure, loopback, point-to-point, and service-address pools;¶

• DHCPv6 prefix delegation; and¶

• special-purpose address registries.¶

Here the prefix commonly needs authority, parentage, organization or tenant, status, intended use, provenance, and validity information. Allocation does not by itself imply reachability or on-link status. DHCPv6 prefix delegation is described by [RFC9915], and special-purpose registry attributes by [RFC6890]. A covering allocation and the end-site assignment length used inside it are different objects. Treating the covering prefix as one site loses that distinction.¶

6.2. Interface Assignment and Link Semantics

Prefixes occur with physical interfaces, virtual interfaces, VLAN interfaces, loopbacks, point-to-point links, and host attachment.¶

An interface configuration commonly uses an address-with-prefix form rather than a canonical prefix. Additional context includes interface identity, zone, virtual routing instance, preferred and valid lifetimes, and whether a prefix is on-link or usable for autonomous address configuration.¶

An IPv4 /31 is a compact example of context-dependent link semantics. A canonical /31 is a two-address set. On an IPv4 point-to-point link, [RFC3021] interprets both addresses as usable hosts rather than withholding them as a traditional network or directed-broadcast address. RFC 3021 specifies this /31 host-address interpretation for point-to-point links; it does not establish /31 behavior for other interface types. /31 notation alone therefore does not establish point-to-point link or host-address semantics.¶

The same /31 writing appears in more than one role. The coverage is two addresses; the role is not implied by the length.¶

On a point-to-point link the two ends are distinct address-with-prefix values, 192.0.2.0/31 and 192.0.2.1/31. They share the containing canonical prefix 192.0.2.0/31.¶

These distinct objects can participate in a common operational purpose without losing their individual meanings; see Section 4.4.¶

A host-length writing (/32 or /128) makes the same point across more roles. The coverage is one address; the role is not implied by the length.¶

Host-length notation alone does not establish that the value is a host route, an interface assignment, a one-address filter, or a DNS naming relationship.¶

For scoped IPv6 addresses such as link-local unicast addresses, the address bits do not identify the zone: the same link-local address can be reused on different links, and a zone index cannot be assumed to have the same meaning on different nodes; see [RFC4007]. A model that permits scoped addresses needs either to carry the relevant zone identity or to state how the surrounding context supplies it.¶

IPv6 also makes link semantics explicit. Router Advertisement Prefix Information Options carry separate on-link and autonomous-configuration flags and lifetimes; see [RFC4861]. [RFC5942] cautions against inferring on-link semantics solely from an assigned address and prefix length.¶

6.3. Routing and Control-Plane Reachability

Routing contexts include:¶

• connected and static routes;¶

• IGP and BGP destinations;¶

• route origination and withdrawal;¶

• route redistribution;¶

• default, discard, aggregate, and more-specific routes;¶

• route summarization and deaggregation; and¶

• multiprotocol AFI/SAFI reachability.¶

A route is not merely a prefix. In BGP, destination prefixes are associated with path attributes; see [RFC4271]. Multiprotocol BGP adds AFI and SAFI context that determines the address family and semantics of Network Layer Reachability Information (NLRI); see [RFC4760].¶

Anycast is a distinct address role: the same service address is assigned to multiple discrete nodes, and routing directs packets toward one of those nodes; see [RFC4786]. The address alone does not identify a unique node or service instance. Anycast does not create a new prefix form, but it demonstrates why address or host-length-prefix syntax alone does not determine operational identity.¶

6.4. Forwarding

Forwarding contexts include Routing Information Base (RIB) and Forwarding Information Base (FIB) entries, recursive next-hop resolution, outgoing interface selection, and policy-selected routing tables.¶

The prefix is a destination match key associated with a forwarding action. Longest-prefix match provides one ordering relation, while administrative preference, route source, metrics, next hops, and routing-table namespace remain separate context. IPv4 router requirements describe this model in [RFC1812]; IPv6 forwarding support across prefix lengths is addressed in [RFC7608].¶

6.5. Routing Policy and Prefix Filtering

Routing-policy contexts include:¶

• inbound and outbound prefix lists;¶

• exact, more-specific, and bounded-length matches;¶

• import and export policy;¶

• route maps and policy statements;¶

• aggregation boundaries; and¶

• origin-AS-, AS-path-, community-, or neighbor-qualified selection.¶

A policy expression frequently denotes a set of candidate routes rather than one address set. Direction, peer, routing instance, action, rule order, and other route attributes can change the result even when the written prefix is identical.¶

BGP Flow Specification makes this structure explicit. A Flow Specification is an n-tuple of packet-match components associated with traffic-filtering actions. IPv4 Flow Specifications can include source and destination prefix components. IPv6 Flow Specification components additionally carry an offset and can therefore express bit-pattern matches that are not CIDR prefixes. Such a component falls outside CIDRPrefix even though it participates in the same higher-level policy rule. A prefix or pattern extracted from the rule is neither the complete selector nor its action; see [RFC8955] and [RFC8956].¶

6.6. Packet Filtering, Admission, and Source Validation

Security and admission contexts include:¶

• source and destination access-control-list (ACL) operands;¶

• ingress and egress filters;¶

• firewall and service-admission policy;¶

• anti-spoofing and reverse-path forwarding;¶

• cloud security groups and network-policy constructs;¶

• threat-intelligence and reputation sets; and¶

• logging, rate-limiting, and classification rules.¶

The prefix acts as a packet-match predicate. Source versus destination, ingress versus egress, attachment point, action, ordering, protocol, ports, and default policy are part of the object. Source-address validation makes this dependence concrete: [RFC2827] (BCP 38) describes filtering traffic originating from a downstream network against known, intentionally advertised source prefixes, while [RFC3704] (BCP 84), as updated by [RFC8704], derives permissible source sets from interface and routing context under different unicast Reverse Path Forwarding (uRPF) modes. [RFC8519] provides a YANG model for ACLs.¶

6.7. Internet Routing Registries and RPKI

Several related systems attach distinct assertions to prefixes:¶

• RIR registrations document the allocation or assignment of number resources;¶

• an Internet Routing Registry (IRR) route or route6 object declares an origin and routing-policy information;¶

• an RPKI resource certificate binds number resources to a certificate subject;¶

• a Route Origin Authorization (ROA) authorizes an Autonomous System to originate specified prefixes, optionally subject to maxLength; and¶

• validated ROA payloads provide route-origin-validation input.¶

None of these objects is itself an observed BGP route, and none proves every other assertion. In particular, a ROA's maxLength is an authorization bound, not the prefix's own length. Resource-certificate prefix and range semantics are defined in [RFC3779], and the current ROA profile is [RFC9582].¶

6.8. Aggregation and Address-Set Transformation

Prefixes are aggregated or normalized for:¶

• routing announcements;¶

• exact-coverage address-set minimization;¶

• ACL and admission-set preparation;¶

• IPAM pool coalescing;¶

• telemetry summarization; and¶

• operational reports.¶

Mathematical adjacency is not sufficient permission to aggregate. Exact address-set aggregation can preserve coverage while still losing provenance, tenant, lifetime, action, authorization, or route attributes. BGP route aggregation can also change path information and reachability behavior.¶

Aggregation is therefore contextual. Prefixes should be combined only when the operation preserves every property relevant to the consuming context.¶

6.9. VPNs, Overlays, Tenants, and Address Realms

Prefixes occur in Virtual Routing and Forwarding instances (VRFs), BGP/MPLS VPNs, EVPN, locator/identifier systems, software-defined networks, containers, and cloud tenant networks.¶

The same private prefix can legitimately exist in many isolated namespaces. For example, [RFC4364] combines a Route Distinguisher with an IPv4 prefix so otherwise identical VPN prefixes remain distinct. Removing namespace context can cause collisions, information disclosure, or incorrect policy.¶

6.10. Translation, DNS, and Service-Specific Prefixes

Some prefixes are parameters to another algorithm or hierarchy:¶

• IPv4/IPv6 translation and IPv4-embedded IPv6 prefixes;¶

• reverse-DNS delegation boundaries;¶

• source- and destination-address selection tables; and¶

• service-specific or protocol-reserved address blocks.¶

A translation prefix determines how address bits are embedded or extracted; [RFC6052] permits specific prefix lengths and defines associated behavior. For IPv6 address-to-name lookup, PTR owner names represent the full address as reversed hexadecimal nibbles under ip6.arpa. ([RFC3596], Section 2.5). Reverse DNS does not map every prefix boundary directly onto the DNS hierarchy; [RFC2317] describes classless IPv4 reverse delegation. [RFC6724] uses prefixes as host address-selection policy keys rather than as forwarding entries.¶

6.11. Multicast

Multicast contexts include group-address ranges, administratively scoped ranges, Source-Specific Multicast (SSM) ranges, and routing-policy or Rendezvous Point mappings.¶

A multicast group prefix classifies destination identifiers; it is not a unicast subnet and does not imply ordinary host, broadcast, or gateway semantics. In SSM, a channel is identified by (S,G), a source and group, not by the group prefix alone; see [RFC4607].¶

6.12. Measurement, Monitoring, Telemetry, and Topology

Prefixes are used as observation and grouping keys in flow telemetry, historical routing data, incident analysis, route collectors, the BGP Monitoring Protocol (BMP), and BGP Link-State (BGP-LS). The observed key is usually a canonical prefix; the role is the observation, not an allocation.¶

An observation can require timestamp, collector, peer, AFI/SAFI, routing instance, inbound or outbound direction, and pre-policy or post-policy view. Flow records and collector archives follow that pattern. BMP is specified in [RFC7854], with Loc-RIB monitoring in [RFC9069]. BGP-LS NLRI and topology context are specified in [RFC9552].¶

These two control-plane feeds illustrate the same prefix in different roles. BGP-LS describes where a prefix is attached in a topology, using node, link, and prefix NLRI together with traffic-engineering and segment-routing attributes. BMP reports what BGP currently advertised, accepted, and selected: Adj-RIB-In, Adj-RIB-Out, Loc-RIB, peer state, and path attributes. Neither feed is an allocation or a Route Origin Authorization ([RFC9582]). A Loc-RIB prefix is a selected BGP route and still not a forwarding-table entry or a registry assignment; a BGP-LS prefix NLRI is topology attachment, not that selected route.¶

7.1. Canonical Prefix Versus Interface Address

If one producer serializes 192.0.2.123/24 as an interface address and a consumer silently normalizes it to 192.0.2.0/24, both parse the text but exchange different objects. The result can configure the wrong address, discard an attachment identity, or cause a later round trip to produce a different value. Conversely, rejecting all non-zero non-prefix bits is correct for a canonical-prefix representation but incorrect for an address-with-prefix representation.¶

7.2. Boundary Prefix Lengths (/0 and Host Length)

Minimum and maximum prefix lengths do not remove semantic ambiguity. In this section, host length means /32 for IPv4 and /128 for IPv6. A /0 canonical prefix denotes the complete address-family space. In a routing table it can be a default route, while in policy it can be an all-addresses predicate or the base of an inclusive prefix selector. A host-length canonical prefix covers one address, but the same written value can represent a canonical singleton prefix, a host route, or an interface assignment. Completing a slash-less address to host length is a normalization to that singleton, as described in Section 4.2. Prefix length determines mathematical coverage, not operational role; see the routing distinction in [RFC1812] and the distinct forms in [RFC9164].¶

7.3. Prefix Versus Prefix Selector

The same writing, 203.0.113.0/24, can be three different objects:¶

• the exact canonical prefix 203.0.113.0/24;¶

• the set of addresses inside that prefix; or¶

• a selector whose base is that prefix.¶

The distinguishing question is not the slash string. It is what the value is being asked to match. If one can answer which prefixes match, and at which lengths, the value is a selector. If one can answer only which addresses sit under the mask, the value is a canonical prefix used as an address-set predicate, not a selector.¶

A Route Origin Authorization (ROA) containing 203.0.113.0/24 with maxLength 26 does not authorize the same set of route announcements as the same prefix with no maxLength. The first selects every prefix from length 24 through 26 under that base. The second selects only {203.0.113.0/24}. Collapsing either authorization to the base prefix can produce a false permit or false deny.¶

7.4. Namespace Identity

10.0.0.0/8 in one VRF or tenant is not operationally identical to 10.0.0.0/8 in another. Equality and deduplication based only on prefix bits can collapse separate objects, leak information across isolation boundaries, or apply an action in the wrong address realm.¶

7.5. Aggregation Safety

Two aligned, equal-length sibling permit prefixes with identical context may be replaceable by an exact covering aggregate. An adjacent permit and deny prefix are not. Two routes with different attributes or two allocations with different authority or lifetime are likewise not interchangeable merely because their address sets can be summarized. Context-blind aggregation can broaden admission, misstate reachability, or erase the provenance needed to reverse a change.¶

13.1. Normative References

[RFC4291]

Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/rfc/rfc4291>.

[RFC4632]

Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/rfc/rfc4632>.

[RFC5952]

Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/rfc/rfc5952>.

[RFC7608]

Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, <https://www.rfc-editor.org/rfc/rfc7608>.

13.2. Informative References

[RFC1020]

Romano, S. and M. Stahl, "Internet numbers", RFC 1020, DOI 10.17487/RFC1020, November 1987, <https://www.rfc-editor.org/rfc/rfc1020>.

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

[RFC1338]

Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, DOI 10.17487/RFC1338, June 1992, <https://www.rfc-editor.org/rfc/rfc1338>.

[RFC1519]

Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519, September 1993, <https://www.rfc-editor.org/rfc/rfc1519>.

[RFC1812]

Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <https://www.rfc-editor.org/rfc/rfc1812>.

[RFC2317]

Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, <https://www.rfc-editor.org/rfc/rfc2317>.

[RFC2622]

Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, DOI 10.17487/RFC2622, June 1999, <https://www.rfc-editor.org/rfc/rfc2622>.

[RFC2827]

Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/rfc/rfc2827>.

[RFC3021]

Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, DOI 10.17487/RFC3021, December 2000, <https://www.rfc-editor.org/rfc/rfc3021>.

[RFC3596]

Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, <https://www.rfc-editor.org/rfc/rfc3596>.

[RFC3704]

Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/rfc/rfc3704>.

[RFC3779]

Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004, <https://www.rfc-editor.org/rfc/rfc3779>.

[RFC4007]

Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, <https://www.rfc-editor.org/rfc/rfc4007>.

[RFC4012]

Blunk, L., Damas, J., Parent, F., and A. Robachevsky, "Routing Policy Specification Language next generation (RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005, <https://www.rfc-editor.org/rfc/rfc4012>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/rfc/rfc4271>.

[RFC4364]

Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/rfc/rfc4364>.

[RFC4607]

Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, <https://www.rfc-editor.org/rfc/rfc4607>.

[RFC4760]

Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/rfc/rfc4760>.

[RFC4786]

Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/rfc/rfc4786>.

[RFC4861]

Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/rfc/rfc4861>.

[RFC5942]

Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes", RFC 5942, DOI 10.17487/RFC5942, July 2010, <https://www.rfc-editor.org/rfc/rfc5942>.

[RFC6052]

Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <https://www.rfc-editor.org/rfc/rfc6052>.

[RFC6177]

Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/RFC6177, March 2011, <https://www.rfc-editor.org/rfc/rfc6177>.

[RFC6724]

Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/rfc/rfc6724>.

[RFC6890]

Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <https://www.rfc-editor.org/rfc/rfc6890>.

[RFC7020]

Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, August 2013, <https://www.rfc-editor.org/rfc/rfc7020>.

[RFC7854]

Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, <https://www.rfc-editor.org/rfc/rfc7854>.

[RFC8519]

Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, "YANG Data Model for Network Access Control Lists (ACLs)", RFC 8519, DOI 10.17487/RFC8519, March 2019, <https://www.rfc-editor.org/rfc/rfc8519>.

[RFC8704]

Sriram, K., Montgomery, D., and J. Haas, "Enhanced Feasible-Path Unicast Reverse Path Forwarding", BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, <https://www.rfc-editor.org/rfc/rfc8704>.

[RFC8955]

Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/rfc/rfc8955>.

[RFC8956]

Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, <https://www.rfc-editor.org/rfc/rfc8956>.

[RFC9069]

Evens, T., Bayraktar, S., Bhardwaj, M., and P. Lucente, "Support for Local RIB in the BGP Monitoring Protocol (BMP)", RFC 9069, DOI 10.17487/RFC9069, February 2022, <https://www.rfc-editor.org/rfc/rfc9069>.

[RFC9164]

Richardson, M. and C. Bormann, "Concise Binary Object Representation (CBOR) Tags for IPv4 and IPv6 Addresses and Prefixes", RFC 9164, DOI 10.17487/RFC9164, December 2021, <https://www.rfc-editor.org/rfc/rfc9164>.

[RFC9315]

Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022, <https://www.rfc-editor.org/rfc/rfc9315>.

[RFC9552]

Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, <https://www.rfc-editor.org/rfc/rfc9552>.

[RFC9582]

Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, May 2024, <https://www.rfc-editor.org/rfc/rfc9582>.

[RFC9911]

Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911, DOI 10.17487/RFC9911, December 2025, <https://www.rfc-editor.org/rfc/rfc9911>.

[RFC9915]

Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", STD 102, RFC 9915, DOI 10.17487/RFC9915, January 2026, <https://www.rfc-editor.org/rfc/rfc9915>.