RFC 4192

Procedures for Renumbering an IPv6 Network without a Flag Day

📅 published September 2005, from ietf

RFC 4192: Procedures for Renumbering an IPv6 Network without a Flag Day 🎀

Okay bestie, this one is a how-to for renumbering an IPv6 network, which means moving everything from one prefix to another without taking the network down 🦋

  • Series: Network Working Group
  • Authors: F. Baker (Cisco Systems), E. Lear (Cisco Systems GmbH), R. Droms (Cisco Systems)
  • Category: Informational
  • Date: September 2005
  • Updates: RFC 2072 💅
  • It doesn't list any RFCs it obsoletes. It only updates RFC 2072.

Status of This Memo ✨

This memo gives information to the Internet community. It is not an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2005).

Abstract 🌸

This doc describes a procedure for renumbering a network from one prefix to another. It uses IPv6's built-in ability to give a network interface several addresses at once, which gives you a "make-before-break" transition so service keeps running the whole time. It also deals with the naming and configuration-management side of things. On top of that, it uses other IPv6 features to cut down on the effort and time needed to finish the switch from the old prefix to the new one.

Table of Contents 🧚

1. Introduction ....................................................2
   1.1. Summary of the Renumbering Procedure .......................3
   1.2. Terminology ................................................4
   1.3. Summary of What Must Be Changed ............................4
   1.4. Multihoming Issues .........................................5
2. Detailed Review of Procedure ....................................5
   2.1. Initial Condition: Stable Using the Old Prefix .............6
   2.2. Preparation for the Renumbering Process ....................6
        2.2.1. Domain Name Service .................................7
        2.2.2. Mechanisms for Address Assignment to Interfaces .....7
   2.3. Configuring Network Elements for the New Prefix ............8
   2.4. Adding New Host Addresses ..................................9
   2.5. Stable Use of Either Prefix ...............................10
   2.6. Transition from Use of the Old Prefix to the New Prefix ...10
        2.6.1. Transition of DNS Service to the New Prefix ........10
        2.6.2. Transition to Use of New Addresses .................10
   2.7. Removing the Old Prefix ...................................11
   2.8. Final Condition: Stable Using the New Prefix ..............11
3. How to Avoid Shooting Yourself in the Foot .....................12
   3.1. Applications Affected by Renumbering ......................12
   3.2. Renumbering Switch and Router Interfaces ..................12
   3.3. Ingress Filtering .........................................13
   3.4. Link Flaps in BGP Routing .................................13
4. Call to Action for the IETF ....................................14
   4.1. Dynamic Updates to DNS Across Administrative Domains ......14
   4.2. Management of the Reverse Zone ............................14
5. Security Considerations ........................................14
6. Acknowledgements ...............................................16
7. References .....................................................17
   7.1. Normative References ......................................17
   7.2. Informative References ....................................17
Appendix A.  Managing Latency in the DNS ..........................20

1. Introduction ✨

The Prussian military theorist Carl von Clausewitz [Clausewitz] wrote, "Everything is very simple in war, but the simplest thing is difficult. These difficulties accumulate and produce a friction, which no man can imagine exactly who has not seen war.... So in war, through the influence of an 'infinity of petty circumstances' which cannot properly be described on paper, things disappoint us and we fall short of the mark". Running a network is honestly so similar to fighting a war 💀 The difference is that your opponent expects homo ignoramus to act intelligently. Iconic, right? 😭

A "flag day" is a procedure where the network, or part of it, gets changed during a planned outage, or suddenly, which causes an outage while the network tries to recover. To avoid outages, you have to modify the network with what mobility people call a "make before break" procedure. The network starts using a new prefix while the old one is still running, operation switches over to the new prefix, and then the old one gets taken down 🦋

This document covers the main procedural issues in renumbering an IPv6 [RFC2460] network without a "flag day". The procedure is pretty straightforward to describe, but it can be hard to automate or carry out in practice because of statically configured network state. That is what "an infinity of petty circumstances" refers to, lol 🙈 Because of that, the procedure is necessarily incomplete in some areas, since network environments vary a lot and no single solution fits everyone. The document points out a few of the many areas where there are multiple approaches. This document updates [RFC2072]. It also includes recommendations for application design and network management which, if you take them seriously, may avoid or minimize the impact of these issues 🫶

1.1. Summary of the Renumbering Procedure 🌈

