RFC 7010

IPv6 Site Renumbering Gap Analysis

📅 published September 2013, from ietf

RFC 7010: IPv6 Site Renumbering Gap Analysis 🦋

okay bestie, this one is the IPv6 Site Renumbering Gap Analysis 💅 It's from September 2013 and it's an Informational doc, so it's sharing knowledge, not setting rules. Written by B. Liu and S. Jiang (Huawei Technologies Co., Ltd.), B. Carpenter (University of Auckland), S. Venaas (Cisco Systems), and W. George (Time Warner Cable). The ISSN is 2070-1721. It has no Obsoletes or Updates line in its header, so it doesn't replace or change any other RFC 🫶

Abstract

This doc quickly introduces the mechanisms that could be used for IPv6 site renumbering ✨ It tries to cover most of the explicit issues and requirements tied to IPv6 renumbering. It's mainly a gap analysis, which means it finds the holes so future work can figure out solutions, or just get people excited to build them 🔥 The analysis is organized by the main steps of a renumbering process.

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes 🌸

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7010.

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🧚

Table of Contents

1. Introduction ....................................................4
2. Overall Requirements for Renumbering ............................4
3. Existing Components for IPv6 Renumbering ........................5
   3.1. Relevant Protocols and Mechanisms ..........................5
   3.2. Management Tools ...........................................6
   3.3. Procedures and Policies ....................................7
4. Managing Prefixes ...............................................7
   4.1. Prefix Delegation ..........................................7
   4.2. Prefix Assignment ..........................................8
5. Address Configuration ...........................................8
   5.1. Host Address Configuration .................................8
   5.2. Router Address Configuration ...............................9
6. Updating Address-Relevant Entries ..............................10
   6.1. DNS Records Update ........................................10
   6.2. In-Host Server Address Update .............................11
   6.3. Address Update in Scattered Configurations ................11
7. Renumbering Event Management ...................................13
   7.1. Renumbering Notification ..................................13
   7.2. Synchronization Management ................................14
   7.3. Renumbering Monitoring ....................................15
8. Miscellaneous ..................................................15
   8.1. Multicast .................................................15
   8.2. Mobility ..................................................17
9. Gap Summary ....................................................17
   9.1. Managing Prefixes .........................................17
   9.2. Address Configuration .....................................17
   9.3. Address-Relevant Entries Update ...........................18
   9.4. Renumbering Event Management ..............................19
   9.5. Miscellaneous .............................................19
10. Gaps Considered Unsolvable ....................................20
   10.1. Address Configuration ....................................20
   10.2. Address-Relevant Entries Update ..........................20
   10.3. Miscellaneous ............................................21
11. Security Considerations .......................................21
12. Acknowledgments ...............................................22
13. References ....................................................23
   13.1. Normative References .....................................23
   13.2. Informative References ...................................23

1. Introduction 🌈

Okay so, as [RFC5887] introduced, renumbering is viewed as expensive and painful, especially for medium to large sites and networks 💀 It's an error-prone process, and network managers avoid it as much as they can. If IPv6 site renumbering keeps feeling this hard, managers will go for Provider Independent (PI) addressing for IPv6 to cut down on future renumbering. The problem is that widespread PI addressing may cause very serious BGP4 scaling problems [RFC4984]. So it's really desirable to build tools and practices that make renumbering simpler and cut down on demand for IPv6 PI space 🫶

This doc builds on the IPv6 enterprise renumbering scenarios described in [RFC6879]. It does a gap analysis to give future work a base to identify and build solutions, or to get people excited to do it ✨ The analysis follows the main steps of a renumbering process. Those steps are prefix management, node address (re)configuration, and updates to address-relevant entries in devices like firewalls, routers, and servers, etc. Renumbering event management gets its own section, separate from those steps, so we can find some operational and administrative gaps in renumbering 🎀

This doc starts from existing work in [RFC5887] and [RFC4192]. It digs further into the issues that are valuable and solvable, finds some gaps nobody has noticed yet, and gives some solution suggestions 👑 It treats the make-before-break approach as a premise for the gap analysis, so readers should be familiar with [RFC4192] 🦋

Renumbering nodes with static addresses has its own particular set of problems, so that space is covered in a related document, [RFC6866] 💅

This document does not cover the unplanned emergency renumbering cases 🙈

2. Overall Requirements for Renumbering 🍓

This section is about the overall goals of a renumbering event. Generally, we want to use renumbering automation to avoid human intervention as much as possible, at a reasonable cost. Some existing mechanisms already give useful capabilities 💜

The automation breaks down into four aspects. (A detailed analysis of each one is in Sections 4 through 7, respectively.)

  • Prefix delegation and delivery should be automatic and accurate in aggregation and coordination. ✨
  • Address reconfiguration should be automatically achieved through standard protocols with minimum human intervention. 🧚
  • Address-relevant entry updates should be performed together and without error. 🔥
  • Renumbering event management is needed to provide the functions of renumbering notification, synchronization, and monitoring. 🌸

