RFC 6866

Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks

📅 published February 2013, from ietf

RFC 6866 🎀 Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks

okay bestie, this is the title block, and it's giving very organized 💅

  • Series: Internet Engineering Task Force (IETF) 🌸
  • Request for Comments: 6866
  • Category: Informational 📚 (published for information, not as an Internet Standards Track spec)
  • ISSN: 2070-1721
  • Authors: B. Carpenter (Univ. of Auckland) and S. Jiang (Huawei Technologies Co., Ltd.) 🫶
  • Date: February 2013
  • Obsoletes / Updates: the title block doesn't list any RFCs it obsoletes or updates 🦋

Abstract ✨

this doc is all about the problems you run into when you need to update the IPv6 addresses of hosts in enterprise networks, but those hosts need static addresses for operational reasons. so yeah, the renumbering drama is real 😭

Status of This Memo 📝

this doc is not an Internet Standards Track specification. it's published for informational purposes 🌷

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for that 🧐

for the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6866 💌

Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read these carefully, bestie, because they spell out your rights and restrictions for this doc. 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 without warranty as described in the Simplified BSD License 📜

Table of Contents 🗺️

1. Introduction ....................................................2
2. Analysis ........................................................3
   2.1. Static Addresses Imply Static Prefixes .....................3
   2.2. Other Hosts Need Literal Address ...........................4
   2.3. Static Server Addresses ....................................5
   2.4. Static Virtual Machine Addresses ...........................6
   2.5. Asset Management and Security Tracing ......................6
   2.6. Primitive Software Licensing ...............................7
   2.7. Network Elements ...........................................7
   2.8. Access Control Lists .......................................7
   2.9. Management Aspects .........................................8
3. Summary of Problem Statement ....................................8
4. Security Considerations .........................................9
5. Acknowledgements ...............................................10
6. Informative References .........................................10

1. Introduction 🌸

okay so renumbering enterprise networks comes up a LOT, and one thing that keeps popping up is statically assigned addresses. see [RFC5887] [RFC6879] [GAP-ANALYSIS] 🦋 this doc's whole job is to analyse the problems static addresses cause for enterprise networks during renumbering, and to find the gaps in existing tech that relate to them. some of it also applies to small office and home networks, but those aren't the main focus here 🏠

so what even is a static address? it's an IP address the network manager intends to stay constant for a long time, possibly many years, no matter system restarts or any other unpredictable stuff ⏳ static addressing usually means manual address assignment, which can include manually writing configuration scripts 🫠 and if hosts have static addresses, then subnets have to have static prefixes too. that needs its own analysis, bestie 🎀

it's kind of a history thing. as Section 3.2 of [RFC6250] explains, a bunch of properties of IP addresses that programmers and operators have long assumed just aren't true anymore 🕰️ they were true back when almost every address was assigned by hand. in some cases, static addressing dodges the operational headaches that come from those old assumptions 🙈

static addressing is generally a pain for renumbering, but hosts inside an enterprise may still have static addresses for a bunch of operational reasons:

  • For some reason, other hosts need to be configured with a literal numeric address for the host in question, so its address must be static.
  • Even if a site has local DNS support and this is normally used to locate servers, some operators wish their servers to have static addresses so that issues of address lifetime and DNS Time to Live (TTL) cannot affect connectivity.
  • Some approaches to virtual server farms require static addressing.
  • On some sites, the network operations staff require hosts to have static addresses for asset management purposes and for address-based backtracking of security incidents.
  • Certain software licensing mechanisms are based on IP addresses.
  • Network elements, such as routers, are usually assigned static addresses, which are also configured into network monitoring and management systems.
  • Access Control Lists and other security mechanisms are often configured using IP addresses.

static addressing and manual addressing are not the same thing, bestie 🫶 static addresses can be configured automatically, for example by stateful DHCPv6. in that case, the database the static address comes from might have been built automatically in some way, or set up manually. and if a host's administrator configures the address by hand, it's static by definition 🧚

this doc digs into all of this and presents a problem statement. wherever there are obvious alternatives to static addresses, we mention them 💖

2. Analysis 🔍

2.1. Static Addresses Imply Static Prefixes 🌈

host addresses can only be static if the subnet prefixes are static too, so this is kinda the foundation of everything 🧱 static prefixes have been such a long-established practice in enterprise networks that it's honestly hard to figure out why anymore 🤷‍♀️ originally, before DHCP existed, there just wasn't any alternative. so it became normal to assign subnet prefixes manually and build them into static router configurations 🖥️

and here's the funny part: the static nature of subnet prefixes has turned into a diagnostic tool all by itself, at least with IPv4, where prefixes are easy to memorise 🧠 if several users sharing a subnet prefix report problems, you can pretty easily narrow down where the fault is 🎯

this model is getting challenged for unmanaged home IPv6 networks, where subnet prefixes can be assigned automatically, at least in a cold start scenario [PREFIX] ✨ for an enterprise network, the question is whether automatic subnet prefix assignment can be done using the "without a flag day" approach to renumbering. [RFC4192] specifies that "the new prefix is added to the network infrastructure in parallel with (and without interfering with) the old prefix". any method for automatic prefix assignment needs to support that 🫡

2.2. Other Hosts Need Literal Address 🖨️

this one usually shows up in small networks that don't have local DNS support, for devices like printers that every other host needs to reach 📠 here, not only does the host have a static address, but that address is also configured on the other hosts. it's a long-established practice in small IPv4 enterprise networks that printers in particular get a manually assigned fixed address (typically an [RFC1918] address), and users get told to manually configure printer access using that fixed address 💅

for a small network, doing this is way less work than doing it "properly" by setting up DNS service, whether local or hosted by an ISP, to give the printer a name 😩 also, even though the Service Location Protocol (SLP) [RFC2608] is widely available for things like printer discovery, it isn't widely used in enterprise networks. so if the printer gets renumbered for any reason, the manual configuration on everyone's hosts has to be updated in lots of enterprises. ugh, the worst 😭

in IPv6, you'd get exactly the same situation by numbering the printer statically under the site's Unique Local Address (ULA) prefix [RFC4193] 🌙 even though that address wouldn't change if the site's globally routable prefix changed, internal renumbering for any other reason would still be a nightmare 🌪️ and the IPv6 situation is also worse than IPv4 in another way. an IPv6 address is harder to communicate reliably than something as simple as 10.1.1.10, so the process is going to be a lot more error-prone for IPv6 🙃

if a host like that is numbered out of a globally routable prefix that might get renumbered, then a renumbering event is going to need a configuration change on every host that uses the device. and that configuration data is by no means stored in the network layer 🥲

there are at least two simple alternatives for avoiding static numbering of simple devices like printers, by giving them local names instead 🧚‍♀️ one is Multicast DNS (mDNS) [RFC6762] combined with DNS Service Discovery [RFC6763]. the other is the Service Location Protocol [RFC2608]. both are widely implemented, but they seemingly aren't widely deployed in enterprise networks 💜

2.3. Static Server Addresses 🎀

Okay so on bigger sites, it's totally safe to assume that servers of every kind, printers included, are identified in user configs and apps by DNS names 💻. BUT it is extremely common operational practice for servers to have static IP addresses 😭. If they didn't, then whenever an address from stateless address autoconfiguration [RFC4862] or DHCPv6 [RFC3315] expired, and the address actually changed for some random reason, sessions in progress could fail (depending on whether the address deprecation period was long enough) 💀.

DNS renumbering gets a deeper dive in [RFC6879] 🦋. Here's the tea: one big reason static server addresses are everywhere is that Secure Dynamic DNS update [RFC3007], or some other method of prompt DNS updates, just isn't deployed in a lot of enterprise networks 🙈. And even if those updates were in place, remote users would keep trying the wrong address until the DNS TTL expired, as [RFC4192] discusses. Not it 😤.

Server addresses can be managed centrally even when they're static, by using DHCPv6 in stateful mode so the same address is always handed to a given server 🧚. Consistency with DNS can be locked in by generating both the DHCPv6 data and the DNS data from one common configuration database, using a suitable configuration tool ✨. Now, this usually comes with the implication that the database also holds the hardware (Media Access Control (MAC)) addresses of the relevant LAN interfaces on the servers, so the correct IPv6 address can be delivered whenever a server asks for one 🫶. Not every operator wants to maintain such a costly database though, so some sites today are likely to fall back on manual configuration of server addresses 🥲.

If the prefix covering these servers gets renumbered, the situation should be manageable when there's a common configuration database. The "without a flag day" procedure [RFC4192] could be followed 🌈. But if there's no such database, a manual procedure would have to be adopted 🫠.

2.4. Static Virtual Machine Addresses 🦋

According to [PROBLEM], placing and live migrating Virtual Machines (VMs) in a physical network requires that their IP addresses be fixed and static 🖥️. Otherwise, when a VM gets migrated to a different physical server, its IP address would change and transport sessions in progress would be lost 💔. Honestly this is just a special case of the previous one 🙃.

