Network Working Group T. Narten Internet-Draft IBM Intended status: Informational November 12, 2007 Expires: May 15, 2008 IETF Statement on IPv4 Exhaustion and IPv6 Deployment draft-narten-ipv6-statement-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Narten Expires May 15, 2008 [Page 1] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 Abstract Over the last year, the Internet community has slowly come to realize that the IANA and RIR IPv4 free address pool will be exhausted within no more than 3-4 years, and possibly sooner. At that point, it will become increasingly difficult for ISPs and end sites to obtain the public IPv4 address space they need to expand operations. IPv6 was developed to address the IPv4 address exhaustion problem, but widespread deployment has barely begun. This document reiterates the IETF's support and continued commitment to IPv6. IPv6 deployment is still necessary to ensure the continued growth and expansion of the Internet. Deployment of IPv6 is needed to preserve important Internet properties that have made it a success and enable new generations of applications and services. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Exhaustion of the IPv4 Free Pool . . . . . . . . . . . . . . . 4 3. The Need for IPv6 . . . . . . . . . . . . . . . . . . . . . . 5 4. The State of IPv6 . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Narten Expires May 15, 2008 [Page 2] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 1. Introduction Over the last year, the Internet community has come to realize that the IANA and RIR free pool of IPv4 addresses will be exhausted within 3-4 years, and possibly sooner. For example, Geoff Huston's "IPv4 Address Report" [1] strongly suggests that IANA free pool will be exhausted by summer 2010, with the remaining RIR pool exhausted by summer 2011. However, even these projections are conservative, and the actual dates may well occur sooner. The model assumes that the rate of address space consumption will follow "recent history" and not change as the free pool dwindles, and that there will be no "rush" by ISPs and end sites to obtain additional address space before the free pool is exhausted. Other reports also suggest that the free pool will be exhausted soon [2]. In the last few months, ICANN [3] and each of the five Regional Internet Registries (RIRs) have issued statements warning the community of the impending free pool exhaustion and encouraging the community to deploy IPv6 (AFRINIC [4], APNIC [5], ARIN [6], LACNIC [7], RIPE [8]). IPv6 was developed to address the IPv4 address exhaustion problem [RFC1752][RFC1726]. And although IPv6 has been widely implemented in commercial and other products, widespread deployment has barely begun. This document reiterates the IETF's support and commitment to IPv6. IPv6 deployment is necessary to ensure the continued growth and expansion of the Internet. Deployment of IPv6 is needed to preserve the important properties of the Internet that have made it a success and enable new generations of applications and services. Narten Expires May 15, 2008 [Page 3] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 2. Exhaustion of the IPv4 Free Pool Today's Internet already suffers from address shortages. The need to conserve public address space has led the RIRs to adopt address assignment policies that demand a high utilization of address space; ISPs and end sites are required to show use of 80% of their existing address space in order to qualify for more. In practice, many users already feel that obtaining IPv4 address space is "too hard". In practice, it is often easier and more convenient to use Network Address Translation (NAT) than to obtain public address space. The exact point at which the IPv4 free pool will become exhausted is more a matter of academic than practical interest. Exhaustion of the free pool doesn't mean that the IPv4 internet will suddenly stop working; indeed, it will continue working as it already does -- devices that already have assigned addresses will continue to work as they did before. However, sites needing additional addresses to support growth will find the cost and overhead of managing and finding available IPv4 address space to increase. Holders of existing address space may be able to squeeze out additional usable addresses by more aggressively managing their existing resources. It may also be possible to purchase address space on an open market, should a market develop as some expect. Increased reliance upon and use of NAT, including within single organizations, is also likely to occur. While some steps could be taken to alleviate some aspects of the looming IPv4 address shortage (e.g., attempt to return underutilized address space to the free pool, attempt to make use of "reserved" space [draft-fuller-240space-00.txt], etc.), such steps are tactical at best and do not address the Internet's fundamental need to have sufficient address space. The IPv4 free pool is currently being consumed at a rate of more than 10 /8s per year, a demand that cannot realistically be satiated by tactical steps that only satisfy a few months of demand. In summary, the exhaustion of the IPv4 free pool means that the cost of managing and finding usable IPv4 address space will increase, perhaps sharply. That cost is already increasing today, and will likely increase more rapidly once the free pool is fully depleted. In addition, increased usage of NAT will increase operational costs, due to the inherent limitations of NAT [RFC2993]. The amount of pain this causes will vary from one organization to another, depending heavily on how fast the organization is growing, the rate of network expansion, and the types of services that need to be supported. Narten Expires May 15, 2008 [Page 4] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 3. The Need for IPv6 IPv6 was developed to address the inherent address size limitations of IPv4 [RFC1752][RFC1726]. Because addressing this limitation required changing the basic IP packet format (i.e., making incompatible changes to IPv4), additional features and benefits were added as well. While some of those changes have benefits for specific environments, it is IPv6's expanded addressing capability that provides its key value. Indeed, a number of the "improvements" that were originally developed for IPv6 have since been retrofitted back into IPv4 (e.g., IPsec (security) and Differentiated Services (QOS)). Other improvements (e.g., stateless address autoconfiguration, multiple address support, etc.), while important, do not appear to be sufficiently compelling on their own to justify the significant effort involved in IPv6 deployment. Hence, the key IPv6 value derives from its vastly increased address space, which simply cannot be retrofitted into IPv4. IPv6's address space is needed to ensure the continued growth of the Internet, namely, the ability for all devices to connect to the network as first-class citizens. o One of the most important architectural principles underpinning the Internet design is its support for the end-to-end principle [RFC1958]. To support that principle, every device must be able to have its own public address, so that communication with any other Internet node is possible. While support for the end-to-end model has already eroded somewhat, depletion of the free pool threatens to accelerate the trend. o Network Address Translation does not solve IPv4's address limitations; it is at best a tactical approach: * NATs generally work only in simple deployment scenarios characterized by simple clients (e.g., browsers) communicating with servers on the public Internet. * A basic assumption of NAT is that a small number of public IPv4 addresses can be shared by a large number of simple clients. This assumption breaks down when large numbers of devices want to be "servers" and accept connections initiated by others. Session establishment between a client and a server becomes more complex in a NAT scenario with the traditional IETF protocols, and might not even be possible. * Inherent limitations of NATs cause subtle and hard-to-diagnose operational problems. Increased use of NAT will lead to an increasingly brittle Internet -- the exact opposite of what is Narten Expires May 15, 2008 [Page 5] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 required in an Internet infrastructure that is increasingly viewed as basic critical infrastructure, like electricity or water. * Some protocols do not work correctly when NATs are present, and cannot always be made to work correctly. This is especially true for peer-to-peer type protocols that do not follow the simple client-server model, or security protocols that view the translations made by NAT devices as security violations. There is a real danger that entire classes of applications (i.e., new, innovative services) simply cannot be deployed and built on an Internet in which NATs are widespread. Narten Expires May 15, 2008 [Page 6] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 4. The State of IPv6 IPv6 (as a standard) is finished and has been widely implemented in products. It is ready for deployment today and the community is urged to begin deployment in earnest. But like with any significant service roll out, advance planning is necessary and some road bumps can be expected in local circumstances and with individual products. IT departments are urged to work closely with vendors to ensure that the necessary IPv6-enabled products will be available within an appropriate time frame. Like with IPv4 (which was "completed" in the early 1980s), the IETF continues (and will continue to) to work on individual technologies, but believes that "core" IPv6 work has been completed and done. But like with IPv4 before it, there will always be individual technologies and individual protocols that require extension or improvement as more experience is gained. As more experience with IPv6 is gained, the IETF stands ready to do additional IPv6-related work as justified. Originally, it was expected that IPv6 would be rolled out before IPv4 address exhaustion occurred. But that does not appear to be happening, given the current state of IPv6 deployment and the size of IPv4 free pool. The key issue is the lack of a short-term return on investment (ROI) for early deployers. The benefits of IPv6 are all long-term, with the cost/benefit assessment difficult to make in concrete dollar terms. Narten Expires May 15, 2008 [Page 7] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 5. Security Considerations TBD Narten Expires May 15, 2008 [Page 8] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 6. IANA Considerations This document contains no IANA actions. Narten Expires May 15, 2008 [Page 9] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 7. Acknowledgments This document has been improved as a result of specific comments from Bob Hinden, Kurtis Lindqvist and Dave Thaler. Narten Expires May 15, 2008 [Page 10] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 8. Informative References [RFC1726] Partridge, C. and F. Kastenholz, "Technical Criteria for Choosing IP The Next Generation (IPng)", RFC 1726, December 1994. [RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995. [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [1] [2] [3] [4] [5] [6] [7] [8] Narten Expires May 15, 2008 [Page 11] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 Author's Address Thomas Narten IBM Email: narten@us.ibm.com Narten Expires May 15, 2008 [Page 12] Internet-Draft IETF Statement on IPv4 and IPv6 November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Narten Expires May 15, 2008 [Page 13]