RFC 2071

Network Renumbering Overview: Why would I want it and what is it anyway? 🎀

Okay bestie, let's get the basics out of the way 💅 This is RFC 2071, written by P. Ferguson (cisco Systems, Inc.) and H. Berkowitz (PSC International). It came out of the Network Working Group in January 1997. The category is Informational, so it's giving "here's some good info" energy, not "this is a standard" energy 🧚 The header doesn't list anything it obsoletes or updates, so there's nothing extra to chase down ✨

Status of This Memo 📜

This memo is here to give information to the Internet community 🦋 It does not specify an Internet standard of any kind, so don't treat it like one. Distribution of this memo is unlimited, so share it with everyone who needs it 💖

Abstract ✨

The PIER [Procedures for Internet/Enterprise Renumbering] working group is putting together a bunch of documents to help and guide organizations that want to renumber 🛠️ But with more new Internet Service Providers (ISP's) popping up, and more organizations connecting to the Internet for the very first time, the concept of network renumbering honestly needs more definition 🫶 This document tries to clearly define what network renumbering is and talks about some of the most important reasons an organization might need to do it 🌸

Table of Contents 🎀

1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
2.   Background . . . . . . . . . . . . . . . . . . . . . . . . .  2
3.   Network Renumbering Defined. . . . . . . . . . . . . . . . .  3
4.   Reasons for Renumbering. . . . . . . . . . . . . . . . . . .  3
5.   Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.   Security Considerations  . . . . . . . . . . . . . . . . . . 12
7.   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 12
8.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14

1. Introduction 🌈

Connecting to the global Internet has been blowing up over the past several years 🚀, and it's brought some new problems along for the ride. What people casually call "growing pains" can be traced back to more basic gaps in understanding what Internet connectivity actually requires 🤓 Organizations might need to renumber their networks for lots of different reasons, and those reasons can vary a lot, so we'll dig into them in some detail below 💅 Just so you know, it is not within the intended scope of this document to talk about renumbering methodologies, techniques, or tools 🙅‍♀️

2. Background 🌸

Any network or interconnected devices, like desktop PCs or workstations, need unique IP host addresses [1] to reach any potential destination on the global Internet 🌐 If a duplicate host address is being used somewhere else on the Internet, that's honestly a mess 💀 because one of the destinations would end up unreachable from some origins. Still, globally unique IP addresses aren't always necessary. It depends on the connectivity requirements [2] 🙈

The recent popularity of getting Internet connectivity has made these connectivity dependencies super unpredictable 😭 so the conventional wisdom in the Internet community is that the address allocation registries (like the InterNIC) and the ISPs need to get more prudent with how they hand out addresses 🧐 The InterNIC has set up address allocation policies [3], where most address allocations for end-user networks come from their upstream ISP. The exceptions are dual- or multihoming, and cases where very large blocks of addresses are needed 🎀 Since this allocation policy has become standard current practice, moving addresses from one provider to another is now a tricky problem 😩

Real talk: if end users want full connectivity to the global Internet, they can't assume they "own" their address allocations 💅 Instead, end users will "borrow" part of an upstream provider's address space. The bigger provider block that their space gets carved out of will have been assigned in a way that's consistent with global Internet routing 🦋

Not having "permanent" addresses doesn't mean you won't have unique identifiers 🫶 Those are usually Domain Name System (DNS) [4] names for endpoints like servers and workstations. The Dynamic Host Configuration Protocol (DHCP) [5] can help automate assigning and maintaining host names, plus the "borrowed" addresses needed for routing-level connectivity ✨

The PIER Working Group is developing procedures and guidelines for detailed renumbering of specific technologies, like routers [6] 🧚 PIER WG documents are meant to suggest methods for getting existing networks ready for convenient renumbering, and also for the operational transition to new addressing schemes 🌈

Also, lots of organizations have never connected to the Internet, but have been using arbitrary blocks of addresses since they were first built. They have their own different and unique challenges 🙃

3. Network Renumbering Defined 🔥

In the simplest of definitions, renumbering a network means changing the IP host addresses, and maybe the network mask too, of each device in the network that has an address associated with it 🔄 This could cover all the networks within a particular domain, like FOO.EDU, or all the networks that make up an entire autonomous system 🌍

Devices that may need to be renumbered include networked PCs, workstations, printers, file servers, terminal servers, and routers 🖨️ Renumbering can also mean changing host parameters and configuration files that contain IP addresses. That includes configuration files with the addresses of DNS and other servers, addresses contained in SNMP [7] management stations, and addresses configured in access control lists 📝 That's not an all-inclusive list, but the PIER working group is making efforts to compile documentation that identifies these devices in a more detailed way 💖

Renumbering doesn't have to be a sudden thing, either 🌙 In most instances, an organization's upstream service provider(s) will allow a grace period where both the "old" addresses and the "new" addresses can be used in parallel 🫶

4. Reasons for Renumbering 💜

The next sections talk about particular reasons that might kick off a renumbering 🎀 They aren't presented in any order of precedence. They're grouped into reasons that mainly reflect decisions made in the past, operational requirements of the present, or plans for the future 📅 Some of these reflect the organization's evolving mission, like needing to communicate with business partners or to work efficiently in a global Internet 🤝 Others reflect changes in network technologies ⚙️

4.1. Past 🕰️

Lots of organizations set up IP-based networks not to connect to the Internet, but simply to make use of effective data communications mechanisms 📡 Later, these organizations found valid reasons to connect to other organizations or to the Internet in general, but the address structures they had chosen didn't fit with overall Internet practice 😬

Other organizations connected to the Internet early, back when address space wasn't scarce 🌷 And yet other organizations still have no requirement to connect to the Internet, but they have legacy addressing structures that don't scale to an adequate size 🦕

4.1.1. Initial addressing using non-unique addresses 🙈

As recently as two years ago, many organizations had no intention of connecting to the Internet. They built their corporate or organizational networks using unregistered, non-unique network addresses 🧱 Then, as things do, these same organizations realized Internet connectivity had become a valuable asset, and found out they could no longer use the same unregistered, non-unique network addresses that they'd deployed all over the organization 😳 So now they're stuck with the labor of renumbering to valid network addresses as they move to connect to the global Internet 🛠️

Valid, unique addresses are certainly required to get full Internet connectivity in most circumstances 💯 But the number of unique addresses needed can be significantly reduced by using Network Address Translation (NAT) devices [8] and private address space, as specified in [9] 🧩 NAT doesn't just reduce the number of required unique addresses, it also localizes the changes required by renumbering 🎯

NAT technology may not always be a viable option, though, depending on scale of addressing, performance, or topological constraints 💀

4.1.2. Legacy address allocation 🐘

There are also several instances where organizations were originally allocated very large amounts of address space, like traditional "Class A" or "Class B" allocations, even though their actual address requirements are much less than what was originally allocated 📉 In many cases, these organizations could get by with a smaller CIDR allocation and use their allocated address space more efficiently 🧁 As allocation requirements become more stringent, mechanisms to review how these organizations are using their address space could, quite possibly, result in a request to return the original allocation to a particular registry, and renumber with a more appropriately sized address block 🔁

4.1.3. Limitations of Bridged Internetworks 🌉

Bridging has a long and distinguished history in legacy networks 👑 As networks grow, though, traditional bridged networks reach performance- and stability-related limits, including (but not limited to) broadcast storms 🌪️

Early routers didn't have the speed to handle the needs of some large networks 🐢 Some organizations literally weren't able to move to routers until router forwarding performance improved to be comparable to bridges 😤 Now that routers are of comparable or superior speed, and offer more robust features, replacing bridged networks becomes reasonable 🚀

IP addresses assigned to pure bridged networks tend not to be subnetted, yet subnetting is a basic approach for router networks 🧠 Introducing subnetting is a practical necessity when moving from bridging to routing 📐

Special cases of bridging show up in workgroup switching systems, which we'll get into below 🎁

4.1.4. Limitations of Legacy Routing Systems 📢

Other performance problems might come from routing mechanisms that advertise excessive numbers of routing updates (e.g., RIP, IGRP) 😵 Meanwhile, appropriate replacement protocols (e.g., OSPF, EIGRP, S-IS) work best with a structured addressing system that encourages aggregation 🏗️

To be continued 👀 Part 2 picks up with the rest of the reasons, so stay tuned, bestie 💜

4.1.5. Limitations of System Administration Methodologies

okay so there can be real limits on growth based on how hard it is to do adds, moves and changes 😩 as enterprise networks get bigger, it may be necessary to hand off parts of address assignment and maintenance to others. but if the address space was assigned randomly or inefficiently, it can be really hard to delegate chunks of it 💀

it's not unusual for organizational networks to grow sporadically, grabbing an address prefix here and there in a non-contiguous way 🧩 depending on how many prefixes an organization collects over time, it may get increasingly unmanageable or need more maintenance and administration when each prefix is acquired this way. ngl, it's a mess 🙈

reasonable IP address management may generally simplify ongoing system administration 💅 a good numbering plan is also a good renumbering plan ✨ renumbering may force a discipline into system administration that will reduce long-term support costs. it's giving "tidy room saves future you" energy 🧹

it has been observed "...there is no way to renumber a network without an inventory of the hosts (absent DHCP). On a large network that needs a database, plus tools and staff to maintain the database."[10] it can be argued that a detailed inventory of router configurations is even more essential 🎀

4.2. Present

okay so organizations now need to connect to the global Internet, or at the very least to other organizations through bilateral private links 🌍

certain new transmission technologies have tended to redefine the basic notion of an IP subnet 🦋 an IP numbering plan needs to work with these new ideas. legacy bridged networks and leading-edge workgroup switched networks may very well need changes in the subnetting structure. renumbering needs may also develop due to the characteristics of new WAN technologies, especially nonbroadcast multi-access (NBMA) services such as Frame-Relay and Asynchronous Transfer Mode (ATM) 🌸

increased use of telecommuting by mobile workers, and in small and home offices, needs on-demand WAN connectivity, using modems or ISDN 📞 effective use of demand media often requires changes in numbering and routing 💜

4.2.1. Change in organizational structure or network topology

as companies grow through mergers, acquisitions and reorganizations, the need may arise for realignment and modification of the various organizational network architectures 🏢 connecting disparate corporate networks presents unique challenges in the realm of renumbering, since one or more individual networks may have to be blended into a much larger architecture consisting of a different IP address prefix altogether 🫠

4.2.2. Inter-Enterprise Connectivity

even if they don't connect to the general Internet, enterprises may interconnect with other organizations that have independent numbering systems 🤝 this can be as simple as bilateral dedicated circuits. if both enterprises use unregistered or private address space, they run the risk of using duplicate addresses 😬

in such cases, one or both organizations may need to renumber into different parts of the private address space, or obtain unique registered addresses 🔁

4.2.3. Change of Internet Service Provider

as mentioned previously in Section 2, it is increasingly becoming current practice for organizations to have their IP addresses allocated by their upstream ISP 🛰️ also, with the advent of Classless Inter Domain Routing (CIDR) [11], and the considerable growth in the size of the global Internet table, Internet Service Providers are becoming more and more reluctant to let customers keep using addresses that were allocated by the ISP when the customer terminates service and moves to another ISP 🙅‍♀️ the prevailing reason is that the ISP was previously issued a CIDR block of contiguous address space, which can be announced to the rest of the Internet as a single prefix. (a prefix is what is referred to, in classless terms, as a contiguous block of IP addresses.)

if a non-customer advertises a specific component of the CIDR block, this adds an additional routing entry to the global Internet routing table. this is what is commonly referred to as "punching holes" in a CIDR block 🕳️ consequently, there are usually no routing anomalies in doing this, since a specific prefix is always preferred over an aggregate route. however, if this practice happened on a large scale, the growth of the global routing table would become much larger, perhaps too large for current backbone routers to accommodate acceptably with regard to the performance of recalculating routing information and the sheer size of the routing table itself 😱 for obvious reasons, this practice is highly discouraged by ISPs with CIDR blocks, and some ISPs are making it a contractual issue, so that customers understand that addresses allocated by the ISP are non-portable 📜

it is noteworthy that the likelihood of being forced to renumber in this situation is inversely proportional to the size of the customer's address space 📏 for example, an organization with a /16 allocation may be allowed to consider the address space "portable", while an organization with multiple non-contiguous /24 allocations may not. while the scenarios may be vastly different in scope, it becomes an issue to be decided at the discretion of the initial allocating entity and the ISPs involved. the major deciding factor is whether or not the change will fragment an existing CIDR block and whether it will significantly contribute to the overall growth of the global Internet routing tables 🧐

it should also be noted that (contrary to opinions sometimes voiced) this form of renumbering is a technically necessary consequence of changing ISPs, rather than a commercial or political mandate 💁‍♀️

4.2.3. Internet Global Routing

even large organizations, now connected to the Internet with "portable" address space, may find their address allocation too small 📦 current registry guidelines require that address space usage be justified by an engineering plan. older networks may not have efficiently used existing address space, and may need to make their existing structures more efficient before new address allocations can be made 🧠

4.2.4. Internal Use of LAN Switching

introducing workgroup switches may introduce subtle renumbering needs 👀 fundamentally, workgroup switches are specialized, high-performance bridges that make their main forwarding decisions based on Layer 2 (MAC) address information. even so, they are rarely independent of Layer 3 (IP) address structure. pure Layer 2 switching has a "flat" address space that will need to be renumbered into a hierarchical, subnetted space consistent with routing 🌳

introducing single switches or stacks of switches may not have a significant impact on addressing, as long as it is understood that each system of switches is a single broadcast domain. each broadcast domain should map to a single IP subnetwork 🫶

Virtual LANs (VLANs) further extend the complexity of the role of workgroup switches 🌀 it is generally true that moving an end station from one switch port to another within the same VLAN will not cause major changes in addressing. many overview presentations of this technology don't make it clear that moving the same end station between different VLANs will move it into another IP subnet, which requires a significant address change 😭

switches are commonly managed by SNMP applications. these network management applications communicate with managed devices using IP. even if the switch doesn't do IP forwarding, it will itself need IP addresses if it is to be managed. also, if the clients and servers in the workgroup are managed by SNMP, they will also require IP addresses. the workgroup, therefore, will need to appear as one or more IP subnetworks 🖥️

increasingly, internetworking products are not purely Layer 2 or Layer 3 devices. a workgroup switch product often includes a routing function, so the numbering plan must support both flat Layer 2 and hierarchical Layer 3 addressing 🎯

4.2.4. Internal Use of NBMA Cloud Services

"cloud" services such as frame relay are often more economical than traditional services ☁️ at first glance, when converting existing enterprise networks to NBMA, it might appear that the existing subnet structure should be preserved, but this is often not the case 🙃

many organizations began by treating the "cloud" as a single subnet, but experience has shown it is often better to treat the individual virtual circuits as separate subnets, which appear as traditional point-to-point circuits 🔗 when the individual point-to-point VCs become separate subnets, efficient address utilization requires the use of long prefixes (i.e., 30 bit) for these subnets. in practice, obtaining 30 bit prefixes means the logical network should support variable length subnet masks (VLSM). VLSMs are the primary method by which an assigned prefix can be subnetted efficiently for different media types. this is accomplished by establishing one or more prefix lengths for LAN media with more than two hosts, and subdividing one or more of these shorter prefixes into longer /30 prefixes that minimize address loss 🍰

there are alternative ways to configure routing over NBMA, using special mechanisms to exploit or simulate point-to-multipoint VCs 🧪 these often have a significant performance impact, and may be less reliable because a single routing point of failure is created. motivations for such alternatives tend to include:

1. a desire not to use VLSM. this is often founded in fear rather than technology 😂
2. router implementation issues that limit the number of subnets or interfaces a given router can support 🔧
3. an inherently point-to-multipoint application (e.g., remote hosts to a data center). in such cases, some of the limitations are due to the dynamic routing protocol in use. in such "hub-and-spoke" implementations, static routing can be preferable from a performance and flexibility standpoint, since it does not produce routing protocol chatter and is unaffected by split horizon constraints (namely, the inability to build an adjacency with a peer within the same IP subnetwork) 🕸️

4.2.5. Expansion of Dialup Services

dialup services, especially public Internet access providers, are experiencing explosive growth 🚀 this success is a particular drain on the available address space, especially with the commonly used practice of assigning unique addresses to each customer 📉

in this case, individual users announce their address to the access server using PPP's IP control protocol (IPCP) [12] 📡 the server may validate the proposed address against some type of user identification, or simply make the address active in a subnet to which the access server (or set of bridged access servers) belongs 🪪

the preferred technique is to allocate dynamic addresses to the user from a pool of addresses available to the access server 💖

4.2.6. Returning non-contiguous prefixes for an aggregate

okay bestie, this is a glow-up arc 💅 In a lot of cases, an org can hand back its current non-contiguous prefix allocations and get one contiguous block of address space that's equal or bigger instead, and CIDR can totally handle that 🦋 Also, tons of orgs are running classless interior routing protocols inside their own domains now. These use route summarization and other optimized routing features, so way fewer routes get propagated through the internal network(s), and it's so much easier to administer and maintain ✨

Hierarchical routing protocols like OSPF scale best when a network's address assignment reflects its topology 🌸 The problem is that topologies are lowkey fluid. Even the best-planned address assignment scheme will eventually drift away from the actual topology, given enough time 🙈 So while it's not required, some organizations may choose to renumber periodically so their address assignments match the network topology again. That gets them the technical and administrative scalability of their IGP 👑 Patrick Henry once said "the tree of liberty must from time to time be watered with the blood of patriots." In the Internet, the routing trees of even the best-planned networks need to be watered from time to time with at least the sweat of network administrators 😭💦 Improving aggregation is also highly encouraged 💜 It shrinks the global Internet routing table and the size and scalability of interior routing inside the enterprise, which is giving double win 🎀

---

4.3. Future

Emerging new protocols will most definitely affect addressing plans and numbering schemes 🧚 Keep your eyes open, bestie ⭐

4.3.1. Internal Use of Switched Virtual Circuit Services

Services like ATM virtual circuits and switched frame relay bring challenges that the original IP design never considered 💀 The basic IP forwarding decision is whether the destination is local or remote, relative to the source host's subnet. Address resolution mechanisms find the medium address of the destination for local destinations, or the medium address of the router for remote ones 🌈

Here's where it gets spicy: in these new services, it can be way more effective to "cut-through" a new virtual circuit straight to the destination 🦋 If the destination is on a different subnet than the source, the cut-through typically goes to the egress router that serves the destination subnet. The perk of cut-through in that case is that it skips the latency of multiple router hops and takes load off "backbone" routers 💅 The cut-through decision is usually made by an entry router that knows about both the routed and switched environments ✨

This entry router talks to an address resolution server using the Next Hop Resolution Protocol (NHRP) [13] 🫶 The server maps the destination network address to either a next-hop router (where cut-through isn't appropriate) or an egress router reached over the switched service. Obviously, the database in such a server may be affected by renumbering 🙈 Clients may have a hard-coded address of the server, which again may need to change. The NHRP protocol specifications are still evolving at the time of this writing, but commercial implementations based on drafts of the protocol standard are already in use 🔥

4.3.2. Transitioning to IP version 6

Okay so when IPv6 [14] deployment gets set in motion, and methodologies for transitioning to IPv6 get developed, renumbering will also be necessary 🌸 It might not be immediately mandatory though. To help with the transition, mechanisms for deploying dual- IPv4/IPv6 stacks on network hosts should also become available 🧚 It's also envisioned that Network Address Translation (NAT) devices will be developed to assist the IPv4 to IPv6 transition, or maybe even supplant the need to renumber most interior networks altogether 👑 That's beyond the scope of this document though. At the very least, DNS hosts will need to be reconfigured to resolve new host names and addresses, and routers will need to be reconfigured to advertise new prefixes 💜

IPv6 address allocation will be managed by the Internet Assigned Numbers Authority (IANA) as set forth in [15] 🎀

---

5. Summary

As the Internet Architecture Board (IAB) pointed out in [16], renumbering networks is becoming more widespread and more commonplace 🌈 There are numerous reasons an organization might want to renumber, or be required to, and there are just as many reasons address allocation should be done with great care and forethought right at the start 🍓 That way the impact of renumbering on the organization stays minimal ✨ Even with the most forethought and vision, though, an organization can't foresee every possibility for renumbering 😭 So the best advice is to be prepared and get ready for renumbering 💅

---

6. Security Considerations

Okay, this part is serious bestie 🚨 Although no obvious security issues are discussed in this document, it stands to reason that renumbering certain devices can defeat security systems designed and based on static IP host addresses 💀 Whoever is doing the renumbering needs to take care that every security system deployed with the network(s) that may need renumbering gets special consideration and significant forethought, so it keeps working and stays adequately secure 🔐🫶

---

7. Acknowledgments

Special shout-outs to Yakov Rekhter [cisco Systems, Inc.], Tony Bates [cisco Systems, Inc.] and Brian Carpenter [CERN] for their contributions and editorial critique 🎀👑

---

8. References

[1] Gerich, E., "Unique Addresses are Good", RFC 1814, IAB, July 1995.

[2] Crocker, D., "To Be `On' the Internet", RFC 1775, March 1995.

[3] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", BCP 12, RFC 2050, November 1996.

[4] Mockapetris, P., "Domain Names - Concepts and Facilities", and "Domain Names - Implementation and Specification", STD 13, RFCs 1034, 1035, November 1987.

[5] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541, October 1993.

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

[7] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.

[8] Egevang,, K., and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994.

[9] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G-J., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.

[10] Messages to PIER list on CERN renumbering; Brian Carpenter, CERN. Available in PIER WG mailing list archives.

[11] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, October 1993.

[12] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.

[13] Luciani, J., Katz, D., Piscitello, D., and Cole, B., "NBMA Next Hop Resolution Protocol (NHRP)", Work in Progress.

[14] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.

[15] IAB and IESG, "IPv6 Address Allocation Management", RFC 1881, December 1995.

[16] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.

---

9. Authors' Addresses

Paul Ferguson
cisco Systems, Inc.
1875 Campus Commons Road
Suite 210
Reston, VA 22091

Phone: (703) 716-9538
Fax: (703) 716-9599
EMail: pferguso@cisco.com


Howard C. Berkowitz
PSC International
1600 Spring Hill Road
Vienna, VA 22182

Phone (703) 998-5819
Fax:  (703) 998-5058
EMail:  hcb@clark.net