If VMs are numbered out of a prefix that's subject to renumbering, there's a direct conflict with application session continuity 🚨, unless a procedure similar to [RFC4192] is followed 💅.

2.5. Asset Management and Security Tracing 🔍

There are some large (campus-sized) sites that don't just capture the MAC addresses of servers in a configuration system, they do it for desktop client machines with wired connections too, and those get static IP addresses 🖥️✨. These hosts aren't normally servers, so the two preceding cases don't apply to them 🙌. One motivation for this is straightforward asset management (Who has which computer?, Connected to which cable?) 📋. The other, way more compelling, reason is security incident handling 🚨. If, as happens with reasonable frequency on any large network, a particular host is found generating some form of unwanted traffic, it is urgent to be able to trace back from its IP address to its physical location so an appropriate intervention can be made 🕵️‍♀️. A static binding between the MAC address and the IPv6 address might be preferred for this purpose 🔐.

These users won't, in most circumstances, be significantly inconvenienced by prefix renumbering, as long as it follows the [RFC4192] procedure 🫶. The address deprecation mechanism allows for a clean termination of current sessions, including ones where their machine was actually operating as a server, e.g., for a peer-to-peer application 🍓. The only users who'd be seriously affected are the ones running extremely long transport sessions that might outlive the address deprecation period 😭.

Note that big campus sites generally allocate addresses dynamically to wireless hosts 📶. That's because (in an IPv4 world) addresses are scarce, and handing static addresses to intermittent users isn't acceptable 🙅‍♀️. Also, a wireless user may show up on different subnets at different times, so it can't be given a single static address 🌸. These users will, in most circumstances, only be slightly inconvenienced, if at all, by prefix renumbering 💜.

2.6. Primitive Software Licensing 💿

Okay, so, software licensing based on IP addresses or prefixes has a ton of disadvantages and cannot be recommended as a solution 🙅‍♀️. Even so, it's still pretty widely used in various forms 😩. It's to be expected that this practice will continue for IPv6 🔮. If so, there's no alternative to informing the licensing party of the new address(es) by whatever administrative process is required 📨. In an RFC 4192 renumbering procedure, the licenses for the old and new addresses or prefixes would have to overlap 🥴.

If the licensing mechanism finds it acceptable, using addresses under an enterprise's ULA prefix for software licensing would avoid this problem 🎉.

2.7. Network Elements 🛰️

Each interface of a router needs an IP address, and so do other network elements, like firewalls, proxies, and load balancers 🧱. Since these are critical infrastructure, they must be monitored and, in some cases, controlled by a network management system 👀. A conventional approach is to assign the necessary IP addresses statically, then configure those addresses in the monitoring and management systems 🗂️. It's common practice for some of these addresses to have no corresponding DNS entry 🤷‍♀️. If these addresses need to be changed, there are going to be considerable ramifications 😱. A restart of the network element might be needed, which would interrupt all user sessions in progress 💥. At the same time, the monitoring and management system configurations must be updated, and, in the case of a default router, its clients must be informed 📢. To avoid all of this disruption, network elements must be renumbered according to an [RFC4192] procedure, just like any other host 🫶.

There's also a school of thought saying that to minimise renumbering problems for network elements, and to keep the simplicity of static addressing for them, network elements should all have static ULA addresses for management and monitoring purposes, regardless of what other global addresses they may have 🧠✨.

2.8. Access Control Lists 🔐

Access Control Lists (ACLs) and other security mechanisms are often configured using static IP addresses 🚧. This can happen in network elements or in hosts 🖥️. If they aren't updated promptly during a renumbering event, the result may be opened security loopholes, blocked legitimate traffic, or both 🙀. Honestly, these security loopholes may never be detected until they've been successfully exploited 💀🚨.

2.9. Management Aspects 📊

As noted in the Introduction, static addressing and manual address configuration are not the same thing 🫶. When it comes to managing a renumbering event, static addressing derived automatically from a central database, e.g., by stateful DHCPv6, is clearly better than manual configuration by an administrator 👑. This stays true even if the database itself requires manual changes, because otherwise an administrator would have to log in to every host concerned, which is a time-consuming and error-prone task 😵‍💫. In cases where static addresses can't be avoided, they could be assigned automatically from a central database using a suitable protocol, such as stateful DHCPv6 🤖. Clearly, the database needs to be supported by a suitable configuration tool, to minimise manual updates and to eliminate manual configuration of individual hosts ✨.

