RFC 5887

Renumbering Still Needs Work

📅 published May 2010, from ietf

RFC 5887: Renumbering Still Needs Work 🎀

Okay bestie, this one is an Informational RFC, so it's published for information and isn't a standard 📚 It's ISSN 2070-1721, dated May 2010, and it was written by B. Carpenter (Univ. of Auckland), R. Atkinson (Extreme Networks), and H. Flinck (Nokia Siemens Networks) 👑 The title block doesn't list anything it obsoletes or updates, so it's standing alone 💅

Abstract 🦋

This doc looks at the renumbering mechanisms that already exist for sites, for both IPv4 and IPv6, and calls out the operational problems with them 🔥 It also sums up the technical proposals people are currently working on for new mechanisms ✨ Last but not least, there's a gap analysis that points to places where future work could happen 🧚

Status of This Memo 📜

Not an Internet Standards Track spec, babe. It's just here for info 💖

This is a product of the IETF, so it represents what the IETF community agrees on. It got public review and was approved for publication by the IESG. Still, not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full tea ☕

You can find the current status, any errata, and how to give feedback at http://www.rfc-editor.org/info/rfc5887 🌸

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info as they were on the publication date. Please read them carefully, because they lay out your rights and restrictions for this doc 📖 Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💅

Table of Contents 🗂️

1. Introduction ....................................................3
2. Existing Host-Related Mechanisms ................................5
   2.1. DHCP .......................................................5
   2.2. IPv6 Stateless Address Autoconfiguration ...................6
   2.3. IPv6 ND Router/Prefix Advertisements .......................7
   2.4. PPP ........................................................7
   2.5. DNS Configuration ..........................................8
   2.6. Dynamic Service Discovery ..................................9
3. Existing Router-Related Mechanisms ..............................9
   3.1. Router Renumbering .........................................9
4. Existing Multi-Addressing Mechanism for IPv6 ...................10
5. Operational Issues with Renumbering Today ......................11
   5.1. Host-Related Issues .......................................11
        5.1.1. Network-Layer Issues ...............................11
        5.1.2. Transport-Layer Issues .............................13
        5.1.3. DNS Issues .........................................14
        5.1.4. Application-Layer Issues ...........................14
   5.2. Router-Related Issues .....................................16
   5.3. Other Issues ..............................................17
        5.3.1. NAT State Issues ...................................17
        5.3.2. Mobility Issues ....................................18
        5.3.3. Multicast Issues ...................................18
        5.3.4. Management Issues ..................................19
        5.3.5. Security Issues ....................................21
6. Proposed Mechanisms ............................................22
   6.1. SHIM6 .....................................................22
   6.2. MANET Proposals ...........................................22
   6.3. Other IETF Work ...........................................23
   6.4. Other Proposals ...........................................23
7. Gaps ...........................................................24
   7.1. Host-Related Gaps .........................................24
   7.2. Router-Related Gaps .......................................25
   7.3. Operational Gaps ..........................................25
   7.4. Other Gaps ................................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................27
10. Informative References ........................................27
Appendix A.  Embedded IP Addresses ................................34

1. Introduction ✨

Back in early 1996, the IAB put out a short RFC called "Renumbering Needs Work" [RFC1900], and you really should read it before going further 🙈 Almost ten years later, the IETF published "Procedures for Renumbering an IPv6 Network without a Flag Day" [RFC4192] 🍓 A few other RFCs have also touched on router or host renumbering: [RFC1916], [RFC2071], [RFC2072], [RFC2874], [RFC2894], and [RFC4076].

Honestly, since 1996 a bunch of individual mechanisms have shown up to make some parts of renumbering easier 💖 DHCP is available for IPv4 [RFC2131] and for IPv6 [RFC3315]. IPv6 also has Stateless Address Autoconfiguration (SLAAC) [RFC4862], which includes Router Advertisements (RAs) with options that list the set of active prefixes on a link 🌈 And PPP [RFC1661] allows automated address assignment for both versions of IP 🦋

Even with all that, renumbering, especially at medium to large sites and networks, is still widely seen as expensive, painful, and error-prone 😭 So network managers avoid it as much as they possibly can. Some folks would argue that the very design of IP addressing and routing makes automatic renumbering intrinsically impossible 🤔 Managers also have an economic incentive to dodge renumbering, so plenty of them have turned to private addressing and Network Address Translation (NAT). The highly unfortunate result is that any mechanisms for managing the scaling problems of wide-area (BGP4) routing that need occasional or frequent site renumbering have been consistently dismissed as unacceptable 💀 But none of that means we can duck the problem, because, as explained below, renumbering is sometimes unavoidable 🫠 This doc sets out to explore the issues behind this problem statement, especially with a view to identifying the gaps and the known operational issues 🔥

It's worth noting that for a very large class of users, renumbering isn't really a problem at all 💅 A domestic or small office user whose device only works as a client or peer-to-peer node gets renumbered at every restart in practice (even if the address assigned is often the same). A user who roams around with a laptop or pocket device also gets renumbered a lot. These users aren't worried about keeping very long-term application sessions alive, so they're basically indifferent to renumbering 🙌 That's why this doc is mainly concerned with issues affecting medium to large sites 🎀

There are lots of reasons such sites might need to renumber in a planned way, including:

  • Change of service provider, or addition of a new service provider, when provider-independent addressing is not an option.
  • A service provider itself has to renumber.
  • Change of site topology (i.e., subnet reorganisation).
  • Merger of two site networks into one, or split of one network into two or more parts.
  • During IPv6 deployment, change of IPv6 access method (e.g., from tunneled to native).

The most demanding case would be unplanned automatic renumbering, presumably initiated by a site border router, for reasons connected with wide-area routing 😱 There's already some automatic renumbering for certain hosts, for example IPv6 "privacy" addresses [RFC4941] ✨

It's definitely expected that, as the pressure on IPv4 address space ramps up over the next few years, there will be many attempts to consolidate address usage to avoid wastage 🥹 That's part of the "end game" for IPv4, and it necessarily requires renumbering the sites involved. Strategically though, it matters more to implement and deploy techniques for IPv6 renumbering, so that once IPv6 is universally deployed, renumbering is seen as a relatively routine event 🌸 In particular, some mechanisms being considered to allow indefinite scaling of the wide-area routing system might assume that site renumbering is a straightforward matter 👀

There's also work in progress that, if it succeeds, would eliminate some of the motivations for renumbering 🧚 Specifically, some types of solutions to the problem of scalable routing for multihomed sites would likely eliminate both multihoming and switching to another ISP as reasons for site renumbering.

Several proposed identifier/locator split schemes are great examples, including at least Identifier Locator Network Protocol [ILNP], Locator/ID Separation Protocol [LISP], and Six/One [SIX-ONE] (in alphabetical order) 💜 The recent discussion about IPv6 Network Address Translation (IPv6 NAT) gives a separate example [NAT66]. It's highly contentious, but this approach, coupled with unique local addresses or a provider-independent address prefix, would appear to eliminate some reasons for renumbering in IPv6 🤞 Even if it succeeds, though, these solutions won't eliminate every reason for renumbering. This doc doesn't take any position on developing or deploying protocols or technologies that would make long-term renumbering unnecessary. Instead, it deals with the practical cases where partial or complete renumbering is necessary in today's Internet 🫶