When we say "renumbering a network", we mean replacing an existing (or "old") prefix everywhere in a network with a new prefix. Usually, both prefixes are the same length. The procedures here mostly still apply if the two prefixes are different lengths. During renumbering, the sub-prefixes (or "link prefixes") carved out of the old prefix and assigned to links all over the network get replaced by link prefixes from the new prefix. Interfaces on systems throughout the network get configured with IPv6 addresses from the new prefix's link prefixes. Any old-prefix addresses in services like DNS [RFC1034][RFC1035], or configured into switches, routers, and applications, get replaced with the matching addresses from the new prefix.

The renumbering procedure in this document can be applied to part of a network as well as to an organization's whole network. For a big organization, it can help to treat the network as a bunch of smaller networks. Renumbering each smaller network on its own makes the whole thing more manageable 💖 The process in this document is generally applicable to any network, whether it's an entire organization network or just part of a bigger one.

1.2. Terminology 📚

  • DDNS: Dynamic DNS [RFC2136][RFC3007] updates can be secured with SIG(0) [RFC4033][RFC4034][RFC4035][RFC2931] and TSIG [RFC2845].
  • DHCP prefix delegation: An extension to DHCP [RFC3315] that automates assigning a prefix, for example from an ISP to a customer [RFC3633].
  • flag day: A transition that involves a planned service outage.
  • ingress/egress filters: Filters applied to a router interface that connects to an external organization, such as an ISP, to exclude traffic with inappropriate IPv6 addresses.
  • link prefix: A prefix, usually a /64 [RFC3177], assigned to a link.
  • SLAC: StateLess Address AutoConfiguration [RFC2462].

1.3. Summary of What Must Be Changed 🍓

Addresses from the old prefix that get affected by renumbering show up all over the place in the components of the renumbered network. The list below covers some of the spots that may contain prefixes or addresses affected by renumbering, plus some tips on how to cut down the work during renumbering:

  • Link prefixes assigned to links. Every link in the network must be assigned a link prefix from the new prefix.
  • IPv6 addresses assigned to interfaces on switches and routers. These are typically assigned manually as part of configuring switches and routers.
  • Routing information propagated by switches and routers.
  • Link prefixes advertised by switches and routers [RFC2461].
  • Ingress/egress filters.
  • ACLs and other embedded addresses on switches and routers.
  • IPv6 addresses assigned to interfaces on hosts. Using StateLess Address Autoconfiguration (SLAC) [RFC2462] or DHCP [RFC3315] can reduce the impact of renumbering host interfaces.
  • DNS entries. New AAAA and PTR records get added and old ones removed in several phases to reflect the prefix change. Caching times get adjusted along the way.
  • IPv6 addresses and other configuration information provided by DHCP.
  • IPv6 addresses embedded in configuration files, applications, and elsewhere. Finding everything that needs updating and automating the process can take a lot of effort. Section 3 goes into more detail on this. This process must be tailored to the needs of each network 🎀

1.4. Multihoming Issues 🦋

Besides the considerations already covered, the operational side of multihoming may also need to be addressed. Networks usually get renumbered for one of three reasons. First, the network itself is changing its addressing policy and has to renumber to carry out the new policy, for example when a company gets acquired and switches to addresses used by its new owner. Second, an upstream provider changes its prefixes and its customers are forced to do the same at the same time. Third, a company changes providers and must use the addresses assigned by the new provider. The third case is the most common 👑

When a company changes providers, it's common to set up an overlap period where it's served by both providers. By definition, the company is multihomed during that period. This document isn't really about multihoming per se, but problems can pop up because of ingress filtering policies applied by the upstream provider, or by one of its upstream providers. So anyone using this document also needs to be aware of these issues. [RFC2827] and [RFC3704] discuss this in detail and describe ways to deal with it 💅

2. Detailed Review of Procedure ✨

okay so bestie, renumbering moves the network through eight states 🦋 At the start, the network is only using the prefix that's getting replaced, and at the end it's only using the new one 💅 To avoid a flag day transition (aka everything breaking at the same time, no thoughts, head empty 💀), the new prefix gets deployed first. Then there's an in-between moment where EITHER prefix works. Hosts move over to the new prefix one at a time, as appropriate, so their apps don't get disrupted 🫶 Once every single host has made the switch, the network gets reconfigured so the old prefix isn't used anywhere anymore. Periodt 👑

We're assuming a whole prefix is being swapped for another whole prefix. Sometimes only part of a prefix changes, or a few prefixes get merged into one joined prefix. In those cases the basic principles still apply, but you'll need to tweak things for your exact situation 🌸 This procedure is more like a skeleton for a detailed plan tailored to a specific environment. Put simply, season to taste 🍓