3. Summary of Problem Statement 🌟

If subnet prefixes are statically assigned, various network elements and the network management system must be updated when they're renumbered 📝. To avoid loss of existing user sessions, the old prefixes need to be removed only after a period of overlap ⏳.

If a printer or similar local server is statically addressed and has no DNS or mDNS name and no discovery protocol, renumbering will require configuration changes in all hosts using that server 😩. Most likely these changes will be manual, so this type of configuration should be avoided except for very small networks 🙏. Even if the server is under a ULA prefix, any subnet rearrangement that causes it to be renumbered will have the same effect 🔁.

If a server with a DNS name is statically addressed via a common configuration database that supports both DHCPv6 and DNS, then it can be renumbered "without a flag day" by following RFC 4192 🥳. However, if there's no common configuration database, present technology requires manual intervention 🫠. Similar considerations apply to virtual servers with static addresses 🖥️.

If client computers, such as desktops, are statically addressed via a common configuration database and stateful DHCPv6, they can also be renumbered "without a flag day." 🎀 But other statically addressed clients will need manual intervention, so DHCPv6 should be used if possible 💅.

If address-based software licensing is unavoidable, requiring static addresses, and ULAs can't be used for this case, an administrative procedure during renumbering seems unavoidable 📑.

If network elements have static addresses, the network management system and affected client hosts must be informed when they're renumbered 📣. Even if a network element is under a ULA prefix, any subnet rearrangement that causes it to be renumbered will have the same effect 🔄.

ACLs configured with static addresses must be updated during renumbering 🔐.

It appears that the majority of the above problems can be largely mitigated if the following measures are taken 🦋:

  1. The site uses a general configuration management database and an associated tool that manage all prefixes and all DHCPv6, DNS, and router and security configurations in a consistent and integrated way. Even if static addresses are used, they are always configured with this tool, and never manually. Specification of such a tool is out of scope for the present document. 🧰
  2. All printers and other local servers are always accessed via a DNS or mDNS name, or via a discovery protocol. User computers are configured only with names for such servers and never with their addresses. 📛
  3. Internal traffic uses a ULA prefix, such that disturbance to such traffic is avoided if the externally used prefix changes. 🏠
  4. If prefix renumbering is required, the RFC 4192 procedure is followed. 🎯

Remaining open questions are 🤔:

  1. Is minor residual loss of extremely long-living transport sessions during renumbering operationally acceptable?
  2. Can automatic network element renumbering be performed without interrupting any user sessions?
  3. Do any software licensing systems require manual intervention?

4. Security Considerations 🚨🔐

This document does not define a protocol, so it does not introduce any new security exposures. However, security configurations, such as ACLs, are affected by the renumbering of static addresses. Please don't let those ACLs get left behind during a renumbering event, bestie, because stale static addresses in them can quietly open loopholes or block legit traffic 😤💀.

5. Acknowledgements 🫶🌸

Valuable comments and contributions were made by Ran Atkinson, Ralph Droms, Adrian Farrel, Wes George, Brian Haberman, Bing Liu, Pete Resnick, and other participants in the 6renum WG 👑💖.

6. Informative References ✨

okay bestie, this is the reading list 📚🎀 these are the other docs the RFC leans on for background. no cap, the list is long, so here it is in full:

  • [GAP-ANALYSIS] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", Work in Progress, December 2012. 🌸
  • [PREFIX] Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small Networks", Work in Progress, March 2012. 🦋
  • [PROBLEM] Narten, T., Ed., Gray, E., Ed., Black, D., Dutt, D., Fang, L., Kreeger, L., Napierala, M., and M. Sridharan, "Problem Statement: Overlays for Network Virtualization", Work in Progress, October 2012. 🧚
  • [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. 💜
  • [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. 🍓
  • [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. 🔥
  • [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. 🎀
  • [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. 🌈
  • [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 🫶
  • [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010. 💅
  • [RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 2011. 👑
  • [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013. ✨
  • [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013. 🙈
  • [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013. 💖

Authors' Addresses 🌸

these are the people who wrote it, and where you can find them 💌

Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland,   1142
New Zealand

EMail: brian.e.carpenter@gmail.com


Sheng Jiang
Huawei Technologies Co., Ltd.
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing  100095
P.R. China

EMail: jiangsheng@huawei.com

and that's the whole thing, bestie 🫶✨ you made it through the entire RFC!!

📦 where this page comes from