IP addresses don't have a built-in lifetime, bestie 😤 Even when an address is leased for a finite time by DHCP or SLAAC, or when it's derived from a DNS record with a finite time to live (TTL) value, that info isn't available to applications once the address has been passed up to an upper layer through the socket interface. So a renumbering event is almost certain to be an unpredictable surprise from the point of view of any application using the address 😭 A lot of the issues listed below come from exactly this fact 💅

2.1. DHCP ✨

okay so DHCP [RFC2131] [RFC3315] is giving the same renumbering support for both versions of IP 💖 the vibe: a host asks for an address when it boots up 🌸. That request can land on a local DHCP server, or it can get relayed to a central server 🧚. If every local policy requirement is met, the server hands over an address with an associated lifetime, plus other network-layer parameters, like the subnet mask and the default router address 🎀.

The part that's actually interesting operationally is the local policy 👑. Some sites require pre-registration of MAC (Media Access Control) addresses as a security measure 🔥, while other sites let any MAC address get an IP address 🦋. Some sites use DHCP to give the same IP address to a given MAC address every time (this is sometimes called "Static DHCP") 💜, while other sites don't (this is sometimes called "Dynamic DHCP") 🍓. And then there are sites that mix both: some devices (like servers and Voice over IP (VoIP) handsets) get a relatively static IP address provisioned via DHCP, while other devices (like portable computers) get a different IP address every time they connect to the network 💅. For example, lots of universities in the United States and United Kingdom require MAC address registration for faculty, staff, and student devices (including handheld computers with wireless connections) 🎓✨

These policy choices are super tied up with whether a site has "strong" or "weak" asset management 😭. At the strong extreme, the site has a complete database of all equipment allowed to connect, definitely including the MAC address(es) for each host, plus other admin info of all kinds 🫶. That database can generate configuration files for DHCP, DNS, and any access control mechanisms in use 🌈. For example, only certain MAC addresses might be allowed to get an IP address on certain subnets 🙈. At the weak extreme, there's no asset management at all: any MAC address can get a first-come, first-served IP address on any subnet, and there's no network-layer access control 💀.

The IEEE 802.1X standard [IEEE.802-1X] [IEEE.802-1X-REV] defines a connection mechanism for wired/wireless Ethernet, and it's often combined with DHCP and other mechanisms to make a network login 🔐. With that login, a user connecting a new device must provide both identity and authentication before they get network access 🛡️. As part of this, the network control point will often configure the connection point for that specific user with a bunch of parameters, like Virtual LAN (VLAN), Access Control Lists (ACLs), and Quality-of-Service (QoS) profiles 🦋. Other network logins exist too, often using an initial web page for user identification and authentication, which is what hotels and cafes usually do ☕

In principle, a site using DHCP can renumber its hosts by reconfiguring DHCP for the new address range 🌸. The issues with this are discussed below 👀

2.2. IPv6 Stateless Address Autoconfiguration ✨

SLAAC, although it was updated recently [RFC4862], was designed before DHCPv6 and was meant for networks where unattended automatic configuration was preferred 🤖. Ignoring the case of an isolated network with no router (which will use link-local addresses forever), SLAAC follows a bootstrap process 🥾. Each host first gives itself a link-local address, then needs to receive a link-local multicast Router Advertisement (RA) [RFC4861] that tells it the routeable subnet prefix and the address(es) of the default router(s) 📡. A node can either wait for the next regular RA or ask for one by sending a link-local multicast Router Solicitation 🙋‍♀️. Once it knows the link prefix from the RA, the node can configure its own address 💖. There are a few methods for this, and the basic one is to build a unique 64-bit identifier from the interface's MAC address 🧩.

We're not going to go into the IPv6 processes for Duplicate Address Detection (DAD), Neighbour Discovery (ND), and Neighbour Unreachability Discovery (NUD) here 🙃. Suffice it to say they work, once the initial address assignment based on the RA has happened 💅.

The RA message is clearly critical to this process and to renumbering 👑. An RA can indicate more than one prefix, and more than one router can send RAs on the same link 🌈. For each prefix, the RA gives two lifetimes: "preferred" and "valid" ⏳. Addresses derived from a prefix must inherit its lifetimes 💜. When the valid lifetime expires, the prefix is dead and the derived address must not be used any more 💀. When the preferred lifetime expires (or is set to zero), the prefix is deprecated and must not be used for any new sessions 🚫. So setting a preferred lifetime that's zero or finite is SLAAC's warning that renumbering is coming 🚨. SLAAC assumes the new prefix will be advertised alongside the deprecated one, so new sessions use addresses configured under the new prefix 🦋

2.3. IPv6 ND Router/Prefix Advertisements ✨

With IPv6, a Router Advertisement doesn't just announce that an upstream router is available, it also announces routing prefix(es) valid on that link (subnetwork) 🌸. The IPv6 RA message also has a flag that says whether or not the host should use DHCPv6 to configure itself 🎀. If that flag says the host should use DHCPv6, then the host is not supposed to autoconfigure itself as outlined in Section 2.2 🙅‍♀️. There are some issues in this area, though, described in Section 5.1.1 😬

If a site has more than one upstream link to the outside world, it might have more than one valid routing prefix 🧚. In that case, all valid routing prefixes within a site will typically have the same prefix length 📏. It might also be nice for hosts that get their addresses using DHCPv6 to learn about upstream links dynamically, by working out from periodic IPv6 RA messages which routing prefixes are currently valid 🔍. This seems possible within the IPv6 Neighbour Discovery architecture, but it doesn't look like it's clearly specified anywhere 🥲. So right now, this approach for hosts to learn about new upstream links or the loss of old ones is unlikely to work with currently shipping hosts or routers 😭

2.4. PPP ✨

"The Point-to-Point Protocol (PPP)" [RFC1661] includes support for a Network Control Protocol (NCP) for both IPv4 and IPv6 💖

For IPv4, the NCP is IPCP [RFC1332], which allows explicit negotiation of an IP address for each end 🎀. PPP endpoints get both their own address and their peer's address during IPCP negotiation, and the peer's address may be assumed to be the default router if no routing protocol is running 🛣️. Renumbering events happen when IPCP negotiation restarts on an existing link, when the PPP connection is terminated and restarted, or when the point-to-point medium is reconnected 🔄. Peers may propose either the local or remote address, or require the other peer to do so 🤝. Negotiation is complete once both peers agree 💅. In practice, if no routing protocol is used (like in a subscriber/provider setup), the provider proposes both addresses and requires the subscriber either to accept the connection or abort 🙄. Basically, the subscriber device gets renumbered every time it connects for a new session 🫠

For IPv6, the NCP is IP6CP [RFC5072], which is used to configure an interface identifier for each end, after which link-local addresses can be created the normal way 🧩. In practice, each side can propose its own identifier, and renegotiation is only needed when there's a collision or when a provider wants to force a subscriber to use a specific interface identifier ⚡. Once link-local addresses are assigned and IP6CP is complete, global scope addresses are automatically assigned using the same methods as with multipoint links, i.e., either SLAAC or DHCPv6 🌍. Again, in a subscriber/provider environment, this allows renumbering per PPP session 🔁

2.5. DNS Configuration ✨

A site must provide DNS records for some or all of its hosts, and of course those DNS records must be updated when hosts get renumbered 📝. Most sites do this by maintaining a DNS zone file (or a database that can generate one) and loading that file into the site's DNS server(s) every time it's updated 💾. As a renumbering tool, this is clumsy but effective 🥴. Perfect synchronisation between renumbering the host and updating its A or AAAA record is clearly impossible 🙃. One alternative is Secure Dynamic DNS Update [RFC3007], where a host tells its own DNS server when it receives a new address 📣

There are widespread reports that the freely available BIND DNS software (which most UNIX hosts use), Microsoft Windows (XP and later), and Mac OS X all support Secure Dynamic DNS Update 🍎. So do many home gateways 🏠. There are also credible reports that these implementations are interoperable when configured properly ([DNSBOOK] p. 228 and p. 506) 🤝

Commonly used commercial DNS and DHCP servers (e.g., Windows Server) are often deployed with Secure Dynamic DNS Update enabled too 🏢. In some cases, just enabling both the DNS server and the DHCP server might turn on Secure Dynamic DNS Update as an automatic side effect ([DNSBOOK] p. 506) 😮. So sites might already have deployed Secure Dynamic DNS Update without realising it 🙈. An extra enhancement would be for DHCP clients to implement support for the "Client FQDN" option (Option 81) 💡

Since address changes are usually communicated to other sites via the DNS, the DNS's security is essential for secure renumbering 🔐. The Internet security community believes the current DNS Security (DNSsec) and Secure Dynamic DNS Update specifications are sufficiently secure, and has been encouraging DNSsec deployment ([RFC3007] [RFC4033] [RFC4034] [RFC4035]) 🛡️✨

As of this writing, there's way more momentum toward rapidly deploying DNS Security standards on the global public Internet than before 🚀. Several country-code Top-Level Domains (ccTLDs) have already deployed signed TLD root zones (e.g., Sweden's .SE) 🇸🇪. Several other TLDs are working to deploy signed TLD root zones by published near-term deadlines (e.g., .GOV, .MIL) 🏛️. In fact, it's reported that .GOV has been signed operationally since early February 2009 📅. It appears likely that the DNS-wide root zone will be signed in the very near future 🌐. See, for example, <http://www.dnssec-deployment.org/> and <http://www.ntia.doc.gov/DNS/DNSSEC.html> 💜

2.6. Dynamic Service Discovery 🧚

okay bestie, hosts hardcoding server addresses is such a mess 😭 but the Service Location Protocol (SLP) can lowkey fix that 🦋 it helps hosts find services without pre-configured addresses, which is huge for site renumbering, esp. for stuff like network printing 🖨️ check out [RFC2608], [RFC2610], [RFC3059], [RFC3224], [RFC3421], and [RFC3832] if you want the full tea ☕

ok and multicast DNS (mDNS) and DNS Service Discovery are already everywhere 💅 they're in BSD, Linux, Mac OS X, UNIX, and Windows systems, and people use them for link-local name resolution AND DNS-based dynamic service discovery [MDNS] [DNSSD]. mixing mDNS with DNS Service Discovery (like using SRV records [RFC3958]) is giving "fewer hardcoded addresses" energy ✨ and it can be a big deal for reducing dependency on configured addresses in lots of environments 🌈

3.1. Router Renumbering

okay so DHCP was originally made for hosts, but it can also do some router config stuff 🤓 the DHCPv6 Prefix Delegation options [RFC3633] are built for this. like, DHCPv6 can be used by an ISP to delegate or withdraw a prefix for a customer's router, and that can cascade through a whole site to get router renumbering done 🎀

there's also an ICMPv6 extension for router renumbering for IPv6, specified in [RFC2894] 👀 but honestly there seems to be little experience with it. [RFC4192] doesn't mention it as a useful mechanism either 😭

[RFC4191] extends IPv6 router advertisements so routers can convey default router preferences and more-specific routes to hosts 💜 it could be an extra tool for passing info around during renumbering, but it doesn't really look like it's used in practice 🙈

and [CPE] says a customer premises router MUST... wait, no caps here, sorry bestie. [CPE] says a customer premises router uses DHCPv6 to get an address prefix from its upstream ISP, and uses IPv6 RA messages to set up a default IPv6 route (when IPv6 is in use) 🫶

4. Existing Multi-Addressing Mechanism for IPv6 🦋

okay IPv6 was designed to handle multiple addresses per interface and multiple prefixes per subnet 💖 as [RFC4192] explains, that lets you do renumbering in phases, where you add the new prefix and addresses before removing the old ones. so cute, right? 🥹

and here's a bonus: a site could use Unique Local Addressing (ULA) [RFC4193] for all on-site communication, or at least for talking to on-site servers, while using globally routeable IPv6 addresses for everything off-site 🌍 you could even use ULAs for all on-site network management by giving them to every device. then those on-site activities are totally immune to renumbering of the prefix(es) used for off-site stuff 🛡️ ULAs can also be safely shared with peer sites you have a VPN connection with, and that's something you can't really do with ambiguous IPv4 addresses [RFC1918] 🔐 so those VPNs wouldn't be affected by renumbering either 💅

and the IPv6 model has "privacy" addresses built from pseudo-random interface identifiers, which hides the actual MAC addresses [RFC4941] 🕵️‍♀️ this means IPv6 stacks and client apps already need to be agile enough to handle frequent IP address changes (like in the privacy address), since in a privacy-sensitive environment the address lifetime will likely be pretty short ⏳ main character energy for sure 👑

5. Operational Issues with Renumbering Today 🔥

okay so for IPv6, [THINK] drafted a really useful description of the practical stuff, as a complement to [RFC4192] 📝 and the main requirement there is to minimise the disruption caused by renumbering 🫶 that happens on two levels: disruption to site operations in general, AND disruption to individual application sessions that are in progress at the moment of renumbering 😭 for IPv6, being able to overlap the old and new prefixes really helps with ongoing sessions, as [RFC4192] explains 💖 but that approach is basically off the table for IPv4, mostly because IPv4 doesn't have Stateless Address Autoconfiguration (SLAAC) 🙃

5.1.1. Network-Layer Issues

for IPv4, most client systems (PCs, workstations, and handheld computers) use DHCP to get their addresses and other network-layer parameters today 💻 DHCP gives leases lifetimes, and then the address lease expires 🎀 so it should be possible to come up with an operational procedure where lease expiry lines up with the moment of renumbering (within some margin of error) 🧚 the simplest version: the network admin just lowers all DHCP address lease lifetimes to something super short (like a few minutes) 🌸 they do that long enough before a site-wide change that every node picks up its new IP address within a few minutes of the renumbering event ⏰ in that case, the DHCP server itself does the client renumbering automatically 🤖 it's a bit of a traffic spike though, so it won't be instant 🙈 DHCPv6 could get a similar result 💜

the FORCERENEW extension is defined for DHCP for IPv4 [RFC3203] 👀 it's unicast-only, so a DHCP client must discard a multicast FORCERENEW 🚫 but the server could still use it to kick off renumbering by cycling through all its clients and sending a FORCERENEW to each one 🔁 DHCPv6 has something similar: a unicast RECONFIGURE message that can be sent to each host to tell it to check its DHCPv6 server for an update 🧚 honestly though, neither of these seems to be widely used for bulk renumbering 🤷‍♀️

procedures for a DHCP approach to site renumbering are gonna be super different depending on whether the site has strong or weak asset management 📋 with strong asset management and careful planning, the subnet addresses and masks get updated in the database, a script regenerates the DHCP MAC-to-IP address tables and the DNS zone file, and the DHCP and DNS timers get set temporarily to small values 💅 then the DHCP and DNS servers get fed the new files, and as soon as the old DHCP leases and DNS TTLs expire, everything follows automatically, as far as the host IP layer is concerned ✨ with weak asset management and a casual approach? the DHCP table gets reconfigured by hand, the DNS zone file gets edited by hand, and once those configs are installed there's a period of confusion until the old leases and TTLs expire 😵‍💫 DHCP FORCERENEW or RECONFIGURE messages could shorten that confusion somewhat 🫶

DHCP, esp. for IPv4, has picked up a LOT of extra capabilities, with approximately 170 options defined at the time of writing 📚 most don't carry IP address info, but some do (like options 68 through 76, which all carry various IP addresses) 👀 so renumbering mechanisms involving DHCP have to think about way more than the basic DHCP job of leasing an address to each host 💀

SLAAC is way less overloaded with options than DHCP 💖 its only extra capability is conveying a DNS server address 🌸 so using SLAAC to force all hosts on a site to renumber is less complex than DHCP, and the difference between strong and weak asset management is less obvious 🦋 the principle of syncing the SLAAC and DNS updates, and of reducing the SLAAC lease time and DNS TTL, doesn't change 🔁