2.1. Initial Condition: Stable Using the Old Prefix

Starting out, the network is using an old prefix for routing, device interface addresses, filtering, firewalls, and other systems. It's a stable setup, so no drama yet ✨

2.2. Preparation for the Renumbering Process

Step one is getting the new prefix and new reverse zone from the delegating authority 🎀 These delegations happen through established procedures, whether the delegating authority is internal or external.

Before any devices get reconfigured because of the renumbering, every link in the network must be assigned a sub-prefix from the new prefix 🧚 The link prefix assignment doesn't actually show up in the config of any specific switch, router, or host, but the network administrator doing the renumbering has to make these assignments before starting. That's what guides the configuration of switches and routers, the assignment of addresses to interfaces, and the changes to network services like DNS and DHCP.

Before renumbering, various processes will need to be reconfigured to confirm bindings between names and addresses more often. Normally, DNS name translations and DHCP bindings get relatively long lifetimes to keep server load low 😴 To speed up the move from old to new prefix, it may be necessary to reduce the time to live (TTL) on DNS records and increase how often DHCP clients contact the DHCP server. Meanwhile, a procedure has to be worked out for updating other configuration parameters during the transition period, when both prefixes are available 💜

2.2.1. Domain Name Service

During renumbering, the DNS database has to be updated to add information about addresses assigned to interfaces from the new prefix, and to remove addresses assigned to interfaces from the old prefix 📝 The DNS changes have to be coordinated with the changes to the interface addresses, no going rogue 🙅‍♀️

Changes to DNS info have to propagate from the server where the change was made out to the resolvers that use the information. How fast that happens is controlled by the TTL for DNS records and how often primary servers update secondary servers 🦋

So the latency in propagating DNS changes can be managed through the TTL on individual DNS records and through the timing of updates from primary to secondary servers. Appendix A has an analysis of the factors controlling propagation delays in the DNS 🤓

The suggestions for reducing the delay in moving to new IPv6 addresses apply when the DNS service can get prior notice about a renumbering event. BUT the DNS service for a host might be run by a different administrative domain than the network the host is attached to 😭 For example, a device from organization A roams onto a network belonging to organization B, but the device's DNS A record is still managed by organization A. In that case, the DNS service won't get advance notice of the renumbering event in organization B. Not fair, but that's life 💀

One strategy for updating DNS is to let each system manage its own DNS information through Dynamic DNS (DDNS) [RFC2136][RFC3007]. Authentication of these DDNS updates is strongly recommended, and it can be done through TSIG and SIG(0) 🔐 Both TSIG and SIG(0) need keys configured and distributed to hosts and name servers in advance of the renumbering event, so plan ahead, bestie 🫶

2.2.2. Mechanisms for Address Assignment to Interfaces

IPv6 addresses may be assigned through SLAC, DHCP, and manual processes 🌈 If DHCP is used for IPv6 address assignment, there may be some delay in getting addresses from the new prefix. That's because hosts using DHCP only check in with the server periodically to extend the lifetimes on their assigned addresses 😩 There are two ways to cut that delay down:

  • Before the renumbering event, the T1 parameter (which controls the time at which a host using DHCP contacts the server) may be reduced.
  • The DHCP Reconfigure message may also be sent from the server to the hosts, to trigger them to contact the server immediately ⚡

2.3. Configuring Network Elements for the New Prefix

In this step, switches, routers, and services get prepped for the new prefix, but the new prefix is NOT used for any datagram forwarding yet 🛑 (no cap, the new prefix just chills in the background.) Throughout this step, the new prefix gets added to the network infrastructure in parallel with the old prefix, without interfering with it. For example, addresses from the new prefix get configured in addition to any old-prefix addresses on the switch and router interfaces. Routing changes for the new prefix get added alongside the old prefix, so forwarding for both prefixes runs side by side 🎀 At the end of this step, the network is still running on the old prefix, but it's ready to start using the new one ✨

The new prefix gets added to the routing infrastructure, firewall filters, ingress/egress filters, and other forwarding and filtering functions 🧱 Routes for the new link prefixes may be injected by routing protocols into the routing subsystem. But router advertisements should not cause hosts to perform SLAC on the new link prefixes. In particular, the "autonomous address-configuration" flag [RFC2461] should not be set in the advertisements for the new link prefixes 🙈 The reason hosts shouldn't be forming addresses at this point is that routing to the new addresses may not be stable yet.