Besides automation, session survivability is another big deal during renumbering 😭 Application outage is one of the most obvious impacts that make renumbering painful and expensive. Session survivability is a fundamental issue that can't be solved within a renumbering context alone. Still, the [RFC4192] make-before-break approach uses the address lifetime mechanisms in IPv6 Stateless Address Autoconfiguration (SLAAC) and Dynamic Host Configuration Protocol for IPv6 (DHCPv6). That lets you make a smooth transition from old to new prefixes. In most cases, we can set the transition period to be long enough to cover ongoing sessions, so we consider this mechanism sufficient to avoid broken sessions in IPv6 site renumbering 🫶 (Heads up: if multiple addresses run on hosts at the same time, the address selection [RFC6724] needs to be handled really carefully 🙈)

3. Existing Components for IPv6 Renumbering 🌷

Renumbering isn't a new issue, so some protocols and mechanisms have already been used for it. There are also some dedicated protocols and mechanisms built specifically for renumbering. This section gives a quick tour of these existing protocols and mechanisms, as a base for the gap analysis 🎀

3.1. Relevant Protocols and Mechanisms 💖

  • Router Advertisement (RA) messages, defined in [RFC4861], are used to deprecate prefixes that are old or announce prefixes that are new, and to advertise the availability of an upstream router. In renumbering, RA is one of the basic mechanisms for host configuration. 🦋
  • When renumbering a host, SLAAC [RFC4862] may be used for address configuration with the new prefix(es). Hosts receive RA messages that contain a routable prefix(es) and the address(es) of the default router(s). Then hosts can generate an IPv6 address(es) by themselves. ✨
  • Hosts that are configured through DHCPv6 [RFC3315] obtain new addresses through the renewal process or when they receive the reconfiguration messages initiated by the DHCPv6 servers. 🧚
  • DHCPv6-PD (Prefix Delegation) [RFC3633] enables automated delegation of IPv6 prefixes using the DHCPv6. 👑
  • [RFC2894] defines standard ICMPv6 messages for router renumbering. This is a dedicated protocol for renumbering, but we are not aware of real network deployment. 🙈

3.2. Management Tools 🧰

Some renumbering jobs can be handled automatically by management tools, which makes the whole process more efficient and accurate 💅. The tools might be built specifically for renumbering, or regular tools could handle some of the renumbering operations.

Here are some examples of these tools 🦋:

  • IP address management (IPAM) tools. There are both commercial and open-source options. IPAM tools are used to manage IP address plans and usually bundle DHCPv6 and DNS together as one whole solution. Lots of mature commercial tools can support management operations, but they normally don't have dedicated renumbering functions. Still, the integrated DNS/DHCPv6 services and address management function can obviously make renumbering way easier 🌸.
  • Third-party tools. Some organizations use third-party tools to push configuration to devices. This is sometimes used as a supplement to vendor-specific solutions. A representative of this kind of tool is [CFENGINE] 🔥.
  • Macros. [LEROY] proposed a mechanism of macros that automatically updates the address-relevant entries and configurations inside the DNS, firewalls, and so on ✨. The macros can be delivered through the SOAP protocol from a network management server to the managed devices.
  • Asset management tools/systems. These tools may let you manage configuration files on devices, so it's convenient to update the address-relevant configuration on those devices 🎀.

3.3. Procedures and Policies 📋

  • Procedures from [RFC4192]. [RFC4192] proposed a procedure for renumbering an IPv6 network without a flag day 🌈. The document includes a set of operational suggestions that network administrators can follow step by step. It should be noted that administrators need to carefully deal with the address selection issue, while the old and new prefixes are both available during the overlapping period, as described in the procedures in [RFC4192]. The address selection policies might need to be updated after renumbering, so the administrator could leverage the address-selection-policy distribution mechanism described in [6MAN-ADDR-OPT] 💖.
  • Enterprise renumbering analysis from [RFC6879]. [RFC6879] analyzes enterprise renumbering events and makes recommendations based on the existing renumbering mechanisms 🧠. According to the different stages, renumbering considerations are sorted into three categories: considerations and recommendations during network design, for the preparation of enterprise network renumbering, and during the renumbering operation.

4. Managing Prefixes 🧩

When renumbering an IPv6 enterprise site, the key procedural issue is switching the old prefix(es) to a new one(s) 🔄. A new short prefix may be divided into longer ones for subnets, so we need to carefully manage the prefixes to make sure they stay synchronized and coordinated across the whole network. This is the part where things can get messy, so pay attention, bestie 👑.

4.1. Prefix Delegation 📦

