idnits 2.17.1 draft-ietf-cidrd-private-addr-05.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-03-28) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (January 1996) is 10300 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1466 (Obsoleted by RFC 2050) ** Downref: Normative reference to an Historic RFC: RFC 1518 ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Rekhter 3 Cisco Systems 4 B. Moskowitz 5 Chrysler Corp. 6 D. Karrenberg 7 RIPE NCC 8 G. J. de Groot 9 RIPE NCC 10 E. Lear 11 Silicon Graphics, Inc. 12 January 1996 14 Address Allocation for Private Internets 15 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 31 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 1. Introduction 37 For the purposes of this document, an enterprise is an entity 38 autonomously operating a network using TCP/IP and in particular 39 determining the addressing plan and address assignments within that 40 network. 42 This document describes address allocation for private internets. The 43 allocation permits full network layer connectivity among all hosts 44 inside an enterprise as well as among all public hosts of different 45 enterprises. The cost of using private internet address space is the 46 potentially costly effort to renumber hosts and networks between 47 Address Allocation for Private Internets January 1996 49 public and private. 51 2. Motivation 53 With the proliferation of TCP/IP technology worldwide, including 54 outside the Internet itself, an increasing number of non-connected 55 enterprises use this technology and its addressing capabilities for 56 sole intra-enterprise communications, without any intention to ever 57 directly connect to other enterprises or the Internet itself. 59 The Internet has grown beyond anyone's expectations. Sustained 60 exponential growth continues to introduce new challenges. One 61 challenge is a concern within the community that globally unique 62 address space will be exhausted. A separate and far more pressing 63 concern is that the amount of routing overhead will grow beyond the 64 capabilities of Internet Service Providers. Efforts are in progress 65 within the community to find long term solutions to both of these 66 problems. Meanwhile it is necessary to revisit address allocation 67 procedures, and their impact on the Internet routing system. 69 Acquiring globally unique addresses from an Internet registry is no 70 longer sufficient to achieve Internet-wide IP connectivity. In the 71 past assignment of globally unique addresses had been sufficient to 72 insure Internet-wide reachability to these addresses. To contain 73 growth of routing overhead, an Internet Provider obtains a block of 74 address space from an address registry, and then assigns to its 75 customers addresses from within that block based on each customer 76 requirement. The result of this process is that routes to many 77 customers will be aggregated together, and will appear to other 78 providers as a single route [RFC1518], [RFC1519]. 80 In order for route aggregation to be effective, Internet providers 81 encourage customers joining their network to use the provider's 82 block, and thus renumber their computers. Such encouragement may 83 become a requirement in the future. With the current size of the 84 Internet and its growth rate it is no longer realistic to assume that 85 by virtue of acquiring globally unique IP addresses out of an 86 Internet registry an organization that acquires such addresses would 87 have Internet-wide IP connectivity once the organization gets 88 connected to the Internet. To the contrary, it is quite likely that 89 when the organization would connect to the Internet to achieve 90 Internet-wide IP connectivity the organization would need to change 91 IP addresses (renumber) all of its public hosts (hosts that require 92 Internet-wide IP connectivity), regardless of whether the addresses 93 used by the organization initially were globally unique or not. 95 The current practice is to assign globally unique addresses to all 96 Address Allocation for Private Internets January 1996 98 hosts that use TCP/IP. In order to extend the life of the IPv4 99 address space, address registries are requiring more justification 100 than ever before, making it harder for organizations to acquire 101 additional address space [RFC1466]. 103 Hosts within enterprises that use IP can be partitioned into three 104 categories: 106 Category 1: hosts that do not require access to hosts in other 107 enterprises or the Internet at large; hosts within 108 this category may use IP addresses that are unambiguous 109 within an enterprise, but may be ambiguous between 110 enterprises. 112 Category 2: hosts that need access to a limited set of outside 113 services (e.g., E-mail, FTP, netnews, remote login) 114 which can be handled by mediating gateways (e.g., 115 application layer gateways). For many hosts in this 116 category an unrestricted external access (provided 117 via IP connectivity) may be unnecessary and even 118 undesirable for privacy/security reasons. Just like 119 hosts within the first category, such hosts may use 120 IP addresses that are unambiguous within an enterprise, 121 but may be ambiguous between enterprises. 123 Category 3: hosts that need network layer access outside the 124 enterprise (provided via IP connectivity); hosts in 125 the last category require IP addresses that are globally 126 unambiguous. 128 We will refer to the hosts in the first and second categories as 129 "private". We will refer to the hosts in the third category as 130 "public". 132 Many applications require connectivity only within one enterprise and 133 do not need external (outside the enterprise) connectivity for the 134 majority of internal hosts. In larger enterprises it is often easy to 135 identify a substantial number of hosts using TCP/IP that do not need 136 network layer connectivity outside the enterprise. 138 Some examples, where external connectivity might not be required, 139 are: 141 - A large airport which has its arrival/departure displays 142 individually addressable via TCP/IP. It is very unlikely that 143 Address Allocation for Private Internets January 1996 145 these displays need to be directly accessible from other 146 networks. 148 - Large organizations like banks and retail chains are switching 149 to TCP/IP for their internal communication. Large numbers of 150 local workstations like cash registers, money machines, and 151 equipment at clerical positions rarely need to have such 152 connectivity. 154 - For security reasons, many enterprises use application layer 155 gateways to connect their internal network to the Internet. 156 The internal network usually does not have direct access to 157 the Internet, thus only one or more gateways are visible from 158 the Internet. In this case, the internal network can use 159 non-unique IP network numbers. 161 - Interfaces of routers on an internal network usually do not 162 need to be directly accessible from outside the enterprise. 164 3. Private Address Space 166 The Internet Assigned Numbers Authority (IANA) has reserved the 167 following three blocks of the IP address space for private internets: 169 10.0.0.0 - 10.255.255.255 (10/8 prefix) 170 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 171 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) 173 We will refer to the first block as "24-bit block", the second as 174 "20-bit block, and to the third as "16-bit" block. Note that the 175 first block is nothing but a single class A network number, while the 176 second block is a set of 16 contiguous class B network numbers, and 177 third block is a set of 256 contiguous class C network numbers. 179 An enterprise that decides to use IP addresses out of the address 180 space defined in this document can do so without any coordination 181 with IANA or an Internet registry. The address space can thus be used 182 by many enterprises. Addresses within this private address space will 183 only be unique within the enterprise, or the set of enterprises which 184 choose to cooperate over this space so they may communicate with each 185 other in their own private internet. 187 As before, any enterprise that needs globally unique address space is 188 required to obtain such addresses from an Internet registry. An 189 Address Allocation for Private Internets January 1996 191 enterprise that requests IP addresses for its external connectivity 192 will never be assigned addresses from the blocks defined above. 194 In order to use private address space, an enterprise needs to 195 determine which hosts do not need to have network layer connectivity 196 outside the enterprise in the foreseeable future and thus could be 197 classified as private. Such hosts will use the private address space 198 defined above. Private hosts can communicate with all other hosts 199 inside the enterprise, both public and private. However, they cannot 200 have IP connectivity to any host outside of the enterprise. While not 201 having external (outside of the enterprise) IP connectivity private 202 hosts can still have access to external services via mediating 203 gateways (e.g., application layer gateways). 205 All other hosts will be public and will use globally unique address 206 space assigned by an Internet Registry. Public hosts can communicate 207 with other hosts inside the enterprise both public and private and 208 can have IP connectivity to public hosts outside the enterprise. 209 Public hosts do not have connectivity to private hosts of other 210 enterprises. 212 Moving a host from private to public or vice versa involves a change 213 of IP address, changes to the appropriate DNS entries, and changes to 214 configuration files on other hosts that reference the host by IP 215 address. 217 Because private addresses have no global meaning, routing information 218 about private networks shall not be propagated on inter-enterprise 219 links, and packets with private source or destination addresses 220 should not be forwarded across such links. Routers in networks not 221 using private address space, especially those of Internet service 222 providers, are expected to be configured to reject (filter out) 223 routing information about private networks. If such a router receives 224 such information the rejection shall not be treated as a routing 225 protocol error. 227 Indirect references to such addresses should be contained within the 228 enterprise. Prominent examples of such references are DNS Resource 229 Records and other information referring to internal private 230 addresses. In particular, Internet service providers should take 231 measures to prevent such leakage. 233 4. Advantages and Disadvantages of Using Private Address Space 235 The obvious advantage of using private address space for the Internet 236 at large is to conserve the globally unique address space by not 237 using it where global uniqueness is not required. 239 Address Allocation for Private Internets January 1996 241 Enterprises themselves also enjoy a number of benefits from their 242 usage of private address space: They gain a lot of flexibility in 243 network design by having more address space at their disposal than 244 they could obtain from the globally unique pool. This enables 245 operationally and administratively convenient addressing schemes as 246 well as easier growth paths. 248 For a variety of reasons the Internet has already encountered 249 situations where an enterprise that has not been connected to the 250 Internet had used IP address space for its hosts without getting this 251 space assigned from the IANA. In some cases this address space had 252 been already assigned to other enterprises. If such an enterprise 253 would later connects to the Internet, this could potentially create 254 very serious problems, as IP routing cannot provide correct 255 operations in presence of ambiguous addressing. Although in principle 256 Internet Service Providers should guard against such mistakes through 257 the use of route filters, this does not always happen in practice. 258 Using private address space provides a safe choice for such 259 enterprises, avoiding clashes once outside connectivity is needed. 261 A major drawback to the use of private address space is that it may 262 actually reduce an enterprise's flexibility to access the Internet. 263 Once one commits to using a private address, one is committing to 264 renumber part or all of an enterprise, should one decide to provide 265 IP connectivity between that part (or all of the enterprise) and the 266 Internet. Usually the cost of renumbering can be measured by 267 counting the number of hosts that have to transition from private to 268 public. As was discussed earlier, however, even if a network uses 269 globally unique addresses, it may still have to renumber in order to 270 acquire Internet-wide IP connectivity. 272 Another drawback to the use of private address space is that it may 273 require renumbering when merging several private internets into a 274 single private internet. If we review the examples we list in Section 275 2, we note that companies tend to merge. If such companies prior to 276 the merge maintained their uncoordinated internets using private 277 address space, then if after the merge these private internets would 278 be combined into a single private internet, some addresses within the 279 combined private internet may not be unique. As a result, hosts with 280 these addresses would need to be renumbered. 282 The cost of renumbering may well be mitigated by development and 283 deployment of tools that facilitate renumbering (e.g. Dynamic Host 284 Configuration Protocol (DHCP)). When deciding whether to use private 285 addresses, we recommend to inquire computer and software vendors 286 about availability of such tools. A separate IETF effort (PIER 287 Working Group) is pursuing full documentation of the requirements and 288 procedures for renumbering. 290 Address Allocation for Private Internets January 1996 292 5. Operational Considerations 294 One possible strategy is to design the private part of the network 295 first and use private address space for all internal links. Then plan 296 public subnets at the locations needed and design the external 297 connectivity. 299 This design does not need to be fixed permanently. If a group of one 300 or more hosts requires to change their status (from private to public 301 or vice versa) later, this can be accomplished by renumbering only 302 the hosts involved, and changing physical connectivity, if needed. In 303 locations where such changes can be foreseen (machine rooms, etc.), 304 it is advisable to configure separate physical media for public and 305 private subnets to facilitate such changes. In order to avoid major 306 network disruptions, it is advisable to group hosts with similar 307 connectivity needs on their own subnets. 309 If a suitable subnetting scheme can be designed and is supported by 310 the equipment concerned, it is advisable to use the 24-bit block 311 (class A network) of private address space and make an addressing 312 plan with a good growth path. If subnetting is a problem, the 16-bit 313 block (class C networks), or the 20-bit block (class B networks) of 314 private address space can be used. 316 One might be tempted to have both public and private addresses on the 317 same physical medium. While this is possible, there are pitfalls to 318 such a design (note that the pitfalls have nothing to do with the use 319 of private addresses, but are due to the presence of multiple IP 320 subnets on a common Data Link subnetwork). We advise caution when 321 proceeding in this area. 323 It is strongly recommended that routers which connect enterprises to 324 external networks are set up with appropriate packet and routing 325 filters at both ends of the link in order to prevent packet and 326 routing information leakage. An enterprise should also filter any 327 private networks from inbound routing information in order to protect 328 itself from ambiguous routing situations which can occur if routes to 329 the private address space point outside the enterprise. 331 It is possible for two sites, who both coordinate their private 332 address space, to communicate with each other over a public network. 333 To do so they must use some method of encapsulation at their borders 334 to a public network, thus keeping their private addresses private. 336 If two (or more) organizations follow the address allocation 337 specified in this document and then later wish to establish IP 338 connectivity with each other, then there is a risk that address 339 uniqueness would be violated. To minimize the risk it is strongly 340 Address Allocation for Private Internets January 1996 342 recommended that an organization using private IP addresses choose 343 randomly from the reserved pool of private addresses, when allocating 344 sub-blocks for its internal allocation. 346 If an enterprise uses the private address space, or a mix of private 347 and public address spaces, then DNS clients outside of the enterprise 348 should not see addresses in the private address space used by the 349 enterprise, since these addresses would be ambiguous. One way to 350 ensure this is to run two authority servers for each DNS zone 351 containing both publically and privately addressed hosts. One server 352 would be visible from the public address space and would contain only 353 the subset of the enterprise's addresses which were reachable using 354 public addresses. The other server would be reachable only from the 355 private network and would contain the full set of data, including the 356 private addresses and whatever public addresses are reachable the 357 private network. In order to ensure consistency, both servers should 358 be configured from the same data of which the publically visible zone 359 only contains a filtered version. There is certain degree of 360 additional complexity associated with providing these capabilities. 362 6. Security Considerations 364 Security Considerations are not addressed in this document. 366 7. Conclusion 368 With the described scheme many large enterprises will need only a 369 relatively small block of addresses from the globally unique IP 370 address space. The Internet at large benefits through conservation of 371 globally unique address space which will effectively lengthen the 372 lifetime of the IP address space. The enterprises benefit from the 373 increased flexibility provided by a relatively large private address 374 space. However, use of private addressing requires that an 375 organization renumber part or all of its enterprise network, as its 376 connectivity requirements change over time. 378 8. Acknowledgments 380 We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans- 381 Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN 382 Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne 383 Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), 384 Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), 385 Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush 386 (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg 387 Address Allocation for Private Internets January 1996 389 Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence), 390 Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet 391 Software Consortium) for their review and constructive comments. 393 9. References 395 [RFC1466] Gerich, E., "Guidelines for Management of IP Address 396 Space", RFC 1466, Merit Network, Inc., May 1993. 398 [RFC1518] Rekhter, Y., Li, T., "An Architecture for IP Address 399 Allocation with CIDR", September 1993 401 [RFC1519] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless 402 Inter-Domain Routing (CIDR): an Address Assignment and 403 Aggregation Strategy", September 1993 404 Address Allocation for Private Internets January 1996 406 10. Authors' Addresses 408 Yakov Rekhter 409 Cisco systems 410 170 West Tasman Drive 411 San Jose, CA, USA 413 Phone: +1 914 528 0090 414 Fax: +1 408 526-4952 415 EMail: yakov@cisco.com 417 Robert G Moskowitz 418 Chrysler Corporation 419 CIMS: 424-73-00 420 25999 Lawrence Ave 421 Center Line, MI 48015 423 Phone: +1 810 758 8212 424 Fax: +1 810 758 8173 425 EMail: rgm3@is.chrysler.com 427 Daniel Karrenberg 428 RIPE Network Coordination Centre 429 Kruislaan 409 430 1098 SJ Amsterdam, the Netherlands 432 Phone: +31 20 592 5065 433 Fax: +31 20 592 5090 434 EMail: Daniel.Karrenberg@ripe.net 435 Address Allocation for Private Internets January 1996 437 Geert Jan de Groot 438 RIPE Network Coordination Centre 439 Kruislaan 409 440 1098 SJ Amsterdam, the Netherlands 442 Phone: +31 20 592 5065 443 Fax: +31 20 592 5090 444 EMail: GeertJan.deGroot@ripe.net 446 Eliot Lear 447 Mail Stop 15-730 448 Silicon Graphics, Inc. 449 2011 N. Shoreline Blvd. 450 Mountain View, CA 94043-1389 452 Phone: +1 415 960 1980 453 Fax: +1 415 961 9584 454 EMail: lear@sgi.com