Scalable Operation of Address Translators with Per-Interface Bindings
RFC 6619
Document | Type |
RFC - Proposed Standard
(June 2012; No errata)
Was draft-arkko-dual-stack-extra-lite (individual in int area)
|
|
---|---|---|---|
Authors | Jari Arkko , Lars Eggert , Mark Townsley | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 6619 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ralph Droms | ||
Send notices to | (None) |
Internet Engineering Task Force (IETF) J. Arkko Request for Comments: 6619 Ericsson Category: Standards Track L. Eggert ISSN: 2070-1721 NetApp M. Townsley Cisco June 2012 Scalable Operation of Address Translators with Per-Interface Bindings Abstract This document explains how to employ address translation in networks that serve a large number of individual customers without requiring a correspondingly large amount of private IPv4 address space. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6619. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Arkko, et al. Standards Track [Page 1] RFC 6619 Scalable NATs June 2012 1. Introduction This document explains how to employ address translation without consuming a large amount of private address space. This is important in networks that serve a large number of individual customers. Networks that serve more than 2^24 (16 million) users cannot assign a unique private IPv4 address to each user, because the largest reserved private address block reserved is 10/8 [RFC1918]. Many networks are already hitting these limits today -- for instance, in the consumer Internet service market. Even some individual devices may approach these limits -- for instance, cellular network gateways or mobile IP home agents. If ample IPv4 address space were available, this would be a non-issue, because the current practice of assigning public IPv4 addresses to each user would remain viable, and the complications associated with using the more limited private address space could be avoided. However, as the IPv4 address pool is becoming depleted, this practice is becoming increasingly difficult to sustain. It has been suggested that more of the unassigned IPv4 space should be converted for private use, in order to allow the provisioning of larger networks with private IPv4 address space. At the time of this writing, the IANA "free pool" contained only 12 unallocated unicast IPv4 /8 prefixes. Although reserving a few of those for private use would create some breathing room for such deployments, it would not result in a solution with long-term viability. It would result in significant operational and management overheads, and it would further reduce the number of available IPv4 addresses. Segmenting a network into areas of overlapping private address space is another possible technique, but it severely complicates the design and operation of a network. Finally, the transition to IPv6 will eventually eliminate these addressing limitations. However, during the migration period when IPv4 and IPv6 have to coexist, address or protocol translation will be needed in order to reach IPv4 destinations. The rest of this document is organized as follows. Section 2 gives an outline of the solution, Section 3 introduces some terms, Section 4 specifies the required behavior for managing NAT bindings, and Section 5 discusses the use of this technique with IPv6. Arkko, et al. Standards Track [Page 2] RFC 6619 Scalable NATs June 2012 2. Solution Outline The need for address or protocol translation during the migration period to IPv6 creates the opportunity to deploy these mechanisms in a way that allows the support of a large user base without the needShow full document text