Contextual IP Prefix Semantics (CIPS)
draft-munro-cips-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Craig A. Munro | ||
| Last updated | 2026-10-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-munro-cips-00
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, <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>.
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, <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>.
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,
<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>.
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,
<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>.
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,
<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>.
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]