idnits 2.17.1
draft-azinger-additional-private-ipv4-space-issues-05.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See
https://trustee.ietf.org/license-info/)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
== There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses
in the document. If these are example addresses, they should be changed.
== There are 1 instance 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 copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 4, 2011) is 4860 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
-- Obsolete informational reference (is this intentional?): RFC 4423
(Obsoleted by RFC 9063)
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Azinger
3 Internet-Draft Frontier Communications
4 Intended status: Informational Corporation
5 Expires: July 8, 2011 L. Vegoda
6 ICANN
7 January 4, 2011
9 Issues Associated with Designating Additional Private IPv4 Address Space
10 draft-azinger-additional-private-ipv4-space-issues-05
12 Abstract
14 When a private network or internetwork grows very large it is
15 sometimes not possible to address all interfaces using private IPv4
16 address space because there are not enough addresses. This document
17 describes the problems faced by those networks, the available options
18 and the issues involved in assigning a new block of private IPv4
19 address space.
21 While this informational document does not make a recommendation for
22 action, it documents the issues surrounding the various options that
23 have been considered.
25 Status of this Memo
27 This Internet-Draft is submitted to IETF in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF), its areas, and its working groups. Note that
32 other groups may also distribute working documents as Internet-
33 Drafts.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 The list of current Internet-Drafts can be accessed at
41 http://www.ietf.org/ietf/1id-abstracts.txt.
43 The list of Internet-Draft Shadow Directories can be accessed at
44 http://www.ietf.org/shadow.html.
46 This Internet-Draft will expire on July 8, 2011.
48 Copyright Notice
49 Copyright (c) 2011 IETF Trust and the persons identified as the
50 document authors. All rights reserved.
52 This document is subject to BCP 78 and the IETF Trust's Legal
53 Provisions Relating to IETF Documents
54 (http://trustee.ietf.org/license-info) in effect on the date of
55 publication of this document. Please review these documents
56 carefully, as they describe your rights and restrictions with respect
57 to this document. Code Components extracted from this document must
58 include Simplified BSD License text as described in Section 4.e of
59 the Trust Legal Provisions and are provided without warranty as
60 described in the BSD License.
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
65 2. Large Networks . . . . . . . . . . . . . . . . . . . . . . . . 3
66 3. Non-Unique Addresses . . . . . . . . . . . . . . . . . . . . . 3
67 3.1. Subscriber Use Network Address Translation . . . . . . . . 3
68 3.2. Carrier Grade Network Address Translation . . . . . . . . 4
69 4. Available Options . . . . . . . . . . . . . . . . . . . . . . 4
70 4.1. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 4
71 4.1.1. Unique Globally Scoped IPv6 Unicast Addresses . . . . 4
72 4.1.2. Unique Local IPv6 Unicast Addresses . . . . . . . . . 4
73 4.2. IPv4 Options . . . . . . . . . . . . . . . . . . . . . . . 5
74 4.2.1. Address Transfers or Leases From Organizations
75 with Available Address Space . . . . . . . . . . . . . 5
76 4.2.2. Using Unannounced Address Space Allocated to
77 Another Organization . . . . . . . . . . . . . . . . . 5
78 4.2.3. Unique IPv4 Space Registered by an RIR . . . . . . . . 6
79 5. Options and Consequences for Defining New Private Use Space . 6
80 5.1. Redefining Existing Unicast Space as Private Address
81 Space . . . . . . . . . . . . . . . . . . . . . . . . . . 6
82 5.2. Unique IPv4 Space Shared by a Group of Operators . . . . . 7
83 5.3. Potential Consequences of Not Redefining Existing
84 Unicast Space as Private Address Space . . . . . . . . . . 8
85 5.4. Redefining Future Use Space as Unicast Address Space . . . 8
86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
90 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
91 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
94 1. Introduction
96 [RFC1918] sets aside three blocks of IPv4 address space for use in
97 private networks: 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8.
98 These blocks can be used simultaneously in multiple, separately
99 managed networks without registration or coordination with IANA or
100 any Internet registry. Very large networks can find that they need
101 to number more device interfaces than there are available addresses
102 in these three ranges. It has occasionally been suggested that
103 additional private IPv4 address space should be reserved for use by
104 these networks. Although such an action might address some of the
105 needs for these very large network operators it is not without
106 consequences, particularly as we near the date when the IANA free
107 pool will be fully allocated.
109 2. Large Networks
111 The main categories of very large networks using private address
112 space are: cable operators, wireless (cell phone) operators, private
113 internets and VPN service providers. In the case of the first two
114 categories, the complete address space reserved in [RFC1918] tends to
115 be used by a single organization. In the case of private internets
116 and VPN service providers there are multiple independently managed
117 and operated networks and the difficulty is in avoiding address
118 clashes.
120 3. Non-Unique Addresses
122 3.1. Subscriber Use Network Address Translation
124 The address space set aside in [RFC1918] is a finite resource which
125 can be used to provide limited Internet access via Network Address
126 Translation (NAT). A discussion of the advantages and disadvantages
127 of NATs is outside the scope of this document but a an analysis of
128 the advantages, disadvantages and architectural implications can be
129 found in [RFC2993]. Nonetheless, it must be acknowledged that NAT is
130 adequate in some situations and not in others. For instance, it
131 might technically feasible to use NAT or even multiple layers of NAT
132 within the networks operated by residential users or corporations
133 where only limited Internet access is required. A more detailed
134 analysis can be found in [RFC3022]. Where true peer to peer
135 communication is needed or where services or applications do not work
136 properly behind NAT, globally unique address space is required. In
137 other cases, NAT traversal techniques facilitate peer-to-peer like
138 communication for devices behind NATs.
140 In many cases it is possible to use multiple layers of NAT to re-use
141 parts of the address space defined in [RFC1918]. It is not always
142 possible to rely on CPE devices using any particular range, however.
143 In some cases this means that unorthodox workarounds including
144 assigning CPE devices unallocated address space or address space
145 allocated to other network operators are feasible. In other cases,
146 organizations choose to operate multiple separate routing domains to
147 allow them to re-use the same private address ranges in multiple
148 contexts. One consequence of this is the added complexity involved
149 in identifying which system is referred to when an IP address is
150 identified in a log or management systems.
152 3.2. Carrier Grade Network Address Translation
154 Another option is to share one address across multiple interfaces and
155 in some cases, subscribers. This model breaks the classical model
156 used for logging address assignments and creates significant risks
157 and additional burdens, as described in [CLAYTON] and more fully
158 discussed in [FORD] and is documented in [DS-LITE].
160 4. Available Options
162 When a network operator has exhausted the private address space set
163 aside in [RFC1918] but needs to continue operating a single routing
164 domain a number of options are available. These include:
166 4.1. IPv6 Options
168 4.1.1. Unique Globally Scoped IPv6 Unicast Addresses
170 Using unique, globally scoped IPv6 unicast addresses is the best
171 permanent solution as it removes any concerns about address scarcity
172 within the next few decades. Implementing IPv6 is a major endeavor
173 for service providers with millions of consumer customers and is
174 likely to take considerable effort and time. In some cases
175 implementing a new network protocol on a very large network takes
176 more time than is available, based on network growth and the
177 proportion of private space that has already been used. In these
178 cases, there is a call for additional private address space that can
179 be shared by all network operators. [DAVIES] makes one such case.
181 4.1.2. Unique Local IPv6 Unicast Addresses
183 Using the unique, local IPv6 unicast addresses defined in [RFC4193]
184 is another approach and does not require coordination with an
185 Internet registry. Although the addresses defined in [RFC4193] are
186 probabilistically unique, network operators on private internets and
187 those providing VPN services might not want to use them because there
188 is a very low probability of non-unique locally assigned global IDs
189 being generated by the algorithm. Also, in the case of private
190 internets, it can be very challenging to coordinate the introduction
191 of a new network protocol to support the internet's continued growth.
193 4.2. IPv4 Options
195 4.2.1. Address Transfers or Leases From Organizations with Available
196 Address Space
198 The Regional Internet Registry (RIR) communities have recently been
199 developing policies to allow organizations with available address
200 space to transfer such designated space to other organizations
201 [RIR-POLICY]. In other cases, leases might be arranged. This
202 approach is only viable for operators of very large networks if
203 enough address space is made available for transfer or lease and if
204 the very large networks are able to pay the costs of these transfers.
205 It is not possible to know how much address space will become
206 available in this way, when it will be available and how much it will
207 cost. However, it is unlikely to become available in large
208 contiguous blocks and this would add to the network management burden
209 for the operator as a significant number of small prefixes would
210 inflate the size of the operators routing table at a time when it is
211 also adding an IPv6 routing table. These reasons will make address
212 transfers a less attractive proposition to many large network
213 operators. Leases might not be attractive to some organizations if
214 both parties cannot agree a suitable length of time. Also, the
215 lessor might worry about its own unanticipated needs for additional
216 IPv4 address space.
218 4.2.2. Using Unannounced Address Space Allocated to Another
219 Organization
221 Some network operators have considered using IP address space which
222 is allocated to another organization but is not publicly visible in
223 BGP routing tables. This option is very strongly discouraged as the
224 fact that an address block is not visible from one view does not mean
225 that it is not visible from another. Furthermore, address usage
226 tends to leak beyond private network borders in e-mail headers, DNS
227 queries, traceroute output and other ways. The ambiguity this causes
228 is problematic for multiple organizations. This issue is discussed
229 in [RFC3879], section 2.3.
231 It is also possible that the registrant of the address block might
232 want to increase its visibility to other networks in the future,
233 causing problems for anyone using it unofficially. In some cases
234 there might also be legal risks involved in using address space
235 officially allocated to another organization.
237 Where this has happened in the past it has caused operational
238 problems [FASTWEB].
240 4.2.3. Unique IPv4 Space Registered by an RIR
242 RIRs policies allow network operators to receive unique IP addresses
243 for use on internal networks. Further, network operators are not
244 required to have already exhausted the private address space set
245 aside in [RFC1918]. Nonetheless, network operators are naturally
246 disinclined to request unique IPv4 addresses for the private areas of
247 their networks as using addresses in this way means they are not
248 available for use by new Internet user connections.
250 It is likely to become more difficult for network operators to obtain
251 large blocks of unique address space as we approach the point where
252 all IPv4 unicast /8s have been allocated. Several RIRs already have
253 policies how to allocate from their last /8 [RIR-POLICY-FINAL-8] and
254 there have been policy discussions that would reduce the maximum
255 allocation size available to network operators [MAX-ALLOC] or would
256 reduce the period of need for which the RIR can allocate
257 [SHORTER-PERIODS].
259 5. Options and Consequences for Defining New Private Use Space
261 5.1. Redefining Existing Unicast Space as Private Address Space
263 It is possible to re-designate a portion of the current global
264 unicast IPv4 address space as private unicast address space. Doing
265 this could benefit a number of operators of large network for the
266 short period before they complete their IPv6 roll-out. However, this
267 benefit incurs a cost by reducing the pool of global unicast
268 addresses available to users in general.
270 When discussing re-designating a portion of the current global
271 unicast IPv4 address space as private unicast address space it is
272 important to consider how much space would be used and for how long
273 it would be sufficient. Not all of the large networks making full
274 use of the space defined in [RFC1918] would have their needs met with
275 a single /8. In 2005, [HAIN] suggested reserving three /8s for this
276 purpose while in 2009 [DAVIES] suggested a single /10 would be
277 sufficient. There does not seem to be a consensus for a particular
278 prefix length nor an agreed basis for deciding what is sufficient.
279 The problem is exacerbated by the continually changing needs of ever
280 expanding networks.
282 A further consideration is which of the currently unallocated IPv4
283 unicast /8 blocks should be used for this purpose. Using address
284 space which is known to be used unofficially is tempting. For
285 instance, 1.0.0.0/8, which was unallocated until January 2010, was
286 proposed in [HAIN] and is known to be used by a number of different
287 users. These include networks making use of HIP LSIs [RFC4423],
288 [WIANA], [anoNet] and others. There is anecdotal [VEGODA] and
289 research [WESSELS] evidence to suggest that several other IPv4 /8s
290 are used in this fashion. Also there have been discussions [NANOG]
291 about some sections of these /8's being carved out and filtered
292 therefore unofficially enabling the use of these sections for private
293 use.
295 Although new IPv4 /8s are allocated approximately once a month, they
296 are not easy to bring into use because network operators are slow to
297 change their filter configurations. This is despite long-running
298 awareness campaigns [CYMRU], [LEWIS] and active work [ripe-351] to
299 notify people whose filters are not changed in a timely fashion.
300 Updating code that recognises private address space in deployed
301 software and infrastructure systems is likely to be far more
302 difficult as many systems have these ranges hard-coded and cannot be
303 quickly changed with a new configuration file.
305 Another consideration when redefining existing unicast space as
306 private address space is that no single class of user can expect the
307 space to stay unique to them. This means that an ISP using a new
308 private address range cannot expect its customers not to already be
309 using that address range within their own networks.
311 5.2. Unique IPv4 Space Shared by a Group of Operators
313 Where a group of networks find themselves in a position where they
314 each need a large amount of IPv4 address space from an RIR in
315 addition to that defined in [RFC1918] they might cooperatively agree
316 to all use the same address space to number their networks. The
317 clear benefit to this approach is that it significantly reduces the
318 potential demand on the pool of unallocated IPv4 address space.
319 However, the issues discussed in 4.4 could also be of concern here,
320 particularly the possibility that one operator might decide to use
321 the address space to number customer connections, rather than private
322 infrastructure.
324 Nonetheless, this approach has the potential to create an unofficial
325 new private address range without proper scrutiny.
327 5.3. Potential Consequences of Not Redefining Existing Unicast Space as
328 Private Address Space
330 If additional private address space is not defined and the large
331 network operators affected by this problem are not able to solve
332 their problems with IPv6 address space or by segmenting their
333 networks into multiple routing domains, those networks will need
334 unique IPv4 addresses. It is possible and even likely that a single
335 network could consume a whole IPv4 /8 in a year. At the time of
336 writing there are just 24 unallocated IPv4 /8s, so it would not take
337 many such requests to make a major dent in the available IPv4 address
338 space. [POTAROO] provides an analysis of IPv4 address consumption
339 and projects the date on which the IANA and RIR pools will be fully
340 allocated.
342 5.4. Redefining Future Use Space as Unicast Address Space
344 There have also been proposals to re-designate the former Class E
345 space (240.0.0.0/4) as unicast address space. [WILSON] suggests that
346 it should be privately scoped while [FULLER] does not propose a
347 scope. Both proposals note that existing deployed equipment may not
348 be able to use addresses from 240.0.0.0/4. Potential users would
349 need to be sure of the status of the equipment on their network and
350 the networks with which they intend to communicate.
352 It is not immediately clear how useful 240.0.0.0/4 could be in
353 practice. While [FULLER] documents the status of several popular
354 desktop and server operating systems, the status of the most widely
355 deployed routers and switches is less clear and it is possible that
356 240.0.0.0/4 might only be useful in very large, new green field
357 deployments where full control of all deployed systems is available.
358 However, in such cases it might well be easier to deploy an IPv6
359 network.
361 6. Security Considerations
363 This document has no security implications.
365 7. IANA Considerations
367 This document makes no request of IANA.
369 8. References
370 8.1. Normative References
372 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
373 E. Lear, "Address Allocation for Private Internets",
374 BCP 5, RFC 1918, February 1996.
376 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
377 November 2000.
379 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
380 Address Translator (Traditional NAT)", RFC 3022,
381 January 2001.
383 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
384 Addresses", RFC 4193, October 2005.
386 8.2. Informative References
388 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
389 Addresses", RFC 3879, September 2004.
391 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
392 (HIP) Architecture", RFC 4423, May 2006.
394 [anoNet] anoNet, "anoNet: Cooperative Chaos",
395 .
397 [CLAYTON] Clayton, R., "Practical mobile Internet access
398 traceability", January 2010, .
402 [CYMRU] Greene, B., "The Bogon Reference",
403 .
405 [DAVIES] Davies, G. and C. Liljenstolpe, "Work in Progress:
406 Transitional non-conflicting reusable IPv4 address block",
407 November 2009, .
410 [DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Work in
411 Progress: Dual-Stack Lite Broadband Deployments Following
412 IPv4 Exhaustion", August 2010, .
415 [FASTWEB] Aina, A., "41/8 announcement", May 2006,
416 .
418 [FORD] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
419 Roberts, "Work in Progress: Issues with IP Address
420 Sharing", March 2010, .
423 [FULLER] Fuller, V., Lear, E., and D. Meyer, "Work in Progress:
424 Reclassifying 240/4 as usable unicast address space",
425 March 2008,
426 .
428 [HAIN] Hain, T., "Work in Progress: Expanded Address Allocation
429 for Private Internets", January 2005,
430 .
432 [LEWIS] Lewis, J., "This system has been setup for testing
433 purposes for 69/8 address space", March 2003,
434 .
436 [MAX-ALLOC]
437 Spenceley, J. and J. Martin, "prop-070: Maximum IPv4
438 allocation size", January 2009,
439 .
441 [NANOG] Dickson, B., "1/8 and 27/8 allocated to APNIC",
442 January 2010, .
445 [POTAROO] Huston, G., "IPv4 Address Report",
446 .
448 [ripe-351]
449 Karrenberg, D., "De-Bogonising New Address Blocks",
450 October 2005,
451 .
453 [RIR-POLICY]
454 Number Resource Organization, "RIR Comparative Policy
455 Overview, October 2009, Section 1.3.2 Transfer of
456 Custodianship",
457 .
459 [RIR-POLICY-FINAL-8]
460 Number Resource Organization, "RIR Comparative Policy
461 Overview, October 2009, 2.6. Use of Final Unallocated IPv4
462 Address Space", October 2009,
463 .
465 [SHORTER-PERIODS]
466 Karrenberg, D., O'Reilly, N., Titley, N., and R. Bush,
467 "RIPE Policy Proposal 2009-03", April 2009,
468 .
471 [VEGODA] Vegoda, L., "Awkward /8 Assignments", September 2007, .
475 [WESSELS] Wessels, D., "Searching for Evidence of Unallocated
476 Address Space Usage in DITL 2008 Data", June 2008, .
480 [WIANA] WIANA, "The Wireless Internet Assigned Numbers Authority",
481 .
483 [WILSON] Wilson, P., Michaelson, G., and G. Huston, "Work in
484 Progress: Redesignation of 240/4 from "Future Use" to
485 "Private Use"",
486 .
488 Appendix A. Acknowledgments
490 The authors would also like to thank Ron Bonica, Michelle Cotton, Lee
491 Howard and Barbara Roseman for their assistance in early discussions
492 of this document and to Maria Blackmore, Alex Bligh, Mat Ford, Thomas
493 Narten, Ricardo Patara and for improvement suggestions.
495 Authors' Addresses
497 Marla Azinger
498 Frontier Communications Corporation
499 Vancouver, WA
500 United States of America
502 Email: marla.azinger@ftr.com
503 URI: http://www.frontiercorp.com/
504 Leo Vegoda
505 Internet Corporation for Assigned Names and Numbers
506 4676 Admiralty Way, Suite 330
507 Marina del Rey, CA 90292
508 United States of America
510 Phone: +1-310-823-9358
511 Email: leo.vegoda@icann.org
512 URI: http://www.iana.org/