RFC 2072
Router Renumbering Guide
RFC 2072: Router Renumbering Guide 🎀
okay bestie, this is the title block 💖 It's RFC 2072, and the title is Router Renumbering Guide. H. Berkowitz from PSC International wrote it, and it was published in January 1997. Its category is Informational, which means it's a guide and not a standard 🧚. The header doesn't list any RFCs it obsoletes or updates.
Part 1 of 10 🌸
Status of This Memo ✨
okay so this memo is just giving info to the Internet community 🦋 It does not specify an Internet standard of any kind, so nobody is required to follow it like a rule. Distribution is totally unlimited, so share it with everyone 💅
Abstract 🌈
IP addresses that organizations are using right now will probably change in the near to moderate term 😭 There are lots of reasons: enterprise reorganization, physically moving equipment, new strategic relationships, changing Internet Service Providers (ISPs), new applications, and the needs of global Internet connectivity. Good IP address management usually makes everyday system administration easier too. Honestly, a good renumbering plan is also a good numbering plan 🍓 Most things you do to make future renumbering easier will also make routine network admin easier, so it's a win-win 👑
Routers are the pieces that connect the parts of the IP address space, each identified by its own unique prefix ✨ So yeah, they're definitely going to be affected by renumbering. Other interconnection devices like bridges, layer 2 switches (basically specialized bridges), and ATM switches might be affected too 🦋 How these lower-layer devices interact with routers has to be considered as part of any renumbering effort.
Routers also talk to a bunch of network infrastructure servers, including DNS and SNMP 💜 Those interactions matter too. It's not just the addressing and routing structure. They all have to be considered as part of router renumbering 💀
Network Working Group H. Berkowitz
Request for Comments: 2072 PSC International
Category: Informational January 1997Table of Contents 🧚
Here's the whole table of contents, copied exactly so you can find your way around 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations for Renumbering . . . . . . . . . . . . . . . . 3
4. Numbering and Renumbering. . . . . . . . . . . . . . . . . . 9
5. Moving toward a Renumbering-Friendly Enterprise. . . . . . . 13
6. Potential Pitfalls in Router Renumbering. . . . . . . . . 20
7. Tools and Methods for Renumbering . . . . . . . . . . . . 25
8. Router Identifiers . . . . . . . . . . . . . . . . . . . . . 29
9. Filtering and Access Control . . . . . . . . . . . . . . . . 35
10. Interior Routing . . . . . . . . . . . . . . . . . . . . . . 37
11. Exterior Routing . . . . . . . . . . . . . . . . . . . . . . 39
12. Network Management . . . . . . . . . . . . . . . . . . . . . 41
13. IP and Protocol Encapsulation . . . . . . . . . . . . . . . 43
14. Security Considerations. . . . . . . . . . . . . . . . . . . 44
15. Planning and Implementing the Renumbering . . . . . . . . . 44
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
18. Author's Address . . . . . . . . . . . . . . . . . . . . . . 481. Introduction 💖
Organizations can decide to renumber some or all of their IP address space for lots of different reasons 🌸 The big-picture motivations are covered in [RFC2071]. This document is about the router side of things, once the decision to renumber has already been made 🎀
A renumbering effort has to be well-planned if it's going to work 😤 This doc covers planning and implementation guidelines for the interconnection devices in an enterprise. Out of all those devices, routers have the clearest connection to the IP numbering plan 👑
Planning starts with understanding the problem you're solving. That includes both the motivation for renumbering and the technical issues involved ✨ Here's the game plan:
- Start with a short, clear statement of why you're renumbering. Section 3 talks about the common reasons 💅
- Understand the principles of numbering in your current and planned environments. Section 4 reviews numbering and suggests a way to describe the scope of renumbering 🧠
- Before the actual renumbering, it can help to evolve your current environment and numbering into something more "renumbering-friendly" 🦋 Section 5 explains how to add that friendliness to existing systems.
- Watch out for potential pitfalls 🙈 They're discussed in Section 6.
- Figure out what tools you might need, which is covered in Section 7 🛠️
- Check out the specific router mechanisms that renumbering will affect. See Sections 8 through 13 🔍
- Set up a specific transition plan framework. Guidelines for that planning are in Section 15 🌈
When you're trying to understand how renumbering affects routers, keep in mind there are different aspects to the problem, depending on how big the renumbering is 🍓 Even an enterprise-wide renumbering probably won't touch every IP address you can see inside the enterprise. Some addresses, like the ones belonging to Internet service providers or external business partners, are outside the address space the enterprise controls 🫶
2. Disclaimer 🎀
The main part of this document is meant to be vendor-independent 💜 Not every feature talked about here has been implemented on every router, and that's just how it is. This doc is not a comparison of how rich the features are across different implementations 🙅♀️ It only points to features that renumbering affects. Some illustrative examples mention vendor-specific characteristics, but those examples don't necessarily reflect what products look like right now 💅
3. Motivations for Renumbering 🦋
Reasons to renumber can be technological, organizational, or both 🌸 The technological ones fall into a few broad categories, which we'll go through below. Just like there can be both technological and organizational motivations for renumbering [RFC2071], there can also be several technological reasons at once ✨
There isn't always a clear line between organizational and technical reasons ☁️ Networks have a charm and beauty all their own, obviously 😍 But the organizational reasons should be defined first, because that's what justifies the budget for the technical renumbering 💰 There can also be purely technical reasons to renumber, like a change in technology (for example, moving from bridging to routing) 🔁
This document is called "Router Renumbering Guide," but it also recognizes that renumbering might be needed because routers are being installed for the first time in a bridged legacy network 🧱 Some organizations had a bridging solution that worked fine but didn't scale as they grew 📈 Some organizations couldn't move to routers until router forwarding performance got good enough to match bridges [Carpenter] 🚀
Other things matter too, like following the rules for routing outside the organization 🌐 Those issues are mostly about the global Internet, but they can also involve bilateral private links to other enterprises 🤝
Certain new transmission technologies have kind of redefined what an IP subnet even is 🤯 Your numbering plan has to work with those new ideas. Legacy bridged networks and leading-edge workgroup switched networks may really need changes to their subnetting structure 🧩 Renumbering needs can also pop up when new WAN technologies show up, especially nonbroadcast multiaccess (NBMA) services like frame relay 📡 Other WAN technologies, like dialup media using modems or ISDN, may also have new routing and numbering requirements ☎️ And switched virtual circuit services like ATM, X.25, or switched frame relay also interact with routing and addressing 🌀
3.1. Internet Global Routing 🌍
A lot of renumbering talk focuses on how an organization's numbering plan interacts with the global Internet [RFC1900] 💖 But organizations that never connect to the global Internet can have just as strong reasons to renumber 🫶
According to RFC1900:
"Unless and until viable alternatives are developed, extended deployment of Classless Inter-Domain Routing (CIDR) is vital to keep the Internet routing system alive and to maintain continuous uninterrupted growth of the Internet....To contain the growth of routing information, whenever such an organization changes to a new service provider, the organization's addresses will have to change.
Sometimes service providers themselves have to move to a new, larger block of address space 📦 In either case, to keep the growth of routing information under control, the organizations involved would need to renumber.... If an organization doesn't renumber, some of the possible consequences include (a) limited (less than Internet-wide) IP connectivity, or (b) extra cost to cover the overhead of the organization's routing information that Internet Service Providers have to maintain, or both." 💀
3.2. Bridge Limitations; Internal Use of LAN Switching 🌸
Bringing in workgroup switches can create sneaky renumbering needs 🙈 Basically, workgroup switches are specialized, high-performance bridges, so their main forwarding decisions are based on Layer 2 (MAC) address information ⚡ Even so, they're rarely independent of the Layer 3 (IP) address structure 😤 Pure Layer 2 switching has a "flat" address space, which will need to be renumbered into a hierarchical, subnetted space that's consistent with routing 🌳 Traditional bridged networks share a lot of the same problems as workgroup switches, but they also have extra performance problems when bridged connectivity stretches across slow WAN links 🐢
Introducing single switches or stacks of switches might not have a big impact on addressing, as long as you remember that each system of switches is a single broadcast domain 📣 And each broadcast domain should map to a single IP subnet 🎯
Virtual LANs (VLANs) make the role of workgroup switches even more complicated 🎨 It's generally true that moving an end station from one switch port to another within the same "color" VLAN won't cause major changes to addressing ✅ But a lot of discussions of this technology don't make it clear that moving the same end station between different colors moves it into another IP subnet, which means a significant address change 😱
Switches are commonly managed by SNMP applications 🖥️ These network management apps talk to managed devices using IP. Even if a switch doesn't do IP forwarding, it still needs IP addresses if it's going to be managed 🔧 And if the clients and servers in the workgroup are managed by SNMP, they'll need IP addresses too 💻 So the workgroup will need to appear as one or more IP subnets 🧁
Internetworking products aren't purely Layer 2 or Layer 3 devices anymore 🌈 A workgroup switch product often includes a router function, so the numbering plan has to support both flat Layer 2 and hierarchical Layer 3 addresses 🦋✨
3.3 Internal Use of NBMA Cloud Services
okay so "cloud" services like frame relay are often way more economical than traditional services 💸✨. At first glance, when you convert an existing enterprise network to NBMA, it might seem like the existing subnet structure should stay the same, but that's often not the case 🙈.
Lots of orgs began by treating the "cloud" as one single subnet, but experience has shown it's usually better to treat each individual virtual circuit as its own subnet 🦋. Once the individual point-to-point VCs become separate subnets, efficient address use requires /30 prefixes 💅. That typically means the addressing and routing plan has to support multiple prefix lengths. You set one or more prefix lengths for LAN media with more than two hosts, then subdivide some of those shorter prefixes into longer /30 prefixes that minimize address loss. Main character addressing 👑.
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 on the router and may be less reliable, because a single point of failure gets created 💀. The mechanics of these alternatives are covered later in this section, but the motivations for them tend to include:
- A desire not to use VLSM. This is often founded in fear rather than technology 😭.
- Router implementation issues that limit the number of subnets or interfaces a given router can support.
- 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 "star" applications, static routing may actually be preferable from performance and flexibility standpoints, since it does not produce routing traffic and is unaffected by split horizon ⭐.
To understand how NBMA services affect the addressing structure and routers, it's worth reviewing what seem like super basic IP subnet concepts 🧚. The traditional view is that a single subnet is tied to a single physical medium. All hosts physically connected to that medium are assumed to be able to reach all other hosts on it, using data link level services. Those services are medium specific. Hosts on a LAN can broadcast to one another, while hosts on a point-to-point line just transmit to the other end 🍓.
When one host wants to transmit to another, it first figures out whether the destination is local or remote. A local destination is on the same subnet and is assumed reachable through data link services. A remote destination is on a different subnet, and it's assumed router intervention is needed to reach it 🎀.
The first NBMA problem shows up when a single subnet is implemented over an NBMA service. Frame Relay provides single virtual circuits between hosts that have connectivity. It's quite common to design Frame Relay services as partial meshes, where not all hosts have VCs to all others. When the set of hosts in a partial mesh sits in a single IP subnet, the partial mesh violates the local model of full connectivity 😤. Even with full meshing, a pessimistic but reasonable operational model has to consider that individual VCs do fail, and full connectivity may be lost transiently 💔.
There are several ways to deal with this violation, and each has its own limitations. If a specific "central" host has connectivity to N all other hosts, that central host can replicate all frames it receives from one host onto outgoing VCs connecting it with the (N-1) other hosts in the subnet. That replication usually causes an appreciable CPU load on the replicating router 🔥. The replicating router is also a single point of failure for the subnet. This method doesn't scale well when extended to fuller meshes within the subnet.
In a routing protocol such as OSPF, which has a concept of designated routers, explicit configuration usually is needed. Another problem with using a meshed subnet is that all VCs may not have the same performance, but the router can't prefer individual paths within the subnet 🙅♀️.
One of the simplest methods is not to try to emulate a broadcast medium, and instead just treat each VC as a separate subnet. This causes a need for renumbering. Efficient use of the address space dictates a /30 prefix for the per-VC subnets, and such a prefix often needs VLSM support in the routers 💖.
3.4 Expansion of Dialup Services
Dialup services, especially public Internet access providers, are growing explosively 🚀. That success is a particular drain on the available address space, especially with the commonly used practice of assigning a unique address to each customer 😩.
In this practice, individual users announce their address to the access server using PPP's IP configuration option [RFC1332]. The server may validate the proposed address against some user identifier, or it may simply make the address active in a subnet to which the access server (or set of bridged access servers) belongs.
These access server functions may be part of the software of a "router," and thus are within the scope of this Guide 📖.
The preferred technique [Hubbard] is to allocate dynamic addresses to the user from a pool of addresses available to the access server. Various mechanisms are actually used to do this assignment, and they're discussed in Section 5.5 🧁.
3.5 Internal Use of Switched Virtual Circuit Services
Services such as ATM virtual circuits and switched frame relay present challenges that weren't considered in the original IP design 🤯. The basic IP decision when forwarding a packet is whether the destination is local or remote, relative to the source host's subnet. Address resolution mechanisms are used to find the medium address of the destination in the case of local destinations, or to find the medium address of the router in the case of remote ones.
In these new services, there are cases where it's far 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 advantage of cut-through in that case is that it avoids the latency of multiple router hops, and it reduces load on "backbone" routers 🏃♀️. The cut-through decision is usually made by an entry router that is aware of both the routed and switched environments.
This entry router communicates with an address resolution server using the Next Hop Resolution Protocol (NHRP) [Cansever] [Katz]. The server maps the destination network address to either a next-hop router (where cut-through isn't appropriate) or to 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 😬.
While the NHRP work was in progress at the time of this writing, commercial implementations based on drafts of the protocol standard were in use 🛠️.
4. Numbering and Renumbering ✨
What is the role of any numbering plan? To get a handle on the general problem, it's worth reviewing the basic principles of routers 🤓. While most readers will have a good intuitive sense of this, the principles have been refined in the current usage of IP.
A router receives an inbound IP datagram on one of its interfaces, and examines some number of bits of the destination address. The sequence of bits examined by the router always begins at the left of the address (i.e., the most significant bit). We call this sequence a "prefix."
Routing decisions are made on totalPrefix bits, which start at the leftmost (i.e., most significant) bit position of the IP address. Those totalPrefix bits may be completely under the control of the enterprise (e.g., if they're in the private address space). Or the enterprise may control the lowOrderPrefix bits while the highOrderPrefix bits are assigned by an outside organization 🌸.
The router looks up the prefix in its routing table (formally called a Forwarding Information Base). If the prefix is in the routing table, the router then selects an outgoing interface that will take the routed packet to the next hop IP address in the end-to-end route. If the prefix can't be found in the routing table, the router returns an ICMP Destination Unreachable message to the source address in the received datagram 🚫.
Assuming the prefix is found in the routing table, the router then transmits the datagram through the indicated outgoing interface. If multicast routing is in effect, the datagram may be copied and sent out multiple outgoing interfaces 📡.
4.1 Categorizing the topology
From the router renumbering perspective, renumbering impact is apt to be greatest in highly connected parts of "backbones," and least in "stub" parts of the routing domain that have a single route to the backbone 🌳.
Global Internet
^
|
|
Back1-------------------Back2
| |
+-----------+ +----------+
| | | |
Reg1.1------Reg1.2 Reg2.1-----Reg2.2
| | | |
| | | |
Branch Branch Branch Branch
1.1.1 to 1.2.1 to 2.1.1 to 2.2.1 to
1.1.N 1.2.N 2.1.N 2.2.NIn this drawing, assume Back1 and Back2 exchange full routes, and Back1 is also the exterior router. Regional routers (Reg) exchange full routes with one another and aggregate addresses to the backbone routers. Branch routers default to regional routers 🗺️.
From a purely topological standpoint, the higher in the hierarchy, the greater the effects of renumbering are apt to be. This is a first approximation to scoping the task, assuming addresses have been assigned systematically. Systematic address space is rarely the case in legacy networks 🥺.
4.2. Categorizing the address space ✨
Okay bestie, before you touch anything you need a full inventory of every prefix you have now and every prefix you're planning. 📋 Figure out which ones are in your network, and whether they were assigned in a neat, systematic, hierarchical way. Trust me, this step is non-negotiable 💅
+--Unaffected by renumbering [A]
|
|
+--Existing prefixes to be renumbered
| |
| |
| +----To be directly renumbered on "flag day"
| |
| |
| +----Initially to be renumbered to temporary address
|
|
+--Existing prefixes to be retired
|
|
+--Planned new prefixes
|
|
+---totalPrefix change, no length change
|
|
+---highOrderPart change only, no length change
|
|
+---lowOrderPart change only, no length change
|
|
+---highOrderPart change only, high length change
|
|
+---lowOrderPart change only, low length change
|
|
+---totalPrefix change only, changes in high and low
|
|
+---highOrderPart change only, no length changeThe dream scenario 🌸 is that every prefix is clearly "unchanged," "old," or "new." Renumbering is way easier when each "old" prefix maps to exactly one "new" prefix. Super clean, super iconic.
Unfortunately, the dream often isn't reachable 😭 Sometimes you'll have to run parts of the old and new address spaces side by side in parallel. Lowkey messy, but it happens.
Renumbering starts with prefixes and then moves on to the host numbers sitting to the right of the prefix. So to understand the scope, you need to do two things:
- Identify the prefixes (and possibly host fields) that could be affected by the renumbering operation.
- Identify the authority that controls the values of the prefix, or the part of the prefix, that's getting renumbered.
In a given enterprise, some prefixes might be under full or partial control of the enterprise, and some might be totally outside its control. Let's review how control over address space actually works 🧚
Most of the time, the most significant bits of the prefix are assigned to the enterprise by an address registry (like InterNIC, RIPE, or APNIC) or by an Internet Service Provider (ISP). Historically, when that high-order assigned part was 8, 16, or 24 bits long, people called it a "network number." Newer usage doesn't stick the assigned part to a byte boundary though. The preferred term is a "CIDR block" of a certain number of bits [RFC1518] ✨
The enterprise then extends the prefix to the right, creating "subnets." Here's the big thing to realize: routers make routing decisions based on the total prefix of interest, no matter who controls which bits 🦋 So the router really doesn't know or care where the subnet boundaries are. Iconic energy from the router, honestly 💀
Think of subnetting as creating a longer prefix. Even before CIDR, we squished multiple subnets into a single network number advertisement sent to external routers. More generally now, extending the prefix to the right is called subnetting, and collapsing it to the left is called supernetting, aggregating, or summarizing 💜 Depending on whether you're subnetting or aggregating, different prefix lengths matter at different router interfaces. Juggling, but make it aesthetic 🎀
4.3. Renumbering Scope 🌈
Prefixes might come from the private address space [RFC1918], which isn't routable on the global Internet. Since those addresses aren't routable out there, changing parts of private address space prefixes is purely an enterprise-local decision 🏠
If a prefix is totally outside the enterprise's control, it's external, and routing will barely affect it 🙈 Still, external prefixes can interact with enterprise renumbering in a few ways:
- Inadvertent alteration or deletion of external addresses as part of router reconfiguration.
- Loss of connectivity to application servers inside the enterprise, because the external client no longer knows the internal address of the server.
- DNS/BGP
- Security
Prefixes partially under enterprise control might change too. How big of a deal that is depends on whether only the externally controlled part changes, or whether part of the internally controlled part gets renumbered as well. If the length of either the high-order or low-order part changes, things get more complicated 😤
High-order-part-only renumbering is the most common one, usually when an organization switches ISPs and needs to renumber into the new provider's space. The old prefix might have been assigned to the enterprise but won't be used for global routing anymore, or it might have been assigned to the previous provider. Heads up: getting the previous prefix back may need administrative procedures, though usually the previous provider handles that part 🫶 There will often be a period where the old and new prefixes coexist.
Low-order-part-only renumbering can happen when an enterprise tweaks its internal routing structure, and those changes only touch the internal subnet structure. This is typical when you're increasing the number of available subnets (for example, for more point-to-point media) or increasing the number of hosts on a medium (for example, with more workgroup switches) 🍓
Both the high-order and low-order parts might change. This can happen when the enterprise moves to a new ISP who assigns address space from a CIDR block instead of the classful network it used before. With a different high-order prefix length, the enterprise might be forced to change its subnet structure too 👑
5. Moving toward a Renumbering-Friendly Enterprise 💖
Renumbering affects both the configuration of individual router "boxes" and the overall system of routers in a routing domain 🌸 This section is all about making your current enterprise more renumbering-friendly before any prefixes actually change. Get ready first, then pull the trigger!
Renumbering has the least impact when you need the fewest reconfiguration options 🧚 When you're planning router renumbering, keep in mind that a lot of existing configurations may contain hard-coded IP addresses that aren't even necessary, even if renumbering weren't happening. Wherever possible, part of the router renumbering effort should be swapping out mechanisms based on hard-coded addresses for more flexible ones. Glow-up era ✨
Renumbering is also generally easier when configuration changes can be made offline on appropriate servers, and then downloaded to the router, as long as the router implementation allows it 💅
5.1. Default Routes 🛣️
A well-known way to reduce how much one router has to reference other routers is to use a default route pointing to a higher-level, better-connected router. This assumes a hierarchical network design, which is generally desirable for scaling 🦋
Default routes are most appropriate for stub routers inside a routing domain, and for boundary routers that connect the domain to a single ISP 🫶
5.2. Route Summarization and CIDR 🎀
When routes need to be advertised, summarize as much as is practical 💜 Summarization works best when address prefixes were assigned in a consistent and contiguous way, which is often not the case in legacy networks 😭 Still, there's less to change when you can refer to blocks of prefixes, so it's worth it.
Not every routing mechanism supports general summarization. The interior routing mechanisms that do include RIPv2, OSPF, EIGRP, IS-IS, and systems of static routes. RIPv1 and IGRP do support classful summarization, meaning only at Class A/B/C network boundaries 🌈
If existing addresses were assigned hierarchically, it may be possible to renumber below the level of summarization while hiding the summarization from the rest of the network 🙌 In other words, if all the address bits being renumbered sit to the right of the summarized prefix length, the change can be totally transparent to the overall routing system. Invisible glow-up 🫠
Even when effective summarization can hide the routing details, DNS, filters, and other services may still be affected by any renumbering 💀 So don't get too comfy yet.
5.3. Server References in Routers 🧚♀️
Routers commonly talk to an assortment of network management and other infrastructure servers. Examples of these servers are listed in the "Network Management" section below. DNS itself, however, may be an important exception 🌸
Wherever possible, servers should be referenced by DNS name rather than by IP address 💖 If a specific router implementation only supports explicit address references, that should be documented as part of the renumbering plan 📝
Routers may also need to forward end host broadcasts to other infrastructure services, such as DNS and DHCP/BOOTP 📡 Configurations that do this are likely to contain hard-coded IP addresses of the destination hosts or their subnets, and those will need to be changed as part of renumbering. Hard-coded drama, every time 🙃
5.4. DNS and Router Renumbering 📖
The Domain Name Service is a powerful tool in any renumbering effort, and it can help routers as well as end hosts 🥰 If traceroute displays DNS names rather than IP addresses, certain debugging options can stay transparent through the address transition. Very helpful, very cute 🦋
Be aware that dynamically learned names and addresses may be cached in router tables 👀 For a router to pick up changes in address-to-name correspondence, it may be necessary to restart the router or explicitly clear the cache. Sometimes you just gotta reset 🔄
Alternatively, router configuration files may contain hard-coded address/name correspondences, and those won't be affected by a change in the DNS server 🙄
Different DNS databases get affected by renumbering in different ways. For example, the enterprise usually controls its own "forward" database, but the reverse mapping database may be maintained by its ISP. That can mean some coordination when you change providers 🤝
Router renumbering commonly goes through a transition period. During this transition, old and new addresses may coexist in the routing system. Coexistence over a significant stretch of time is especially likely for DNS references to addresses that are known across the global Internet [deGroot]. Various DNS servers around the world may cache addresses for days at a time ⏳
If, for example, a given router interface has both a coexisting new and old address, it can be appropriate to introduce the new address as an additional A record for the new address 🌷
DNS RR statements can end with a semicolon, which means the rest of the line is a comment. You can use this as the basis of tools that renumber DNS names for router addresses, by putting a comment (for example, ;newaddr) at the end of the A statements for the new addresses 🛠️ At an appropriate time, a script could generate a new zone file where the new addresses become the primary definitions on A records, and the old addresses become appropriately commented A records. Later on, those commented entries can be removed. Clean girl cleanup 🧹✨
Make sure PTR reverse mapping entries are defined for new addresses too, because some router vendor tools depend on reverse mapping 🔍 Don't skip this one, bestie, it's a whole vibe-killer if you do 💀
5.5 Dynamic Addressing ✨
okay so renumbering is easiest when addresses only need to change in the least possible number of places 💅 which is why dynamic address assignment is sooo attractive for end hosts 🦋. Routers can be a total key player here 👑. They may act as servers and actually assign addresses, or they may just be responsible for forwarding end host address assignment requests to address assignment servers 🧚.
The most common use of dynamic address assignment is giving IP addresses to end systems 💖. But it's also used to assign IP addresses to router interfaces 🎀. An address assignment server may assign an IP address to a router either in the usual DHCP way, based on a MAC address in the router, or simply based on the physical connectivity of the new router 🌈. In other words, any router connected on a specific interface of the configuring router would be assigned the same IP address 🙈.
5.5.1 Router Roles in LAN-based DHCP Address Assignment
End hosts attached to LANs often get their address assignments from BOOTP or DHCP servers 🌸. If the server isn't on the same medium as the end hosts, routers may need to play a role in setting up connectivity between the end host and the address server 💜.
If the client isn't on the same medium as the address assignment server, routers either must act as address assignment services, or forward limited broadcasts to the location of the appropriate servers 😭.
If the router acts as an address assignment server, its database of addresses that it can assign may change during renumbering 💀. If the router forwards to a DHCP or BOOTP server, it must know the address of that server. That server address can itself change as a result of renumbering 🙈.
While the usual perception of DHCP is that it assigns addresses from a pool, so that assignments to a given host at a given time are random within the pool, DHCP can also return a constant IP address for a specific MAC address 🍓. This may be much easier to manage and troubleshoot, especially during renumbering ✨.
Clearly, if the DHCP server identifies end hosts based on their MAC address, you have to think about making that address unique, and change the DHCP database if either the MAC address or the IP address changes 👀. One way to reduce that reconfiguration is to use Locally-Administered Addresses (LAA) on end hosts, rather than globally unique addresses stored in read-only memory (ROM) 🫶. Using LAAs solves the problem of MAC addresses changing when a network interface card changes, but LAAs have their own management problems, namely configuration into end systems and maintaining uniqueness within the enterprise 😩.
5.5.2 Router Roles in Dialup Address Assignment
There are several possible ways a dialup end host can interact with address assignment 📞. Routers and access servers can play critical roles in this process, either by providing connectivity between the client and server, or by directly assigning addresses 💫.
Different vendors handle address assignment in different ways 🏳️🌈. The methods include:
- The access server forwards the request to a DHCP server, using a unique 48-bit identifier associated with the client. Note that this usually should not be the MAC address of the access server, since the same MAC address would then be associated with different hosts 🙅♀️.
- The server forwards the request to an authentication server, which in turn gets a dynamic address either from: a. internal pools b. a DHCP server to which it forwards
- The server selects an address from locally configured pools and provides it to the dialing host without the intervention of other services 🦄.
When the router contains assignable addresses, these may need to change as part of renumbering 🔄. Alternatively, hard-coded references to address assignment or authentication servers may need to change 😤.
5.5.3 Router Autoonfiguration
This initial address assignment may provide an address only for a single connection (i.e., between the new and configuring routers) 🔌. The newly assigned address may then be used to "bootstrap" a full configuration into the new router 🥾.
Dynamic address assignment to routers is probably most common at outlying "stub" or "edge" routers that connect via WAN links to a central location with a configuration server 🛰️. Such edge devices may be shipped to a remote site, plugged into a WAN line, and use proprietary methods to acquire part or all of their address configuration 📦.
When this kind of autoconfiguration is used on edge routers, it may be necessary to force a restart of the edge router after renumbering 🔁. Restarting may be the only way to force the autoconfigured router to learn its new address 🙃. Other out-of-band methods may be available to change the edge router addresses 🧃.
5.6 Network Address Translation
Network address translation (NAT) is a valuable technique for renumbering, or even for avoiding the need to renumber significant parts of an enterprise [RFC1631] 🎀. It isn't always transparent to network layer protocols, upper layer protocols, and network management tools, and it must not be regarded as a panacea 🙅♀️. Not a magic fix, bestie!
In the classic definition of NAT, certain parts of the routing system are designated as stub domains, and they connect to the global domain only through NAT functions 🧱. The NAT contains a translation mechanism that maps a stub address to a global address 🗺️. This mechanism may map statically or dynamically ⚡.
A more general NAT mechanism is often implemented in firewall bastion hosts, which isolate "inside" and "outside" addresses through transport- or application-level authenticated gateways 🏰. Mappings from a "local" or "inside" address to a global address often aren't one-to-one, because an inside address is dynamically mapped to a TCP or UDP port on an outside interface address 🌐.
In general, if there are multiple NATs, their translation mechanisms should be synchronized 🔗. There are specialized cases when a given stub address appears in more than one stub domain, and ambiguity develops if you want to map, say, from 10.1.0.1/16 in stub domain A to 10.1.0.1/16 in stub domain B 😵💫. In this case, both 10.1.0.1 addresses identify different hosts. Special mechanisms would have to exist to map the domain A local address into one global address, and to map the domain B local address into a different global address 🫠.
NAT can have a valuable role in renumbering 💖. Its intelligent use can greatly minimize the amount of renumbering that needs to be done ✨. NAT, however, is not completely transparent 👀.
Specifically, it can interfere with the proper operation of any protocol that carries an IP address as data, since NAT does not understand passenger fields and is unaware that numbers need to change 🚫.
Examples of protocols affected are:
- TCP and UDP checksums that are in part based on the IP header. This includes end-to-end encryption schemes that include the TCP/UDP checksum 🔐
- ICMP messages containing IP addresses 📨
- DNS queries that return addresses or send addresses 🔍
- FTP interactions that use an ASCII-encoded IP address as part of the PORT command 📂
It may be possible to avoid conflict if only certain hosts use affected protocols 🙌. Such hosts could be assigned only global addresses, if the network topology and routing plan permit 🗺️.
Early NAT experiments suggested that NAT needs a sparse end-to-end traffic mapping database for reasonable performance 📉. This may or may not be an issue in more hardware-based NAT implementations 🔧.
Another concern with NAT is that unique host addresses are hidden outside the local stub domains 🕵️♀️. This may in fact be desirable for security, but it may present network management problems 😬. One possibility would be to develop a NAT MIB that could be queried by SNMP to find the specific local-to-global mappings in effect 🔎.
There are also issues for DNS, DHCP, and other address management services 📚. There presumably would need to be local servers within stub domains, so that address requests would be resolved uniquely in each stub (or would return appropriate global addresses) 🧚♀️.
6. Potential Pitfalls in Router Renumbering ⚠️
One way to categorize potential pitfalls is to look at those associated with the overall numbering plan itself and routing advertisement, and those associated with protocol behavior 🧐. In general, the former case is static and the latter is dynamic 🌀.
6.1 Static
Problems can be implicit to the address/routing structure itself 🏗️. These can include failures of components to understand arbitrary prefix addressing (i.e., classless routing), reachability due to inappropriate default or aggregated routes, and so on 🙃.
6.1.1 Classless Routing Considerations
Among the major reasons to renumber is to gain globally routable address space 🌍. In the global Internet, routable address space is based on arbitrary-length prefixes rather than traditional address classes 🍰. Classless Inter-Domain Routing (CIDR) is the administrative realization of prefix addressing in the global Internet 👑. Inside enterprises, arbitrary prefix length addressing is often called Variable Length Subnet Masking (VLSM) or "subnetting a subnet" 🪆.
The general rules of prefix addressing must be followed in CIDR 📏. Among these are permitting use of the all-zeroes and all-one subnets [RFC1812], and not assuming that a route to a "Class A/B/C network number" implies routes to all subnets of that network 🙅♀️. Assumptions also should not be made that a prefix length is implied by the structure of the high-order bits of the IP address (i.e., the "First Octet Rule") 🚫.
This ideal, unfortunately, is not understood by a significant number of routers (and terminal access servers that participate in routing), and an even more significant number of host IP implementations 😭.
When planning renumbering, network designers must know whether the new address has been allocated using CIDR rules rather than traditional classful addressing 🧠. If CIDR rules have been followed in address assignment, then steps need to be taken to make sure the router understands them, or appropriate steps need to be taken to interface the existing environment to the CIDR environment 🔀.
Current experience suggests that it is best, when renumbering, to maintain future compatibility by moving to a CIDR-supportive routing environment 🚀. While this is usually thought to mean introducing a classless dynamic routing protocol, it need not mean that routing becomes much more complex 😌. In a RIPv1 environment, moving to RIPv2 may be a relatively simple change 🎉. Alternative simple methods include establishing a default route from a non-CIDR-compliant routing domain to a CIDR-compliant service provider, or making use of static routes that are CIDR-compliant 🛣️.
Some routers support classless routing without further configuration, other routers support classless routing but require specific configuration steps to enable it, and other routers only understand classful routing 🤓. In general, most renumbering will eventually require classless routing support 💅. It is essential to know whether a given router can support classless routing 🔍. If it can't, workarounds may be possible 🛠️. Workarounds are likely to be necessary 😮💨.
6.1.1.1. Aggregation Problems
Okay so, experimenting with CIDR on a former Class A network number showed in RFC1879 that CIDR compliance rules have to be enabled explicitly in some routers, while other routers just don't understand CIDR rules at all. 😭
RFC 1897 showed the same kind of trouble with some existing equipment, especially "equipment that depends on use of a classful routing protocol, such as RIPv1 are prone to misconfiguration. Tested examples are current Ascend and Livingston gear, which continue to use RIPv1 as the default/only routing protocol. RIPv1 use will create an aggregate announcement.... The Ascend was told to announce 39.1.28/24, but since RIPv1 can't do this, the Ascend instead sent 39/8." Yikes, bestie. 💀 RIPv1, like all classful interior protocols, is obsolescent. 🦋
6.1.1.2. Discontiguous Networks
Another problem shows up with routers or routing mechanisms that don't understand arbitrary length prefix addressing: discontiguous networks. ✨ It's super easy to cause this by accident when you're renumbering. In the example below, the enterprise has been using 10.0.0.0/8 as its primary prefix, but it has also brought in an ISP whose registered addresses were in 172.31.0.0/16. 🌸
Let's say we have a RIPv1 system of three routers:
10.1.0.1/16 10.2.0.1/16
| |
| |
+-------------------------------------+
| Router 1 |
+-------------------------------------+
| 172.31.1.1/24
|
|
| 172.31.1.2/24
+-------------------------------------+
| Router 2 |<------OUTSIDE
+-------------------------------------+
| 172.31.2.1/24
|
|
| 172.31.2.2/24
+-------------------------------------+
| Router 3 |
+-------------------------------------+
| |
| |
10.3.0.1/16 10.4.0.1/16Router 1 can reach its two locally connected subnets, 10.1.0.0/16 and 10.2.0.0/16. 🎀 It aggregates them into one single announcement of 10.0.0.0/8 when it advertises out the 172.31.1.1 interface.
Router 3 is doing the same thing. It can reach its two locally connected subnets, 0.3.0.0/16 and 10.4.0.0/16 (the spec writes it as 0.3.0.0/16, so that's what we're keeping 🙈). It aggregates them into a single announcement of 10.0.0.0/8 when it advertises out the 172.31.2.2 interface.
Now here's the tea. ☕ When Router 2 gets a packet from its "outside" interface destined for, say, 10.1.1.56/16, where does it send it? Router 2 has received two advertisements of 10.0.0.0 on different interfaces, and there's no detail about the subnets inside 10.0.0.0. So its routing table is ambiguous about the next hop to any subnet of 10.0.0.0. We call this problem, when parts of the same classful network are separated by different networks, discontigous subnets. 🧩
Two problems pop up in this setup. First, Router 2 doesn't know where to send outside packets destined for a subnet of 10.0.0.0. Second, connectivity between Routers 1 and 3 breaks too, because Router 2 doesn't know the next hop for any subnet of 10.0.0.0. Not ideal, bestie. 😩
There are a few workarounds. Obviously, one option is to switch to a routing mechanism that advertises subnets. ✨ Another is to set up an IP-over-IP tunnel through Router 2 and give it a subnet in 10.0.0.0. That extra subnet would only be visible in Routers 1 and 3. It would fix the connectivity problem between Routers 1 and 3, but Router 2 still wouldn't be able to forward outside packets. This could be a perfectly fine solution if Router 2 is just being used to connect two parts of 10.0.0.0. 💖
Another way to handle the discontiguous network problem is to assign secondary addresses in 10.0.0.0 to the R1-R2 and R2-R3 interfaces. That lets the 10.0.0.0 subnets get advertised to R2. This works as long as there isn't a problem advertising the 10.0.0.0 subnets into the R2 routing system. For example, there would be a problem if the 10.0.0.0 address were in the private address space but the R2 primary addresses were registered, and R2 advertised the 10.0.0.0 addresses to the outside. 👀
This can be handled if R2 has filtering mechanisms that can selectively block 10.0.0.0 advertisements to the outside world. The configuration, though, gets more and more complicated. 🥲
6.1.1.3. Router-Host Interactions
The situation might not be as bleak if hosts don't understand prefix addressing but routers do. 🌈 There are ways to hide a VLSM structure from end hosts that don't understand it. These do involve protocol mechanisms as workarounds, but the fundamental problem is the hosts' understanding of arbitrary prefix lengths.
A key mechanism is proxy ARP [Carpenter]. The basic idea behind using proxy ARP in prefix-based renumbering is that the hosts issue an ARP whenever they want to talk to a destination. If the destination is actually on the same subnet, it responds directly to the ARP. If the destination isn't, the router responds as if it were the destination, and the originating host sends the datagram to the router. Once the datagram is in the router, the VLSM-aware router can forward it. 🧚
Many end hosts, however, will only issue an ARP if they conclude the destination is on their own subnet. All other traffic goes to a hard-coded default router address. In those cases, workarounds may be needed to force the host to ARP for all destinations. 😤
One workaround involves a deliberate misconfiguration of hosts. Hosts that only understand default routers are also apt to understand only classful addressing. If the host is told its major (i.e., classful) network is not subnetted, even though the address plan actually is subnetted, this will often persuade it to ARP to all destinations. Sneaky, right? 🙈
This also works for hosts that don't understand subnetting at all. An example will cover both levels of host understanding. Let's say the enterprise uses 172.31.0.0/16 as its major address, which is in the Class B format. It's actually subnetted with eight bits of subnetting -- 172.31.0.0/24. Individual hosts that are unaware of VLSM either infer Class B from the address value, or they're told that the subnet mask in effect is 255.255.0.0. 🍓
Another approach that helps hosts find routers is to run passive RIP on the hosts, so they hear routing updates. They assume any host that issues routing updates must be a router, so traffic for non-local destinations can be forwarded there. RIPv1 doesn't support arbitrary prefixes, but the router(s) issuing the routing updates may have additional capabilities that let them forward that traffic correctly. So the priority is getting the non-local routers to a router that understands the overall routing structure, and passive RIP may be a viable way to do that. 💜
It may be appropriate to cut over on a site-by-site basis [Lear]. In that approach, some sites have VLSM-aware hosts but others don't. As long as the routing structure supports VLSM, workarounds can be applied where needed. 🫶
6.1.2. MAC Address Interactions
It's uncommon now for a router to acquire any of its interface addresses as a DHCP client, but this may become more common. When a router does acquire addresses that way, care must be taken that the MAC address presented to the DHCP server is in fact unique. 🔥
Modern routers usually support protocol architectures besides IP. Some of these architectures, notably DECnet, Banyan VINES, Xerox Network Services, and IPX, may modify MAC addresses of routers such that a given MAC address appears on more than one interface. While this is normally not a problem, it could cause difficulties when the MAC address is assumed to be unique. 😬
Other situations happen where the same MAC address can appear on more than one interface. For example, there are high-availability IBM options that establish primary and backup instances of the same MAC address on different physical interfaces of 37x5 communications controllers. 🖥️
Some end hosts running protocol stacks other than IP, notably DECnet, may change their MAC address from the globally assigned built-in address. 🌸
6.2. Dynamic ✨
Dynamic protocol mechanisms that depend to some extent on IP addresses may be affected by router renumbering. These include mechanisms that assign or resolve addresses (e.g., DHCP, DNS), mechanisms that use IP addresses for identification (e.g., SNMP), security and authentication mechanisms, and so on. The listed mechanisms are apt to have configuration files that will be affected by renumbering. 📂
Another area of dynamic behavior that can be affected is caching. Application servers, directory functions such as DNS, and so on, may cache IP addresses. When the router is renumbered, these servers may point to old addresses. Certain proxy server functions may reside on routers, and the router may need to be restarted to reset the cache. 🔄
The endpoints of TCP tunnels terminating on routers may be internally identified by address/port pairs at each end. If the address changes, even if the port stays the same, the tunnel is likely to need to be reestablished. 🦋
7. Tools and Methods for Renumbering 🧰
The function of a renumbering tool can be realized either as manual procedures or as software. This section deals with the functionality of hypothetical yet general renumbering tools rather than their implementation. 💅
General caveat: tools should know whether the environment supports classless addressing. If it does not, newly generated addresses should be checked to see that they don't fall into the all-zeroes or all-ones subnet values. ⚠️
7.1. Search Mechanisms 🔍
Tools will be needed to search configuration files and other databases to identify addresses and names that will be affected by reorganization. This search should be based on the address inventory described above. 📋
Especially when searching for names, common search tools using regular expressions (e.g., grep) may be very useful. Some additional search tools may be needed. One would convert dotted decimal search arguments to binary and only then make the comparison. 🧮
The comparison may need to be done under the constraint of a mask. Such a comparator would also be relevant as the second phase that looks for ipAddress and other relevant strings in MIBs. Main character energy for sure. 👑
7.2 Address Modification ✨
Okay bestie, the general move for address modification is swapping out any number of bits in an address 🦋. In the simplest cases, every old bit position lines up one-to-one with a new one, so it's giving easy 💖.
Heads up though: when you're doing this by hand, the bits you're changing can totally hide behind dotted decimal 🙈. So work in binary, or at least think in binary, to keep things accurate 💅.
Two basic functions to know:
zerobits(position,length):
clear <length> bits starting at <position>
orbits(position,length,newbits)
OR the bit string <newbits> of <length> starting at <position>In these examples, the index [j] points to entries in the address inventory database for existing addresses, and [k] points to the new addresses 📝.
Remember that these tools work at the bit level 🔬. That means the new address has to get converted back into dotted decimal, MIB ASN.1, or whatever notation you're using before it can go into your configuration files. Don't skip this step, periodt!
7.2.1 Prefix Change, No Change in Length
If the entire new prefix has the same number of bits as the old external part, and you don't need to change any subnetting, the router side of renumbering is pretty simple 🌸. If your router configs are in machine-readable form, like text files or parsable SNMP data, you can make a tool that scans the IP addresses in the config, finds the ones starting with the old prefix, and swaps in the new prefix bit by bit. Easy slay 👑.
for each address[j],
zerobits(0,PrefixLength[j])
orbits(0,PrefixLength[j],NewPrefix[j])The host part isn't touched at all 🫶. Both subnet specifications (like the ones in route advertisements) and specific host references get changed correctly in this simple case ✨.
7.2.2 highOrderPart change
Things get a little spicier when the change only applies to the externally controlled part of the prefix 🌈. This can happen when an organization switches ISPs and renumbers into the ISP's address space, but keeps its internal subnet structure the same.
The process is basically the same as the previous case, except only the high-order bits change:
for each address,
zerobits(0,highOrderPartLength[j])
orbits(0,highOrderPartLength,newHighOrderPart[k])7.2.3 lowOrderPart change
Sometimes organizations only renumber the lowOrderPart (aka the subnet field) of their address space 🧚. A reason to do this is to clean up the address space into contiguous blocks before bringing in a routing system that aggregates addresses, such as OSPF.
for each address[j],
zerobits(highOrderPartLength[j],lowOrderPartLength[j])
orbits(highOrderPartLength[j],
lowOrderPartLength[j],newLowOrderPart[k])7.2.4 lowOrderPart change, Change in lowOrderPart length
When the length of the subnet field changes in all or part of the address space, things get significantly more complex 😭. A fairly simple case shows up when the host field is consistently too long, at least in the affected subnets. This is common when address space is being reclaimed from an existing Class B network with 8 bits of subnetting. For example, certain /24 prefixes get extended to /30 and reallocated to point-to-point real or virtual (e.g., DLCI) media 🍓.
for each address [j]
if address is affected by renumbering
if newLowOrderPartLength[k] > oldLowOrderPartLength[j]
then
zerobits(highOrderPartLength[k],newLowOrderPartLength[k])
orbits(highOrderPartLength[k],newLowOrderPart[k])
end7.2.5 highOrderPart change, Change in highOrderPart length
When the length of the high-order part changes but you still want to keep the existing subnet structure, there are constraints 🚧. If the new high-order part is shorter than the existing one, the situation is fairly simple.
If the new high-order part is longer than the old high-order part, the constraints get more complex 💀. The key is to check whether any of the <k> most significant bits of the oldHighOrderPart, which overlap the <k> least significant bits of the newHighOrderPart, are nonzero. If none of those bits are nonzero, it may be simple to just overlay the new prefix bits 🎀.
7.3 Naming
It's worth noticing that a router using a DNS name doesn't necessarily mean that name is defined in a name server 👀. Routers often hold static address-to-name mappings locally, so you need to check both the DNS zone files and the router configurations 🔍.
First, generate a list of name/address mappings. For each one, record the mapping mechanism (like a static entry in a configuration file, an RR in your zone's DNS, or an RR in a zone file outside yours), the definition statement (or the equivalent if the routers are configured with SNMP), and the current IP address 📋. Then compare the addresses in this list with the list you made earlier of prefixes affected by renumbering. Wherever the two lists intersect is where you need to make changes 💜.
Note that the explicit definition statement, or at least its variables, should be kept 🫶. In the real world, static IP address mappings in hosts often aren't maintained as systematically as RR records in a DNS server 😤. It's totally possible for different host mapping entries for the same name to point to different addresses, so keep an eye out!
7.3.1 DNS Tools
The DNS can both slow down and speed up router renumbering 🐢⚡. Caches in DNS servers, both inside and outside the organization, may be persistent enough that a "flag day" cutover isn't practical if you want to keep worldwide connectivity. That said, DNS can help make a period where old and new addresses coexist work 🫶.
For example, if a given router interface has both a new and an old address during the transition, it can be appropriate to introduce the new address as a CNAME alias for the new address 🌷.
DNS RR statements can end with a semicolon, which marks the rest of the line as a comment 💬. You can use this to build tools that renumber DNS names for router addresses, by putting a comment (e.g., ";newaddr") at the end of the CNAME statements for the new addresses 🧠. At an appropriate time, a script could generate a new zone file where the new addresses become the primary definitions on A records, and the old addresses become appropriately commented CNAME records. Later on, those commented CNAME entries can be removed 🧹.
Make sure PTR reverse mapping entries are defined for the new addresses too, because some router vendor tools depend on reverse mapping 🔁. Don't get caught without them!
7.3.2 Related name tools
Especially on UNIX and other systems that do routing, there may be static name definitions 🐧. These are probably harder to keep maintained than DNS entries, simply because they're spread out more widely 😩.
Several tools can generate more maintainable entries 🛠️. A perl script called h2n converts host tables into zone data files that can be added to the DNS server. It's available at ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z. Another tool, makezones, is part of the current BIND distribution, and it can also be obtained from ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones.
For more, check out the DNS Resources Directory at http://www.dns.net/dnsrd 📚.
8. Router Identifiers ✨
Configuration commands in this category assign IP addresses to physical or virtual interfaces on a single router 🧩. They also include commands that assign IP-address-related information to the router "box" itself, plus commands that involve the router's interaction with neighbors below the full routing level (e.g., default gateways, ARP).
Routers may have other unique identifiers too, like DNS names used for the set of addresses on the "box," or SNMP systemID strings 🏷️.
8.1. Global Router Identification
Traditional IP routers don't have unique identifiers 🙅. Instead, they're treated as collections of IP addresses tied to their interfaces. Some protocol mechanisms, notably OSPF and BGP, need an address for the router itself, typically to set up tunnel endpoints between peer routers 🚇. Another use is "unnumbered interfaces," which conserve address space for serial media (more on that practice below) 🦋.
In the illustration below, the 10.1.0.0/16 address space is used for global identifiers 🌈. A TCP tunnel runs from 10.1.0.1 to 10.1.0.2, but its traffic is load-shared across the two real links, 172.31.1.0 and 172.31.2.0 🫶.
172.31.4.1/24 172.31.5.1/24
| |
| |
+-------------------------------------+
| Router 1 |
| |
| 10.1.0.1/16 |
| # |
+-------------------#-----------------+
| 172.31.1.1/24 # | 172.31.2.1/24
| # |
| # |
| # |
| # |
| # |
| # |
| 172.31.1.2/24 # | 172.31.2.2/24
+-------------------#-----------------+
| Router 2 |
| |
| 10.1.0.2/16 |
| |
+-------------------------------------+
| |
| |
172.31.5.1/24 172.31.6.1/24A common practice is to use the "highest IP address" on the router as its identifier for the "box" 🏆. Many implementations have a default mechanism for establishing the router ID, which may be the highest configured address or the highest active address 🤓.
Typical applications of a global router ID don't need it to be a "real" IP address that gets advertised through the routing domain 🙌. It can simply be a 32-bit identifier local to each router. When that's the case, the identifier can come from the RFC 1918 private address space rather than the enterprise's registered address space 🔒.
Letting the router ID be selected by default can be unstable, and it is not recommended 🚨. Most implementations have a way to declare a pseudo-IP address for the router itself, as opposed to any of its ports.
Changes to this pseudo-address may have implications for DNS 🌐. Even if it isn't a real address, A and PTR resource records may have been set up for it, so diagnostics can display names rather than addresses 📛.
Another potential DNS implication: a CNAME may have been set up for the entire set of interface addresses on a router 🎀. This lets you test, telnet, and so on to the router via any reachable path 💖.
8.2 Interface Address ✨
okay so interface addresses are literally the most basic place to start router renumbering 💅 the interface config needs an IP address and usually a subnet mask or prefix length too. some implementations don't have a mask in the existing config because they use a "default mask" based on a classful assumption about the address 🙈 so be aware you might need to explicitly specify a subnet mask or other prefix length when none was specified before. this is gonna be super common on older host-based routers, bestie 💀
multiple IP addresses in different subnets can be assigned to the same interface 🫶 this is often a valuable technique in renumbering, because the router interface can be configured to respond to both the new and old addresses. iconic move 👑
BUT caution is necessary when you use multiple subnet addresses on the same interface 😭 OSPF and IS-IS implementations may not advertise the additional addresses, or they may constrain their advertisement so all of them must be in the same area. not me being nervous about area boundaries 🥺
when you use this method to make the interface respond to new and old addresses, and the renumbering process is complete, care must be taken in removing the old addresses 🌸 some router implementations have special meaning to the order of address declarations on an interface, so the order matters, fr fr. it is highly likely that routers, or at least the interface, must be restarted after an address is removed. so plan for a little downtime energy ✨
8.3 Unnumbered Interfaces 🦋
okay so as mentioned before, several conventions have been used to avoid wasting subnet space on serial links 🍓 one mechanism is to implement proprietary "half-router" schemes, where the unnumbered link between router pairs is treated as an "internal bus" creating a "virtual router." so the scope of the unnumbered interface is limited to the pair of routers. it's giving secret agent vibes 🕵️♀️
here's the picture, bestie 👇
| +------------+ +------------+ |
| | | | | |
| e0 | |s0 s0 | | |
|-------------| R1 |................| R2 |-------|
| 192.168.1.1 | 10.1.0.1/16| | 10.1.0.2/16| |
| /24 | | | | |
| +------------+ +------------+in the example above, the software in routers R1 and R2 automatically forwards every packet received on serial interface S0 to Ethernet interface E0 🔥 and they forward every packet on e0 to their local S0. neither S0 has an IP address. R1 has the router ID 10.1.0.1/16 and R2 has 10.1.0.2/16. the vibes are a lil chaotic but it works 🌈
it is thus impossible to send a specific ping to the S0 interfaces, which makes it difficult to test whether a connectivity problem is due to S0 or E0 😩 some management is possible as long as at least one IP address on the router (e.g., E0) is reachable, since this will permit SNMP connectivity to the router. once the router is reachable with SNMP, the unnumbered interface can be queried through the MIB ifTable 🧚
another approach is to use the global router identifier as a pseudo-address for every unnumbered interface on a router 💜 in the example above, R1 would use 10.1.0.1 as its identifier. this gives you an address to use for stuff like the IP Route Recording option, and for providing a next-hop-address for routes. super useful, no cap ✨
the second approach is cleaner, but it can still create operational difficulties 🙃 if there are multiple unnumbered interfaces on a router, which one (if any) should/will respond to a ping? and other network management mechanisms don't work cleanly with unnumbered interfaces. the drama is real 💀
as part of a renumbering effort, the need for unnumbered interfaces should be examined 🎀 if the renumbering process moves the domain to classless addressing, then serial links can be given addresses with a /30 prefix, which wastes a minimum of address space. bestie, that's a glow-up 💖
for dedicated or virtual dedicated point-to-point links within an organization, another alternative to unnumbered operation is using RFC1918 private address space 🌿 inter-router links rarely need to be accessed from the Internet unless they're explicitly used for exterior routing. external traceroutes will also fail reverse DNS lookup, so just know that going in 🫠
if unnumbered interfaces are kept and the router-ID convention is used, it will probably be more stable to rely on an explicitly configured router ID rather than a default from a numbered interface address 💅 the main character move is being explicit, periodt.
the situation gets even more awkward if you want to use unnumbered interfaces over NBMA services such as Frame Relay 😵💫 OSPF, for example, uses the IP address of numbered interfaces as a unique identifier for that interface. since unnumbered interfaces don't have their own unique address, OSPF has not obvious way to identify these interfaces. a physical index (e.g., ifTable) could be used, but it would have to be extended to have an entry for each logical entry (i.e., VC) multiplexed onto the physical interface. so many layers, not me getting dizzy 🌀
8.4 Address Resolution 🌷
while mapping IP addresses to LAN MAC addresses is usually done automatically by the router software, there will be cases where special mappings are needed 🫶 for example, the MAC address used by router interfaces may be locally administered (i.e., set manually), rather than relying on the burnt-in hardware address. it may also be part of a proprietary method that dynamically assigns MAC addresses to interfaces. in cases like that, an IP address may be part of the MAC address configuration statements and will need to be changed, lowkey annoying but manageable 🧁
manual mapping to medium addresses will usually be needed for NBMA and switched media 💜 when you renumber IP addresses, statements that map the IP address to Frame Relay DLCIs, X.121 addresses, SMDS and ATM addresses, telephone numbers, etc. will need to be changed to the new address. local requirements may call for a period of parallel operation, where the old and new IP addresses map to the same medium address. think of it as a little overlap era 🦋
8.5 Broadcast Handling 📢
RFC1812 specifies that router interfaces MUST NOT forward limited broadcasts (i.e., to the all-ones destination address, 255.255.255.255) 🚫 it's super common, though, to have situations where a LAN segment is only populated by clients that talk to key servers (e.g., DNS or DHCP) by sending limited broadcasts. router interfaces can cope with this by translating the limited broadcast address to a directed broadcast address or a specific host address, which is legit to forward. the workaround is giving main character energy 🎭
when limited address translation is done for serverless segments and the new target address gets renumbered, the translation rule must be reconfigured on every interface to a serverless segment 😤 be sure to recognize that a given segment might have a server from the perspective of one service (e.g., DHCP), but could be serverless for other services (e.g., NFS or DNS). so don't assume one server means all services are covered, iykyk 🙈
8.6 Dynamic Addressing Support 🌈
routers can participate in dynamic addressing with RARP, DHCP, BOOTP, or PPP 💫 in a renumbering effort, several kinds of changes may need to be made on routers participating in dynamic addressing 🛠️
if the router acts as a server for dynamic address assignment, the addresses it assigns will need to be renumbered 🍰 these might be specific addresses associated with MAC addresses or dialup ports, or they could be a pool of addresses. pools of addresses may be seen in pure IP environments, or in multiprotocol situations such as Apple MacIP. it's giving a whole family of configs 🎀
if the router does not assign addresses, it may be responsible for forwarding address assignment requests to the appropriate server(s) 🧚♀️ if that's the case, there may be hard-coded references to the IP addresses of those servers, and those may need to be changed as part of renumbering. hard-coded stuff is so sneaky, bestie 😭
9. Filtering and Access Control 🛡️
routers may implement mechanisms to filter packets based on criteria other than next hop destination 🔍 these mechanisms are often implemented differently for unicast packets (the most common case) or for multicast packets (including routing updates). filtering rules may contain source and/or destination IP addresses that will need to change as part of a renumbering effort, so keep an eye on them 👀
filtering can be done to implement security policies or to control traffic 🔐 in either case, extreme care must be taken in changing the rules, to avoid leakage of sensitive information. denial of access to legitimate users, or network congestion. this part is seriously high stakes, no cap 😱
routers may implement logging of filtering events, typically denial of access 📝 if logging is implemented, logging servers to which log events are sent preferably should be identified by DNS name 🌟 if the logging server is referenced by IP address, its address may need to change during renumbering. care should be taken that critical auditing data is not lost during the address change. protect the receipts, periodt 💅
9.1 Static Access Control Mechanisms 🧱
router filters typically contain some number of include/exclude rules that define which packets to include in forwarding and which to exclude 🎯 these rules typically contain an address argument and some indication of the prefix length. that length indication could be a count, a subnet mask, or some other mask. basically, the rules are the bouncers of the network 🚪
when renumbering, the address argument clearly has to change 🙌 it can be more subtle if the prefix length changes, because the length specification in the rule must change as well. needs for such changes may be hard to recognize, because they apply to ranges of addresses that might sit at a level of aggregation above the explicit renumbering operation. sneaky, sneaky 🥷
RFC 1812 requires that address-based filtering allow arbitrary prefix lengths, but some hosts and routers might only allow classful prefixes 🫣 so double-check what your gear actually supports before you assume anything, bestie ✨
9.2. Special Firewall Considerations ✨
Okay bestie, firewalls are a whole vibe and routers are the main characters 🔥 Architecturally, firewall models describe two router functions: the external screening router between the outside and the "demilitarized zone (DMZ)," and the internal screening router between the inside and the "perimeter network." Chilling between those two networks is the bastion host 🏰, which holds various non-routing isolation and authentication functions. Those are beyond the scope of this doc, so we're not diving in today 💅
One relevant thing about the bastion host, though: it may do address translation or higher-layer mappings between different address spaces. If the "outside" address space (aka what's visible to the Internet) changes, the outside screening router will need configuration changes 😭 And since that outside screening router may be controlled by the ISP instead of the enterprise, admin coordination is needed. It's giving group project 🫶
DMZ +--------+ Peri-
|---| Public | meter
+-----------+ | | Hosts | | +-----------+
From | External | | +--------+ |---| Internal |
Internet...| Screening |---| +--------+ | | Screening |
| Router | |---| Bastion|------| | Router |....To
+-----------+ | | Host | | +-----------+ Internal
| +--------+ | +-----------+ Network
| +--------+ |---| Dialup |
|---| Split | | | Access |
| | DNS | | | Server |
| +--------+ | +-----------+External screening routers typically have inbound access lists that block unauthorized traffic from the Internet, and outbound access lists that only permit access to DMZ servers and the bastion host 🛡️ The inbound filters commonly block the Private Address Space, along with address space from the enterprise's internal network. If the internal network address changes, the inbound filters clearly will need to change too 🙈
If DMZ host addresses change, the matching outbound filters on the external screening router also will need to change. Internal screening routers permit access from the internal network to selected servers on the perimeter network, as well as to the bastion host itself. If the enterprise uses private address space internally, renumbering may not affect this router, which is lowkey a win 🦋
Another firewall piece is the "split DNS" server, which provides address mapping in relation to the globally visible parts of the
9.3. Dynamic Access Control Mechanisms 🎀
Certain access control services, like RADIUS and TACACS+, may insert dynamically assigned access rules into router configurations. For example, a RADIUS database "contains a list of requirements which must be met to allow access for the user. This always includes verification of the password, but can also specify the client(s) or port(s) to which the user is allowed access. [Rigney]."
Configuration information dynamically communicated to the router may be in the form of filtering rules. Basically, this authentication database becomes an extension of the router configuration database 🧚 Both of these databases may need to change as part of a renumbering effort.
Another dynamic configuration issue shows up when "stateful packet screening" on bastion hosts or routers is used to provide security for UDP-based services, or just for IP. In these services, when an authorized packet leaves the local environment to go into an untrusted address space, a temporary filtering rule gets set up on the interface where the response to that packet is expected. The rule typically has a lifetime of a single packet response ⏳ If these rules live in a database outside of the router, the rule database is again an extension of router configuration that must be part of the renumbering effort 💜
10. Interior Routing 🌸
This section is all about routing inside an enterprise, which generally follows these rules, ignoring default routes:
- Does a single potential route exist to a destination? If so, use it.
- Is there more than one potential path to a destination? If so, use the path with the lowest end-to-end metric.
- Are there multiple paths with equal lowest cost to the destination? If so, consider load balancing.
Most enterprises don't directly participate in global Internet routing mechanisms, the details of which are more of a concern to their service providers. The next section deals with those more complex exterior mechanisms 👑
10.1. Static Routes
During renumbering, the destination and/or next hop address of static routes may need to change. It may be necessary to restart routers or explicitly clear a routing table entry to force the changed static route to take effect 🔄
10.2. RIP (Version 1 unless otherwise specified)
The Routing Information Protocol (RIP) has been around forever, as one of the first interior routing protocols 🦖 It still does that job in small networks, and it has also been used for assorted functions that aren't strictly part of interior routing. In this discussion, we'll first deal with pure interior routing applications.
In a renumbering effort that involves classless addressing, RIPv1 may not be able to cope with the new addressing scheme. Officially, this protocol is Historic and should be avoided in new routing plans. Where legacy support requirements dictate it be kept, it's worth trying to limit RIPv1 to "stub" parts of the network. Vendor-specific mechanisms may be available to interface RIPv1 with a classless environment 💀
As part of planning renumbering, strong consideration should be given to moving to RIPv2, OSPF, or other classless routing protocols as the primary means of interior routing. Doing so, however, may not remove the need to run RIP in certain parts of the enterprise.
RIP is widely implemented on hosts, where it may be used as a method of router discovery, or for load-balancing and fault tolerance when multiple routers are on a subnet 🍓 In these applications, RIP need not be the only routing protocol in the domain, and RIP may be present only on stub subnets. Destination information from more capable routing protocols may be translated into RIP updates. While it's generally reasonable to minimize or remove RIP as part of a renumbering effort, be careful not to disable the ability of hosts to locate routers ⚠️
RIP is also used as a quasi-exterior routing mechanism between some customers and their ISPs, as a means simpler than BGP for the customer to announce routes to the provider 🌈
10.3. OSPF
OSPF has several sensitivities to renumbering beyond those of simpler routing protocols. If router IDs are assigned to be part of the registered address space, they may need to be changed as part of the renumbering effort. It may be appropriate to use RFC 1918 private address space for router IDs, as long as these can be looked up in a DNS server within the domain 🔍
Summarization rules are likely to be affected by renumbering, especially if area boundaries change.
Special addressing techniques, like unnumbered interfaces and physical interfaces with IP addresses in multiple subnets, may not be transparent to OSPF. Care should be exercised in their use, and their use definitely should be limited to intra-area scope 🙃
If part of the renumbering motivation is the introduction of NBMA services, there can be numerous impacts on OSPF. Generally, the best way to minimize impact is to use separate subnets for each VC. By doing so, different OSPF costs can be assigned to different VCs, and designated router configuration isn't needed, etc. ✨
10.4. IS-IS
IP prefixes are usually associated with IS-IS area definitions. If IP prefixes change, there may be a corresponding change in area definitions 🗺️
10.5. IGRP and Enhanced IGRP
When a change from IGRP to enhanced IGRP is part of a renumbering effort, the need to disable IGRP automatic route summarization needs to be considered. This is likely if classless addressing is being implemented 🫠
Also be aware of the nuances of automatic redistribution between IGRP and EIGRP. The "autonomous system number," which need not be a true AS number but simply identifies a set of cooperating routers, must be the same on the IGRP and EIGRP processes for automatic redistribution to occur 🔗
11. Exterior Routing 🌍
Exterior routes may be defined statically. If dynamic routing is involved, such routes are learned primarily from BGP. RIP is not infrequently used to let ISPs learn dynamically about new customer routes, although there are security concerns with that approach 😬 IGRP and EIGRP can be used to advertise external routes.
Renumbering that affects BGP-speaking routers can get complex, because it can require changes not only in the BGP routers of the local Autonomous System, but also in routers of other AS and in routing registries. This will require careful administrative coordination 📋
If for no other reason than documentation, consider using a routing policy notation [RIPE-181++] [RPSL] to describe exterior routing policies 📝
11.1. Routing Registries/Routing Databases
Organizations that participate in exterior routing usually have routing information not only in their routers, but also in databases operated by registries or higher-level service providers (e.g., the Routing Arbiter) 🗄️
If an ISP whose previous address space came from a different provider either renumbers into a different provider's address space, or gains a recognized block of its own, there may be administrative requirements to return the previously allocated addresses. These include changes in IN-ADDR.ARPA delegation, SWIP databases, etc., and they need to be coordinated with the specific registries and providers involved. Not all registries and providers have the same policies 🧾
If the enterprise is a registered Autonomous System and renumbers into a different address space, route objects with old prefixes in routing registries need to be deleted, and route objects with new prefixes need to be added 💅
11.2. BGP--Own Organization
IP addressing information can be hard-coded in several aspects of a BGP speaker. These include:
- Router ID
- Peer router IP addresses
- Advertised prefix lists
- Route filtering rules
Some tools exist [RtConfig] for generating the policy configuration part of BGP router configuration statements from the policies specified in RIPE-181 or RPSL 🛠️
11.3. BGP--Other AS
Other autonomous systems, including nonadjacent ones, can contain direct or indirect (e.g., aggregated) references to the above routing information. Tools exist that can do preliminary checking of connectivity to given external destinations [RADB] 🔭
12. Network Management ✨
okay so this section is about the network management stuff that's intimately tied to routers, not a general chat about renumbering and network management as a whole 🎀
Methods used for managing routers include telnets to virtual console ports, SNMP, and TFTP. Network management scripts may contain hard-coded references to IP addresses supporting these services. In general, try to convert script references to IP addresses to DNS names 💅
A critical and complex problem will be converting SNMP databases, which are usually organized by IP address 😭
12.1. Configuration Management
Names and addresses of servers that participate in configuration management may need to change, as well as the contents of the configurations they provide. TFTP servers are commonly used here, as may be SNMP managers 🧚
12.2. Name Resolution/Directory Services
During renumbering, it will probably be useful to assign DNS names to interfaces, virtual interfaces, and router IDs of routers. Remember that it is perfectly acceptable to identify internal interfaces with RFC1597/RFC1918 private addresses, as long as firewalling or other filtering prevent these addresses to be propagated outside the enterprise 🦋
If dynamic addressing is used, dynamic DNS should be considered. Since this is under development, it may be appropriate to consider proprietary means to learn what addresses have been assigned dynamically, so they can be pinged or otherwise managed 🌈
Also remember that some name resolution may be done by static tables that are part of router configurations. Changing the DNS entries, and even restarting the routers, will not change these 🙈
12.3. Fault Management
Abnormal condition indications can be sent to several places that may have hard-coded IP addresses, such as SNMP trap servers, syslogd servers, etc.
It should be remembered that large bursts of transient errors may be caused as part of address cutover in renumbering. Be aware that these bursts might overrun the capacity of logging files, and conceivably cause loss of auditing information. Consider enlarging files or otherwise protecting them during cutover 💀
⚠️ bestie, those error bursts can literally flood your logs and you could lose your auditing info. protect those files during cutover!!
12.4. Performance Management
Performance information can be recorded in routers themselves, and retrieved by network management scripts. Other performance information may be sent to syslogd, or be kept in SNMP data bases 📊
Load-generating scripts used for performance testing may contain hard-coded IP addresses. Look carefully for scripts that contain executable code for generating ranges of test addresses. Such scripts may, at first examination, not appear to contain explicit IP addresses. They may, for example, contain a "seed" address used with an incrementing loop 🔍
12.5. Accounting Management
Accounting records may be sent periodically to syslogd or as SNMP traps. Alternatively, the SNMP manager or other management applications may periodically poll accounting information in routers, and thus contain hard-coded IP addresses 🧾
12.6. Security Management
Security management includes logging, authentication, filtering, and access control. Routers can have hard-coded references to servers for any of these functions 🔐
In addition, routers commonly will contain filters containing security-related rules. These rules are apt to need explicit recoding, since they tend to operate on a bit level 🧱
Some authentication servers and filtering mechanisms may dynamically update router filters ✨
12.7. Time Service
Hard-coded references to NTP servers should be changed to DNS when possible, and renumbered otherwise ⏰
13. IP and Protocol Encapsulation 🎁
okay so IP packets can be routed to provide connectivity for non-IP protocols, or for IP traffic with addresses that aren't consistent with the active routing environment. These encapsulating functions usually have a tunneling model, where an end-to-end connection between two "passenger" protocol addresses is mapped to a pair of endpoint IP addresses. Generic Route Encapsulation is a representative means of such tunneling [RFC1701, RFC1702] 🚇
13.1. Present
Renumbering of the primary IP environment often does not mean that passenger protocol addresses need to change. In fact, such protocol encapsulation for IP traffic may be a very viable method for handling legacy systems that cannot easily be renumbered. For this legacy case, the legacy IP addresses can be tunneled over the renumbered routing environment 🫶
Also note that IP may be a passenger protocol over non-IP systems using IPX, AppleTalk, etc. 🌸
13.2. Future
Tunneling mechanisms are fundamental for the planned transition of IPv4 to IPv6. As part of an IPv4 renumbering effort, it may be worthwhile to reserve some address space for future IPv6 tunnels 🔮
While there are clear and immediate needs for IPv4 renumbering, there may be cases where IPv4 renumbering can be deferred for some months or years. If the effort is deferred, it may be prudent at that time to consider if available IPv6 implementations or tunneling mechanisms form viable alternatives to IPv4 renumbering. It might be appropriate to renumber certain parts of the existing IPv4 space directly into the IPv6 space. Tools for this purpose are experimental at the time this document was written 🧪
14. Security Considerations 🚨
Routers are critical parts of firewalls, and are otherwise used for security enforcement. Configuration errors made during renumbering can expose systems to malicious intruders, or deny service to authorized users. The most critical area of concern is that filters are configured properly for old and new address, but other numbers also can impact security, such as pointers to authentication, logging, and DNS servers 😱
🛑 this part is seriously important, bestie. a filter that's wrong for the old OR new address can let intruders in or lock your authorized users out. check every pointer to authentication, logging, and DNS servers too!
During a renumbering operation, it may be appropriate to introduce authentication mechanisms for routing updates 🔒
15. Planning and Implementing the Renumbering 📋
Much of the effort in renumbering will be on platforms other than routers. Nevertheless, routers are a key part of any renumbering effort 👑
Step 1--Inventory of affected addresses and names. 🗂️
Step 2--Design any needed topological changes. If temporary address space, network address translators, etc., are needed, obtain them.
Step 3--Install and test changes to make the network more renumbering-friendly. These include making maximum use of default routes and summarization, while minimizing address-based references to servers.
Step 4--Plan the actual renumbering. Should it be phased or total? Can it be done in a series of stub network renumberings, possibly with secondary addresses on core routers? Is NAT appropriate? If so, how is it to be used?
What is your plan of retreat if major problems develop? Make a distinction between problems in the routing system and unforeseen problems in hosts affected by renumbering 🛟
Step 5--Take final backups. 💾
Step 6--Cut over addresses and names, or begin coexistence.
- Make needed DNS and firewall changes.
- Restart routers and servers as appropriate.
- Clear caches as appropriate.
- Remember static name definitions in routers may not be affected by DNS changes.
- Coordinate changes with affected external organizations (e.g., ISPs, business partners, routing registries)
Step 6--Document what isn't already documented. Make notes to help the person who next needs to renumber. Share experience with the PIER working group or other appropriate organizations 📝
15.1. Applying Changes
Renumbering changes should be introduced with care into operational networks. For changes to take effect, it is likely that at least interfaces and probably routers will have to be restarted. The sequence in which changes are applied must be carefully thought out, to avoid loss of connectivity, routing loops, etc., while the renumbering is in process 🔄
See case studies presented to the PIER Working Group for examples of operational renumbering experience. Organizations that have undergone renumbering have had to pay careful attention to informing users of possible outages, coordinating changes among multiple sites, etc. It will be an organization-specific decision whether router renumbering can be implemented incrementally or must be done in a major "flag day" conversion 📚
💾 before making significant changes, TAKE BACKUPS FIRST of all router configuration files, DNS zone files, and other information that documents your present environment. no excuses!!
15.2. Configuration Control
Operationally, an important part of renumbering and continued numbering maintenance is not to rely on local router interfaces, either command language interpreter, menu-based, or graphic, for the more sophisticated aspects of configuration, but to do primary configuration (and changes) on an appropriate workstation. On a workstation or other general-purpose computer, configuration files can be edited, listed, processed with macro processors and other tools, etc. Source code control tools can be used on the router configuration files 🛠️
Once the configuration file is defined for a router, mechanisms for loading it vary with the specific router implementation. In general, these will include a file transfer using FTP or TFTP into a configuration file on the router, SNMP SET commands, or logging in to the router as a remote console and using a terminal emulator to upload the new configuration under the router's interactive configuration mode. Original acquisition of legacy configuration files is the inverse of this process 📤
15.3. Avoiding Instability
Routing processes tend towards instability when they suddenly need to handle very large numbers of updates, as might occur if a "flag day" cutover is not carefully planned. A general guideline is to make changes in only one part of a routing hierarchy at a time 🌊
Routing system design should be hierarchical in all but the smallest domains. While OSPF and IS-IS have explicit area-based hierarchical models, hierarchical principles can be used with most implementations of modern routing protocols. Hierarchy can be imposed on a protocol such as RIPv2 or EIGRP by judicious use of route aggregation, routing advertisement filtering, etc. 🏗️
Respecting a hierarchical model during renumbering means such things as renumbering a "stub" part of the routing domain and letting that part stabilize before changing other parts. Alternatively, it may be reasonable to add new numbers to the backbone, allowing it to converge, renumbering stubs, and then removing old numbers from the backbone. Obviously, these guidelines are most practical when there is a distinct old and new address space without overlaps. If a block of addresses must simply be reassigned, some loss of service must be expected 🧘
16. Acknowledgments 🙌
Thanks to Jim Bound, Paul Ferguson, Geert Jan de Groot, Roger Fajman, Matt Holdrege, Dorian Kim, Walt Lazear, Eliot Lear, Will Leland, and Bill Manning for advice and comments 💜
17. References ✨
Okay bestie, here's the full bibliography, and yes, I read every single one 🤓📚
- [RFC2071] Ferguson, P., and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997. 💖
- [Cansever] Cansever, D., "NHRP Protocol Applicability Statement", Work in Progress. 🦋
- [Katz] Luciani, J., Katz, D., Piscitello, D., and Cole, B., "NBMA Next Hop Resolution Protocol (NHRP)", Work in Progress. 🌸
- [Hubbard] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", BCP 12, RFC 2050, November 1996. 🎀
- [RFC1631] Egevang,, K., and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, May 1994. 🧚
- [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G-J., and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996. 💜
- [RFC1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996. 🍓
- [RPS] Alaettinoglu, C., Bates, T., Gerich, E., Terpstra, M., and C. Villamizer, "Routing Policy Specification Language", Work in Progress. ✨
- [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. 👑
- [Rigney] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997. 🌈
- [Carpenter] Message to PIER Mailing List, see PIER Archives. 💅
- [Lear] Message to PIER Mailing List, see PIER Archives. 💅
- [deGroot] Message to PIER Mailing List, see PIER Archives. 💅
- [Wobus] "DHCP FAQ Memo",
http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html🫶
18. Author's Address 🎀
Howard C. Berkowitz, bestie, is the one who wrote this 🙌
Howard C. Berkowitz
PSC International
1600 Spring Hill Road, Suite 310
Vienna VA 22182
Phone: +1 703 998 5819
EMail: hcb@clark.netThat's the whole RFC, babe! 💖 Thanks for reading all the way to the end with me 🦋✨
📦 where this page comes from
- ietf: rfc2072 1997-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms