RouteObjects

US craig@routeobjects.com

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.

Introduction The plan that became known as Classless Inter-domain Routing (CIDR) began with and was standardized in . 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. , 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. summarizes the relationship between semantic forms, operational context, and interchange review.

CIPS semantic forms, context qualification, 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 | +---------------------------------------------------+

Connecting lines show the conceptual relationships indicated by their labels, not a processing sequence or implementation schema.

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 , 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 for classless IPv4 prefix semantics and for IPv6 address and prefix construction. defines the complete one-bit-increment IPv6 prefix-length behavior when a support claim includes forwarding across that range, and 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.

Historical Continuity and Semantic Evolution

The Short-Term Plan That Endured , 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. , published in September 1993, gave CIDR its established name and obsoleted RFC 1338. , 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. defines an IPv6 prefix length as the number of leftmost contiguous bits comprising the prefix. warns against hard-coding a small set of IPv6 prefix boundaries, and 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.

Terminology Index

• CIDR means Classless Inter-domain Routing as specified by BCP 122. Its expansion and underlying classless semantics remain unchanged.
• CIPS means Contextual IP Prefix Semantics, the analysis model defined by this document.
• Semantic forms are address, canonical prefix, address with prefix context, and prefix selector, as defined in .
• Operational context comprises the namespace, role, matching semantics, associated attributes, authority or provenance, and lifetime described in .

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.

The CIPS Model and Semantic Forms

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. shows examples of canonical IPv4 and IPv6 prefixes.

Examples of canonical IPv4 and IPv6 prefixes IPv4: 192.0.2.0/24 (binary) Significant prefix bits Non-prefix bits 24 bits 8 bits +-----------------------------------------------+---------------+ | 11000000 00000000 00000010 | 00000000 | +-----------------------------------------------+---------------+ IPv6: 2001:db8:1234::/48 (hexadecimal) Significant prefix bits Non-prefix bits 48 bits 80 bits +-----------------------+---------------------------------------+ | 2001:0db8:1234 | 0000:0000:0000:0000:0000 | +-----------------------+---------------------------------------+

These examples show canonical prefix representations; addresses covered by each prefix may have nonzero bits after its prefix boundary. A prefix denotes a power-of-two-sized address set. An arbitrary closed address range is a different mathematical form; 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 ). This is an analysis model, not a required wire structure.

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 specifies this interpretation for its CBOR Address Format when used where a prefix is expected. Under the same convention in textual interchange, completing the writing is representation normalization: it makes the implied length explicit. Conversely, omitting a family-maximum length preserves singleton coverage and permits reconstruction of the same canonical prefix when that interpretation remains established. Neither writing alone establishes an interface assignment, route, policy match, or other operational role. By contrast, 192.0.2.123/24 in an address-with-prefix context preserves both the complete address and its associated length; omitting that length loses prefix context. A prefix selector denotes a set of prefixes or a matching relation. Its identity can include a base prefix, an inclusive or exclusive relation, and minimum or maximum prefix-length bounds. A selector is not equivalent to its base prefix. For example, each ROAIPAddress entry in a Resource Public Key Infrastructure (RPKI) Route Origin Authorization (ROA) combines a base prefix with an optional maxLength; the ROA binds the resulting authorization to an Autonomous System (AS); see . 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. 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. 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; 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. IP value forms distinguished by CIPS

Form	Non-prefix-bit treatment	Denotes	Minimal identity
Address	Not applicable	One address	Family, bits, and zone when applicable
Canonical prefix	Zero after length	Address set or prefix key	Family, prefix bits, and length
Address with prefix context	Preserved	Address attachment or configuration	Family, full address, length, and zone when applicable
Prefix selector	Defined by base form	Set of prefixes or match relation	Base, relation, and length bounds

Context Qualification Context qualification is orthogonal to the base forms rather than an additional peer form: IPValueForm = Address | CanonicalPrefix | AddressWithPrefixContext | PrefixSelector CIPSValue = IPValueForm + OperationalContext CIPS centers on prefix-bearing forms but includes address as an adjacent form. Context such as an IPv6 zone or an anycast role can be necessary to identify an address correctly and to keep it distinct from a prefix-shaped value. Operational context can contain: OperationalContext = Namespace + Role + MatchSemantics + AssociatedAttributes + AuthorityOrProvenance + Lifetime Not every context uses every component. These names are analytical vocabulary for kinds of information that can be lost when a richer object is collapsed into a bare prefix or string. They do not define a schema or require every implementation to store every field.

