]> NetDEF, Inc.

San Jose USA equinox@diac24.net equinox@opensourcerouting.org

Internet Link-state routing ipv6 Between large enterprise networks that can reasonably use their own IPv6 address space and small home and office networks that do not utilize a complex routing topology, there is an intermediate space where a network may need to utilize a nontrivial routed topology but still connect to the internet in a plain "customer" role, with IPv6 address space being assigned over e.g. DHCPv6-PD. This poses a yet-unsolved issue that the prefix(es) assigned by the ISP may change, either frequently due to operational practice, or infrequently on some external events like loss of prefix assignment state. This change in prefix needs to propagate, at minimum, into mechanisms, but frequently also other components like firewalls, naming systems, etc.

Introduction and history Renumbering is a longstanding, non-trivial and well-known problem with IPv6 networks. Being driven entirely by real-world operational considerations and conditions - a "pure" IPv6 network in a perfect world need never renumber - has turned into somewhat of a sour note, given that (almost?) no one ever voluntarily renumbers. There is a large body of applicable context on this topic. The Renumbering Still Needs Work document has gone as far as spawning a (since concluded) IETF working group, 6renum, dedicated to this topic. Output from this working group includes a Gap Analysis document, a Problem Statement, and Scenarios, Considerations and Methods. Furthermore, the process of adding a new prefix in make-before-break manner before removing an old one was described in . TBD: TBD: fill in homenet and autoconf context too / full-auto This document takes a "router-down" perspective without attempting to take all address management and policy out of the operator's hands. For perspective, this relates to above documents as follows:

• Generally, the problem considered here is renumbering routers (RFC5887 Section 3.1, RFC7010 Section 5.2 and 9.1).
• Only communicating available prefixes and making subnets or host addresses out of them is considered here. How to apply the results to an innumerable amount of entities that may need reconfiguring or flushing of state (RFC5887 Section 5.2) is a giant of its own, e.g. discusses using macros to convene this. The ecosystem is also relevant here, both to query prefix information from the routing system, as well as to apply it.
• The very heart of this document is challenging "Static Addresses Imply Static Prefixes", by allowing static addressing with dynamic prefixes.
• RFC 7010 Section 6.3 (first bullet point, "Self-Contained Configuration in Individual Devices") already documents the concept of "keywords or variables" that reduce configuration change impact from renumbering by reusing bits "defined as a value once". It proceeds to say that this "still means that every device needs to be individually updated". This document formalizes this very concept and provides a mechanism to automate updating this information.

Rationale and bootstrap considerations There are many places and methods that could be used to communicate prefixes to be used in a network. Using the routing system to do this is a better choice than many others for several reasons:

1. At its most basic, to establish IPv6 reachability given a number of (working) lower layer links, two things are needed: addresses and routing information. When the routing domain has come up, the network should work, and if addresses are assigned statically, it hopefully will. This mechanism attempts to not worsen this situation - the network should work after routing has come up.
2. Performing renumbering through configuration management systems can lead to the configuration changes themselves breaking the ability of the configuration management system to apply configuration. Even if make-before-break semantics are followed throughout, ordering constraints may exist - and be very hard to detect. For example, if new addresses are configured on the management system and some routers, the management system's network stack may decide to (in fact, is likely to) immediately use the new addresses in source address selection. If some firewall device has not been updated yet, it will block these connections. It may also block connections to itself. This is not an unsolvable problem, but it has both significant risk, as well as poor verifiability - even if it works in a test, ordering constraints can be subject to race conditions that may randomly show up in a later execution of the exact same renumbering event.
3. Providing alternate or fallback connectivity specifically for management can be costly. Particularly devices used in small to medium business scenarios - the exact target of this approach - may support a limited routing table size, and may not have any VRF support. Providing parallel ULA addressing doubles the resource need when added next to only one GUA prefix. Physically connecting out-of-band management ports can be very difficult with infrastructure cabling constraints.
4. If address configuration is kept in ephemeral state, this can result in bootstrap problems. Both IS-IS and OSPFv3 will start up on exclusively link-local addresses.