okay now we need to talk about an ambiguity between DHCPv6 and SLAAC from the host's point of view that is still unresolved 😤 RA messages include a 'Managed Configuration' flag, known as the M bit, which is supposed to indicate that DHCPv6 is in use 🚩 but it's unspecified whether hosts must read this flag rigidly (so they may or must only start DHCPv6 if it's set, or if no RAs are received), or whether hosts are allowed or are recommended to start DHCPv6 by default 🤔 and it gets more complicated: DHCPv6 has a 'stateless' mode [RFC3736] where SLAAC gets the address, but DHCPv6 is used for other parameters 🧩 another RA flag, the 'Other configuration' or O bit, indicates this 🏷️

until the IETF clearly resolves this ambiguous behaviour, operational problems are to be expected 😩 different host operating systems have taken different approaches, which makes it hard for a site network manager to configure systems so all hosts boot in a consistent way 🙃 hosts will start SLAAC if appropriately configured RA messages direct them to 👍 but if one OS also starts a DHCPv6 client by default, and another only starts it when it gets the M bit, systematic address management gets impeded 🚧

also, on an isolated LAN, neither RA nor DHCPv6 responses will be received, so the host just stays with its self-assigned link-local address 🏝️ and picture a multihomed network that uses SLAAC for one address prefix and DHCPv6 for another: that would clearly create a risk of inconsistent host behaviour and operational confusion 😬

neither the SLAAC approach nor DHCP without pre-registered MAC addresses works reliably in all cases of systems that are assigned fixed IP addresses for practical reasons 📌 of course, even systems with static addressing can be configured to use DHCP to get their IP address(es), and this "Static DHCP" usually eases site renumbering when it does become necessary 🎀 but in other cases, manual or script-driven procedures are needed, which are likely to be site-specific and definitely prone to human error 🥲 if a site has even one host with a fixed, manually configured address, completely automatic host renumbering is very likely to be impossible 🚫

all of this assumes typical off-the-shelf hardware and software 🛒 there are other environments, often called embedded systems, where DHCP or SLAAC might not be used and even configuration scripts might not be an option 🤖 for example, fixed IP addresses might be stored in read-only memory, or even set up using Dual In-Line Package (DIP) switches 🕹️ these systems create special problems that no general-purpose solution is likely to address 💀✨

5.1.2. Transport-Layer Issues

Okay so TCP connections and UDP flows are rigidly bound to a given pair of IP addresses 🎀. Both addresses get baked into the checksum calculation, and there's no provision right now for the endpoint IP addresses to change 😭. So it's fundamentally impossible for the flows to survive a renumbering event at either end 💀.

From an ops point of view, that means a site planning to renumber is obliged either to follow the overlapped procedure described in [RFC4192] or to announce a site-wide outage for the renumbering process, during which all user sessions will fail 🙈. For IPv4, overlapping old and new addresses is unlikely to be an option, and in any case it's not commonly supported by software. So unless TCP and UDP get enhancements that allow dynamic endpoint address changes (for example, [HANDLEY]), interruptions to TCP and UDP sessions seem inevitable if renumbering happens at either session endpoint. The same vibe appears to apply to Datagram Congestion Control Protocol (DCCP) [RFC4340] 🌸.

In contrast, Stream Control Transmission Protocol (SCTP) already supports dynamic multihoming of session endpoints, so SCTP sessions ought not be adversely impacted by renumbering the SCTP session endpoints [RFC4960] [RFC5061] 🦋✨.

5.1.3. DNS Issues

The main issue is whether the site has a systematic procedure for updating its DNS configuration 🧚. If it does, updating the DNS for a renumbering event is basically a clerical issue that must be coordinated as part of a complete plan, including both forward and reverse mapping. As mentioned in [RFC4192], the DNS TTL will be manipulated to ensure that stale addresses are not cached. However, if the site uses a weak asset management model in which DNS updates are made manually on demand, there will be a substantial period of confusion and errors will be made 💀.

There are anecdotal reports that many small user sites don't even maintain their own DNS configuration, despite running their own web and email servers 🙈. They point to their ISP's resolver, request the ISP to install DNS entries for their servers, but operate internally mainly by IP address. Thus, renumbering for such sites will require administrative coordination between the site and its ISP(s), unless the DNS servers in use have Secure Dynamic DNS Update enabled. Some commercial DNS service firms include Secure Dynamic DNS Update as part of their DNS service offering 💅.

It should be noted that DNS entries commonly have matching Reverse DNS entries 🎀. When a site renumbers, these reverse entries will also need to be updated. Depending on a site's operational arrangements for DNS support, it might or might not be possible to combine forward and reverse DNS updates in a single procedure.

5.1.4. Application-Layer Issues

Ideally, we would carry out a renumbering analysis for each application protocol. To some extent, this has been done, in [RFC3795]. This found that 34 out of 257 Standards-Track or Experimental application-layer RFCs had explicit address dependencies. Although this study was made in the context of IPv4 to IPv6 transition, it is clear that all these protocols might be sensitive to renumbering. However, the situation is worse, in that there is no way to discover by analyzing specifications whether an actual implementation is sensitive to renumbering. Indeed, such analysis might be quite impossible in the case of proprietary applications 😭.

The sensitivity depends on whether the implementation stores IP addresses in such a way that it might refer back to them later, without allowing for the fact that they might no longer be valid. In general, we can assert that any implementation is at risk from renumbering if it does not check that an address is valid each time it opens a new communications session. This could be done, for example, by knowing and respecting the relevant DNS TTL, or by resolving relevant Fully-Qualified Domain Names (FQDNs) again. A common experience is that even when FQDNs are stored in configuration files, they are resolved only once, when the application starts, and they are cached indefinitely thereafter. This is insufficient 🙅. Of course, this does not apply to all application software; for example, several well-known web browsers have short default cache lifetimes.

There are even more egregious breaches of this principle 💀, for example, software license systems that depend on the licensed host computer having a particular IP address. Other examples are the use of literal IP addresses in URLs, HTTP cookies, or application proxy configurations. (Also see Appendix A.)

In contrast, there are also many application suites that actively deal with connectivity failures by retrying with alternative addresses or by repeating DNS lookups. This places a considerable burden of complexity on application developers 🫶.

It should be noted that applications are in effect encouraged to be aware of and to store IP addresses by the very nature of the socket API calls gethostbyname() and getaddrinfo(). It is highly unfortunate that many applications use APIs that require the application to see and use lower-layer objects, such as network-layer addresses. However, the BSD Sockets API was designed and deployed before the Domain Name System (DNS) was created, so there were few good options at the time. This issue is made worse by the fact that these functions do not return an address lifetime, so that applications have no way to know when an address is no longer valid. The extension of the same model to cover IPv6 has complicated this problem somewhat. An application using the socket API is obliged to contain explicit logic if it wishes to benefit from the availability of multiple addresses for a given remote host.

If a programming model were adopted in which only FQDNs were exposed to applications, and addresses were cached with appropriate lifetimes within the API, most of these problems would disappear 🌈. It should be noted that at least the first part of this is already available for some programming environments. A common example is Java, where only FQDNs need to be handled by application code in normal circumstances, and no additional application logic is needed to deal with multiple addresses, which are handled by the run-time system. This is highly beneficial for programmers who are not networking experts, and insulates application software from many aspects of renumbering. It would be helpful to have similarly abstract, DNS-oriented, Networking APIs openly specified and widely available for C and C++.

Some web browsers intentionally violate the DNS TTL with a technique called "DNS Pinning." DNS Pinning limits acceptance of server IP address changes, due to a JavaScript issue where repeated address changes can be used to induce a browser to scan the inside of a firewalled network and report the results to an outside attacker. Pinning can persist as long as the browser is running, in extreme cases perhaps months at a time. Thus, we can see that security considerations may directly damage the ability of applications to deal with renumbering 💀🔥.

Server applications might need to be restarted when the host they contain is renumbered, to ensure that they are listening on a port and socket bound to the new address. In an IPv6 multi-addressed host, server applications need to be able to listen on more than one address simultaneously, in order to cover an overlap during renumbering. Not all server applications are written to do this, and a name-based API as just mentioned would have to provide for this case invisibly to the server code.

As noted in Section 2.6, the Service Location Protocol (SLP), and multicast DNS with SRV records for service discovery, have been available for some years. For example, many printers deployed in recent years automatically advertise themselves to potential clients via SLP. Many modern client operating systems automatically participate in SLP without requiring users to enable it. These tools appear not to be widely known, although they can be used to reduce the number of places that IP addresses need to be configured 🦋.

[RFC2072] gives a detailed review of the operational realities in 1997. A number of the issues discussed in that document were the result of the relatively recent adoption of classless addressing; those issues can be assumed to have vanished by now. Also, DHCP was a relative newcomer at that time, and can now be assumed to be generally available. Above all, the document underlines that systematic planning and administrative preparation are needed, and that all forms of configuration file and script must be reviewed and updated. Clearly this includes filtering and routing rules (e.g., when peering with BGP, but also with intradomain routing as well). Two particular issues mentioned in [RFC2072] are:

  • Some routers cache IP addresses in some situations. So routers might need to be restarted as a result of site renumbering.
  • Addresses might be used by configured tunnels, including VPN tunnels, although at least the Internet Key Exchange (IKE) supports the use of Fully-Qualified Domain Names instead.

On the latter point, the capability to use FQDNs as endpoint names in IPsec VPNs is not new and is standard (see [RFC2407], Section 4.6.2.3 and [RFC4306], Section 3.5). This capability is present in most IPsec VPN implementations. There does seem to be an "educational" or "awareness" issue that many system/network administrators do not realise that it is there and works well as a way to avoid manual modification during renumbering. (Of course, even in this case, a VPN may need to be reconnected after a renumbering event, but most products appear to handle this automatically.)

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

5.3. Other Issues

5.3.1. NAT State Issues 🦋

Okay so when a renumbering event happens, any entries in a Network Address Translator's state table that hold the affected addresses are gonna become invalid and eventually time out 💀. But TCP and UDP sessions probably aren't surviving renumbering anyway, so the hosts involved won't get extra hurt by it 🙈. Multihomed SCTP [SCTPNAT] is the messier situation, and it depends on whether a single NAT or multiple NATs are involved. It's giving complicated 😭

A NAT can get renumbered too, and it might need a config change during a renumbering event 🌸. One of the authors has a NAT-enabled home gateway that gets its exterior address from the residential ISP by acting as a DHCP client, and honestly that main character setup has never had operational problems when the ISP uses DHCP to renumber the gateway's exterior IP address ✨. A big part of why it works is that IKE on the home gateway is set to use a "mailbox name" for the user's identity type (instead of the gateway's exterior IP address) when creating or managing the IP Security Associations 🔐. Iconic 👑.

5.3.2. Mobility Issues 🧚

A mobile node using Mobile IP that isn't in its home network right now will be negatively affected if either its current care-of address or its home address gets renumbered. For IPv6, if the care-of address changes, it's exactly like moving from one foreign network to another, and Mobile IP re-binds with its home agent the normal way 💜. If its home address changes unexpectedly, it can be told the new global routing prefix used at the home site through the Mobile Prefix Solicitation and Mobile Prefix Advertisement ICMPv6 messages [RFC3775] 📨. It gets trickier if the mobile node is detached when the renumbering happens, because it won't know a valid subnet anycast address for its home agent anymore, so it's left to deduce a valid address from DNS information 😵‍💫.

Mobile IPv4 is different. It doesn't support prefix solicitation and prefix advertisement messages, so its renumbering only works for well-scheduled events when the mobile node is connected to its home agent and managed by the home network administration 📅. Unexpected home network renumbering while the node is away and not connected to the home agent is only supported if a relevant Authentication, Authorisation, and Accounting (AAA) system can dynamically allocate a home address and home agent for the mobile node 🫶.

5.3.3. Multicast Issues 📡

As discussed in [THINK], IPv6 multicast can actually help renumbering instead of hurting it, like using multicast as a discovery protocol (as in IPv6 Neighbour Discovery) 🙌. Plot twist though: the embedding of IPv6 unicast addresses into multicast addresses specified in [RFC3306], and the embedded-RP (Rendezvous Point) in [RFC3956], will cause issues when renumbering 😬.

For both IPv4 and IPv6, changing the unicast source address of a multicast sender might also be an issue for receivers, especially for Source-Specific Multicast (SSM). Applications need to learn the new source addresses and new multicast trees need to be built

For IPv4 or IPv6 with Any-Source Multicast (ASM), renumbering can be easy 💖. If sources get renumbered, from the routing perspective it's like there are new sources within the same multicast group. There may be application issues though. Changing the RP address is easy when using Bootstrap Router (BSR) [RFC5059] for dynamic RP discovery. BSR is widely used, but it's also common to use static config of RP addresses on routers, and in that case router configurations must be updated too 🛠️.

If any multicast ACLs are configured, they raise the same issue as the unicast ACLs mentioned elsewhere 🚧.

5.3.4. Management Issues 📋

Today, static IP addresses are routinely embedded in numerous configuration files and network management databases, including MIB modules 😩. Ideally all of these would be generated from a single central asset management database for a given site, but that's far from universal practice. It should be noted that for IPv6, where multiple routing prefixes per interface and multiple addresses per interface are standard practice, the database and the configuration files will need to allow for this (rather than for a single address per host, as is normal practice for IPv4) 🌈.

Furthermore, because of routing policies and VPNs, a site or network might well embed addresses from other sites or networks in its own configuration data. (It's preferable to embed FQDNs instead, obvi, whenever possible 💅.) So renumbering causes a ripple effect of updates for a site and for its neighbours. To the extent these updates are manual, they'll be costly and prone to error. Synchronising updates between independent sites can cause unpredictable delays ⏳. Note that Section 4 suggests IPv6 ULAs can mitigate this problem, but of course only for VPNs and routes that are suitable for ULAs rather than globally routeable addresses 🙃. The majority of external addresses to be configured will not be ULAs.

See Appendix A for an extended list of possible static or embedded addresses 📖.

Some address configuration data is relatively easy to find (for example, site firewall rules, ACLs in site border routers, and DNS). Others might be widely dispersed and way harder to find (for example, configurations for building routers, printer addresses configured by individual users, and personal firewall configurations) 🕵️. Some of these will inevitably be found only after the renumbering event, when the users concerned run into a problem 💀.

The overlapped model for IPv6 renumbering, with old and new addresses valid simultaneously, means planned database and configuration file updates will proceed in two stages -- add the new information some time before the renumbering event, and remove the old information some time after 🔁. All policy rules must be configured to behave correctly during this process (e.g., preferring the new address as soon as possible) ✅. Similarly, monitoring tools must be set up to monitor both old and new during the overlap 👀.

However, the notion of simultaneously operating multiple prefixes for the same network, although natural for IPv6, is generally not supported by operational tools such as address management software. It also increases the size of IGP routing tables in proportion to the number of prefixes in use 📈. For these reasons, and due to its unfamiliarity to operational staff, the use of multiple prefixes remains rare. Accordingly, the use of ULAs to provide stable on-site addresses even if the off-site prefix changes is also rare 🥲.

If both IPv4 and IPv6 are renumbered simultaneously in a dual-stack network, additional complications could result, especially with configured IP-in-IP tunnels. This scenario should probably be avoided 🚫.

Using FQDNs rather than raw IP addresses wherever possible in configuration files and databases will reduce/mitigate the potential issues arising from such files or databases when renumbering is required or otherwise occurs. This is advocated in [RFC1958] (point 4.1). Just as we noted in Section 5.1.4 for applications, this is insufficient in itself; some devices, such as routers, are known to resolve FQDNs only once, at start-up, and to continue using the resulting addresses indefinitely. This may require routers to be rebooted, when they should instead be resolving the FQDN again after a given timeout 🔄.

By definition, there is at least one place (i.e., the DNS zone file or the database from which it is derived) where address information is nevertheless inevitable 🤷‍♀️.

It is also possible that some operators may choose to configure addresses rather than names, precisely to avoid a possible circular dependency and the resulting failure modes. This is arguably even advocated in [RFC1958] (point 3.11) 🧠.

It should be noted that the management and administration issues (i.e., tracking down, recording, and updating all instances where addresses are stored rather than looked up dynamically) form the dominant concern of managers considering the renumbering problem. This has led many sites to continue the pre-CIDR (Classless Inter-Domain Routing) approach of using a provider-independent (PI) prefix. Some sites, including very large corporate networks, combine PI addressing with NAT. Others have adopted private addressing and NAT as a matter of choice rather than obligation. This range of techniques allows for addressing plans that are independent of the ISP(s) in use, and allows a straightforward approach to multihoming. The direct cost of renumbering is perceived to exceed the indirect costs of these alternatives. Additionally, there is a risk element stemming from the complex dependencies of renumbering: it is hard to be fully certain that the renumbering will not cause unforeseen service disruptions, leading to unknown additional costs 😰.

A relevant example in a corporate context is VPN configuration data held in every employee laptop, for use while on travel and connecting securely from remote locations. Typically, such VPNs are statically configured using numeric IP addresses for endpoints and even with prefix lists for host routing tables. Use of VPN configurations with FQDNs to name fixed endpoints, such as corporate VPN gateways, and with non-address identity types would enable existing IP Security with IKE to avoid address renumbering issues and work well for highly mobile users 🧳. This is all possible today with standard IPsec and standard IKE. It just requires VPN software to be configured with names instead of addresses, and thoughtful network administration 💼.

It should be noted that site and network operations managers are often very conservative, and reluctant to change operational procedures that are working reasonably well and are perceived as reasonably secure. They quite logically argue that any change brings with it an intrinsic risk of perturbation and insecurity 😤. Thus, even if procedural changes are recommended that will ultimately reduce the risks and difficulties of renumbering (such as using FQDNs protected by DNSsec where addresses are used today), these changes might be resisted 🥺✨.

5.3.5. Security Issues 🔐

okay so for IPv6, addresses are supposed to be protected from forgery during neighbour discovery by SEcure Neighbour Discovery (SEND) [RFC3971]. ngl this is giving very important energy during dynamic renumbering, because it stops an attacker from hijacking the whole process 🚨. Any automatic renumbering scheme is exposed to that kind of hijacking at the exact moment a new address gets announced. The catch is that it's still unclear whether or when SEND will be widely implemented or widely deployed 😭.

Firewall rules will definitely need updating, and so will any other place where addresses or address prefixes are baked into security components (access control lists, AAA systems, intrusion detection systems, etc.) 🧱. If that doesn't get done in advance, legitimate access to resources might get blocked after the renumbering event 💀. And if the old rules aren't removed promptly, illegitimate access might become possible after the event 👀. So the security updates need to happen in two stages, right before and right after the event. Two stages, bestie, no shortcuts 💅.

There will be operational and security issues if an X.509v3 Public Key Infrastructure (PKI) Certificate has a subjectAltName extension that contains an iPAddress [RFC5280], and the node then undergoes an IP address change without a concurrent update to its PKI Certificate 🎀. For these reasons, use of the dNSName rather than the iPAddress is recommended for the subjectAltName extension. Any other use of IP addresses in cryptographic material is likely to be similarly troublesome 🙈.

If a site is, for some reason, listed by IP address in a white list (such as a spam white list), that entry will need updating 📝. Plot twist though: a site that's listed in a black list can escape that list just by renumbering itself 😈🦋.

Using IP addresses instead of FQDNs in configurations is sometimes driven by a perceived security need. Name resolution has historically lacked authentication, so admins prefer raw IP addresses for security-sensitive applications (firewalls and VPNs are two typical examples) 🔒. It might be possible to solve this in the next few years with DNSsec (see Section 2.5), now that there is strong DNS Security deployment momentum ✨. The glow-up is coming 🌈.

6. Proposed Mechanisms 🧚

6.1. SHIM6

SHIM6 was proposed as a host-based multihoming mechanism for IPv6, and it has the iconic property of dynamically switching the addresses used for forwarding the actual packet stream while presenting a constant address as the upper-layer identifier for the transport layer [RFC5533] 🦋. At least in principle, this property could be used during renumbering to ease the problem described in Section 5.1.2 💖.

SHIM6 is an example of a whole class of solutions with this or a similar property. Others include Host Identity Protocol (HIP), IKEv2 Mobility and Multihoming (MOBIKE), Mobile IPv6, SCTP, and proposals for multi-path TCP 🫶.

6.2. MANET Proposals

The IETF working groups dealing with mobile ad hoc networks have been cooking up a bunch of mechanisms so mobile routers can discover available border routers dynamically, and so those mobile routers can tell the hosts connected to them about that information 🛰️.

Recently, some MANET work has shown up on a "Border Router Discovery Protocol (BRDP)" that might be useful towards a more dynamic mechanism for site interior router renumbering [BRDP] 🔥.

Right now, the IETF AUTOCONF WG (http://www.ietf.org/html.charters/autoconf-charter.html) is working on address autoconfiguration mechanisms for MANET networks that also seem useful for ordinary non-mobile non-MANET networks [AUTOC]. This work is extensively surveyed in [AUTOC2] and [AUTOC3]. Other work in the same area, e.g., [RFC5558], might also be relevant 📚.

MANETs are, of course, unusual in that they have to be able to reconfigure themselves at all times and without notice 🏃‍♀️. So the type of hidden static configurations discussed above in Section 5.3.4 is simply intolerable in MANETs 🙅‍♀️. Because of that, it's possible that when a consensus is reached on autoconfiguration for MANETs, the selected solution(s) might not suit the more general renumbering problem. Still, it's certainly worthwhile to explore applying MANET techniques to conventional networks too ✨.

6.3. Other IETF Work

A DHCPv6 extension has been proposed that could convey alternative routes, in addition to the default router address, to IPv6 hosts [DHRTOPT] 🗺️. Other DHCP options are also on the table that may offer information about address prefixes and routing to DHCP or DHCPv6 clients, such as [DHSUBNET] and [DHMIFRT]. It's conceivable that these could be extended as a way of informing hosts dynamically about prefix changes 💅.

In the area of management tools, the Network Configuration (NETCONF) Protocol [RFC4741] is suitable for configuring any network element or server, so it could in principle be used to support secure remote address renumbering 🔧.

The DNSOP WG has considered a Name Server Control Protocol (NSCP) based on NETCONF. It provides means for consistent DNS management, including potential host renumbering events [DNSCONT] 🧠.

6.4. Other Proposals

A proposal has been made to include an address lifetime as an embedded field in IPv6 addresses. The idea is that all prefixes would automatically expire after a certain period and become unrouteable [CROCKER] ⏳. Okay, this is provocative, I'll admit it 😳. But it would force the issue by making renumbering compulsory, and honestly that's kind of iconic 👑.

7. Gaps 🕳️

This section tries to identify the technology gaps between what's available from existing open specifications and what appears to be needed for site renumbering to be tolerable 🌸.

It would be beneficial to expose address lifetimes in the socket API, or in any low-level networking API. That would let applications avoid using stale addresses 🫧.

The various current discussions of a name-based transport layer or a name-based network API also have the potential to ease the application-layer issues noted in this document 💜. Application development would be enhanced by a more abstract network API that supports the C and C++ programming languages. For example, it could use FQDNs and Service Names, rather than SockAddr, IP Address, protocol, and port number. This would be equivalent to similar interfaces that already exist for Java programmers ☕.

Moving to a FQDN-based transport layer might enhance the ability to migrate the IP addresses of endpoints for TCP/UDP without interrupting a session, or at least in a way that lets a session restart gracefully 🦋.

Having a single registry per host for all address-based configuration (/etc/hosts, anyone?) with secure access for site network management might be helpful 🙋‍♀️. Ideally, this would be remotely configurable, for example by leveraging the IETF's current work on networked-device configuration protocols (NetConf). There are proprietary versions of this approach, sometimes based on Lightweight Directory Access Protocol (LDAP), but a fully standardised approach seems desirable 🌈.

Do we really need more than DHCP or SLAAC for regular hosts? Do we need an IPv4 equivalent of SLAAC? How can the use of DHCP FORCERENEW and DHCPv6 RECONFIGURE for bulk renumbering be deployed? FORCERENEW in particular requires DHCP authentication [RFC3118] to be deployed 🤔.

The IETF should resolve the 'IPv6 ND M/O flag debate' once and for all, with the default, mandatory and optional behaviours of hosts being fully specified 💀.

The host behaviour for upstream link learning suggested in Section 2.3 should be documented 📝.

It would be helpful to have multi-path, survivable extensions for both UDP and TCP (or to institutionalise some aspects of SHIM6) 🫶.

We need a non-proprietary, secure mechanism that lets all address-based configuration be driven by a central repository for site configuration data. NETCONF might be a good starting point 🗂️.

We also need a MANET solution that's solid enough to apply to fully operational small to medium fixed sites for voluntary or involuntary renumbering 🏢.

And a MANET-style solution that can be applied convincingly to large or very large sites for voluntary renumbering would be amazing 🏙️.

A useful short-term measure would be to ensure that [RFC2894] and [RFC3633] can be used in practice ⚡.

7.3. Operational Gaps

Since address changes are usually communicated via the DNS, the DNS's security is essential for secure renumbering. So we should keep pushing existing efforts to deploy DNSsec globally, which means not just signing the DNS root, DNS TLDs, and subsidiary DNS zones, but also widely deploying the already available DNSsec-capable DNS resolvers 🔐.

Similarly, we should document and encourage widespread deployment of Secure Dynamic DNS Update, both in DNS servers and in client and server operating systems. This capability is already widely implemented and widely available, but it isn't widely deployed yet 😤.

Deploy multi-prefix usage of IPv6, including Unique Local Addresses (ULAs) to provide stable internal addresses 🏠. In particular, address management tools need to support the multi-prefix model and ULAs 🛠️.

Make sure network monitoring systems will keep functioning during renumbering, in particular to confirm that renumbering has completed successfully or that some traffic is still using the old prefixes 👀.

Document and encourage systematic site databases and secure configuration protocols for network elements and servers (e.g., NETCONF). The database should store all the information about the network, and scripts and tools should derive all configurations from the database 🗃️. An example of this approach to simplifying renumbering is given at [LEROY] 💫.

Document functional requirements for site renumbering tools or toolkits 📋.

Document operational procedures useful for site renumbering 🧾.

In general, document renumbering instructions as part of every product manual 📖.

I strongly recommend that all IPv6 deployment plans, for all sizes of site or network, include provision for future renumbering. Renumbering should be planned from day one, when the first lines of the configuration of a network or network service are written. Every IPv6 operator should expect to have to renumber the network one day and should plan for that event 🗓️✨.

7.4. Other Gaps

We need to define a secure mechanism for announcing changes of site prefix to other sites (for example, those that configure routers or VPNs to point to the site in question) 📣.

For Mobile IP, we need a better mechanism to handle a change of home agent address while the mobile is disconnected 📡💜.

8. Security Considerations 🔐✨

Okay bestie, this section is SERIOUS 😭 Known current issues are discussed in Section 5.3.5. Security issues related to SLAAC are discussed in [RFC3756], and DHCP authentication is defined in [RFC3118].

For future mechanisms that help simplify renumbering, care must be taken to make sure that prefix or address changes are adequately authenticated at all points. This matters most for changes coming from another site or through public sources like the DNS. If we skip this, misuse of renumbering mechanisms becomes an attractive target for anyone who wants to divert traffic or cause major disruption 💀 As noted in Section 5.1.4, this may lead to defensive techniques such as "DNS pinning", which make renumbering harder 🙈

Whatever authentication method(s) get adopted, key distribution will be a big deal too 🔑 Most likely, public key cryptography will be needed to authenticate renumbering announcements passing from one site to another, since you can't assume a preexisting trust relationship between those sites. Not a vibe we can skip 💅

9. Acknowledgements 🫶

Big thank-yous! A lot of the text was adapted from [THINK], which reflects work done during the 6NET project, funded by the Information Society Technologies Programme of the European Commission 🌸 The authors of that document agreed to have their text submitted under the IETF's current copyright provisions, which is so generous 🥹 Helpful material about work following on from 6NET was also provided by Olivier Festor of INRIA ✨

Useful comments and contributions were made (in alphabetical order) by Jari Arkko, Fred Baker, Olivier Bonaventure, Teco Boot, Stephane Bortzmeyer, Dale Carder, Gert Doering, Ralph Droms, Pasi Eronen, Vijay Gurbani, William Herrin, Cullen Jennings, Eliot Lear, Darrel Lewis, Masataka Ohta, Dan Romascanu, Dave Thaler, Iljitsch van Beijnum, Stig Venaas, Nathan Ward, James Woodyatt, and others 💖 The whole squad is iconic 👑

10. Informative References 📚🎀

These are the extra reads, the receipts for everything above. Here they are, all of them:

  • [AUTOC] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc Network Architecture", Work in Progress, November 2007.
  • [AUTOC2] Bernardos, C., Calderon, M., and H. Moustafa, "Survey of IP address autoconfiguration mechanisms for MANETs", Work in Progress, November 2008.
  • [AUTOC3] Bernardos, C., Calderon, M., and H. Moustafa, "Ad-Hoc IP Autoconfiguration Solution Space Analysis", Work in Progress, November 2008.
  • [BRDP] Boot, T. and A. Holtzer, "Border Router Discovery Protocol (BRDP) based Address Autoconfiguration", Work in Progress, July 2009.
  • [CPE] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, Ed., "Basic Requirements for IPv6 Customer Edge Routers", Work in Progress, May 2010.
  • [CROCKER] Crocker, S., "Renumbering Considered Normal", 2006, <http://www.arin.net/meetings/minutes/ARIN_XVIII/PDF/wednesday/Renumbering_Crocker.pdf>.
  • [DHMIFRT] Sun, T. and H. Deng, "Route Configuration by DHCPv6 Option for Hosts with Multiple Interfaces", Work in Progress, March 2009.
  • [DHRTOPT] Dec, W. and R. Johnson, "DHCPv6 Route Option", Work in Progress, March 2010.
  • [DHSUBNET] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "Subnet Allocation Option", Work in Progress, May 2010.
  • [DNSBOOK] Albitz, P. and C. Liu, "DNS and BIND", 5th Edition, O'Reilly, 2006.
  • [DNSCONT] Dickinson, J., Morris, S., and R. Arends, "Design for a Nameserver Control Protocol", Work in Protocol, October 2008.
  • [DNSSD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, March 2010.
  • [HANDLEY] Handley, M., Wischik, D., and M. Bagnulo, "Multipath Transport, Resource Pooling, and implications for Routing", 2008, <http://www.ietf.org/proceedings/08jul/slides/RRG-2.pdf>.
  • [IEEE.802-1X] Institute of Electrical and Electronics Engineers, "Port-Based Network Access Control: IEEE Standard for Local and Metropolitan Area Networks 802.1X-2004", December 2009.
  • [IEEE.802-1X-REV] Institute of Electrical and Electronics Engineers, "802.1X-REV - Revision of 802.1X-2004 - Port Based Network Access Control: IEEE Standard for Local and Metropolitan Area Networks", 2009.
  • [ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, February 2010.
  • [LEROY] Leroy, D. and O. Bonaventure, "Preparing network configurations for IPv6 renumbering", International Journal of Network Management, 2009, <http://inl.info.ucl.ac.be/system/files/dleroy-nem-2009.pdf>.
  • [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, April 2010.
  • [MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, March 2010.
  • [NAT66] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address Translation (NAT66)", Work in Progress, March 2009.
  • [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
  • [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
  • [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
  • [RFC1916] Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser, "Enterprise Renumbering: Experience and Information Solicitation", RFC 1916, February 1996.
  • [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
  • [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
  • [RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
  • [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
  • [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
  • [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
  • [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
  • [RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999.
  • [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.
  • [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
  • [RFC3059] Guttman, E., "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001.
  • [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
  • [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001.
  • [RFC3224] Guttman, E., "Vendor Extensions for Service Location Protocol, Version 2", RFC 3224, January 2002.
  • [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
  • [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
  • [RFC3421] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Select and Sort Extensions for the Service Location Protocol (SLP)", RFC 3421, November 2002.
  • [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
  • [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
  • [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
  • [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
  • [RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents", RFC 3795, June 2004.
  • [RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV", RFC 3832, July 2004.
  • [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
  • [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
  • [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
  • [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
  • [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
  • [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
  • [RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
  • [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
  • [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
  • [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
  • [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
  • [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
  • [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.

[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. ✨
  • [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. 🎀
  • [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. 🦋
  • [RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008. 🌸
  • [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007. 💅
  • [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. 🍓
  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. 🔥
  • [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. 👑
  • [RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010. 🌈
  • [SCTPNAT] Xie, Q., Stewart, R., Holdrege, M., and M. Tuexen, "SCTP NAT Traversal Considerations", Work in Progress, November 2007. 🙈
  • [SIX-ONE] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009. ⭐
  • [THINK] Chown, T., "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006. 🫶

Appendix A. Embedded IP Addresses 🧚

okay so this appendix is basically a treasure map of all the places IP addresses like to hide 🙈 it was adapted from [THINK], and if you're renumbering, these are the spots you need to go check. bestie, don't get caught with an old address lurking in your config 💀

  • Provider based prefix(es)
  • Names resolved to IP addresses in firewall at startup time
  • IP addresses in remote firewalls allowing access to remote services
  • IP-based authentication in remote systems allowing access to online bibliographic resources
  • IP address of both tunnel end points for IPv6 in IPv4 tunnel
  • Hard-coded IP subnet configuration information
  • IP addresses for static route targets
  • Blocked SMTP server IP list (spam sources)
  • Web .htaccess and remote access controls
  • Apache .Listen. directive on given IP address
  • Configured multicast rendezvous point
  • TCP wrapper files
  • Samba configuration files
  • DNS resolv.conf on Unix
  • Any network traffic monitoring tool
  • NIS/ypbind via the hosts file
  • Some interface configurations
  • Unix portmap security masks
  • NIS security masks
  • PIM-SM Rendezvous Point address on multicast routers

Authors' Addresses 🫶

these are the lovely people who wrote this doc, so here are their details 🌸

Brian Carpenter 💖

Department of Computer Science
University of Auckland
PB 92019
Auckland  1142
New Zealand

EMail: brian.e.carpenter@gmail.com

Randall Atkinson ✨

Extreme Networks
PO Box 14129
Suite 100, 3306 East NC Highway 54
Research Triangle Park, NC  27709
USA

EMail: rja@extremenetworks.com

Hannu Flinck 🦋

Nokia Siemens Networks
Linnoitustie 6
Espoo  02600
Finland

EMail: hannu.flinck@nsn.com
📦 where this page comes from