idnits 2.17.1 draft-ietf-cidrd-private-addr-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-16) 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 10 instances of too long lines in the document, the longest one being 3 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: ---------------------------------------------------------------------------- == Line 66 has weird spacing: '...revisit addre...' == Line 205 has weird spacing: '...will be publi...' -- 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 (July 1995) is 10503 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 (~~), 5 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 July 1995 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 between all hosts 44 inside an enterprise as well as between 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 July 1995 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 [CITE growth 61 ietf proceedings)]. One challenge is a concern within the community 62 that globally unique address space will be exhausted. A separate and 63 far more pressing concern is that the amount of routing overhead will 64 grow beyond the capabilities of Internet Service Providers. Efforts 65 progress within the community to find long term solutions to both 66 these problems. Meanwhile it is necessary to revisit address 67 allocation procedures, and their impact on the Internet routing 68 system. 70 Acquiring globally unique addresses from an Internet registry is no 71 longer sufficient to achieve Internet-wide IP connectivity. In the 72 past assignment of globally unique addresses had been sufficient to 73 insure Internet-wide reachability to these addresses. To contain 74 growth of routing overhead, an Internet Provider obtains a block of 75 address space from an address registry, and then assigns to its 76 customers addresses from within that block based on each customer 77 requirement. The result of this process is that routes to many 78 customers will appear to other providers as a single route [RFC1518], 79 [RFC1519]. 81 In order for route aggregation to be effective, Internet providers 82 encourage customers joining their network to use the provider's 83 block, and thus renumber their computers. Such encouragement may 84 become a requirement in the future. With the current size of the 85 Internet and its growth rate it is no longer realistic to assume that 86 by virtue of acquiring globally unique IP addresses out of an 87 Internet registry an organization that acquires such addresses would 88 have Internet-wide IP connectivity once the organization gets 89 connected to the Internet. To the contrary, it is quite likely that 90 when the organization would connect to the Internet to achieve 91 Internet-wide IP connectivity the organization would need to change 92 IP addresses (renumber) all of its public hosts (hosts that require 93 Internet-wide IP connectivity), regardless of whether the addresses 94 used by the organization initially were globally unique or not. 96 Address Allocation for Private Internets July 1995 98 The current practice is to assign globally unique addresses to all 99 hosts that use TCP/IP. In order to extend the life of the IPv4 100 address space, address registries are requiring more justification 101 than ever before, making it harder for organizations to acquire 102 additional address space [RFC1466]. 104 Hosts within enterprises that use IP can be partitioned into three 105 categories: 107 Category 1: hosts that do not require access to hosts in other 108 enterprises or the Internet at large; hosts within 109 this category may use IP addresses that are unambiguous 110 within an enterprise, but may be ambiguous between 111 enterprises. 113 Category 2: hosts that need access to a limited set of outside 114 services (e.g., E-mail, FTP, netnews, remote login) 115 which can be handled by application layer gateways. 116 for many hosts in this category an unrestricted external 117 access (provided via IP connectivity) may be unnecessary 118 and even undesirable for privacy/security reasons. 119 Just like hosts within the first category, such hosts 120 may use IP addresses that are unambiguous within an 121 enterprise, 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 135 to identify a substantial number of hosts using TCP/IP that do not 136 need 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 July 1995 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 (e.g., firewalls) to connect their internal network to 156 the Internet. The internal network usually does not have direct 157 access to the Internet, thus only one or more firewall hosts are 158 visible from the Internet. In this case, the internal network 159 can use non-unique IP 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 182 used by many enterprises. Addresses within this private address 183 space will only be unique within the enterprise, or the set of 184 enterprises which choose to cooperate over this space so they may 185 communicate with each 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 July 1995 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 201 not having external (outside of the enterprise) IP connectivity 202 private hosts can still have access to external services via 203 application layer relays. 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. 215 Because private addresses have no global meaning, routing information 216 about private networks shall not be propagated on inter-enterprise 217 links, and packets with private source or destination addresses 218 should not be forwarded across such links. Routers in networks not 219 using private address space, especially those of Internet service 220 providers, are expected to be configured to reject (filter out) 221 routing information about private networks. If such a router 222 receives such information the rejection shall not be treated as a 223 routing protocol error. 225 Indirect references to such addresses should be contained within the 226 enterprise. Prominent examples of such references are DNS Resource 227 Records and other information referring to internal private 228 addresses. In particular, Internet service providers should take 229 measures to prevent such leakage. 231 4. Advantages and Disadvantages of Using Private Address Space 233 The obvious advantage of using private address space for the Internet 234 at large is to conserve the globally unique address space by not 235 using it where global uniqueness is not required. 237 Enterprises themselves also enjoy a number of benefits from their 238 usage of private address space: They gain a lot of flexibility in 239 Address Allocation for Private Internets July 1995 241 network design by having more address space at their disposal than 242 they could obtain from the globally unique pool. This enables 243 operationally and administratively convenient addressing schemes as 244 well as easier growth paths. 246 For a variety of reasons the Internet has already encountered 247 situations where an enterprise that has not been connected to the 248 Internet had used IP address space for its hosts without getting this 249 space assigned from the IANA. In some cases this address space had 250 been already assigned to other enterprises. When such an enterprise 251 later connects to the Internet, it could potentially create very 252 serious problems, as IP routing cannot provide correct operations in 253 presence of ambiguous addressing. Using private address space 254 provides a safe choice for such enterprises, avoiding clashes once 255 outside connectivity is needed. 257 A major drawback to the use of private address space is that it may 258 actually reduce an enterprise's flexibility to access the Internet. 259 Once one commits to using a private address, one is committing to 260 renumber all or part of an enterprise, should one decide to route an 261 entire enterprise to the Internet. Usually the cost of renumbering 262 can be measured by counting the number of hosts that have to 263 transition from private to public. As was discussed earlier, 264 however, even if a network uses globally unique addresses, it may 265 still have to renumber. Although not the case today, it is likely 266 that renumbering may be necessary, regardless of whether private or 267 public address space is used. 269 The cost of renumbering may well be mitigated by development and 270 deployment of tools that facilitate renumbering, make use of Dynamic 271 Host Configuration Protocol (DHCP). When deciding whether to use 272 private addresses, we recommend that one consult computer and 273 software vendors about availability of such tools. 275 If we review the examples we list in Section 2, we note that banks 276 tend to merge, as do companies with firewalls. Therefore it may be 277 advisable to discuss with management the implications of private 278 networks. 280 5. Operational Considerations 282 A recommended strategy is to design the private part of the network 283 first and use private address space for all internal links. Then 284 plan public subnets at the locations needed and design the external 285 connectivity. 287 This design is not fixed permanently. If a number of hosts require 288 to change status later this can be accomplished by renumbering only 289 Address Allocation for Private Internets July 1995 291 the hosts involved and installing another physical subnet if 292 required. 294 If a suitable subnetting scheme can be designed and is supported by 295 the equipment concerned, it is advisable to use the 24-bit block of 296 private address space and make an addressing plan with a good growth 297 path. If subnetting is a problem, the block of 255 /24 prefixes can 298 be used. 300 One might be tempted to have both public and private addresses on the 301 same physical medium. While this is possible, there are pitfalls to 302 such a design. We advise caution when proceeding in this area. 304 Moving a single host between private and public status will involve a 305 change of address and in most cases physical connectivity. In 306 locations where such changes can be foreseen (machine rooms etc.) it 307 may be advisable to configure separate physical media for public and 308 private subnets to facilitate such changes. 310 Changing the status of all hosts on a whole (sub)network can be done 311 easily and without disruption for the enterprise network as a whole. 312 Consequently it is advisable to group hosts whose connectivity needs 313 might undergo similar changes in the future on their own subnets. 315 It is strongly recommended that routers which connect enterprises to 316 external networks are set up with appropriate packet and routing 317 filters at both ends of the link in order to prevent packet and 318 routing information leakage. An enterprise should also filter any 319 private networks from inbound routing information in order to protect 320 itself from ambiguous routing situations which can occur if routes to 321 the private address space point outside the enterprise. 323 It is possible for two sites who both coordinate their private 324 address space to communicate with each other over a public network. 325 To do so they must use some method of encapsulation at their borders 326 to a public network, thus keeping their private addresses private. 328 If two (or more) organizations follow the address allocation 329 specified in this document and then later wish to establish IP 330 connectivity with each other, then there is a risk that address 331 uniqueness would be violated. To minimize the risk it is strongly 332 recommended that an organization that decides to use addresses out of 333 the blocks specified in this document selects a random contiguous 334 sub-block(s) for its internal allocation. 336 A possible approach to avoid leaking of DNS RRs is to run two 337 nameservers, one external server authoritative for all globally 338 unique IP addresses of the enterprise and one internal nameserver 339 Address Allocation for Private Internets July 1995 341 authoritative for all IP addresses of the enterprise, both public and 342 private. In order to ensure consistency both these servers should be 343 configured from the same data of which the external nameserver only 344 receives a filtered version. 346 The resolvers on all internal hosts, both public and private, query 347 only the internal nameserver. The external server resolves queries 348 from resolvers outside the enterprise and is linked into the global 349 DNS. The internal server forwards all queries for information 350 outside the enterprise to the external nameserver, so all internal 351 hosts can access the global DNS. This ensures that information about 352 private hosts does not reach resolvers and nameservers outside the 353 enterprise. 355 6. References 357 [RFC1466] Gerich, E., "Guidelines for Management of IP Address 358 Space", RFC 1466, Merit Network, Inc., May 1993. 360 [RFC1518] 362 [RFC1519] 364 7. Security Considerations 366 While using private address space can improve security, it is not a 367 substitute for dedicated security measures. 369 8. Conclusion 371 With the described scheme many large enterprises will need only a 372 relatively small block of addresses from the globally unique IP 373 address space. The Internet at large benefits through conservation 374 of globally unique address space which will effectively lengthen the 375 lifetime of the IP address space. The enterprises benefit from the 376 increased flexibility provided by a relatively large private address 377 space. However, use of private addressing requires that an 378 organization renumber part or all of its enterprise network, as its 379 needs change over time. 381 9. Acknowledgments 383 We would like to thank Tony Bates (RIPE NCC), Jordan Becker (ANS), 384 Hans-Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran 385 (NEARNET), Vince Fuller (Barrnet), Tony Li (cisco Systems), Anne Lord 386 Address Allocation for Private Internets July 1995 388 (RIPE NCC), Milo Medin (NSI), Marten Terpstra (RIPE NCC), Geza 389 Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy 390 Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), 391 Erik Fair (Apple Computer), Dave Crocker (XXX), Tom Kessler (SGI), 392 and Dave Piscitello (Core Competence) for their review and 393 constructive comments. 395 Address Allocation for Private Internets July 1995 397 10. Authors' Addresses 399 Yakov Rekhter 400 Cisco systems 401 170 West Tasman Drive 402 San Jose, CA, USA 404 Phone: +1 914 528 0090 405 Fax: +1 408 526-4952 406 EMail: yakov@cisco.com 408 Robert G Moskowitz 409 Chrysler Corporation 410 CIMS: 424-73-00 411 25999 Lawrence Ave 412 Center Line, MI 48015 414 Phone: +1 810 758 8212 415 Fax: +1 810 758 8173 416 EMail: rgm3@is.chrysler.com 418 Daniel Karrenberg 419 RIPE Network Coordination Centre 420 Kruislaan 409 421 1098 SJ Amsterdam, the Netherlands 423 Phone: +31 20 592 5065 424 Fax: +31 20 592 5090 425 EMail: Daniel.Karrenberg@ripe.net 426 Address Allocation for Private Internets July 1995 428 Geert Jan de Groot 429 RIPE Network Coordination Centre 430 Kruislaan 409 431 1098 SJ Amsterdam, the Netherlands 433 Phone: +31 20 592 5065 434 Fax: +31 20 592 5090 435 EMail: GeertJan.deGroot@ripe.net 437 Eliot Lear 438 Mail Stop 15-730 439 Silicon Graphics, Inc. 440 2011 N. Shoreline Blvd. 441 Mountain View, CA 94043-1389 443 Phone: +1 415 960 1980 444 Fax: +1 415 961 9584 445 EMail: lear@sgi.com