Aside from above applicability considerations, the OSPFv3 and IS-IS link state routing protocols provide discovery and flooding mechanisms that are very desirable for disseminating available prefixes. The limited size and expected count of this data is also a great match for the capabilities of these protocols.

Non-goals This document does not attempt any kind of automatic prefix or address assignment in the "second half" of the prefix. It only attempts a mechanism to convey the "first half" of a prefix, and deal with changing it - while keeping the second half firmly under operator control.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Disseminated prefix concept The behavior and encodings described in this document rely on the concept of a disseminated prefix. The semantics of such a prefix are as follows:

• There is a flow of information from "upstream" sources of assignment to "downstream" consumers of addressing information.
• Disseminated prefixes are created by operator configuration and policy, but this policy may not contain the actual prefix and instead reference another upstream source. In the primary case this document attempts to address, one or more prefixes will be picked up from one or more upstream ISPs. DHCPv6 Prefix Delegation and explicit assignment by the ISP are assumed to be the most common sources of a prefix. A randomly generated ULA prefix may also be used, though this would mainly be useful to just apply the same numbering that GUA prefixes receive. ULA prefixes should hopefully not need the renumbering feature.
• Disseminated prefixes can in theory be carried in any arbitrary way across the network. This document describes carrying them in or . Care should be taken both when entering this information into these protocols as well as when passing it outside, to not create "information loops". This is not expected to be a problem since there is a clear upstream to downstream flow direction with disseminated prefixes.
• Prefixes (and host addresses) are carved out of a disseminated prefix for actual use. The bits "filled in" to make these assignments are always configured explicitly. This document does not suggest any kind of automatic numbering. Both prefix and host assignments are called "carve-outs" in the remainder of this document.
• There may be use cases for creating a disseminated prefix as a subnet of another disseminated prefix, but this is not expected to be a primary use case in this document. If this is done, the latter prefix MUST be longer than (covered by) the first prefix to establish a clear hierarchy.
• Disseminated prefixes have a lifetime, which may be inherited from their upstream source (e.g. DHCPv6), or be configured by the operator (e.g. for a static assignment.)
• Additional attributes can be placed on disseminated prefixes to influence how the prefix is (or is not) used. These attributes may be sourced along with the prefix itself (again, DHCPv6) or explicitly configured by the operator. A plain 32-bit opaque integer tag is specified in this document, other types of attributes may be specified.

Example scenario

Basic prefix dissemination example

Using a disseminated prefix First and most importantly, disseminated prefixes are not routing information. A system MUST NOT use disseminated prefix as input in any kind of path calculation. However, specific carve-outs MAY be used to configure routing functions, e.g. announce the carve-out into a routing protocol to create reachability. This is purely a function of automated configuration; routing protocols MUST NOT introduce any special behavior for routing information sourced in this way even if the disseminated prefix was carried by the same routing protocol. Wherever a disseminated prefix turns into actual prefixes or addresses used is considered a "consumer". This would likely happen on routers participating in the link state routing protocol, but disseminated prefix information MAY also be queried by additional applications (e.g. configuration management systems, name servers, firewalls, etc.) and then realized into use. Any system performing this step is equally a "consumer" and MUST follow the steps outlined below. To make use of ("realize") a disseminated prefix, a carve-out MUST be created by explicit operator configuration. This requires input to fill in part of or all of the bits left unspecified in the prefix. This input consists of 4 pieces:

1. Minimum length of the disseminated prefix that is valid to make this carve-out from.
2. Target length of the carve-out to be created; this must be equal to or longer than the minimum length above. Common values are 64 for a subnet to be used for SLAAC and 128 for a host address. Other lengths are also possible e.g. to configure firewall rules for a range of networks or other subdivisions of the network.
3. Values for all bits of the prefix between minimum length and target length.
4. Optionally, additional restrictions/filtering of disseminated prefixes eligible to make this carve-out from, relying on additional attributes the disseminated prefix may carry, e.g. the opaque tag. Other metadata may also influence this filtering, e.g. reachability of the originating router, age of the disseminated prefix, or a limit on the number of disseminated prefixes used to realize a carve-outs.

To realize a carve-out, the consumer considers the operator's configuration against all disseminated prefixes available. The consumer MUST NOT arbitrarily limit the disseminated prefixes. In general, one configured carve-out can result in more than one actual prefix if more than one disseminated prefix is available. If there is a limit on the number of actual prefixes / addresses, the consumer MUST allow the operator to configure eligibility conditions and evaluate them against all disseminated prefix. Only if the limit is still not met, the consumer MUST then fall back to using the oldest disseminated prefix available. (TBD: figure exact behavior.) The consumer MUST reevaluate carve-outs whenever a disseminated prefix becomes available, is no longer available, or has a change in any of its attributes. There MAY be a minor delay or rate limiting on this behavior to protect against overloads or degenerate conditions. A realized carve-out is ultimately a variable carrying a list of prefixes, made available for use wherever that variable is referenced. A system MAY limit the number of prefixes carried (e.g. to 1 prefix), but MUST support the empty case (no prefix) as it occurs when no no disseminated prefixes are available. Realizing a carve-out MUST NOT unadvisedly create a disseminated prefix advertisement. Realizing carve-outs is a local process that does not create state in the network at large. In order to fulfill the above requirements, any consumer residing outside the routing system itself MUST retrieve all disseminated prefix information from the routing system and MUST receive timely updates on change to it. Conversely, if routers provide methods of access to disseminated prefix information (not realized), they MUST include all such information with all of its metadata and attributes.

Advertising a disseminated prefix As outlined in the disseminated prefix semantics, to create an advertisement always requires a configured policy to determine what to disseminate. A system MUST NOT create a disseminated prefix advertisement without operator policy. A system MAY support consuming disseminated prefixes without support for creating advertisements. However, if capable of creating advertisement, a system SHOULD also support consuming them. To aid debugging, any system capable of creating disseminated prefix advertisements SHOULD allow creating disseminated prefixes from operators. This also covers the use case where a prefix is statically assigned by an ISP and manually input by an operator. In principle, it does not matter how some prefix becomes available to the system for disseminating, but the expectation is that this primarily happens through DHCPv6-PD or static assignment. Other methods may require additional considerations.

Policy factors in disseminating a prefix The following considerations apply to systems capable of creating a disseminated prefix advertisement:

• There MUST be a method to constrain acceptable prefixes both in their network bits as well as their prefix length, e.g. a prefix-list style filter. (This does not apply to explicit, statically configured prefixes as that is already a constraint.)
• There MUST be some way to limit the number of prefixes disseminated, to prevent resource exhaustion security issues. If the limit is hit, the oldest known prefixes SHOULD be retained over newer ones to reduce churn.
• If a currently disseminated prefix is known to be withdrawn, its advertisement MUST be withdrawn in a timely manner.
• If the prefix has known lifetimes, it MUST be possible to exclude prefixes below some specified remaining lifetime. This lifetime data MUST be propagated into the disseminated prefix data.
• Other metadata (e.g. from DHCPv6-PD) SHOULD be made available to filter on where useful, and SHOULD be carried in the disseminated prefix if possible.

OSPFv3 transport TBD: which LSA to stick this in? Make a new one? Router Info (12)? Ext. Router LSA (33)? It's only given as a TLV below, but having it be its own LSA is probably better - in particular, with DHCPv6-PD it may need refreshing whenever the lifetime of the delegation is extended - this shouldn't cause routing system load. Needs discussion. A disseminated prefix is transported in OSPFv3 using an Extended LSA TLV with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | PrefixOptions | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Sub-TLVs (variable) :

Type

to be assigned (not sure if possible for experimental?)

Length

TBD

Prefix Length, PrefixOptions and Prefix