For big enterprises, the new short prefix(es) usually arrive through offline human communication 📞. But for SOHO-style (Small Office, Home Office) SMEs (Small & Medium Enterprises), the prefixes might be dynamically received by DHCPv6 servers or routers inside the enterprise networks. The short prefix(es) could be automatically delegated through DHCPv6-PD. Then the downlink DHCPv6 servers or routers could begin advertising the longer prefixes to the subnets 🚀.

The delegation routers might need to renumber themselves with the new delegated prefixes. So there should be a mechanism to inform the routers to renumber themselves by delegated prefixes. There should also be a mechanism for the routers to derive addresses automatically based on the delegated prefixes 🫶.

4.2. Prefix Assignment 🎯

When subnet routers receive the longer prefixes, they can advertise a prefix on a link where hosts are connected. For prefix assignment, host address configuration is the primary concern rather than routers, and that's described in Section 5.1 🌟.

5. Address Configuration 🏠

5.1. Host Address Configuration 💻

  • SLAAC and DHCPv6 Interaction Problems.

Both DHCPv6 and Neighbor Discovery (ND) protocols have an IP address configuration function, and they're suited to different scenarios 🧃. During renumbering, SLAAC-configured hosts can reconfigure IP addresses by receiving ND Router Advertisement (RA) messages containing new prefix information. (It should be noted that prefix delivery could be achieved through DHCPv6 according to [PREFIX-DHCPv6].) DHCPv6-configured hosts can reconfigure addresses by initiating RENEW sessions [RFC3315] when the current addresses' lease times have expired, or when they receive reconfiguration messages initiated by the DHCPv6 servers 😭.

Sometimes the two address configuration modes are available in the same network. This adds extra complexity for both the hosts and network management 🌀.

With the flags defined in RA (ManagedFlag (M), indicating the DHCPv6 service is available in the network; OtherConfigFlag (O), indicating other configurations such as DNS/routing), the two separate address configuration modes are correlated 🔗. However, the ND protocol does not define the flags as prescriptive, only as advisory. This has led to variation in how hosts interpret the flags, and different operating systems have followed different approaches 🙈. (For more details, please refer to [DHCPv6-SLAAC] and [6RENUM-SLAAC].)

The impact of ambiguous M/O flags includes the following aspects:

  • DHCPv6-configured hosts might not be able to be renumbered by RA.

It is unclear whether a DHCPv6-configured host will accept address configuration through RA messages, especially when the M flag transitions from 1 to 0. This depends on the implementation of the operating system 💀. It might not be possible for administrators to only use RA messages for renumbering, since renumbering might fail on some hosts that are already DHCPv6-configured. This means administrators have to use DHCPv6 reconfiguration for some DHCPv6-configured hosts. That's not convenient, and DHCPv6 reconfiguration isn't suitable for bulk usage, as analyzed below.

  • DHCPv6-configured hosts might not be able to learn new RA prefixes.

[RFC5887] mentions that DHCPv6-configured hosts may want to learn about the upstream availability of new prefixes, or the loss of prior prefixes, dynamically by deducing this from periodic RA messages 👀. Relevant standards [RFC4862] [RFC3315] are ambiguous about what approach a DHCPv6-configured host should take when it receives RA messages containing a new prefix. Current behavior depends on the operating system of the host and cannot be predicted or controlled by the network 🎭.

  • SLAAC-configured hosts might not be able to add a DHCPv6 address(es).

The behavior when the host receives RA messages with the M flag set is unspecified 🤷‍♀️.

The host may start a DHCPv6 session and receive the DHCPv6 address configuration, or it may just ignore the messages. Whether hosts start DHCPv6 configuration is outside the control of the network side 🙃.

5.2. Router Address Configuration 🛣️

  • Learning New Prefixes.

As described in [RFC5887], "if a site wanted to be multihomed using multiple provider-aggregated (PA) routing prefixes with one prefix per upstream provider, then the interior routers would need a mechanism to learn which upstream providers and prefixes were currently reachable (and valid). In this case, their Router Advertisement messages could be updated dynamically to only advertise currently valid routing prefixes to hosts. This would be significantly more complicated if the various provider prefixes were of different lengths or if the site had non-uniform subnet prefix lengths." 🌐

  • Restarting After Renumbering.

As [RFC2072] mentions, some routers cache IP addresses in some situations, so routers might need to be restarted as a result of site renumbering 🔁. While most modern systems support a cache-clear function that eliminates the need for restarts, there are always exceptions that must be taken into account 😤.

  • Router Naming.

[RFC4192] states that "To better support renumbering, switches and routers should use domain names for configuration wherever appropriate, and they should resolve those names using the DNS when the lifetime on the name expires". As [RFC5887] described, this capability is not new, and it's currently present in most IPsec VPN implementations 🥰. However, many administrators may need to be alerted to the fact that it can be used to avoid manual modification during renumbering 🙌.

