idnits 2.17.1 draft-ietf-pier-renum-ovrvw-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 403 has weird spacing: '...s often began...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'CERN' on line 562 == Unused Reference: '9' is defined on line 592, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1814 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 1775 (ref. '2') -- Unexpected draft version: The latest known version of draft-hubbard-registry-guidelines is -04, but you're referring to -05. ** Downref: Normative reference to an Historic draft: draft-hubbard-registry-guidelines (ref. '3') ** Obsolete normative reference: RFC 1541 (ref. '5') (Obsoleted by RFC 2131) == Outdated reference: A later version (-02) exists of draft-ietf-pier-rr-01 ** Downref: Normative reference to an Informational draft: draft-ietf-pier-rr (ref. '6') ** Obsolete normative reference: RFC 1631 (ref. '7') (Obsoleted by RFC 3022) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 1519 (ref. '10') (Obsoleted by RFC 4632) == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-09 ** Obsolete normative reference: RFC 1883 (ref. '13') (Obsoleted by RFC 2460) ** Downref: Normative reference to an Informational RFC: RFC 1881 (ref. '14') ** Downref: Normative reference to an Informational RFC: RFC 1900 (ref. '15') Summary: 18 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PIER Working Group P. Ferguson 2 Internet Draft cisco Systems, Inc. 3 August 1996 H. Berkowitz 4 Expires in six months PSC International 6 Network Renumbering Overview: 7 Why would I want it and what is it anyway? 8 draft-ietf-pier-renum-ovrvw-01.txt 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a 21 ``working draft'' or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 The PIER [Procedures for Internet/Enterprise Renumbering] working 32 group is compiling a series of documents to assist and instruct 33 organizations in their efforts to renumber. However, it is becoming 34 apparent that, with the increasing number of new Internet Service 35 Providers (ISP's) and organizations getting connected to the 36 Internet for the first time, the concept of network renumbering 37 needs to be further defined. This document attempts to clearly 38 define the concept of network renumbering and discuss some of the 39 more pertinent reasons why an organization would have a need to do 40 so. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 45 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 46 3. Network Renumbering Defined. . . . . . . . . . . . . . . . . 3 47 4. Reasons for Renumbering. . . . . . . . . . . . . . . . . . . 3 48 5. Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 49 6. Security Considerations . . . . . . . . . . . . . . . . . . 12 50 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 12 51 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 52 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 54 1. Introduction 56 The popularity of connecting to the global Internet over the course 57 of the past several years has spawned new problems; what most people 58 casually refer to as ``growing pains'' can be attributed to more 59 basic problems in understanding the requirements for Internet 60 connectivity. However, the reasons why organizations may need to 61 renumber their networks can greatly vary. We'll discuss these issues 62 in some amount of detail below. It is not within the intended scope 63 of this document to discuss renumbering methodologies, techniques, or 64 tools. 66 2. Background 68 The ability for any network or interconnected devices, such as 69 desktop PCs or workstations, to obtain connectivity to any potential 70 destination in the global Internet is reliant upon the possession of 71 unique IP host addresses [1]. A duplicate host address that is 72 being used elsewhere in the Internet could best be described as 73 problematic, since the presence of duplicate addresses would cause 74 one of the destinations to be unreachable from some origins in the 75 Internet. It should be noted, however, that globally unique IP 76 addresses are not always necessary, and is dependent on the 77 connectivity requirements [2]. 79 However, the recent popularity in obtaining Internet connectivity 80 has made these types of connectivity dependencies unpredictable, 81 and conventional wisdom in the Internet community dictates that 82 the various address allocation registries, such as the interNIC, 83 as well as the ISP's, become more prudent in their address 84 allocation strategies. In that vein, the interNIC has defined 85 address allocation policies [3] wherein the majority of address 86 allocations for end-user networks are accommodated by their 87 upstream ISP, except in cases where dual- or multihoming and 88 very large blocks of addresses are required. With this allocation 89 policy becoming standard current practice, it presents unique 90 problems regarding the portability of addresses from one provider 91 to another. 93 As a practical matter, end users cannot assume they ``own'' address 94 allocations, if their intention is to be to have full connectivity 95 to the global Internet. Rather, end users will ``borrow'' part of the 96 address space of an upstream provider's allocation. The larger 97 provider block from which their space is suballocated will have been 98 assigned in a manner consistent with global Internet routing. 100 Not having ``permanent'' addresses does not mean users will not have 101 unique identifiers. Such identifiers are typically Domain Name 102 System (DNS) [4] names for endpoints such as servers and 103 workstations. Mechanisms such as the Dynamic Host Configuration 104 Protocol (DHCP) [5] can help automate the assignment and maintenance 105 of host names, as well as the 'borrowed' addresses required for 106 routing-level connectivity. 108 The PIER Working Group is developing procedures and guidelines for 109 detailed renumbering of specific technologies, such as routers [6]. 110 PIER WG documents are intended to suggest methods both for making 111 existing networks prepared for convenient renumbering, as well as 112 for operational transition to new addressing schemes. 114 Also, in many instances, organizations who have never connected to 115 the Internet, yet have been using arbitrary blocks of addresses since 116 their construction, have different and unique challenges. 118 3. Network Renumbering Defined 120 In the simplest of definitions, the exercise of renumbering a 121 network consists of changing the IP host addresses, and perhaps 122 the network mask, of each device within the network that has an 123 address associated with it. This activity may or may not consist 124 of all networks within a particular domain, such as FOO.EDU, or 125 networks which comprise an entire autonomous system. 127 Devices which may need to be renumbered, for example, are networked 128 PC's, workstations, printers, file servers, terminal servers, and 129 routers. While this is not an all-inclusive list, the PIER working 130 group is making efforts to compile documentation to identify these 131 devices in a more detailed fashion. 133 Network renumbering need not be sudden activity, either; in most 134 instances, an organization's upstream service provider(s) will 135 allow a grace period where both the ``old'' addresses and the ``new'' 136 addresses may be used in parallel. 138 4. Reasons for Renumbering 140 The following sections discuss particular reasons which may 141 precipitate network renumbering, and are not presented in any 142 particular order of precedence. They are grouped into reasons that 143 primarily reflect decisions made in the past, operational 144 requirements of the present, or plans for the future. 146 Some of these requirements reflect evolution in the organization's 147 mission, such as a need to communicate with business partners, or 148 to work efficiently in a global Internet. Other requirements 149 reflect changes in network technologies. 151 4.1 Past 153 Many organizations implemented IP-based networks not for 154 connectivity to the Internet, but simply to make use of effective 155 data communications mechanisms. These organizations subsequently 156 found valid reasons to connect to other organizations or the 157 Internet in general, but found the address structures they chose 158 incompatible with overall Internet practice. 160 Other organizations connected early to the Internet, but did so at 161 a time when address space was not scarce. Yet other organizations 162 still have no requirement to connect to the Internet, but have 163 legacy addressing structures that do not scale to adequate size. 165 4.1.1 Initial addressing using non-unique addresses 167 As recently as two years ago, many organizations had no intention 168 of connecting to the Internet, and constructed their corporate or 169 organizational network(s) using unregistered, non-unique network 170 addresses. Obviously, as most problems evolve, these same 171 organizations determined that Internet connectivity had become 172 a valuable asset, and subsequently discovered that they could no 173 longer use the same unregistered, non-unique network addresses 174 that were previously deployed throughout their organization. 175 Thus, the labor of renumbering to valid network addresses is 176 now upon them, as they move to connect to the global Internet. 178 While obtaining valid, unique addresses are certainly required 179 to obtain full Internet connectivity in most circumstances, the 180 number of unique addresses required can be significantly reduced 181 by the implementation of Network Address Translation (NAT) devices 182 [7] and the use of private address space, as specified in [8]. 183 NAT reduces not only the number of required unique addresses, but 184 also localizes the changes required by renumbering. 186 It should also be noted that NAT technology may not always be 187 a viable option, depending upon scale of addressing, performance 188 or topological constraints. 190 4.1.2 Legacy address allocation 192 There are also several instances where organizations were originally 193 allocated very large amounts of address space, such as traditional 194 ``Class A'' or ``Class B'' allocations, while the actual address 195 requirements are much less than the total amount of address space 196 originally allocated. In many cases, these organizations could 197 suffice with a smaller CIDR allocation, and utilize the allocated 198 address space in a more efficient manner. As allocation requirements 199 become more stringent, mechanisms to review how these organizations 200 are utilizing their address space could, quite possibly, result in 201 a request to return the original allocation to a particular registry 202 and renumber with a more appropriately sized address block. 204 4.1.3 Limitations of Bridged Internetworks 206 Bridging has a long and distinguished history in legacy networks. 207 As networks grow, however, traditional bridged networks reach 208 performance- and stability-related limits, including (but not 209 limited to) broadcast storms. 211 Early routers did not have the speed to handle the needs of some 212 large networks. Some organizations were literally not able to move 213 to routers until router forwarding performance improved to be 214 comparable to bridges. Now that routers are of comparable or 215 superior speed, and offer more robust features, replacing bridged 216 networks becomes reasonable. 218 IP addresses assigned to pure bridged networks tend not to be 219 subnetted, yet subnetting is a basic approach for router networks. 220 Introducing subnetting is a practical necessity in moving from 221 bridging to routing. 223 Special cases of bridging are realized in workgroup switching 224 systems, discussed below. 226 4.1.4 Limitations of Legacy Routing Systems 228 Other performance problems might come from routing mechanisms that 229 advertise excessive numbers of routing updates (e.g., RIP, IGRP). 230 Appropriate replacement protocols (e.g., OSPF, EIGRP, IS-IS) will 231 work best with a structured addressing system that encourages 232 aggregation. 234 4.1.5 Limitations of System Administration Methodologies 236 There can be operational limits to growth based on the difficulty 237 of adds, moves and changes. As enterprise networks grow, it may 238 be necessary to delegate portions of address assignment and 239 maintenance. If address space has been assigned randomly or 240 inefficiently, it may be difficult to delegate portions of the 241 address space. 243 It is not unusual for organizational networks to grow sporadically, 244 obtaining an address prefix here and there, in a non-contiguous 245 fashion. Depending on the number of prefixes that an organization 246 acquires over time, it may become increasingly unmanageable or demand 247 higher levels of maintenance and administration when individual 248 prefixes are acquired in this way. 250 Reasonable IP address management may in general simplify continuing 251 system administration; a good numbering plan is also a good 252 renumbering plan. Renumbering may force a discipline into system 253 administration that will reduce long-term support costs. 255 It has been observed ``...there is no way to renumber a network 256 without an inventory of the hosts (absent DHCP). On a large 257 network that needs a database, plus tools and staff to 258 maintain the database.''[9] It can be argued that a detailed 259 inventory of router configurations is even more essential. 261 4.2 Present 263 Organizations now face needs to connect to the global Internet, or 264 at a minimum to other organizations through bilateral private links. 266 Certain new transmission technologies have tended to redefine the 267 basic notion of an IP subnet. An IP numbering plan needs to work 268 with these new ideas. Legacy bridged networks and leading-edge 269 workgroup switched networks may very well need changes in the 270 subnetting structure. Renumbering needs may also develop due to 271 the characteristics of new WAN technologies, especially nonbroadcast 272 multiaccess (NBMA) services such as Frame-Relay and Asynchronous 273 Transfer Mode (ATM). 275 Increased use of telecommuting by mobile workers, and in small and 276 home offices, need on-demand WAN connectivity, using modems or ISDN. 277 Effective use of demand media often requires changes in numbering 278 and routing. 280 4.2.1 Change in organizational structure or network topology 282 As companies grow, through mergers, acquisitions and reorganizations, 283 the need may arise for realignment and modification of the various 284 organizational network architectures. The connectivity of disparate 285 corporate networks present unique challenges in the realm of 286 renumbering, since one or more individual networks may have to be 287 blended into a much larger architecture consisting a different IP 288 address prefix altogether. 290 4.2.2 Inter-Enterprise Connectivity 292 Even if they do not connect to the general Internet, enterprises may 293 interconnect to other organizations which have independent numbering 294 systems. Such connectivity can be as simple as bilateral dedicated 295 circuits. If both enterprises use unregistered or private address 296 space, they run the risk of using duplicate addresses. 298 In such cases, one or both organizations may need to renumber into 299 different parts of the private address space, or obtain unique 300 registered addresses. 302 4.2.3 Change of Internet Service Provider 304 As mentioned previously in Section 2, it is increasingly becoming 305 current practice for organizations to have their IP addresses 306 allocated by their upstream ISP. Also, with the advent of Classless 307 Inter Domain Routing (CIDR) [10], and the considerable growth in the 308 size of the global Internet table, Internet Service Providers 309 are becoming more and more reluctant to allow customers to continue 310 using addresses which were allocated by the ISP, when the customer 311 terminates service and moves to another ISP. The prevailing 312 reason is that the ISP was previously issued a CIDR block of 313 contiguous address space, which can be announced to the remainder of 314 the Internet community as a single prefix. (A prefix is what is 315 referred to in classless terms as a contiguous block of IP 316 addresses.) If a non-customer advertises a specific component 317 of the CIDR block, then this adds an additional routing entry to 318 the global Internet routing table. This is what is commonly 319 referred to as ``punching holes'' in a CIDR block. Consequently, 320 there are usually no routing anomalies in doing this since a specific 321 prefix is always preferred over an aggregate route. However, if 322 this practice were to happen on a large scale, the growth of the 323 global routing table would become much larger, and perhaps too 324 large for current backbone routers to accommodate in an acceptable 325 fashion with regards to performance of recalculating routing 326 information and sheer size of the routing table itself. For obvious 327 reasons, this practice is highly discouraged by ISP's with CIDR 328 blocks, and some ISP's are making this a contractual issue, so that 329 customers understand that addresses allocated by the ISP are non- 330 portable. 332 It is noteworthy to mention that the likelihood of being forced to 333 renumber in this situation is inversely proportional to the size of 334 the customer's address space. For example, an organization with a 335 /16 allocation may be allowed to consider the address space 336 ``portable'', while an organization with multiple non-contiguous 337 /24 allocations may not. While the scenarios may be vastly different 338 in scope, it becomes an issue to be decided at the discretion of the 339 initial allocating entity, and the ISP's involved; the major deciding 340 factor being whether or not the change will fragment an existing CIDR 341 block and whether it will significantly contribute to the overall 342 growth of the global Internet routing tables. 344 It should also be noted that (contrary to opinions sometimes voiced) 345 this form of renumbering is a technically necessary consequence of 346 changing ISP's, rather than a commercial or political mandate. 348 4.2.3 Internet Global Routing 350 Even large organizations, now connected to the Internet with 351 ``portable'' address space, may find their address allocation too 352 small. Current registry guidelines require that address space usage 353 be justified by an engineering plan. Older networks may not have 354 efficiently utilized existing address space, and may need to make 355 their existing structures more efficient before new address 356 allocations can be made. 358 4.2.4 Internal Use of LAN Switching 360 Introducing workgroup switches may introduce subtle renumbering 361 needs. Fundamentally, workgroup switches are specialized, high- 362 performance bridges, which make their main forwarding decisions 363 based on Layer 2 (MAC) address information. Even so, they rarely 364 are independent of Layer 3 (IP) address structure. Pure Layer 2 365 switching has a ``flat'' address space that will need to be 366 renumbered into a hierarchical, subnetted space consistent with 367 routing. 369 Introducing single switches or stacks of switches may not have 370 significant impact on addressing, as long as it is understood 371 that each system of switches is a single broadcast domain. Each 372 broadcast domain should map to a single IP subnetwork. 374 Virtual LANs (VLANs) further extend the complexity of the role of 375 workgroup switches. It is generally true that moving an end 376 station from one switch port to another within the same ``color'' 377 VLAN will not cause major changes in addressing. Many overview 378 presentations of this technology do not make it clear that moving 379 the same end station between different colors will move the 380 end station into another IP subnet, requiring a significant 381 address change. 383 Switches are commonly managed by SNMP applications. These 384 network management applications communicate with managed devices 385 using IP. Even if the switch does not do IP forwarding, it will 386 itself need IP addresses if it is to be managed. Also, if the 387 clients and servers in the workgroup are managed by SNMP, they 388 will also require IP addresses. The workgroup, therefore, will 389 need to appear as one or more IP subnetworks. 391 Increasingly, internetworking products are not purely Layer 2 or 392 Layer 3 devices. A workgroup switch product often includes a routing 393 function, so the numbering plan must support both flat Layer 2 and 394 hierarchical Layer 3 addressing. 396 4.2.4 Internal Use of NBMA Cloud Services 398 "Cloud" services such as frame relay often are more economical than 399 traditional services. At first glance, when converting existing 400 enterprise networks to NBMA, it might appear that the existing subnet 401 structure should be preserved, but this is often not the case. 403 Many organizations often began by treating the "cloud" as a single 404 subnet, but experience has shown it is often better to treat the 405 individual virtual circuits as separate subnets, which appear as 406 traditional point-to-point circuits. When the individual 407 point-to-point VCs become separate subnets, efficient address 408 utilization requires the use of long prefixes (i.e., 30 bit) for 409 these subnets. In practice, obtaining 30 bit prefixes means the 410 logical network should support variable length subnet masks (VLSM). 411 VLSMs are the primary method in which an assigned prefix can be 412 subnetted efficiently for different media types. This is 413 accomplished by establishing one or more prefix lengths for LAN 414 media with more than two hosts, and subdividing one or more of these 415 shorter prefixes into longer /30 prefixes that minimize address loss. 417 There are alternative ways to configure routing over NBMA, using 418 special mechanisms to exploit or simulate point-to-multipoint VCs. 419 These often have a significant performance impact, and may be less 420 reliable because a single routing point of failure is created. 421 Motivations for such alternatives tend to include: 423 1. A desire not to use VLSM. This is often founded in fear 424 rather than technology. 426 2. Router implementation issues that limit the number of subnets 427 or interfaces a given router can support. 429 3. An inherently point-to-multipoint application (e.g., remote 430 hosts to a data center). In such cases, some of the 431 limitations are due to the dynamic routing protocol in use. 432 In such ``hub-and-spoke'' implementations, static routing can 433 be preferable from a performance and flexibility standpoint, 434 since it does not produce routing protocol chatter and is 435 unaffected by split horizon constraints. 437 4.2.5 Expansion of Dialup Services 439 Dialup services, especially public Internet access providers, are 440 experiencing explosive growth. This success represents a particular 441 drain on the available address space, especially with a commonly 442 used practice of assigning unique addresses to each customer. 444 In this case, individual users announce their address to the 445 access server using PPP's IP control protocol (IPCP) [11]. The 446 server may validate the proposed address against some type 447 of user identification, or simply make the address active in a 448 subnet to which the access server (or set of bridged access 449 servers) belongs. 451 The preferred technique is to allocate dynamic addresses to the 452 user from a pool of addresses available to the access server. 454 4.2.6 Returning segregate prefixes for an aggregate 456 In many instances, an organization can return their current, 457 non-contiguous prefix allocations for a contiguous block of address 458 space of equal or greater size, which can be accommodated with CIDR. 459 Also, many organizations have begun to deploy classless interior 460 routing protocols within their domains that make use of route 461 summarization and other optimized routing features, effectively 462 reducing the total number of routes being propagated within their 463 internal network(s), and making it much easier to administer and 464 maintain. 466 Hierarchical routing protocols such as OSPF scale best when the 467 address assignment of a given network reflects the topology, and the 468 topology of the network can often be fluid. Given that the network is 469 fluid, even the best planned address assignment scheme, given time, 470 will diverge from the actual topology. While not required, some 471 organization may choose to gain the benefit of both technical and 472 administrative scalability of their IGP by periodically renumbering 473 to have address assignments reflect the network topology. Patrick 474 Henry once said ``the tree of liberty must from time to time be 475 watered with the blood of patriots.'' In the Internet, routing 476 trees of the best-planned networks need from time to time be 477 watered with at least the sweat of network administrators. 478 Improving aggregation is also highly encouraged to reduce the size 479 of not only the global Internet routing table, but also the size 480 and scalability of interior routing within the enterprise. 482 4.3 Future 484 Emerging new protocols will most definitely affect addressing plans 485 and numbering schemes. 487 4.3.1 Internal Use of Switched Virtual Circuit Services 489 Services such as ATM virtual circuits, switched frame relay, etc., 490 present challenges not considered in the original IP design. The 491 basic IP decision in forwarding a packet is whether the destination 492 is local or remote, in relation to the source host's subnet. Address 493 resolution mechanisms are used to find the medium address of the 494 destination in the case of local destinations, or to find the medium 495 address of the router in the case of remote routers. 497 In these new services, there are cases where it is far more effective 498 to ``cut-through'' a new virtual circuit to the destination. If the 499 destination is on a different subnet than the source, the cut-through 500 typically is to the egress router that serves the destination subnet. 501 The advantage of cut-through in such a case is that it avoids the 502 latency of multiple router hops, and reduces load on ``backbone'' 503 routers. The cut-through decision is usually made by an entry router 504 that is aware of both the routed and switched environments. 506 This entry router communicates with a address resolution server using 507 the Next Hop Resolution Protocol (NHRP) [12]. This server maps the 508 destination network address to either a next-hop router (where 509 cut-through is not appropriate) or to an egress router reached over 510 the switched service. Obviously, the data base in such a server may 511 be affected by renumbering. Clients may have a hard-coded address 512 of the server, which again may need to change. 513 While the NHRP protocol specifications are still evolving at the 514 time of this writing, commercial implementations based on drafts 515 of the protocol standard are in use. 517 4.3.2 Transitioning to IP version 6 519 Of course, when IPv6 [13] deployment is set in motion, and as 520 methodologies are developed to transition to IPv6, renumbering will 521 also be necessary, but perhaps not immediately mandatory. To aid 522 in the transition to IPv6, mechanisms to deploy dual- IPv4/IPv6 523 stacks on network hosts should also become available. It is also 524 envisioned that Network Address Translation (NAT) devices will be 525 developed to assist in the IPv4 to IPv6 transition, or perhaps 526 supplant the need to renumber the majority of interior networks 527 altogether, but that is beyond the scope of this document. At the 528 very least, DNS hosts will need to be reconfigured to resolve new 529 host names and addresses, and routers will need to be reconfigured 530 to advertise new prefixes. 532 IPv6 address allocation will be managed by the Internet Assigned 533 Numbers Authority (IANA) as set forth in [14]. 535 5. Summary 537 As indicated by the Internet Architecture Board (IAB) in [15], 538 the task of renumbering networks is becoming more widespread 539 and commonplace. Although there are numerous reasons why an 540 organization would desire, or be required to renumber, there are 541 equally as many reasons why address allocation should be done with 542 great care and forethought at the onset, in order to minimize the 543 impact that renumbering would have on the organization. Even 544 with the most forethought and vision, however, an organization 545 cannot foresee the possibility for renumbering. The best advice, 546 in this case, is to be prepared, and get ready for renumbering. 548 6. Security Considerations 550 Although no obvious security issues are discussed in this 551 document, it stands to reason that renumbering certain devices 552 can defeat security systems designed and based on static IP host 553 addresses. Care should be exercised by the renumbering entity 554 to ensure that all security systems deployed with the network(s) 555 which may need to be renumbered be given special consideration 556 and significant forethought to provide continued functionality 557 and adequate security. 559 7. Acknowledgments 561 Special acknowledgments to Yakov Rekhter [cisco Systems, Inc.], 562 Tony Bates [cisco Systems, Inc.] and Brian Carpenter [CERN] for 563 their contributions and editorial critique. 565 8. References 567 [1] RFC-1814, ``Unique Addresses are Good''; E. Gerich; IAB; July 1995 569 [2] RFC-1775, ``To Be `On' the Internet''; D. Crocker, March 1995 571 [3] Work in Progress; ``INTERNET REGISTRY IP ALLOCATION GUIDELINES''; 572 K. Hubbard, J. Postel, M. Kosters, D. Conrad, D. Karrenberg; 573 August 1996; draft-hubbard-registry-guidelines-05.txt 575 [4] RFC-1034, ``Domain Names - Concepts and Facilities''; 576 P. Mockapetris, November 1987; 577 RFC-1035, ``Domain Names - Implementation and Specification''; 578 P. Mockapetris, November 1987 580 [5] RFC-1541, ``Dynamic Host Configuration Protocol''; R. Droms, 581 October 1993 583 [6] Work in Progress, ``Router Renumbering Guide''; H. Berkowitz; 584 June 1996; draft-ietf-pier-rr-01.txt 586 [7] RFC-1631, ``The IP Network Address Translator (NAT)''; K. Egevang, 587 P. Francis; May 1994 589 [8] RFC-1918, ``Address Allocation for Private Internets''; Y. Rekhter, 590 R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear; February 1996 592 [9] Messages to PIER list on CERN renumbering; Brian Carpenter, CERN. 593 Available in PIER WG mailing list archives. 595 [10] RFC-1519, ``Classless Inter-Domain Routing (CIDR): an Address 596 Assignment and Aggregation Strategy''; V. Fuller, T. Li, J. Yu, 597 K. Varadhan; October 1993 599 [11] RFC-1332, ``The PPP Internet Protocol Control Protocol (IPCP)''; 600 G. McGregor; May 1992 602 [12] Work in Progress; ``NBMA Next Hop Resolution Protocol (NHRP)''; 603 J. Luciani, D. Katz, D. Piscitello, B. Cole; July 1996; 604 draft-ietf-rolc-nhrp-09.txt 606 [13] RFC-1883, ``Internet Protocol, Version 6 (IPv6) Specification''; 607 S. Deering, R. Hinden; December 1995 609 [14] RFC-1881, ``IPv6 Address Allocation Management''; IAB + IESG; 610 December 1995 612 [15] RFC-1900, ``Renumbering Needs Work''; B. Carpenter, Y. Rekhter; 613 IAB; February 1996 615 9. Author's Address 617 Paul Ferguson 618 cisco Systems, Inc. 619 1875 Campus Commons Road 620 Suite 210 621 Reston, VA 22091 623 Phone: (703) 716-9538 624 Fax: (703) 716-9599 625 EMail: pferguso@cisco.com 627 Howard C. Berkowitz 628 PSC International 629 1600 Spring Hill Road 630 Vienna, VA 22182 632 Phone (703) 998-5819 633 Fax: (703) 998-5058 634 EMail: hcb@clark.net