The details of this step depend on the specific architecture of the network being renumbered, and on the capabilities of the components that make up the network infrastructure 🧠 The effort needed to finish this step may be eased by using DNS, DHCP prefix delegation [RFC3633], and other automated configuration tools 🤖

While the new prefix is being added, it won't be working everywhere in the network yet. Unless it's properly protected by some means, such as ingress and egress access lists, the network may be attacked through the new prefix in those places where it is operational. Lock it down early, bestie, this is not a drill 🚨

Once the new prefix has been added to the network infrastructure, access-lists, route-maps, and other network configuration options that use IP addresses should be checked. The goal is to make sure hosts and services using the new prefix will behave the way they did with the old one 🔍 Name services other than DNS, and other services that provide information affected by renumbering, must be updated in a way that avoids responding with stale information. There are a few useful approaches to find and update these configurations:

  • Develop a mapping from each network and address derived from the old prefix to each network and address derived from the new prefix. Tools such as the UNIX sed or perl utilities are useful for then finding and augmenting access-lists, route-maps, and the like 🛠️
  • A similar approach involves using mechanisms such as DHCP prefix delegation to abstract networks and addresses 🧩

Switches and routers, or manually configured hosts, that have IPv6 addresses assigned from the new prefix may be used at this point to test the network infrastructure 🧪

Advertising the prefix outside its network is the LAST thing to configure in this phase 🏁 You want all of your defenses in place before advertising the prefix, if only because the prefix may come under immediate attack. Main character energy means protecting yourself first 👑

At the end of this phase, routing, access control, and other network services should work interchangeably for both the old and new prefixes 💖

2.4. Adding New Host Addresses

Once the network infrastructure for the new prefix is in place and tested, IPv6 addresses from the new prefix may be assigned to host interfaces. The addresses from the old prefix stay on those interfaces too 🫧 The new IPv6 addresses may be assigned through SLAC, DHCP, and manual processes. If SLAC is used in the network, the switches and routers are configured to indicate that hosts should use SLAC to assign IPv6 addresses from the new prefix. If DHCP is used for IPv6 address assignment, the DHCP service is configured to assign addresses from both prefixes to hosts. The addresses from the new prefix will NOT be used until they're inserted into the DNS 🚫

Once the new IPv6 addresses are assigned to host interfaces, both the forward and reverse maps within DNS should be updated for the new addresses, either through automated or manual means 🗺️ Some clients may be able to update their forward maps through DDNS. But automating updates to the reverse zone may be more difficult, as discussed in Section 4.2 🥺

2.5. Stable Use of Either Prefix

Once the network has been configured with the new prefix and has had enough time to stabilize, it becomes a stable platform 🌷 Every infrastructure component interface has two addresses configured on it (apart from interfaces that only use the link-local address). Any host can use two non-link-local addresses, one in the old prefix and one in the new. This is a stable configuration 💜

2.6. Transition from Use of the Old Prefix to the New Prefix

When the new prefix has been fully integrated into the network infrastructure and tested for stable operation, hosts, switches, and routers can begin using it 🚀 Once the transition has completed, the old prefix will not be in use anywhere in the network. Bye bye, old prefix 👋

2.6.1. Transition of DNS Service to the New Prefix

The DNS service gets configured to use the new prefix by removing any IPv6 addresses from the old prefix from the DNS server configuration 🎯 External references to the DNS servers, such as in the DNS service that this DNS domain was delegated from, get updated to use the IPv6 addresses from the new prefix 🌸

2.6.2. Transition to Use of New Addresses 🦋

Okay so once both prefixes are usable on the network, each host can hop over from the old prefix to the new one at a time that makes sense for its own apps 💅. If the host transitions are randomized, DNS dynamic update mechanisms can scale way better when all those DNS changes come in 📈✨.

As services start showing up at addresses from the new prefix, the references to the hosts behind them get updated to use the new prefix 🌸. Addresses pulled from DNS update automatically whenever the DNS names get resolved 🫶. Addresses can also come through DHCP, and those update as hosts check in with DHCP servers 🎀. Addresses that are configured some other way must be updated appropriately 🔧.

It may be necessary to give users tools or other explicit procedures to finish the switch from the old prefix to the new one 🧰. Some applications and OS functions are set up in ways that don't use DNS at all, or they won't use DNS to resolve a domain name to a new address once the new prefix is available 🙈. For example, a device that only uses DNS to resolve the name of an NTP server when it boots won't grab the new prefix's address for that server at this point in the renumbering process 🕰️.

This last point is worth saying again, just in a slightly different form 📣. Applications can cache addressing info in different ways, for different amounts of time. They might keep it in memory, on a file system, or in a database 🗂️. Only after careful observation and consideration of your environment should you conclude that a prefix is no longer in use 👀. For more on this, see [DNSOP].

The transition of critical services like DNS, DHCP, NTP [RFC1305], and important business services should be managed and tested carefully to avoid outages 🚨. Each host should take reasonable precautions before switching to the new prefix so there's a smaller chance of broken connections 🛡️. For example, tools like netstat and network analyzers can help you check whether any existing connections to the host are still using the host's old-prefix address 🔍.

Link prefixes from the old prefix in router advertisements, and addresses from the old prefix handed out through DHCP, should have their preferred lifetimes set to zero at this point 🙅‍♀️. That way hosts won't use the old prefixes for new communications 💀.

2.7. Removing the Old Prefix

Once all sessions are deemed to have completed, nothing depends on the old prefix anymore 🥳. It can be removed from the configuration of the routing system, and from any static configs that depend on it 🧹. If any configuration was created based on DNS information, that configuration should be refreshed after the old prefixes have been removed from the DNS 🔄.

During this phase, the old prefix may be reclaimed by the provider or Regional Internet Registry that granted it, and addresses within that prefix get removed from the DNS 👋.

Also, DNS reverse maps for the old prefix may be removed from the primary name server, and the zone delegation may be removed from the parent zone 🗺️. Any DNS, DHCP, or SLAC timers that were changed should be reset to their original values, most notably the DNS forward map TTL ⏲️✨.

2.8. Final Condition: Stable Using the New Prefix

This is equivalent to the first state, but using the new prefix 🎉👑.

3. How to Avoid Shooting Yourself in the Foot 🔫🦶

The difficult operational issues in Section 2.3, Section 2.6, and Section 2.7 are all about dealing with the configurations of routers and hosts that aren't under the network administrator's control, or that are configured manually 😤. Examples include Voice over IP (VoIP) telephones with static configuration of boot or name servers, dedicated manufacturing devices configured with the IP addresses for specific services, the boot servers of routers and switches, and so on 📞🏭.

3.1. Applications Affected by Renumbering

Applications may accidentally ignore the DNS caching semantics tied to IP addresses obtained through DNS resolution 😬. The result is that a long-lived application may keep using a stale IP address after the TTL for that address has expired, even if DNS gets updated with new addresses during a renumbering event 😱.

For example, lots of existing applications use standard POSIX functions like getaddrinfo(), which don't preserve DNS caching semantics 🙃. If the application caches the response, or for whatever reason actually records it on disk, the application has no way to know when the TTL for that response has expired 🫠. Any application that needs repeated use of an IP address should either not cache the result, or use an appropriate function that also conveys the TTL of the record, such as getrrsetbyname() 🧠.

Application designers, equipment vendors, and the Open Source community should take note 📝. There's a real chance to serve their customers well here, and network operators should either develop or purchase appropriate tools 🛠️💖.

3.2. Renumbering Switch and Router Interfaces

The configuration and operation of switches and routers are often designed around static configuration with IP addresses, or around resolving domain names only once and then using the resulting IP addresses until the element is restarted 🥱. These static setups make renumbering way harder, since all of the static info has to be administered and configured by hand during a renumbering event 😩.

Because switches and routers are usually single-purpose devices, the user interface and operating functions (software and hardware) tend to be better integrated than independent services running on a server platform 🧩. So switch vendors and router vendors can likely design and implement consistent support for renumbering across all of their functions 🌈.

To better support renumbering, switches and routers should use domain names for configuration wherever appropriate, and they should resolve those names using DNS when the lifetime on the name expires ⏰🦋.

3.3. Ingress Filtering

An important consideration in Section 2.3, when the network being renumbered is connected to an external provider, is the ingress filtering policy of the network and of its provider 🚧. Both the network firewall's ingress filter and the provider's ingress filter on the access link to the network should be configured to prevent attacks that use source address spoofing 🕵️‍♀️. Ingress filtering is covered in detail in "Ingress Filtering for Multihomed Networks" [RFC3704] 📚.

Okay, this one is kind of subtle 🙈. It shows up during step 2 in BGP routing when you renumber the address(es) used to name the BGP routers 🧐. Two practices are common. One is to identify a BGP router by a stable address, like a loopback address. The other is to use the interface address facing the BGP peer 🔌. In each case, when a new prefix gets added, a certain ambiguity sneaks in: the systems have to choose between the addresses, and depending on how they choose, different things can happen 🎲.

  • If the existing address stays in use until it's removed, this is minimized to a routing flap on that event 🦋.
  • If both systems decide to use the address in the new prefix at the same time, the link flap may happen earlier in the process. If this is being done automatically (such as via the router renumbering protocol), it may cause route flaps throughout the network 😵‍💫.
  • If the two systems choose differently (one uses the old address and one uses the new address), a stable routing outage occurs 💔.

This isn't addressed by proposals like [IDR-RESTART], since it changes the "name" of the system. That makes it not a flap in an existing relationship, but (from BGP's perspective) the replacement of one routing neighbor with another 🔄. Ideally, you'd bring up the new BGP connection for the new address while the old one stays stable and in use, and only then take down the old one 🧘‍♀️. That way, even though there's a TCP connection flap, routing stays stable 🌸✨.

4. Call to Action for the IETF 📣💜

The more automated the renumbering process can be, the better for everyone 🤖. Sadly, several mechanisms either haven't been automated, or haven't been automated consistently across platforms 😭.

4.1. Dynamic Updates to DNS Across Administrative Domains

The configuration files for a DNS server (such as named.conf) contain addresses that must be reconfigured manually during a renumbering event 📄. There's currently no easy way to automate updating these addresses, because the updates need both complex trust relationships and automation to verify them 🔐. For instance, a reverse zone is delegated by an upstream ISP, but there's currently no mechanism to note additional delegations 🙃.

4.2. Management of the Reverse Zone

In networks where hosts obtain IPv6 addresses through SLAC, updating the reverse zone is problematic 🥴. The reason is the lack of a trust relationship between the administrative domain that owns the prefix and the host assigning the low 64 bits using SLAC 🧱.

For example, suppose a host, H, from organization A is connected to a network owned by organization B 🖥️. When H obtains a new address during a renumbering event through SLAC, H will need to update its reverse entry in the DNS through a DNS server from B that owns the reverse zone for the new address 📝. For H to update its reverse entry, the DNS server from B must accept a DDNS request from H, which requires that an inter-administrative domain trust relationship exist between H and B 🤝. The IETF should develop a BCP recommendation for addressing this problem 🙏💖.

5. Security Considerations 🔐

Okay bestie, renumbering is super straightforward in theory 🙈 but in practice it can get messy and dangerous fr fr. The threats fall into two big buckets: stuff that goes wrong because of misconfiguration, and stuff that's an actual attack 💀.

Misconfigs happen when some system in the network "knows" the old prefix (or an address inside it) ahead of time, but isn't set up with the new prefix. They also happen when the new prefix gets configured in a way that replaces the old one instead of sitting co-equal with it for a while. Some simple examples:

Neglecting to reconfigure a system that's still using the old prefix in some static configuration. When the old prefix is removed, whatever feature was configured that way just stops working 😭. It isn't set up for the new prefix, and the old one doesn't matter anymore.

Configuring a system through an IPv6 address, then swapping that address out for a new one. The TCP connection is still using the old, now-invalid IPv6 address, so your SSH session gets killed and you have to reconnect through the new address for any more config changes 💅.

Removing the old configuration before you've supplied the new one. Now you might need on-site support, or you have to travel to the system and get in through its console 🥲.

Honestly, taking the extra time to add the new prefix to the configuration, letting the network settle, and only then removing the old one totally avoids this whole class of problem ✨. There's a special case for devices that are only used now and then: the administration has to leave enough time in Section 2.6, or use some other verification procedures, so that the chance of detecting them is high enough 🧚.

Here's a sneaky one 👀. DNS can be used to fill in access control lists and other security or QoS configs. In this procedure, DNS names that map system or service names to addresses are treated as giving the address in the preferred prefix, which is either the old prefix or the new prefix but never both 🫶. These DNS names are a way (as described in Section 2.6) to make systems stop using the old prefix to reach servers or peers and start using the new one. But DNS names used for access control lists have to go through the same three-step procedure as every other access control list: the new prefix gets added (see Section 2.3), and the old prefix gets removed (see Section 2.7) 🎀.

Also, using DNS names like this isn't universally accepted as the answer 🤷‍♀️. [RFC3871] specifically points out cases where static IP addresses are preferred over DNS names, so you avoid a name lookup when the naming system is unreachable, or when the lookup might return one of several interfaces or systems. In those cases, you have to be extra careful to manage renumbering properly 🌸.

Attacks are also possible, not just mistakes 😱. Say the new prefix was handed out by a service provider, and the provider starts advertising it before the customer network is ready. That new prefix could get targeted in a distributed denial of service attack. Or a system could get broken into through an application that would not have crossed the firewall using the old prefix, all before the network's defenses are set up 💀. So obviously you want to configure the defenses first, and only then turn on accessibility and routing, as described in Section 2.3 and Section 3.3 🔥.

The SLAC procedure described in [RFC2462] is what renumbers hosts 💻. Dynamic DNS gives you a way to update DNS to match. Managing configuration items outside of those procedures is way more straightforward if every configuration comes from one central configuration repository or database. Another option is to read them all into a temporary database, change them with appropriate scripts, and then apply them to the right systems ✨. Anywhere scripted configuration management isn't possible or isn't being used has to be tracked and managed by hand. Here, there be dragons 🐉.

Now for ingress filtering on a multihomed network 🌈. An easy fix for the issues raised in Section 3.3 might be to say ingress filtering shouldn't be done for multihomed customers, or that it should be special-cased. But that hurts Internet security. A sufficient level of ingress filtering is needed to stop attacks that use spoofed source addresses 🛡️. There's also the problem that if ingress filtering gets too hard to do (for example, if every ISP has to special-case it), it might not get done at an ISP at all 😬. So any mechanism that depends on relaxing ingress filtering checks needs to be handled with extreme care 💅.

6. Acknowledgements 🫶

This document grew out of a discussion on the IETF list 💬. Commentary on it came from Bill Fenner, Christian Huitema, Craig Huegen, Dan Wing, Fred Templin, Hans Kruse, Harald Tveit Alvestrand, Iljitsch van Beijnum, Jeff Wells, John Schnizlein, Laurent Nicolas, Michael Thomas, Michel Py, Ole Troan, Pekka Savola, Peter Elford, Roland Dobbins, Scott Bradner, Sean Convery, and Tony Hain 🌟.

Some people took it upon themselves to convince the authors that renumbering the network as a normal or frequent procedure is daft 😭. If their comments end up improving address management practices in networks, that might be the best contribution this note has to offer 💜.

Christian Huitema, Pekka Savola, and Iljitsch van Beijnum described the ingress filtering issues 🔍. Those made their way separately into [RFC3704], which anyone who's going to temporarily or permanently create a multihomed network by renumbering from one provider to another should read and understand 📚.

Also, the 6NET consortium, especially Alan Ford, Bernard Tuy, Christian Schild, Graham Holmes, Gunter Van de Velde, Mark Thompson, Nick Lamb, Stig Venaas, Tim Chown, and Tina Strauf, took it upon themselves to test the procedure 🧪. Some of the outcomes from that testing are documented here because they seemed immediately significant to the procedure. 6NET will also be documenting its own "lessons learned" 🍓.

7. References 📚

7.1. Normative References

[RFC1034]     Mockapetris, P., "Domain names - concepts and
              facilities", STD 13, RFC 1034, November 1987.

[RFC1035]     Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

[RFC2072]     Berkowitz, H., "Router Renumbering Guide", RFC 2072,
              January 1997.

[RFC2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
              6 (IPv6) Specification", RFC 2460, December 1998.

[RFC2461]     Narten, T., Nordmark, E., and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

[RFC2462]     Thomson, S. and T. Narten, "IPv6 Stateless Address
              Autoconfiguration", RFC 2462, December 1998.

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

[RFC3704]     Baker, F. and P. Savola, "Ingress Filtering for
              Multihomed Networks", BCP 84, RFC 3704, March 2004.

7.2. Informative References

[Clausewitz]  von Clausewitz, C., Howard, M., Paret, P. and D.
              Brodie, "On War, Chapter VII, 'Friction in War'", June
              1989.

[DNSOP]       Durand, A., Ihren, J. and P. Savola, "Operational
              Considerations and Issues with IPv6 DNS", Work in
              Progress, October 2004.

[IDR-RESTART] Sangli, S., Rekhter, Y., Fernando, R., Scudder, J. and
              E.  Chen, "Graceful Restart Mechanism for BGP", Work in
              Progress, June 2004.

[RFC1305]     Mills, D., "Network Time Protocol (Version 3)
              Specification, Implementation and Analysis", RFC 1305,
              March 1992.

[RFC1995]     Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              August 1996.

[RFC1996]     Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, August 1996.

[RFC2136]     Vixie, P., Thomson,  S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS
              UPDATE)", RFC 2136, April 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.