6. Updating Address-Relevant Entries 📝

When you renumber the nodes, any configuration or data store containing previous addresses must be updated as well 🧹. Some examples are DNS records and filters in various entities, such as Access Control Lists (ACLs) in firewalls and gateways 🔐.

6.1. DNS Records Update 🌍

  • Secure Dynamic DNS (DDNS) Update.

In real network operations, a DNS update is normally achieved by maintaining a DNS zone file and loading that file into the site's DNS server(s). Synchronizing host renumbering with updates to its AAAA record is hard 😩. [RFC5887] discusses an alternative that uses the Secure Dynamic DNS Update [RFC3007], in which a host informs its own DNS server when it receives a new address 💌.

The Secure Dynamic DNS Update has been widely supported by the major DNS implementations, but it hasn't been widely deployed. Normal hosts aren't suitable to do the update, mainly because of the complex key-management issues inherited from secure DNS mechanisms. So current practices usually assign DHCP servers to act as DNS clients, requesting that the DNS server update relevant records [RFC4704] 🛠️. The key-management problem is tractable when updating a limited number of servers, so Dynamic DNS updates could serve as a suitable solution for keeping server DNS records up to date on a typical enterprise network. However, this solution isn't easily applicable to hosts in general 🫠.

To address the larger use case of arbitrary non-server hosts being renumbered, DHCP servers have to learn that the relevant hosts have changed their addresses, and then trigger the DDNS update. If the hosts were numbered and also renumbered by DHCP, it would be easy for the DHCP servers to learn the address changes. However, if the hosts were numbered by SLAAC, then there could be trouble 🚨.

6.2. In-Host Server Address Update ✨

okay so DNS keeps track of host addresses in its servers, but hosts also have to know the addresses of servers, like DNS and RADIUS servers [RFC2865] 🖥️. so during renumbering, hosts need to update these server addresses if the servers' addresses change. it's a whole chain, bestie 🔗

in principle, DHCPv6 server addresses don't need updating, because hosts could find them dynamically through DHCPv6-relevant multicast messages 🛰️. but in practice, most relay agents can be configured with a DHCPv6 server address instead of sending to a multicast address. so the DHCP server address update might actually be a problem IRL 😬

6.3. Address Update in Scattered Configurations 🕸️

besides the DNS records and the in-host server address entries, IP addresses are also configured in tons of other places. think filters like ACLs and routing policies 🧱. it gets even more sophisticated when IP addresses are used to derive other values. for example, the unique portion of a loopback address can be used to generate an ISIS net ID 🤯

in renumbering, updating the IP addresses everywhere I just mentioned is burdensome and super error-prone 😭. we don't have a "one-stop" mechanism that can trigger updates for all the subsystems on a host or server, and for all the external databases that refer to the IP address. we split this general "one-stop" gap into two aspects, and I'm going to walk you through both 💅

  • Self-Contained Configuration in Individual Devices 🎀

ideally, an IP address gets defined as a value once. then admins can use keywords or variables to call that value in other places, kind of like internal inheritance in a CLI (command line interface) or other local configurations 🧠. this makes renumbering easier because there are fewer places where a device's configuration has to be updated.

however, every device still needs to be updated individually. the difference is that it's only once per device now, instead of having to inspect the entire configuration to make sure no separate place where an IP address shows up was missed 🙈

some current routers let you define multiple loopback interfaces that other configurations can call. for example, when you define a tunnel, it can call a defined loopback interface and use its address as the tunnel's local address 🚇. this can be seen as a kind of parameterized self-contained configuration. but it only works for certain use cases. you can't use loopback interfaces to represent external devices, and it's not always possible to call loopback interfaces from other configurations 🥲. parameterized self-contained configuration is still a gap that needs filling, fr fr 🩹

  • Unified Configuration Management among Devices 🌈

this is about a more formalized central configuration management system, where all changes are made in one place and the system handles how they get pushed out to each device 🗂️. this issue has two parts:

  • Configuration Aggregation 🧩

configuration data based on addresses or prefixes is usually spread across lots of different devices. as [RFC5887] describes, some address configuration data can be widely dispersed and way harder to find 🔍. some of it will inevitably only get found after the renumbering event happens 💀. since there's a big gap in configuration aggregation, it's hard to gather all the relevant configuration data in one place.

  • Configuration Update Automation 🤖

as mentioned in Section 3.2, [LEROY] proposes a mechanism that can automatically update configurations. it uses macros that suit different devices, like routers and firewalls, to update configurations based on the new prefix ✨. this kind of automation tool is valuable for renumbering because it cuts down on manual work, and manual work is error-prone and inefficient 🙌

