One document matched: draft-droms-softwires-snat-01.txt
Differences from draft-droms-softwires-snat-00.txt
Internet Engineering Task Force R. Droms
Internet-Draft Cisco
Intended status: Informational B. Haberman
Expires: January 13, 2009 July 12, 2008
Softwires Network Address Translation (SNAT)
draft-droms-softwires-snat-01.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 January 13, 2009.
Abstract
Service providers (ISPs) are interested in reducing the use of IPv4
in their internal networks because of the anticipated exhaustion of
the IPv4 address space. Softwires Network Address Translation (SNAT)
combines IPv4 NAT and IPv4-in-IPv6 softwires to carry IPv4 traffic
through the ISP network that uses only IPv6 service. Multiple
subscribers are multiplexed through a single external global IPv4
address, reducing the total number of IPv4 addresses in use by the
ISP to support Internet traffic to those subscribers.
Droms & Haberman Expires January 13, 2009 [Page 1]
Internet-Draft Softwires Network Address Translation July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Problem statement and requirements . . . . . . . . . . . . . . 4
5. SNAT Architecture . . . . . . . . . . . . . . . . . . . . . . 4
6. Example message flow . . . . . . . . . . . . . . . . . . . . . 7
7. Translation details . . . . . . . . . . . . . . . . . . . . . 11
8. Supporting multiple subscribers through one IPv4 address . . . 12
9. Setting up state . . . . . . . . . . . . . . . . . . . . . . . 12
10. Analysis and Future Work . . . . . . . . . . . . . . . . . . . 13
11. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Revision -01 . . . . . . . . . . . . . . . . . . . . . . 13
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Droms & Haberman Expires January 13, 2009 [Page 2]
Internet-Draft Softwires Network Address Translation July 2008
1. Introduction
Service providers (ISPs) are interested in reducing the use of IPv4
in their internal networks because of the anticipated exhaustion of
the IPv4 address space. Reducing the use of IPv4 addresses will
allow the conservation of addresses assigned to the ISP for use in
specific places where IPv4 is required. One way of reducing the use
of IPv4 addresses to deploy IPv6 to replace IPv4 in internal
networks.
Softwires Network Address Translation (SNAT) combines IPv4 NAT
[RFC3022] and IPv4-in-IPv6 softwire to carry IPv4 traffic through the
ISP network where only IPv6 is deployed. RFC 4925 [RFC4925]
describes the two initial softwires WG problem statements, "Hubs and
Spokes" (Section 2) and "Mesh" (Section 3). The problem that this
document addresses is more narrowly scoped than either of these two
initial problem statements, focusing on IPv4 over IPv6 only and the
specific needs of a large ISP network facing scaling issues from lack
of RFC 1918 address space for all of its devices. It most closely
resembles the "converse case" of that depicted in Figure 2, Case 2,
of RFC 4925 (except that the Host may be IPv4-only, rather than Dual
Stack as depicted, and the portion of the network labeled "IPv4-only"
is likely larger than that implied in the diagram). SNAT multiplexes
multiple subscribers through a single IPv4 address, reducing the
total number of IPv4 addresses in use by the ISP to support Internet
traffic to those subscribers.
Elements of SNAT are inspired by the proposal from NTT to deploy dual
IPv4 NAT and the proposal from Comcast to use IPv4-IPv6-IPv4
translation. SNAT retains the characteristics of IPv4-IPV4 NAT,
rather than introducing IPv4-IPV6 translation, while saving IPv4
addresses in the ISP core network. This document has been submitted
to foster discussion about these mechanisms for IPv4 address space
conservation.
SNAT requires one IPv4-in-IPv6 softwire per subscriber. These
softwires will require configuration and special effort for
reliability, as well as resources for scaling at the ISP endpoint for
potentially thousands or even millions of softwires. SNAT also
requires additional functions in subscriber CPEs.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Droms & Haberman Expires January 13, 2009 [Page 3]
Internet-Draft Softwires Network Address Translation July 2008
3. Terminology
This document uses softwires terminology described in Section 1.1 of
RFC 4925 throughout. The reader is expected to refer to this
document for a number of terms and abbreviations. In addition to the
terminology defined in RFC 4925, this document defines the following
terms:
HGW: Home gateway; the gateway between the subscriber network and
the ISP network
Subscriber host or host: A host attached to a subscriber network
SPSWE: Service provider softwire endpoint; the endpoint of the
softwires in the ISP network
4. Problem statement and requirements
The motivation for SNAT is to reduce the number of IPv4 addresses in
use in an ISP network. The reduction is achieved in two ways:
o Use NAT to multiplex subscribers through a single global IPv4
address
o Use softwires to provide IPv4 service through an ISP core network
that uses only IPv6 addresses
The following requirements were considered in the design of SNAT:
o Provide IPv4 service to CPE through NAT similar to familiar NAT in
use today
o Minimize the use of global IPv4 addresses for subscriber IPv4
service
o Eliminate the use of IPv4 addresses (global or RFC 1918) within
the ISP as much as possible
o No changes to subscriber CPEs (hosts attached to the subscribe
network)
5. SNAT Architecture
As illustrated in Figure 1, SNAT consists of three components: the
subscriber home gateway (HGW), the service provider softwire endpoint
(SPSWE) and a softwire between the SI in the HGW and the SC in the
Droms & Haberman Expires January 13, 2009 [Page 4]
Internet-Draft Softwires Network Address Translation July 2008
SPSWE. The SPSWE performs IPv4-IPv4 NAT translations to multiplex
multiple subscribers through a single globl IPv4 address.
Overlapping address spaces used by subscribers are disambiguated
through the identification of tunnel endpoints.
Droms & Haberman Expires January 13, 2009 [Page 5]
Internet-Draft Softwires Network Address Translation July 2008
+-----------+
| Host |
+-----+-----+
|10.0.0.1
|
|
|10.0.0.2
+---------|---------+
| | |
|HGW | |
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
|||2001:0:0:1::1
|||
|||<-IPv4-in-IPv6 softwire
|||
-------|||-------
/ ||| \
| ISP core network |
\ ||| /
-------|||-------
|||
|||2001:0:0:2::1
+--------|||--------+
|SPSWE ||| |
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
|129.0.0.1
|
--------|--------
/ | \
| Internet |
\ | /
--------|--------
|
|128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 1: SNAT Architecture
Droms & Haberman Expires January 13, 2009 [Page 6]
Internet-Draft Softwires Network Address Translation July 2008
The resulting solution accepts an IPv4 datagram that is translated
into an IPv4-in-IPv6 softwire datagram for transmission across the
softwire. At the corresponding endpoint, the IPv4 datagram is
decapsulated, and the translated IPv4 address is inserted based on a
translation from the softwire.
6. Example message flow
In the example shown in Figure 2, the translation tables in the SPSWE
is configured to forward between IP/TCP (10.0.0.1/10000) and IP/TCP
(129.0.0.1/5000). That is, a datagram received by the HGW from the
CPE at address 10.0.0.1, using TCP DST port 10000 will be translated
a datagram with IP SRC address 129.0.0.1 and TCP SRC port 5000 in the
Internet.
Droms & Haberman Expires January 13, 2009 [Page 7]
Internet-Draft Softwires Network Address Translation July 2008
+-----------+
| CPE |
+-----+-----+
| |10.0.0.1
IPv4 datagram 1 | |
| |
v |10.0.0.2
+---------|---------+
| | |
|HGW | |
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
| |||2001:0:0:1::1
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|SPSWE v ||| |
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
| |129.0.0.1
IPv4 datagram 3 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
v |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 2: Outbound Datagram
Droms & Haberman Expires January 13, 2009 [Page 8]
Internet-Draft Softwires Network Address Translation July 2008
+-----------------+--------------+---------------+
| Datagram | Header field | Contents |
+-----------------+--------------+---------------+
| IPv4 datagram 1 | IPv4 Dst | 128.0.0.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:2::2 |
| | IPv6 Src | 2001:0:0:1::1 |
| | IPv4 Dst | 128.0.0.1 |
| | IPv4 Src | 10.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 10000 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 128.0.0.1 |
| | IPv4 Src | 129.0.0.1 |
| | TCP Dst | 80 |
| | TCP Src | 5000 |
+-----------------+--------------+---------------+
Datagram header contents
When datagram 1 is received by the HGW, the SI function encapsulates
the datagram in datagram 2 and forwards it to the SPSWE over the
softwire.
When it receives datagram 2, the SC in the SPSWE hands the IPv4
datagram to the NAT, which determines from its translation table that
the datagram received on Softwire_1 with TCP SRC port 10000 should be
translated to datagram 3 with IP SRC address 129.0.0.1 and TCP SRC
port 5000.
Figure 3 shows an inbound message received at the SPSWE. When the
NAT function in the SPSWE receives datagram 1, it looks up the IP/TCP
DST in its translation table. In the example in Figure 3, the NAT
translates the TCP DST port to 10000, sets the IP DST address to
10.0.0.1 and hands the datagram to the SC for transmission over
Softwire_1. The SI in the HGW decapsulates IPv4 datagram from the
inbound softwire datagram, and forwards it to the host.
Droms & Haberman Expires January 13, 2009 [Page 9]
Internet-Draft Softwires Network Address Translation July 2008
+-----------+
| Host |
+-----+-----+
^ |10.0.0.1
IPv4 datagram 3 | |
| |
| |10.0.0.2
+---------|---------+
| +-+-+ |
|HGW |NAT| |
|+--------+--------+|
|| SNAT SI ||
|+--------+--------+|
+--------|||--------+
^ |||2001:0:0:1::1
IPv6 datagram 2 | |||
| |||<-IPv4-in-IPv6 softwire
| |||
-----|-|||-------
/ | ||| \
| ISP core network |
\ | ||| /
-----|-|||-------
| |||
| |||2001:0:0:2::1
+------|-|||--------+
|SPSWE | ||| |
|+--------+--------+|
|| SNAT SC ||
|+--------+--------+|
| |NAT| |
| +-+-+ |
+---------|---------+
^ |129.0.0.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| Internet |
\ | | /
-----|--|--------
| |
| |128.0.0.1
+-----+-----+
| IPv4 Host |
+-----------+
The postamble.
Droms & Haberman Expires January 13, 2009 [Page 10]
Internet-Draft Softwires Network Address Translation July 2008
Figure 3: Inbound Datagram
+-----------------+--------------+---------------+
| Datagram | Header field | Contents |
+-----------------+--------------+---------------+
| IPv4 datagram 1 | IPv4 Dst | 129.0.0.1 |
| | IPv4 Src | 128.0.0.1 |
| | TCP Dst | 5000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv6 Datagram 2 | IPv6 Dst | 2001:0:0:1::1 |
| | IPv6 Src | 2001:0:0:2::2 |
| | IPv4 Dst | 10.0.0.1 |
| | IP Src | 128.0.0.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
| --------------- | ------------ | ------------- |
| IPv4 datagram 3 | IPv4 Dst | 10.0.0.1 |
| | IPv4 Src | 128.0.0.1 |
| | TCP Dst | 10000 |
| | TCP Src | 80 |
+-----------------+--------------+---------------+
Datagram header contents
7. Translation details
The SPSWE has a NAT that translates between softwire/port pairs and
IPv4-address/port pairs. The same translation is applied to IPv4
datagrams received on the device's external interface and from the
softwire endpoint in the device.
In Figure 2, the translator network interface in the SPSWE is on the
Internet, and the softwire interface connects to the HGW. The SPSWE
translator is configured as follows:
Network interface: Translate IPv4 destination address and TCP
destination port to the softwire identifier and TCP destination
port
Softwire interface: Translate softwire identifier and TCP source
port to IPv4 source address and TCP source port
Here is how the translation in Figure 3 works:
o Datagram 1 is received on the SPSWE translator network interface.
The translator looks up the IPv4-address/port pair in its
Droms & Haberman Expires January 13, 2009 [Page 11]
Internet-Draft Softwires Network Address Translation July 2008
translator table, rewrites the IPv4 destination address to
10.0.0.1 and the TCP source port to 10000, and hands the datagram
to the SE to be forwarded over the softwire.
o The IPv4 datagram is received on the HGW SI. The SI function
extracts the IPv4 datagram and the HGW forwards datagram 3 to the
host.
+-------------------------------+--------------------+
| Softwire/IPv4/Port | IPv4/Port |
+-------------------------------+--------------------+
| Softwire_1/10.0.0.1/TCP 10000 | 129.0.0.1/TCP 5000 |
+-------------------------------+--------------------+
SPSWE translation table
8. Supporting multiple subscribers through one IPv4 address
One key advantage of SNAT is the ability to provide Internet access
for multiple subscribers through a single global IPv4 address. The
SPTE table can be configured to translate traffic from multiple
customers through one global IPv4 address. Even a small degree of
multiplexing, as few as five subscribers through each global IPv4
address, would give ISPs sufficient IPv4 address space to continue
and grow operations until IPv6 is more fully deployed.
9. Setting up state
The translation tables in the SPSWE can be set up dynamically by
outbound traffic from a CPE. When the SPSWE receives the initial
datagram in a new flow, there will be no corresponding IPv4-address/
port pair for that flow in the SPSWE NAT translation table. The NAT
selects an unused outbound TCP port, adds the resulting mapping to
the NAT translation table, performs the appropriate translation and
forwards it to the destination.
The resulting table entry is now in place for translation of
returning inbound traffic.
The translation table can also be configured manually, which would
allow, for example, traffic to be forwarded to servers on subscriber
networks. However, because multiple subscribers may be supported
through a single IPv4 address, only one of those subscribers would be
able to have statically assigned external server address through the
NAT/softwire.
Droms & Haberman Expires January 13, 2009 [Page 12]
Internet-Draft Softwires Network Address Translation July 2008
10. Analysis and Future Work
There are several opportunities for future work on SNAT:
o SNAT requires provisioning of a softwire from each HGW to an
SPSWE. This document should include a description of at least one
provisioning mechanism. Candidates include a new DHCP option and
anycast.
o SNAT requires an IPv4-in-IPv6 softwire for each subscriber, and
NAT for each flow from the subscriber. What are the effects of
scaling this architecture to millions of subscribers?
o Security issues have not been considered
o How can the configuration of the IPv4-in-IPv6 softwire be
automated?
o What is the interaction between SNAT and native IPv6 service to
the subscriber?
11. Change log
This section shall be removed prior to publication of this document
as an RFC.
11.1. Revision -01
o Eliminated the NAT function in the HGW, which simplifies
forwarding IPv4 datagrams over the IPv6 softwire between the HGW
and the SPSWE.
o Added DHCP as a mechanism for tunnel endpoint discovery.
12. Contributors
Mark Townsley suggested elimination of a NAT function in the HGW.
Bernie Volz and Carlos Pignataro provided substantive and editorial
review of draft-droms-softwires-snat-00.
13. IANA Considerations
This memo includes no requests to IANA.
Droms & Haberman Expires January 13, 2009 [Page 13]
Internet-Draft Softwires Network Address Translation July 2008
14. Security Considerations
Security considerations must be developed.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
15.2. Informative References
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
Authors' Addresses
Ralph Droms
Cisco
1414 Massachusetts Avenue
Boxborough, MA 01714
US
Phone: +1 978.936.1674
Email: rdroms@cisco.com
Brian Haberman
11100 Johns Hopkins Road
Laurel, MD 20723-6099
US
Phone: +1 443 778 1319
Email: brian@innovationslab.net
Droms & Haberman Expires January 13, 2009 [Page 14]
Internet-Draft Softwires Network Address Translation July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Droms & Haberman Expires January 13, 2009 [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 07:38:43 |