These fields behave as specified in . For the PrefixOptions field, all bits MUST be set to zero. TODO: determine if some are applicable, possibly P and DN?

TODO: flesh out, figure how exactly to carry lifetime (in TLV?), add sub-TLVs for e.g. DHCPv6 extra details

Applicable Sub-TLVs The following preexisting sub-TLVs semantically make sense when nested in the Prefix Dissemination TLV and SHOULD be supported in creating advertisements and filtering for realization:

(3) Route-Tag sub-TLV

This sub-TLV may be used to carry operator-defined semantics on a disseminated prefix. Other uses of this sub-TLV limit it to one occurrence, for consistency this requirement is applied here too.

Other sub-TLVs MAY be supported to attach attributes to a disseminated prefix and filter upon them. Note that sub-TLVs present in a disseminated prefix (even explicitly listed above) MUST NOT have any effect on routing behavior by themselves. They also MUST NOT be copied or inherited into any use of realized addresses or prefixes, even if that use reflects back into OSPFv3.

IS-IS transport A disseminated prefix is transported in IS-IS LSPs using a TLV with the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | 0 | MT ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Prefix (variable) | +-+-+-+-+-+-+-+-+ | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Sub-TLVs (variable) :

Type

to be assigned (not sure if possible for experimental?)

MT ID

Topology ID as described in . There is no variant of this TLV without topology identifier; while this may waste 2 bytes, this trade-off was chosen against the alternative of creating two TLV types with and without MT ID. For applicable values see below.

Length

TBD

Prefix Length and Prefix

The Prefix Length field is given in bits, ranging from 0 to 128. As in RFC5308 Section 2, the prefix is "packed" and the number of octets used for the prefix is calculated by rounding up to the next byte boundary.

TODO: flesh out, figure how exactly to carry lifetime (maybe in TLV?), add sub-TLVs for e.g. DHCPv6 extra details. NB: IS-IS TLV (for now) has 255 byte length limit (cf. current drafts on Multi-part / Big TLVs)

Multi-Topology considerations Multi-Topology IS-IS is often used to allow separate topologies for IPv4 and IPv6, in which case IPv6 information is carried under MT ID #2. If IPv4 and IPv6 topologies are identical, MT ID #0 may be in use for IPv6. Implementations of this specification MUST by default place disseminated prefix information in the same topology they use for IPv6 routing, and MUST only process information from that same topology. The topology used MAY be configurable. TBD: other MT IDs? Exclude multicast and IPv4 specific ones? Implementations not supporting IS-IS multi-topology routing MUST use MT ID #0 for disseminated prefix TLVs and MUST ignore any received TLVs of this type with MT ID unequal zero.

Applicable Sub-TLVs The following preexisting sub-TLVs semantically make sense when nested in the Prefix Dissemination TLV:

(1) 32-bit Administrative Tag Sub-TLV

This sub-TLV may be used to carry operator-defined semantics on a disseminated prefix. The Sub-TLV may appear more than once.

(2) 64-bit Administrative Tag Sub-TLV

Same as above.

TODO: (4) Prefix Attribute Flags

for R bit? - if yes then presumably 11 and 12 too (Source Router ID) - need to clear up L1/L2 behavior.

Other sub-TLVs MAY be supported to attach attributes to a disseminated prefix and filter upon them. Note that any (even explicitly listed above) sub-TLVs present in a disseminated prefix MUST NOT have any effect on routing behavior by themselves. They also MUST NOT be copied or inherited into any use of realized addresses or prefixes, even if that use reflects back into IS-IS.

YANG model well, this certainly needs one, other software will definitely want to pull prefix data out of the routing protocol...

Security Considerations TBD

Privacy Considerations TBD

IANA Considerations TBD - needs codepoints for IS-IS and OSPFv3

References Normative References ISO/IEC Informative References International Journal of Network Management, Volume 19, Issue 5

Acknowledgements TBD, FILL IN

Editing notes (TO BE REMOVED) This draft lives at

• -00: 2023-07-26 (IETF 117), initial revision.