besides the macros, [LEROY] also proposes using SOAP to deliver them to devices 📬. alongside SOAP, we may consider whether it's possible and suitable to use other standardized protocols, like the Network Configuration Protocol (NETCONF) [RFC6241] 🧐

in current real networks, most devices use vendor-private protocols to update configurations. so it's not necessarily valid to assume there will be a formalized configuration management system to leverage 🙃. there are some vendor-independent tools, as mentioned in Section 3.2, but a standard and comprehensive way to uniformly update configurations across multi-vendor devices is still missing 🫠

7. Renumbering Event Management 🎬

from the network management perspective, renumbering is an event that may need additional processes to make it easier and more manageable 💼

7.1. Renumbering Notification 📣

the renumbering process could benefit from hosts or servers being made aware that a renumbering event happened 🔔. here are a few examples of extra processes that might ease renumbering:

  • A notification mechanism may be needed to tell hosts that a renumbering event has changed some DNS records on DNS servers (normally, in an enterprise, that's a local recursive DNS server or servers). then hosts might want to refresh their DNS cache 🔄. that mechanism may also need to indicate that such a change will happen at a specific time in the future ⏰
  • As suggested in [RFC4192], if the DNS service can get prior notice about a renumbering event, the delay in transitioning to new IPv6 addresses could be reduced, which improves renumbering efficiency 🚀
  • Router awareness: in a site with multiple domains connected by border routers, all border routers should be aware of renumbering in one domain or several domains. they should update their internal forwarding tables and their address- and prefix-based filters accordingly, so inbound packets get handled correctly 🛣️
  • Ingress filtering: ISPs normally turn on an ingress filter that drops packets with source addresses from other ISPs at end-site routers, to prevent IP spoofing [RFC2827] 🛡️. in a multihomed site with multiple PA prefixes, the ingress router of ISP A should be notified if ISP B starts a renumbering event, so it can update its filters to permit the new legitimate prefix(es). large enterprises might manage this new legitimate prefix information through human communication, but for the millions of small enterprises, an automated notification mechanism is needed 🏢
  • Log collectors: in the NMS (network management system), log collectors that gather logs through syslog, SNMP notifications, IPFIX, and so on usually treat UDP message source IP addresses as host or router IDs 🗃️. when one source IP address changes, the log collectors think a brand new device showed up on the network 😵. so there needs to be a mechanism for NMS applications to learn about the renumbering event, including the mappings of old and new IP addresses for each host or router. that way they can update the address-relevant mappings described in Section 7.2 🧾

7.2. Synchronization Management 🔗

  • DNS Update Synchronization ⏳

DNS changes must be coordinated with node address configuration changes 🤝. DNS has a latency issue when information propagates from the server to the resolver. the latency is mainly caused by the Time to Live (TTL) assigned to individual DNS records, and by the timing of updates from primary to secondary servers [RFC4192] 🐢

ideally, during a renumbering operation, the DNS TTLs should always be shorter than any other lifetimes associated with an address 💖. if the TTLs are set correctly, the DNS latency can be well controlled. however, there might be some exceptional situations where the DNS TTLs were already set too long for the time available to plan and execute a renumbering event 😩. in these situations, there are currently no mechanisms to deal with the long DNS TTLs that are already configured 🙁

  • NMS Address-Relevant Mapping Synchronization 🗺️

as described in Section 7.1, the NMS needs to learn about the renumbering event so it can correlate the old and new addresses in the logs 📚. if the NMS assigns unique IDs to hosts or routers, then the mappings between those unique IDs and IP addresses also need to be updated after renumbering 🔑

7.3. Renumbering Monitoring 👀

while treating renumbering as a network event, mechanisms to monitor the renumbering process might be needed so administrators can tell whether renumbering was successful ✅. since the address configuration operation might be stateless (if ND is used for renumbering), it's difficult to monitor 😤

8. Miscellaneous 🌸

since multicast and mobility are special use cases that might not be part of routine or common renumbering operations, they get discussed separately in this miscellaneous section 🦋

8.1. Multicast ✨

Okay so, from the point of view of interface renumbering ops, renumbering a multicast address is basically the same as renumbering a unicast address 🦋. This section is mostly about the stuff that hits multicast application systems when renumbering happens. Renumbering also affects multicast 💅. Renumbering unicast addresses messes with multicast even if the multicast addresses stay the same, and sometimes the multicast addresses need renumbering too 😭.

  • Renumbering of Multicast Sources

If a host that is a multicast source gets renumbered, the application on that host may need to be restarted before it can successfully send packets with the new source address 🔄.

For ASM (Any-Source Multicast), the receiver sees a brand new source start sending, and it stops receiving from the previous source. Whether that's an issue depends on the app, but we think it's likely not a major one 🌸.

For SSM (Source-Specific Multicast) though, there's one significant problem 💀. The receiver needs to learn which source addresses it must join. Some apps might have their own way of learning sources, where the source app somehow signals the receiver.

Otherwise, the receiver may need to get new SDP (Session Description Protocol) info with the new source address. That's similar to how it learns a new group address, so see the "Renumbering of Multicast Addresses" topic below 🧚.

  • Renumbering of Rendezvous-Point

If the unicast addresses of routers in a network get renumbered, the RP (Rendezvous-Point) address is also likely to change for at least some groups 👑. An RP address is needed by PIM-SM (Protocol Independent Multicast - Sparse Mode) to provide ASM, and for Bidir PIM. Changing the RP address isn't a major issue, except the multicast service may be impacted while the new RP addresses are being configured ⏳. If dynamic protocols are used to distribute group-to-RP mappings, the change can be fairly quick and the impact time should be very brief ⚡. However, if routers are statically configured, the impact time depends on how long it takes to update all the configurations 🐢.

For PIM-SM, one typically switches to SPT (Shortest-Path-Tree) when the first packet is received by the last-hop routers. Forwarding on the SPT should not be impacted by the change of IP address 🌈. A network operator should be careful not to deprecate the previous mapping before configuring a new one, because implementations may revert to Dense Mode if no RP is configured 🙈.

  • Renumbering of Multicast Addresses

In general, multicast addresses can be chosen independently of the unicast addresses, and the multicast addresses can remain fixed even if the unicast addresses are renumbered 💜. However, for IPv6, there are useful ways of deriving multicast addresses from unicast addresses, such as those described in "Unicast-Prefix-based IPv6 Multicast Addresses" [RFC3306] and "Embedded-RP IPv6 Multicast Addresses" [RFC3956]. In those cases, the multicast addresses used may have to be renumbered 🔁.

Renumbering group addresses may be complicated. For multicast, it's common to use literal addresses and not DNS 📝. When multicast addresses change, source applications need to be reconfigured and restarted 🔧.

Multicast receivers need to learn the new group addresses to join 📢.

Note that for SSM, receivers need to learn which multicast channels to join. A channel is a source and group pair. This means that for an SSM application, a change of source address is likely to have the same effect as a change of group address 🫶.

Some applications may have dynamic methods of learning which groups (and possibly sources) to join. If not, the application may have to be reconfigured and restarted 🔄.

One common way for receivers to learn the necessary parameters is by using SDP. SDP information may be distributed via various application protocols or from a file. An SDP file may be distributed via HTTP, email, etc. If a user is in a web browser and clicking a link to launch the application with the necessary data, it may be a matter of closing the current application and re-clicking the link 🖱️.

In summary, right now, multicast renumbering issues are basically handled by application-specific methods. There is no standard way to guarantee that multicast service could live across a renumbering event 😭🎀.

8.2. Mobility 🦋

As described in [RFC5887], if a mobile node's home address changes unexpectedly, the node can be informed of the new global routing prefix used at the home site through the Mobile Prefix Solicitation and Mobile Prefix Advertisement ICMPv6 messages [RFC6275]. However, if the mobile node is disconnected at the time of home address renumbering, it will no longer know a valid subnet anycast address for its home agent. That leaves it to deduce a valid address based on DNS information 🕵️‍♀️.

So, for Mobile IP, we need a better mechanism to handle the change of home agent address while the mobile address is disconnected 🥺.

9. Gap Summary 📋

The following is a summary of the gaps identified previously in this document that are considered solvable, but may require process or protocol changes to resolve ✨.

9.1. Managing Prefixes

  • A mechanism informing the routers to renumber themselves by delegated prefixes.
  • A mechanism for the routers to derive addresses automatically based on the delegated prefixes.

9.2. Address Configuration

  • Host Address Configuration
    • DHCPv6-configured hosts might not be able to be renumbered by RA on some current implementations.
    • DHCPv6-configured hosts might not be able to learn new RA prefixes on some current implementations.
    • SLAAC-configured hosts might not be able to add DHCPv6 address(es) on some current implementations.
  • Router Address Configuration
    • A mechanism for interior routers in a multihomed site to learn which upstream providers and prefixes are currently reachable 🗺️.
    • Cache-clear might need to restart (rarely in modern routers).
    • Use of router domain names is not widely learned or deployed by administrators.

9.3. Address-Relevant Entries Update

  • DNS Records Update
    • For key-management scalability issues, secure dynamic DNS update is usually done by DHCP servers on behalf of the hosts, so it might not be practical for SLAAC-configured hosts to do secure DDNS 🔐.
  • In-Host Server Address Update
    • DHCP relays might be configured with DHCP server addresses rather than by sending multicast messages to discover the DHCP server dynamically, so updating the DHCP server addresses might be an issue in practice 🤔.
  • Address Update in Scattered Configurations
    • For devices that don't support parameterized configuration, administrators need to individually update all devices in which IP addresses were previously configured 😩.
    • It is hard to get all the address-relevant configurations spread across various devices through one place.
    • Uniformly updating configurations in multi-vendor devices is currently a big gap that needs to be filled 🚧.

9.4. Renumbering Event Management

  • Renumbering Notification
    • A mechanism to indicate a host's local recursive DNS is going to be renumbered.
    • A prior notice about a renumbering event for DNS.
    • A mechanism for border routers to know internal partial renumbering.
    • For multihomed sites, a mechanism is needed to notify the egress router connecting to ISP A that the egress router connecting to ISP B has initiated renumbering 📣.
    • A mechanism is needed for the NMS applications to learn the renumbering event, so that they could correlate the old and new addresses in the logs, and update the unique ID of the device and address mappings 🗂️.
  • Synchronization Management
    • DNS information propagation latency issue ⏱️.
    • Mechanisms are needed for the NMS applications to correlate the old and new addresses in logs and to update the unique ID of the device and address mappings.
  • Renumbering Monitoring
    • Mechanisms to monitor the process and feedback of renumbering might be needed 👀.

9.5. Miscellaneous

  • Multicast
    • A mechanism for SSM receivers to learn the source addresses when multicast sources are renumbered 📡.
  • Mobility
    • A better mechanism to handle a change of home agent address while the mobile address is disconnected.

10. Gaps Considered Unsolvable 🙅‍♀️

This section lists gaps that have been identified by other documents but are considered unsolvable 💔.

10.1. Address Configuration

  • RA Prefix Lifetime Limitation

Section 5.5.3 of [RFC4862] states "If the received Valid Lifetime is greater than 2 hours or greater than RemainingLifetime, set the valid lifetime of the corresponding address to the advertised Valid Lifetime." So when renumbering, if the previous RemainingLifetime is longer than two hours, it is impossible to reduce a prefix's lifetime to less than two hours. This limitation is to prevent denial-of-service attacks 🛡️. Lowkey a bummer, but it's for a good reason, bestie 🫶.

10.2. Address-Relevant Entries Update 💅

okay bestie, this part is all about the stuff that still points at your old addresses after you renumber 😭 like, it's not just your routers. DNS and friends are sitting there holding onto the old numbers and nobody updated them yet 💀

  • DNS Authority 🏢

In an enterprise that hosts servers for collaborators and customers, it's very common for DNS zones outside the hosting enterprise's administrative control to keep resource records about addresses for hosted nodes inside its address space. so when the hosting enterprise renumbers, it doesn't have enough authority to change those records. not fair, but that's the vibe 🥲

This is an operational and policy issue. It is out of scope for this document to consider a technical solution or to propose an additional protocol or mechanism to standardize the interaction between DNS systems for authority negotiations. so we're not fixing this one here, we're just naming it 🫶

  • DNS Entries 📝

DNS entries commonly have matching reverse DNS entries that will also need to be updated during renumbering. bestie, it might not be possible to combine forward and reverse DNS entry updates in one procedure where addresses are not being managed using DHCP. so yeah, two separate chores 🧹

  • DNS Data Structure Optimization 🧚

okay this one is lowkey iconic. [RFC2874] proposed an A6 record type for DNS recording of the IPv6 address and prefix. Several extensions to DNS query and processing were also proposed. A6 was designed to be a replacement for the AAAA record. The changes were designed to facilitate network renumbering and multihoming. With the A6 record and the extensions, an IPv6 address could be defined by using multiple DNS records. This feature would increase the complexity of resolvers but reduce the cost of zone file maintenance, so renumbering could be easier than with the AAAA record. it's giving "split the prefix from the suffix so you only change the part that moved" 🌸

[RFC2874] has been deprecated and moved to Historic status by [RFC6563]. The A6 record has not been widely used and has been shown to have various problems and disadvantages (see Section 2 in [RFC6563]). The idea of a structured record to separate prefix and suffix is still potentially valuable for renumbering, but avoiding the problems of the A6 record would require a major development effort. so the idea is still a vibe, but A6 itself is retired 🥀

10.3. Miscellaneous ✨

  • Transport layer 🚌

For the transport layer, [RFC5887] said that TCP connections and UDP flows are rigidly bound to a given pair of IP addresses. translation: once the addresses change, those connections are stuck to the old pair 😭

  • Application layer 🍓

For the application layer, in general, we can assert that any implementation is at risk from renumbering if it does not check whether an address is valid each time it starts session resumption (e.g., a laptop wakes from sleep state). It is also more or less risky when it opens a new communications session by using cached addresses. so if your app is holding onto old addresses like a clingy ex, it's gonna have a bad time 💀

We considered the above two points (ID/Locator overloading in transport layer and address caching in application layer) fundamental issues that might not be proper to deal with just in terms of renumbering. so these two are bigger than renumbering alone, and we're flagging them as such 🔥

11. Security Considerations 🔥

okay bestie, security is where things get dramatic, so buckle up 🙈

  • Prefix Validation 🔐

Prefixes from the ISP may need authentication to prevent prefix fraud. Announcing changes of site prefix to other sites (for example, those that configure routers or VPNs to point to the site in question) also needs validation.

In the LAN, Secure DHCPv6 [SECURE-DHCPv6] or Secure Neighbor Discovery (SEND) [RFC3971] deployment may be needed to validate prefixes.

  • Influence on Security Controls 🛡️

During renumbering, security controls (e.g., ACLs) protecting legitimate resources should not be interrupted. For example, if some addresses are in a blacklist, they should not escape from the blacklist due to renumbering. no sneaky loopholes allowed 🙅‍♀️

Addresses in SEND certificates will need to get updated when renumbering. During the overlap between old and new addresses, both certificates must remain valid. two certs, one moment, zero drama 💜

  • Security Protection for Renumbering Notification 📣

Section 7.1 mentions possible notification mechanisms to signal a change in the DNS system or in the border routers related to a renumbering event. Since the DNS system and border routers are key elements in any network, and they might take action according to the notification, a security authentication for the renumbering notification is needed.

the DNS system and border routers are the backbone of the whole network, so anyone can't just shout "renumber now!" and expect everyone to listen 🚨
  • Security Protection for Configuration Update ⚠️

Automated configuration update approaches like [LEROY] would increase the risk since a bad actor with the right permission could cause havoc to the networks. automation is amazing until the wrong person has the keys 💀

12. Acknowledgments 🫶

This work adopts significant amounts of content from [RFC5887]. In addition, it draws largely from the "DNS Authority" topic in Section 10.2 from [IPv6-RENUM-THINK]. Both documents offer such important input for this work that some principles and considerations applied in this work are implicitly inherited from them. So thanks go to Randall Atkinson, Hannu Flinck, Tim Chown, Mark Thompson, and Alan Ford. Some useful materials were provided by Oliver Bonaventure and his student, Damien Leroy.

Many useful comments and contributions were made by Ted Lemon, Lee Howard, Robert Sparks, S. Moonesamy, Fred Baker, Sean Turner, Benoit Claise, Stephen Farrell, Brian Haberman, Joel Jaeggli, Eric Vyncke, Phillips Matthew, Benedikt Stockebrand, Gustav Reinsberger, Teco Boot, and other members of the 6renum WG. the whole squad showed up for this one 👑🌈

13. References 📚

13.1. Normative References

  • [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
  • [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
  • [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
  • [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
  • [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
  • [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

13.2. Informative References

  • [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
  • [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
  • [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
  • [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
  • [RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
  • [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
  • [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
  • [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
  • [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
  • [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011.
  • [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
  • [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
  • [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
  • [RFC6563] Jiang, S., Conrad, D., and B. Carpenter, "Moving A6 to Historic Status", RFC 6563, March 2012.
  • [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
  • [RFC6866] Carpenter, B. and S. Jiang, "Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks", RFC 6866, February 2013.
  • [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013.
  • [6MAN-ADDR-OPT] Matsumoto, A., Fujisaki T., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, August 2013.
  • [6RENUM-SLAAC] Liu, B., "DHCPv6/SLAAC Address Configuration Switching for Host Renumbering", Work in Progress, January 2013.
  • [CFENGINE] CFEngine, <http://cfengine.com/what-is-cfengine>.
  • [DHCPv6-SLAAC] Liu, B. and R. Bonica, "DHCPv6/SLAAC Address Configuration Interaction Problem Statement", Work in Progress, February 2013.
  • [IPv6-RENUM-THINK] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006.
  • [LEROY] Leroy, D. and O. Bonaventure, "Preparing network configurations for IPv6 renumbering", International of Network Management, 2009, <http://inl.info.ucl.ac.be/ system/files/dleroy-nem-2009.pdf>
  • [PREFIX-DHCPv6] Jiang, S., Xia, F., and B. Sarikaya, "Prefix Assignment in DHCPv6", Work in Progress, February 2013.
  • [SECURE-DHCPv6] Jiang, S. and Shen S., "Secure DHCPv6 Using CGAs", Work in Progress, September 2012.

Authors' Addresses 🌸

Bing Liu
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No. 156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
EMail: leo.liubing@huawei.com

Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No. 156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
EMail: jiangsheng@huawei.com

Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: brian.e.carpenter@gmail.com

Stig Venaas
Cisco Systems
Tasman Drive
San Jose, CA 95134
United States
EMail: stig@cisco.com

Wesley George
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
United States
Phone: +1 703-561-2540
EMail: wesley.george@twcable.com
📦 where this page comes from