• Namespace is the address realm in which the prefix bits are interpreted. The same bits in two routing tables, VRFs, Route Distinguishers, tenants, or other isolated realms are not the same object. For example, 10.0.0.0/8 in one tenant is not 10.0.0.0/8 in another.
• Role is the operational job of the value: what kind of assertion it is. The same writing can be an allocation, an interface assignment, a route destination, a filter operand, an origin authorization, or a telemetry key. For example, 192.0.2.0/24 as a registry assignment is not the same object as 192.0.2.0/24 as a BGP destination.
• Match semantics is how the value is applied as a predicate: what it matches and by which relation. Address-set membership, exact-prefix equality, more-specific selection, longest-prefix match, and bounded length ranges are different match semantics. For example, 203.0.113.0/24 used as an exact prefix-list entry is not the same match as that prefix used as orlonger or as an ACL address-set. When the relation and length bounds are part of the value itself, the value is a prefix selector (see ) 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 , a ROA and its issuing trust anchor, an IRR object, local configuration, or a looking-glass snapshot. For example, collapsing a ROA to the base prefix discards the authorized origin AS and the authority that signed it.
• Lifetime is the interval during which the assertion is intended to hold. It is not the prefix length. Examples include allocation or lease validity, SLAAC preferred and valid lifetimes, a ROA validity window, and the age of telemetry. For example, a prefix that was authorized last year is not interchangeable with a currently valid authorization for the same bits.

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

Composition of Roles Distinct contextual objects can participate in a common operational purpose. The operator or containing system declares that purpose and explicitly associates the participating objects. Matching prefix bits or the presence of particular roles does not establish the relationship. Composition relates objects; it does not introduce another semantic form. For example, providing and operating numbered IPv4 point-to-point connectivity between two routers may involve:

• Allocation: A record reserving 192.0.2.0/31 for the connection.
• Interface assignments: Two address-with-prefix objects, one per end:
  • Router 1 (R1): 192.0.2.0/31 assigned to its interface toward R2.
  • Router 2 (R2): 192.0.2.1/31 assigned to its interface toward R1.
