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)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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
Show full document text