[RFC2845]     Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for
              DNS (TSIG)", RFC 2845, May 2000.

[RFC2931]     Eastlake 3rd, D., "DNS Request and Transaction
              Signatures ( SIG(0)s )", RFC 2931, September 2000.

[RFC3007]     Wellington, B., "Secure Domain Name System (DNS)
              Dynamic Update", RFC 3007, November 2000.

[RFC3177]     IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
              Allocations to Sites", RFC 3177, September 2001.

[RFC3633]     Troan, O. and R. Droms, "IPv6 Prefix Options for
              Dynamic Host Configuration Protocol (DHCP) version 6",
              RFC 3633, December 2003.

[RFC3871]     Jones, G., "Operational Security Requirements for Large
              Internet Service Provider (ISP) IP Network
              Infrastructure", RFC 3871, September 2004.

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

Appendix A. Managing Latency in the DNS ✨

okay so this appendix is basically a recipe for changing a DNS record without chaos 🍓 it shows how to manage the latency when you update info in a DNS resource record (RR) 💅

there are some delays we're just going to ignore in the math 🙈:

  • the time the admins take to actually make the changes
  • the time you might spend waiting for the DNS update, if the secondaries only get updated on a schedule and not right away
  • the time it takes to push the update out to all the secondaries

the setup assumes NOTIFY [RFC1996] and IXFR [RFC1995] are used to move updated info from the primary DNS server to any secondary servers 🦋 this is a super quick process, so the actual update time doesn't really count as significant.

so there's a target time, TC, when we want the contents of a DNS RR to change 🎯 right now the RR has TTL == TTLOLD, which means any cached copies will expire no more than TTLOLD in the future. no cap, that's the whole timing puzzle 🧩

at time TC - (TTLOLD + TTLNEW), the RR on the primary gets configured with TTLNEW (where TTLNEW < TTLOLD) 💜 the update gets kicked off to push the RR to the secondaries. once that's done, queries for the RR come back with TTLNEW. the old cached copies with TTLOLD are still hanging around, and that's fine 🫶

at time TC - TTLNEW, the RR on the primary is configured with the new address ✨ the update is kicked off again to push it out. after that, queries for the RR return the new address, and all the cached references have TTLNEW. between now and TC, queries might get either the old address or the new one. this ambiguity is acceptable, as long as the host is configured to respond to both addresses 💖

at time TC, every cached reference with the old address has expired, and all future queries return the new address 👑 after TC (which lines up with the final state described in Section 2.8), the TTL on the RR can be set back to the initial value TTLOLD 🌈

the network administrator can pick TTLOLD and TTLNEW to fit local requirements, so you're in charge of the numbers 💅

here's a concrete example, because I love an example 🎀 say TTLOLD is a week (168 hours) and TTLNEW is an hour. the prep for the address change starts 169 hours before the change. after 168 hours have gone by and only one hour is left, TTLNEW has propagated everywhere, so you can change the address record(s) 🧚 those changes propagate within that hour, and then you can bump the TTL back up to a bigger value. this approach keeps the window of uncertainty about what address info the DNS returns as small as possible 🔥

Authors' Addresses

Here's where to find the authors, bestie 🫶

Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA  93117
US

Phone: 408-526-4257
Fax:   413-473-2403
EMail: fred@cisco.com


Eliot Lear
Cisco Systems GmbH
Glatt-com 2nd Floor
CH-8301 Glattzentrum
Switzerland

Phone: +41 1 878 9200
EMail: lear@cisco.com


Ralph Droms
Cisco Systems
200 Beaver Brook Road
Boxborough, MA  01719
US

Phone: +1 978 936-1674
EMail: rdroms@cisco.com

Copyright (C) The Internet Society (2005). 💖

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 🎀

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭

Intellectual Property

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available 🧐 it also doesn't say it has made any independent effort to identify any such rights. info on how rights work for RFC documents lives in BCP 78 and BCP 79 📚

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission to use these proprietary rights (for implementers or users of this spec) can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔗

the IETF invites any interested party to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology required to implement this standard 💅 send that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸

📦 where this page comes from