Network Working Group C. A. Munro Internet-Draft RouteObjects Intended status: Informational 3 October 2026 Expires: 6 April 2027 Contextual IP Prefix Semantics (CIPS) draft-munro-cips-00 Abstract This document defines Contextual IP Prefix Semantics (CIPS), a model that distinguishes addresses, canonical prefixes, addresses with prefix context, and prefix selectors, and describes how these forms are qualified by operational context. It provides a taxonomy of operational contexts and vocabulary for stating implementation support. In that vocabulary, canonical-prefix support means the canonical prefix form is preserved as its own identity; accepting slash-qualified text is not that capability. The model is intended to help specification authors, API and schema designers, tool authors, and operators preserve semantic distinctions when prefix- bearing values cross interchange boundaries. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Munro Expires 6 April 2027 [Page 1] Internet-Draft CIPS October 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 5 3. Historical Continuity and Semantic Evolution . . . . . . . . 5 3.1. The Short-Term Plan That Endured . . . . . . . . . . . . 6 3.2. Terminology Index . . . . . . . . . . . . . . . . . . . . 6 4. The CIPS Model and Semantic Forms . . . . . . . . . . . . . . 7 4.1. Foundational CIDR Prefix . . . . . . . . . . . . . . . . 7 4.2. Semantic Forms . . . . . . . . . . . . . . . . . . . . . 8 4.3. Context Qualification . . . . . . . . . . . . . . . . . . 10 4.4. Composition of Roles . . . . . . . . . . . . . . . . . . 12 5. Describing CIDR and CIPS Support . . . . . . . . . . . . . . 15 5.1. Worked Support Statement . . . . . . . . . . . . . . . . 20 5.2. Selector Mathematics: RPSL as Example . . . . . . . . . . 21 6. Taxonomy of IP Prefix Contexts . . . . . . . . . . . . . . . 23 6.1. Address Governance, Allocation, and Planning . . . . . . 23 6.2. Interface Assignment and Link Semantics . . . . . . . . . 23 6.3. Routing and Control-Plane Reachability . . . . . . . . . 27 6.4. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 27 6.5. Routing Policy and Prefix Filtering . . . . . . . . . . . 28 6.6. Packet Filtering, Admission, and Source Validation . . . 28 6.7. Internet Routing Registries and RPKI . . . . . . . . . . 29 6.8. Aggregation and Address-Set Transformation . . . . . . . 29 6.9. VPNs, Overlays, Tenants, and Address Realms . . . . . . . 30 6.10. Translation, DNS, and Service-Specific Prefixes . . . . . 30 6.11. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 31 6.12. Measurement, Monitoring, Telemetry, and Topology . . . . 31 7. Interoperability Failure Cases . . . . . . . . . . . . . . . 32 7.1. Canonical Prefix Versus Interface Address . . . . . . . . 32 7.2. Boundary Prefix Lengths (/0 and Host Length) . . . . . . 32 7.3. Prefix Versus Prefix Selector . . . . . . . . . . . . . . 32 7.4. Namespace Identity . . . . . . . . . . . . . . . . . . . 33 7.5. Aggregation Safety . . . . . . . . . . . . . . . . . . . 33 8. Interoperability Guidance . . . . . . . . . . . . . . . . . . 33 9. Operational Considerations . . . . . . . . . . . . . . . . . 35 10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.1. Normative References . . . . . . . . . . . . . . . . . . 37 13.2. Informative References . . . . . . . . . . . . . . . . . 37 Munro Expires 6 April 2027 [Page 2] Internet-Draft CIPS October 2026 Appendix A. Context Review Checklist . . . . . . . . . . . . . . 41 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42 1. Introduction The plan that became known as Classless Inter-domain Routing (CIDR) began with [RFC1338] and was standardized in [RFC1519]. It replaced reliance on implicit IPv4 Class A, B, and C network boundaries in inter-domain assignment and routing with explicitly carried prefix lengths, hierarchical address assignment, route aggregation, and longest-prefix-match forwarding. [RFC4632], now BCP 122, records the history and operational results of that deployment. CIDR's mathematical foundation subsequently became common currency throughout Internet architecture. Address management, interface configuration, routing, forwarding, policy, security, registries, authorization, overlays, translation, multicast, and telemetry all carry values based on IP addresses and prefix lengths. The same written value does not necessarily denote the same operational object. For example, 192.0.2.0/24 can identify an allocation, a route destination, an exact route-filter operand, the base of a more-specific selector, an origin authorization, a packet- filter match, an address pool, or a telemetry grouping key. These objects share prefix mathematics, but they are not interchangeable. This document develops Contextual IP Prefix Semantics (CIPS), an analysis model for preserving those distinctions across operational roles and interchange boundaries. It provides semantic forms, context qualification, and support vocabulary to facilitate discussion across specialties and make semantic assumptions explicit in specifications and implementations. The model depends on the established classless invariants; it does not replace them. The central thesis is: An IP prefix is common mathematical currency. Its operational meaning depends on semantic form and operational context; neither the prefix bits and length nor slash-qualified notation alone establishes that meaning. Syntactic interoperability exists when two implementations can parse the same address and prefix length. Semantic interoperability additionally requires agreement about the form of the value, the mathematical relation being applied, the namespace in which the value exists, and any policy, authority, or lifetime attached to it. Canonical-prefix support as described here requires canonical-prefix identity, not merely the ability to parse address/length. Munro Expires 6 April 2027 [Page 3] Internet-Draft CIPS October 2026 Figure 1 summarizes the relationship between semantic forms, operational context, and interchange review. SEMANTIC FORM OPERATIONAL CONTEXT What does it denote? How is it qualified? +------------------------------+ +------------------------------+ | One of four forms: | | Components, as applicable: | | | | | | Address | | Namespace | | Canonical prefix | | Role | | Address with prefix context | + | Match semantics | | Prefix selector | | Associated attributes | | | | Authority or provenance | | | | Lifetime | +---------------+--------------+ +---------------+--------------+ | | +----------------+-----------------+ | +----------+----------+ | Contextual IP value | | CIPSValue | +----------+----------+ | Examined across operational roles | +-------------------------+-------------------------+ | Allocation | Interfaces | Routing | Policy | | Authorization | Naming | Observation | +-------------------------+-------------------------+ | Examples, failures, and review | +-------------------------+-------------------------+ | Distinguish canonicalization from lossy projection| | Describe implementation support explicitly | | Identify meaning lost at interchange boundaries | +---------------------------------------------------+ Figure 1: CIPS semantic forms, context qualification, and interchange review Connecting lines show the conceptual relationships indicated by their labels, not a processing sequence or implementation schema. Munro Expires 6 April 2027 [Page 4] Internet-Draft CIPS October 2026 2. Scope and Non-Goals This document is an Informational taxonomy and architectural analysis. It is intended for specification authors, API and schema designers, tool authors, and operators who exchange or transform IP prefix information. It applies to IPv4 and IPv6 where the referenced protocol or operational context supports those address families. The listed contexts are representative rather than exhaustive. An implementation need not support every semantic form, operation, or context. It does need to state the scope of its support precisely enough that another implementation can determine whether an interchange preserves meaning, including whether the peer has canonical-prefix support or only address support or slash parsing. This document: * does not define a protocol version, capability negotiation, wire encoding, or routing algorithm; * does not change the interpretation of an IPv4 or IPv6 prefix length; * does not update, obsolete, or replace [RFC4632], and does not re- expand CIDR; * does not define a universal container that every protocol must adopt; and * does not establish a certification program, Best Current Practice, or IETF consensus. CIPS relies on [RFC4632] for classless IPv4 prefix semantics and [RFC4291] for IPv6 address and prefix construction. [RFC7608] defines the complete one-bit-increment IPv6 prefix-length behavior when a support claim includes forwarding across that range, and [RFC5952] defines canonical IPv6 output when that textual behavior is claimed. These references are normative. References cited only for historical background, operational contexts, selector examples, or example encodings are informative. 3. Historical Continuity and Semantic Evolution Munro Expires 6 April 2027 [Page 5] Internet-Draft CIPS October 2026 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. Munro Expires 6 April 2027 [Page 6] Internet-Draft CIPS October 2026 * *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. The CIPS Model and Semantic Forms 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 | +-----------------------+---------------------------------------+ Munro Expires 6 April 2027 [Page 7] Internet-Draft CIPS October 2026 Figure 2: Examples of canonical IPv4 and IPv6 prefixes 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 Munro Expires 6 April 2027 [Page 8] Internet-Draft CIPS October 2026 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. Munro Expires 6 April 2027 [Page 9] Internet-Draft CIPS October 2026 +=============+================+===============+==================+ | Form | Non-prefix-bit | Denotes | Minimal identity | | | treatment | | | +=============+================+===============+==================+ | Address | Not applicable | One address | Family, bits, | | | | | and zone when | | | | | applicable | +-------------+----------------+---------------+------------------+ | Canonical | Zero after | Address set | Family, prefix | | prefix | length | or prefix key | bits, and length | +-------------+----------------+---------------+------------------+ | Address | Preserved | Address | Family, full | | with prefix | | attachment or | address, length, | | context | | configuration | and zone when | | | | | applicable | +-------------+----------------+---------------+------------------+ | Prefix | Defined by | Set of | Base, relation, | | selector | base form | prefixes or | and length | | | | match | bounds | | | | relation | | +-------------+----------------+---------------+------------------+ Table 1: IP value forms distinguished by CIPS 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: Munro Expires 6 April 2027 [Page 10] Internet-Draft CIPS October 2026 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 Munro Expires 6 April 2027 [Page 11] Internet-Draft CIPS October 2026 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. Munro Expires 6 April 2027 [Page 12] Internet-Draft CIPS October 2026 * *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. Munro Expires 6 April 2027 [Page 13] Internet-Draft CIPS October 2026 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 | +-----------------------+ +-----------------------+ Figure 3: Composition of roles for numbered IPv4 point-to-point connectivity 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: Munro Expires 6 April 2027 [Page 14] Internet-Draft CIPS October 2026 * *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. Describing CIDR and CIPS Support Claims such as "supports CIDR", "CIDR-ready", "CIDR-compatible", or "CIDR-conformant" are often applied to any implementation that accepts slash-qualified text. In this document, canonical-prefix support means the canonical prefix form in Section 4.2 preserved as its own identity. Parsing 192.0.2.123/24 into an address, or projecting that address onto 192.0.2.0/24, is not canonical-prefix support by itself: projection alone does not establish that capability. Munro Expires 6 April 2027 [Page 15] Internet-Draft CIPS October 2026 Support is otherwise a collection of independently stated capabilities. The 6-tuple below is a questionnaire, not a certificate and not a headline. An implementation that preserves only the address form still fills the tuple; that fill is an address- support statement, not a canonical-prefix support statement. CIDRSupportClaim = AddressFamilies + AcceptedInputRepresentations + ProducedOutputRepresentations + SupportedSemanticForms + SupportedRelationsAndOperations + ConversionBehavior CIPSCapabilityClaim = CIDRSupportClaim + SupportedOperationalContexts + ContextPreservation This is descriptive vocabulary, not a certification ladder. An implementation can support a small, well-defined subset. It should not imply support for forms, relations, or contexts that it does not implement, and it should not describe a subset that omits canonical- prefix identity as canonical-prefix support. These claim-model names are analytical vocabulary; they do not define an IANA registry, machine-readable schema, certification system, or capability- negotiation protocol. Prefix selector support is an independent capability: this document defines the form because interchange needs it, and canonical-prefix support does not imply it. The components of a CIDR support claim are defined as follows. * *Address families* are the IP versions the claim covers. A claim that names IPv4 does not imply IPv6. For example, a parser that accepts 192.0.2.0/24 but rejects 2001:db8::/32 supports IPv4 only. * *Accepted input representations* are the textual or binary writings the implementation will take as input, including slash- less addresses, prefix-length-qualified (slash) text, leading zeros, IPv6 compression, and zone suffixes. For example, an implementation may accept 192.0.2.123 and 192.0.2.123/24 while rejecting 192.0.2.01 or fe80::1%eth0. Munro Expires 6 April 2027 [Page 16] Internet-Draft CIPS October 2026 * *Produced output representations* are how a value already held in a given form is written, including IPv6 text ([RFC5952]) and whether a prefix length is included. Output does not change the form. For example, an address-with-prefix value 192.0.2.129/25 is emitted as 192.0.2.129/25. Emitting 192.0.2.128/25 instead is a conversion, not an output representation. * *Supported semantic forms* are which of the forms defined in Section 4.2 are preserved as themselves. For example, an implementation may preserve address, canonical prefix, and address with prefix context while rejecting prefix selectors rather than reducing them to their base prefixes. * *Supported relations and operations* are the comparisons and calculations that are implemented, such as form-value equality, address membership, prefix containment, overlap, specificity, exact-coverage aggregation, longest-prefix match, and selector membership. For example, an implementation may test whether an address lies in 192.0.2.0/24 without implementing 192.0.2.0/24^+. * *Conversion behavior* is what happens at a form boundary: reject, normalize in place, or expose an explicit lossy projection. For example, projecting an address-with-prefix value 192.0.2.123/24 to the canonical prefix 192.0.2.0/24 is a conversion, not identity- preserving canonicalization of that address-with-prefix value, and a support claim says whether that step is available, required, or forbidden. A CIPS capability claim includes a CIDR support claim and adds the following. * *Supported operational contexts* are which components of Section 4.3 the implementation understands well enough to preserve or apply, such as namespace, role, or lifetime. For example, a store may retain a VRF or tenant namespace while ignoring ROA authority. * *Context preservation* is what happens to operational context the implementation does not understand: retain it opaquely without reinterpretation, reject the value, or report the context as lost. Silent discard is not preservation. For example, a zone-qualified address may be rejected rather than stripped to an unzoned address. The following named layers show how those components combine. A slash-parsing claim is not a prefix-math claim, and a prefix-math claim is not a context-preservation claim. Munro Expires 6 April 2027 [Page 17] Internet-Draft CIPS October 2026 *Slash parsing / prefix-length writing* states whether an implementation accepts, produces, or preserves on round trip the glyphs address/length (and slash-less addresses), and what transformations it applies. The same glyphs can denote an address with prefix context or a canonical prefix. This layer alone says nothing about which form is stored, canonical prefix identity, retained non-prefix bits, selectors, containment, or aggregation. It is not canonical-prefix support as described here. *Canonical-prefix support* preserves the canonical prefix form as its own identity, not only a computed zeroed address or a derived string. It preserves the address family, validates the prefix length against that family, interprets the length as leftmost contiguous bits, and defines whether input with non-zero unused bits is rejected or, if accepted, taken as the canonical prefix with those bits set to zero. A legacy non-contiguous mask is represented as a different form rather than as a CIDR prefix. *Semantic-form support* identifies which of the forms defined in Section 4.2 are preserved. A conversion from address-with-prefix to canonical prefix is an explicit lossy projection. A conversion from selector to base prefix loses the matching relation and bounds. Such conversions are not treated as identity-preserving canonicalization. *Mathematical support* names the implemented relations and operations. Relevant operations include canonical-prefix equality, address membership, prefix containment, overlap, inclusive and proper specificity, exact address-set equality, exact-coverage aggregation, longest-prefix selection, and selector membership. Equality must be qualified: * *representation equality* compares character or octet encodings under a named format; * *form-value equality* compares decoded values that have the same semantic form and the same minimal identity for that form; * *denotational or selected-set equivalence* compares the address sets, selected-prefix sets, or packet-match predicates denoted in a named domain; and * *context-qualified object equality* requires form-value equality and equality of every context field that the containing model declares identity-bearing. Munro Expires 6 April 2027 [Page 18] Internet-Draft CIPS October 2026 Membership, containment, overlap, specificity, and selection are distinct relations or operations, not forms of equality. 192.0.2.0/25 and 192.0.2.128/25 together have the same address-set coverage as 192.0.2.0/24, while the two-element prefix set and the singleton /24 are not form-value equal. Two objects can contain identical canonical prefixes while remaining unequal because their namespaces, roles, authorities, lifetimes, or actions differ. *CIPS context support* identifies the operational contexts an implementation preserves and the fields that participate in identity, matching, and conversion. It does not require every implementation to understand every context. It requires the boundary of understanding to be explicit: unknown context is retained opaquely without reinterpretation, rejected, or reported as lost rather than silently discarded. The following named capabilities are this document's support vocabulary. They are not a certification ladder and do not restrict how other documents use the word CIDR. Munro Expires 6 April 2027 [Page 19] Internet-Draft CIPS October 2026 +==================+==========================+==================+ | Capability | Observable meaning | Implication | +==================+==========================+==================+ | Address support | Host bits are preserved. | Canonical-prefix | | | An associated prefix | identity is not | | | length is allowed: both | required. | | | 192.0.2.123/32 and | | | | 192.0.2.123/24 can be | | | | addresses. | | +------------------+--------------------------+------------------+ | Slash parsing / | The implementation | Form is still | | prefix-length | accepts or emits addr/ | unknown. | | writing | len as text. | | +------------------+--------------------------+------------------+ | Projection only | A lossy operation yields | Conversion, not | | | a zeroed writing or | a preserved | | | another address value. | form. | +------------------+--------------------------+------------------+ | Canonical-prefix | Canonical prefix is | Slash parsing | | support | preserved as itself. | alone is not | | | | this capability. | +------------------+--------------------------+------------------+ | Selector support | Prefix selectors require | Independent of | | | a canonical prefix. | canonical-prefix | | | Selectors are preserved | support; not | | | as themselves. | implied by it. | +------------------+--------------------------+------------------+ Table 2: Support capabilities in CIPS vocabulary A useful support statement therefore names the address families, forms, relations, contexts, and lossy boundaries, and uses the capabilities above when stating support. This permits two implementations to determine semantic compatibility before exchanging values that happen to share the same textual notation. 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 Munro Expires 6 April 2027 [Page 20] Internet-Draft CIPS October 2026 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. Munro Expires 6 April 2027 [Page 21] Internet-Draft CIPS October 2026 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. Munro Expires 6 April 2027 [Page 22] Internet-Draft CIPS October 2026 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. Taxonomy of IP Prefix Contexts The following categories are intentionally broad and representative rather than exhaustive. A single real-world object can participate in more than one category, but that does not erase the distinctions between its roles. The examples below apply the form-and-context distinctions summarized in Figure 1. 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. Munro Expires 6 April 2027 [Page 23] Internet-Draft CIPS October 2026 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. Munro Expires 6 April 2027 [Page 24] Internet-Draft CIPS October 2026 +=============+=============+================+======================+ |Writing |Role | Context | What the /31 is | | | | | not | +=============+=============+================+======================+ |192.0.2.0/31 |Covering | Governance or | Not a point-to- | |as an |assignment of| planning | point link; not | |allocation or|two addresses| | two interface | |IPAM pool | | | hosts | +-------------+-------------+----------------+----------------------+ |192.0.2.0/31 |Interface | IPv4 point-to- | Neither address is | |and |assignment | point link | withheld as a | |192.0.2.1/31,|([RFC3021]) | | network or | |one per end | | | directed-broadcast | | | | | address | +-------------+-------------+----------------+----------------------+ |192.0.2.0/31 |Route | Routing or | Not automatically | |in a routing |destination | forwarding | [RFC3021]; the | |table | | | route is the set, | | | | | not the link type | +-------------+-------------+----------------+----------------------+ |192.0.2.0/31 |Address-set | Match | Not orlonger; not | |as an ACL or |of two, or | semantics | two host routes | |exact prefix-|exact prefix | | unless the filter | |list entry | | | says so | +-------------+-------------+----------------+----------------------+ |192.0.2.0/31 |Prefix | Policy or IRR- | Not the two- | |as orlonger |selector | style filter | address set itself | |or ^+ | | | | +-------------+-------------+----------------+----------------------+ |192.0.2.0/31 |Exact origin | RPKI | Not permission to | |in a ROA with|authorization| | originate /32s | |no maxLength | | | | +-------------+-------------+----------------+----------------------+ |192.0.2.0/31 |Vendor or | Not [RFC3021] | Notation does not | |on a |local | | make it a point- | |broadcast LAN|practice | | to-point pair | |interface | | | | +-------------+-------------+----------------+----------------------+ Table 3: IPv4 /31 writings distinguished by role 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. Munro Expires 6 April 2027 [Page 25] Internet-Draft CIPS October 2026 +==================+==================+===========================+ | Writing | Role | Context | +==================+==================+===========================+ | 192.0.2.123/32 | Host route | Routing or forwarding | | in a routing | | | | table | | | +------------------+------------------+---------------------------+ | 192.0.2.123/32 | Interface | Interface | | on a loopback or | assignment | | | as an interface | | | | address | | | +------------------+------------------+---------------------------+ | 192.0.2.123/32 | Address-set of | Match semantics | | as an ACL or | one, or exact | | | exact prefix- | prefix | | | list entry | | | +------------------+------------------+---------------------------+ | 192.0.2.123 used | Address-to-name | DNS PTR query for | | in a reverse-DNS | lookup | 123.2.0.192.in-addr.arpa. | | lookup | | | +------------------+------------------+---------------------------+ | 192.0.2.123 with | Address (family- | No further role | | no prefix length | max completion | | | | names the same | | | | singleton) | | +------------------+------------------+---------------------------+ Table 4: Host-length writings distinguished by role 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. Munro Expires 6 April 2027 [Page 26] Internet-Draft CIPS October 2026 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]. Munro Expires 6 April 2027 [Page 27] Internet-Draft CIPS October 2026 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 Munro Expires 6 April 2027 [Page 28] Internet-Draft CIPS October 2026 * 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; Munro Expires 6 April 2027 [Page 29] Internet-Draft CIPS October 2026 * 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. Munro Expires 6 April 2027 [Page 30] Internet-Draft CIPS October 2026 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. Munro Expires 6 April 2027 [Page 31] Internet-Draft CIPS October 2026 7. Interoperability Failure Cases The following failures illustrate why successful parsing is not sufficient for semantic interoperability. 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. Munro Expires 6 April 2027 [Page 32] Internet-Draft CIPS October 2026 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. 8. Interoperability Guidance Specifications, APIs, schemas, and operational tools that exchange IP prefix information are encouraged to address the following points explicitly. 1. *Identify the semantic form.* State whether the value is an address, a canonical prefix, an address with prefix context, a prefix selector, an arbitrary range, or a higher-level object containing one of those forms. If the form is a prefix selector, the base, relation, and length bounds (for example a ROA maxLength) are part of the value. They are not optional context. 2. *Identify the address family.* Validate prefix lengths against the family. Do not infer IPv4 or IPv6 solely from an ambiguous string or storage width when the surrounding format permits an explicit family. 3. *Specify non-prefix bits by form.* A canonical prefix has all bits after its prefix length set to zero. An address-with- prefix form preserves the full address. A canonical-prefix field either rejects input with non-zero unused bits or, if it Munro Expires 6 April 2027 [Page 33] Internet-Draft CIPS October 2026 accepts that writing, the value is the canonical prefix with those bits set to zero. An address-with-prefix field preserves the bits. The writing does not choose the form. Projection from address-with-prefix onto the containing canonical prefix is a cross-form operation, not identity-preserving canonicalization of the address-with-prefix value. 4. *Use contiguous prefix lengths.* A prefix length counts contiguous leading bits. If a system supports a legacy non- contiguous mask, it should represent that mask as a different form rather than labeling it a CIDR prefix. 5. *Define the match relation.* Terms such as "contains" and "matches" should be qualified as address containment, exact- prefix equality, more-specific, less-specific, overlap, bounded prefix-length selection, or longest-prefix match. 6. *Preserve namespace.* When overlapping address space can exist, retain VRF, Route Distinguisher, tenant, realm, interface zone, or equivalent identity through comparison, storage, and interchange. 7. *Preserve policy and authority.* Direction, action, ordering, attachment point, origin AS, owner, resource authority, provenance, and lifetime should not be silently discarded when relevant to the consuming operation. 8. *Constrain aggregation by context.* Do not aggregate across different policy actions, namespaces, authorities, provenance, validity periods, route attributes, or authorization semantics. If exact coverage is claimed, the output address set should equal the input address set. 9. *Mark lossy conversions.* A conversion from a route, allocation, authorization, interface assignment, or policy object to a bare prefix is lossy. APIs should make such conversion visible, and security-sensitive consumers should not invent missing permit, route, or authorization semantics. 10. *Define deterministic interchange.* Specify textual or binary normalization, ordering, equality, duplicate handling, and error behavior when prefix sets cross implementation boundaries. [RFC5952] recommends one canonical output form for IPv6 text while requiring implementations to accept every legitimate [RFC4291] form. Textual canonicalization is an interchange rule, not an internal value model or a substitute for semantic equality. Munro Expires 6 April 2027 [Page 34] Internet-Draft CIPS October 2026 11. *Carry observation context.* Telemetry should identify the source, routing instance, peer, direction, policy stage, and observation time when those distinctions affect interpretation. 12. *Keep mathematical currency reusable.* Common prefix mathematics can be shared without collapsing routes, allocations, policies, authorizations, and interface assignments into one universal semantic type. See also Appendix A, which restates these questions in a compact form for specification, API, schema, and implementation review. 9. Operational Considerations Introducing distinct semantic forms does not require every implementation to use identical internal types. It does require conversion boundaries to be deliberate. Before merging or copying a prefix, operators and implementers should ask which semantic form the value is and which operational role it is being used in. They should then be able to determine: * whether displayed non-prefix bits were preserved or normalized; * which namespace and address family a prefix belongs to; * which match relation was evaluated; * whether aggregation preserved exact coverage and contextual attributes; * where authority or observed data originated; and * whether time-dependent data remains valid. Logs and diagnostics are more useful when they identify both the prefix and its role. For example, "ROA authorization failed", "inbound route filter denied", and "address pool exhausted" are materially different events even if they include the same written prefix. The CIPS model can be applied incrementally. A system can first make its supported semantic forms and lossy conversions explicit, then add context qualification where an operational boundary requires it. The model does not require a single universal representation. Munro Expires 6 April 2027 [Page 35] Internet-Draft CIPS October 2026 10. Security Considerations Losing prefix context can convert data without changing its syntax. This is a security concern when the discarded information controls authorization, policy, isolation, or validity. Examples include: * interpreting a registration or ROA as proof that a route is currently reachable; * treating a route observation as proof of resource authority; * removing permit or deny action, direction, ordering, or attachment point from an ACL operand; * aggregating policy entries in a way that broadens permitted address space; * losing a VRF or tenant namespace and applying policy to overlapping address space in another realm; * silently normalizing an address-with-prefix into a canonical prefix; * using non-canonical or inconsistently normalized encodings as equality, deduplication, cache, or signed-representation keys; and * applying stale allocation, authorization, reputation, or telemetry data after its lifetime. Cross-role misuse of prefix data can also create failures of authority. A component authorized to act on a prefix in one role can be induced to act on an assertion from another role. For example, an address-management system may be authorized to allocate a prefix but not to permit it through an ACL or originate it into routing. If its output is reduced to a bare prefix and passed to a privileged policy or routing installer, that installer can mistake allocation for admission or route-origination authority. Implementations should bind each authorization decision to the asserted role, namespace, authority, and intended action; matching prefix bits alone do not transfer authority between allocation, routing, and admission contexts. Selectors and ranges can denote extremely large sets. Implementations should preserve symbolic forms where possible and bound the time, memory, and output consumed by expansion, comparison, or serialization. Munro Expires 6 April 2027 [Page 36] Internet-Draft CIPS October 2026 Implementations should validate the semantic form before acting, preserve security-relevant context through conversions, and reject ambiguous input when the missing context cannot be recovered safely. 11. IANA Considerations This document has no IANA actions. 12. Acknowledgements The author thanks John P. Stoneback, who introduced him to Internet addressing at Moravian College in 1987 and was listed as the Moravian contact in [RFC1020], for early discussions that led to a lasting interest in how prefixes are used. The author thanks the operators, protocol designers, registry communities, software implementers, and reviewers whose experience informed this taxonomy and the distinctions in the CIPS model. 13. References 13.1. Normative References [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [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, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, . 13.2. Informative References [RFC1020] Romano, S. and M. Stahl, "Internet numbers", RFC 1020, DOI 10.17487/RFC1020, November 1987, . Munro Expires 6 April 2027 [Page 37] Internet-Draft CIPS October 2026 [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [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, . [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, . [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, . [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/RFC2317, March 1998, . [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, . [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, . [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, . [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, . [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, . Munro Expires 6 April 2027 [Page 38] Internet-Draft CIPS October 2026 [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, . [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, . [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, . [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, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, DOI 10.17487/RFC4607, August 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, . [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, . [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, . Munro Expires 6 April 2027 [Page 39] Internet-Draft CIPS October 2026 [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, . [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/RFC6177, March 2011, . [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, . [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, . [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, August 2013, . [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP Monitoring Protocol (BMP)", RFC 7854, DOI 10.17487/RFC7854, June 2016, . [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, . [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, . [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, . Munro Expires 6 April 2027 [Page 40] Internet-Draft CIPS October 2026 [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, . [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, . [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, . [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, . [RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, . [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, . [RFC9911] Schönwälder, J., Ed., "Common YANG Data Types", RFC 9911, DOI 10.17487/RFC9911, December 2025, . [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, . Appendix A. Context Review Checklist When a specification or implementation exchanges an IP prefix, reviewers can ask: * Which CIDR capabilities are claimed, and which additional CIPS context capabilities, if any? Munro Expires 6 April 2027 [Page 41] Internet-Draft CIPS October 2026 * What semantic form is this: address, canonical prefix, address with prefix context, selector, range, or a richer object? * Is the address family explicit, and is the prefix length valid for it? * Are non-prefix bits preserved, rejected, or normalized? * Is the prefix boundary contiguous and canonical when canonical form is required? * Which mathematical relation is used: representation equality, form-value equality, denotational equivalence, address membership, containment, overlap, specificity, bounded selection, exact coverage, or longest-prefix match? * Which namespace or address realm identifies the value? * Which role, action, direction, order, authority, provenance, and lifetime accompany the prefix? * When objects are composed, who asserted or authorizes them, what does each denote, when does it apply, where is it scoped, and why is it related to the others (see Section 4.4)? * Which explicit associations identify the participating objects, and which dependencies or consuming operations could be affected by changing one? * Can aggregation change coverage or discard relevant context? * Is any conversion intentionally lossy, and is that visible to the caller or consumer? * What happens when a receiving implementation does not support the claimed form, relation, or context? * What error behavior applies when required context is absent or invalid? Author's Address Craig A. Munro RouteObjects United States of America Email: craig@routeobjects.com Munro Expires 6 April 2027 [Page 42]