• Routing: Routing state associated with the intended reachability, such as a connected route for 192.0.2.0/31 on each router. These routes can result from the interface assignments while remaining distinct contextual objects.
• Reverse DNS (optional): PTR records associating each interface address with a diagnostic name (, 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. summarizes the participating objects in this example. IPAM denotes IP address management.

Composition of roles for numbered IPv4 point-to-point connectivity Declared purpose: Provide and operate numbered IPv4 point-to-point connectivity between R1 and R2. Participating objects, explicitly associated by the operator: +---------------------------+ | Allocation record (IPAM) | | 192.0.2.0/31 | +---------------------------+ +-----------------------+ +-----------------------+ | Router 1 (R1) | | Router 2 (R2) | +-----------------------+ +-----------------------+ | Interface assignment | Intended | Interface assignment | | toward R2 | point-to-point | toward R1 | | 192.0.2.0/31 +------link-------+ 192.0.2.1/31 | +-----------------------+ +-----------------------+ | R1 routing table | | R2 routing table | | Connected route: | | Connected route: | | 192.0.2.0/31 | | 192.0.2.0/31 | +-----------------------+ +-----------------------+ Optional naming records +-----------------------+ +-----------------------+ | PTR record for | | PTR record for | | 192.0.2.0 | | 192.0.2.1 | +-----------------------+ +-----------------------+

The allocation and connected-route objects use the canonical-prefix form. The interface assignments use the address-with-prefix-context form, retaining each complete interface address and its prefix length. In particular, R1's assignment and the allocation share the writing 192.0.2.0/31, but differ in semantic form and contextual identity. The connecting line represents the intended point-to-point link, not verified connectivity. Grouping shows participation in a shared purpose, not provisioning order or shared authority. The optional PTR records use the complete owner and target names given in the example text. Five questions help reviewers examine the composition at system level:

• Who: Who asserted the information, according to its provenance, and who authorizes the relevant action?
• What: What semantic form and operational role does each object have, and which operation applies to it?
• When: When is each assertion valid, and when was any supporting state observed? Observation time and validity are distinct.
• Where: In which namespace or address realm, at which attachment, and in which relevant deployment context does the object apply?
• Why: Which declared purpose or intended outcome relates these objects?

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

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 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. 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.
• Produced output representations are how a value already held in a given form is written, including IPv6 text () 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 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 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. 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 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.

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. Support capabilities in CIPS vocabulary

Capability	Observable meaning	Implication
Address support	Host bits are preserved. An associated prefix length is allowed: both 192.0.2.123/32 and 192.0.2.123/24 can be addresses.	Canonical-prefix identity is not required.
Slash parsing / prefix-length writing	The implementation accepts or emits addr/len as text.	Form is still unknown.
Projection only	A lossy operation yields a zeroed writing or another address value.	Conversion, not a preserved form.
Canonical-prefix support	Canonical prefix is preserved as itself.	Slash parsing alone is not this capability.
Selector support	Prefix selectors require a canonical prefix. Selectors are preserved as themselves.	Independent of canonical-prefix support; not implied by it.

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.

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 is accepted. Fields explicitly designate address, canonical-prefix, or address-with-prefix form, and prefix-bearing forms include a decimal prefix length. In canonical-prefix fields, input with non-zero non-prefix bits is rejected. Zone-qualified input is unsupported and rejected.
• Produced output representations: IPv4 output uses four decimal octets without leading zeros, and IPv6 output follows . 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.

Selector Mathematics: RPSL as Example The following is a worked example of selector mathematics, not an RPSL profile. Routing Policy Specification Language (RPSL) provides a concrete example of selector semantics. Let P be a canonical prefix of length L in an address family whose width W is 32 for IPv4 or 128 for IPv6. For any integer k, define: S(P,k) = { Q | Q is a canonical prefix, length(Q) = k, and addresses(Q) is a subset of or equal to addresses(P) } S(P,k) is empty when k < L or k > W. For integers n and m satisfying 0 <= n <= m <= W, the RPSL range operators defined by 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; separately defines how an outer operator applies to a set whose members already contain ranges. applies the same range-operator model to IPv6 prefix ranges. The same selector relations appear under other syntaxes. For the base prefix P of length L, RPSL P^+ is the inclusive more-specific match commonly written orlonger or le of the family width; P^- is the exclusive more-specific match commonly written longer or ge L+1. A bounded length range P^n-m is commonly written prefix-length-range /n-/m or ge n le m. The upto /m match type is the special case P^L-m: lengths from L through m, inclusive of the base. It is not an arbitrary P^n-m. For example, 192.0.2.0/24^26-28 excludes /24 and /25, whereas 192.0.2.0/24 upto /28 includes them. An exact prefix-list or route-filter ... exact entry is the singleton {P}. Writings that denote the same bounds name the same selector relation. They are not interchangeable with P as a canonical prefix. This example illustrates why selector conformance cannot be inferred from prefix parsing. A base prefix, its covered addresses, and the set of route prefixes selected by ^+, ^-, or a bounded length range are different mathematical objects.

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 .

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 , and special-purpose registry attributes by . 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.

Interface Assignment and Link Semantics Prefixes occur with physical interfaces, virtual interfaces, VLAN interfaces, loopbacks, point-to-point links, and host attachment. An interface configuration commonly uses an address-with-prefix form rather than a canonical prefix. Additional context includes interface identity, zone, virtual routing instance, preferred and valid lifetimes, and whether a prefix is on-link or usable for autonomous address configuration. An IPv4 /31 is a compact example of context-dependent link semantics. A canonical /31 is a two-address set. On an IPv4 point-to-point link, 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. IPv4 /31 writings distinguished by role

Writing	Role	Context	What the /31 is not
192.0.2.0/31 as an allocation or IPAM pool	Covering assignment of two addresses	Governance or planning	Not a point-to-point link; not two interface hosts
192.0.2.0/31 and 192.0.2.1/31, one per end	Interface assignment ()	IPv4 point-to-point link	Neither address is withheld as a network or directed-broadcast address
192.0.2.0/31 in a routing table	Route destination	Routing or forwarding	Not automatically ; the route is the set, not the link type
192.0.2.0/31 as an ACL or exact prefix-list entry	Address-set of two, or exact prefix	Match semantics	Not orlonger; not two host routes unless the filter says so
192.0.2.0/31 as orlonger or ^+	Prefix selector	Policy or IRR-style filter	Not the two-address set itself
192.0.2.0/31 in a ROA with no maxLength	Exact origin authorization	RPKI	Not permission to originate /32s
192.0.2.0/31 on a broadcast LAN interface	Vendor or local practice	Not	Notation does not make it a point-to-point pair

These distinct objects can participate in a common operational purpose without losing their individual meanings; see . A host-length writing (/32 or /128) makes the same point across more roles. The coverage is one address; the role is not implied by the length. Host-length writings distinguished by role

Writing	Role	Context
192.0.2.123/32 in a routing table	Host route	Routing or forwarding
192.0.2.123/32 on a loopback or as an interface address	Interface assignment	Interface
192.0.2.123/32 as an ACL or exact prefix-list entry	Address-set of one, or exact prefix	Match semantics
192.0.2.123 used in a reverse-DNS lookup	Address-to-name lookup	DNS PTR query for 123.2.0.192.in-addr.arpa.
192.0.2.123 with no prefix length	Address (family-max completion names the same singleton)	No further 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 . 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 . cautions against inferring on-link semantics solely from an assigned address and prefix length.

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 . Multiprotocol BGP adds AFI and SAFI context that determines the address family and semantics of Network Layer Reachability Information (NLRI); see . 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 . 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.

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 ; IPv6 forwarding support across prefix lengths is addressed in .

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 and .

Packet Filtering, Admission, and Source Validation Security and admission contexts include:

• source and destination access-control-list (ACL) operands;
• ingress and egress filters;
• firewall and service-admission policy;
• anti-spoofing and reverse-path forwarding;
• cloud security groups and network-policy constructs;
• threat-intelligence and reputation sets; and
• logging, rate-limiting, and classification rules.

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

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 , and the current ROA profile is .

Aggregation and Address-Set Transformation Prefixes are aggregated or normalized for:

• routing announcements;
• exact-coverage address-set minimization;
• ACL and admission-set preparation;
• IPAM pool coalescing;
• telemetry summarization; and
• operational reports.

Mathematical adjacency is not sufficient permission to aggregate. Exact address-set aggregation can preserve coverage while still losing provenance, tenant, lifetime, action, authorization, or route attributes. BGP route aggregation can also change path information and reachability behavior. Aggregation is therefore contextual. Prefixes should be combined only when the operation preserves every property relevant to the consuming context.

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, 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.

Translation, DNS, and Service-Specific Prefixes Some prefixes are parameters to another algorithm or hierarchy:

• IPv4/IPv6 translation and IPv4-embedded IPv6 prefixes;
• reverse-DNS delegation boundaries;
• source- and destination-address selection tables; and
• service-specific or protocol-reserved address blocks.

A translation prefix determines how address bits are embedded or extracted; 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. (, Section 2.5). Reverse DNS does not map every prefix boundary directly onto the DNS hierarchy; describes classless IPv4 reverse delegation. uses prefixes as host address-selection policy keys rather than as forwarding entries.

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 .

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 , with Loc-RIB monitoring in . BGP-LS NLRI and topology context are specified in . 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 (). 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.

Interoperability Failure Cases The following failures illustrate why successful parsing is not sufficient for semantic interoperability.

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.

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 . Prefix length determines mathematical coverage, not operational role; see the routing distinction in and the distinct forms in .

Prefix Versus Prefix Selector The same writing, 203.0.113.0/24, can be three different objects:

• the exact canonical prefix 203.0.113.0/24;
• the set of addresses inside that prefix; or
• a selector whose base is that prefix.

The distinguishing question is not the slash string. It is what the value is being asked to match. If one can answer which prefixes match, and at which lengths, the value is a selector. If one can answer only which addresses sit under the mask, the value is a canonical prefix used as an address-set predicate, not a selector. A Route Origin Authorization (ROA) containing 203.0.113.0/24 with maxLength 26 does not authorize the same set of route announcements as the same prefix with no maxLength. The first selects every prefix from length 24 through 26 under that base. The second selects only {203.0.113.0/24}. Collapsing either authorization to the base prefix can produce a false permit or false deny.

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.

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.

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 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. recommends one canonical output form for IPv6 text while requiring implementations to accept every legitimate form. Textual canonicalization is an interchange rule, not an internal value model or a substitute for semantic equality.
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 , which restates these questions in a compact form for specification, API, schema, and implementation review.

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.

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. 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.

IANA Considerations This document has no IANA actions.

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 , 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.

References Normative References This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length. Informative References This RFC is a list of the Assigned IP Network Numbers and EGP Autonomous System Numbers. This RFC obsoletes RFC-997. This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers run by transit routing domain providers. This memo provides information for the Internet community. It does not specify an Internet standard. This memo discusses strategies for address assignment of the existing IP address space with a view to conserve the address space and stem the explosive growth of routing tables in default-route-free routers. [STANDARDS-TRACK] This memo defines and discusses requirements for devices that perform the network layer forwarding function of the Internet protocol suite. [STANDARDS-TRACK] This document describes a way to do IN-ADDR.ARPA delegation on non-octet boundaries for address spaces covering fewer than 256 addresses. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time. [STANDARDS-TRACK] This paper discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS (Denial of Service) attacks which use forged IP addresses to be propagated from 'behind' an Internet Service Provider's (ISP) aggregation point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. [STANDARDS-TRACK] This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK] BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines two X.509 v3 certificate extensions. The first binds a list of IP address blocks, or prefixes, to the subject of a certificate. The second binds a list of autonomous system identifiers to the subject of a certificate. These extensions may be used to convey the authorization of the subject to use the IP addresses and autonomous system identifiers contained in the extensions. [STANDARDS-TRACK] This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK] This memo introduces a new set of simple extensions to the Routing Policy Specification Language (RPSL), enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. [STANDARDS-TRACK] This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK] IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK] This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VPN, etc.). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. [STANDARDS-TRACK] As the Internet has grown, and as systems and networked services within enterprises have become more pervasive, many services with high availability requirements have emerged. These requirements have increased the demands on the reliability of the infrastructure on which those services rely. Various techniques have been employed to increase the availability of services deployed on the Internet. This document presents commentary and recommendations for distribution of services using anycast. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] IPv6 specifies a model of a subnet that is different than the IPv4 subnet model. The subtlety of the differences has resulted in incorrect implementations that do not interoperate. This document spells out the most important difference: that an IPv6 address isn't automatically associated with an IPv6 on-link prefix. This document also updates (partially due to security concerns caused by incorrect implementations) a part of the definition of "on-link" from RFC 4861. [STANDARDS-TRACK] This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK] RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document obsoletes RFC 3177. [STANDARDS-TRACK] This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa. Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK] This memo reiterates the assignment of an IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries. Upon restructuring, the aforementioned registries will record all special-purpose address blocks, maintaining a common set of information regarding each address block. This document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. This document also provides information about the processes for further evolution of the Internet Numbers Registry System. This document replaces RFC 2050. This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today. This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet. This document identifies a need for and proposes improvement of the unicast Reverse Path Forwarding (uRPF) techniques (see RFC 3704) for detection and mitigation of source address spoofing (see BCP 38). Strict uRPF is inflexible about directionality, the loose uRPF is oblivious to directionality, and the current feasible-path uRPF attempts to strike a balance between the two (see RFC 3704). However, as shown in this document, the existing feasible-path uRPF still has shortcomings. This document describes enhanced feasible-path uRPF (EFP-uRPF) techniques that are more flexible (in a meaningful way) about directionality than the feasible-path uRPF (RFC 3704). The proposed EFP-uRPF methods aim to significantly reduce false positives regarding invalid detection in source address validation (SAV). Hence, they can potentially alleviate ISPs' concerns about the possibility of disrupting service for their customers and encourage greater deployment of uRPF techniques. This document updates RFC 3704. This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. The BGP Monitoring Protocol (BMP) defines access to local Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Local Routing Information Base (Loc-RIB), as defined in RFC 4271. The Loc-RIB contains the routes that have been selected by the local BGP speaker's Decision Process. This specification defines two Concise Binary Object Representation (CBOR) tags for use with IPv6 and IPv4 addresses and prefixes. Intent and Intent-Based Networking are taking the industry by storm. At the same time, terms related to Intent-Based Networking are often used loosely and inconsistently, in many cases overlapping and confused with other concepts such as "policy." This document clarifies the concept of "intent" and provides an overview of the functionality that is associated with it. The goal is to contribute towards a common and shared understanding of terms, concepts, and functionality that can be used as the foundation to guide further definition of associated research and engineering problems and their solutions. This document is a product of the IRTF Network Management Research Group (NMRG). It reflects the consensus of the research group, having received many detailed and positive reviews by research group participants. It is published for informational purposes. In many environments, a component external to a network is called upon to perform computations based on the network topology and the current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism applies to physical and virtual (e.g., tunnel) IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). This document obsoletes RFC 7752 by completely replacing that document. It makes some small changes and clarifications to the previous specification. This document also obsoletes RFC 9029 by incorporating the updates that it made to RFC 7752. This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991. This document specifies the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC 8415. It incorporates verified errata and obsoletes the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code).

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?
• 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 )?
• 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?