Network Working Group Xiaohong Deng
Internet Draft M. Boucadair
Intended status: Standards Track France Telecom
Expires: May 2012 C. Zhou
Huawei Technologies
October 31, 2011
NAT offload extension to Dual-Stack lite
draft-zhou-softwire-b4-nat-04
Abstract
Dual-Stack Lite, combining IPv4-in-IPv6 tunnel and Carrier Grade NAT
technologies, provides an approach that offers IPv4 service via IPv6
network by sharing IPv4 addresses among customers during IPv6
transition period. Dual-stack lite, however, requires CGN to maintain
active NAT sessions, which means processing performance, memory size
and log abilities for NAT sessions should scale with number of
sessions of subscribers; Hence increasing in CAPEX for operators
would be resulted in when traffic increase.
This document propose the NAT offload extensions to DS-Lite, which
allows offloading NAT translation function from centralized network
side (AFTR) to distributed customer equipments (B4), thereby offering
a trade-off between CAPEX (e.g. less performance requirements on AFTR
device) and OPEX (e.g., easy and fast deployment of Dual-Stack Lite)
for operators. The ability of easily co-deploying with basic Dual-
Stack Lite is essential to NAT offload extension to DS-Lite.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
DBC Expires May 31, 2012 [Page 1]
Internet-Draft Lightweight extension to DS-Lite October 2011
This Internet-Draft will expire on April 26, 2012.
Copyright Notice
Copyright (c) 2011 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.
Table of Contents
1. Background........................................................3
2. NAT offload extended DS-Lite Overview and terminologies...........3
3. NATed B4 Behavior.................................................5
3.1. Plain IPv4 Address...........................................5
3.2. Restricted IPv4 Address and port set provisioning............5
3.2.1. Restricted port allocation strategies and requirements..5
3.2.2. Restricted IPv4 Address and port set provisioning method
..............................................................6
3.3. Outgoing Packets Processing..................................6
3.4. Incoming Packets Processing..................................6
3.4.1. Incoming Ports considerations on a given restricted IPv4
address........................................................6
4. NAT offload AFTR Behaviour........................................7
4.1. Outgoing Packets Processing..................................7
4.2. Incoming Packets Processing..................................7
5. Fragmentation and Reassembly and DNS..............................7
6. Security Considerations...........................................8
7. IANA Considerations..............................................10
8. References.......................................................10
8.1. Normative References........................................10
8.2. Informative References......................................10
9. Acknowledgments..................................................12
DBC Expires May 31, 2012 [Page 2]
Internet-Draft Lightweight extension to DS-Lite October 2011
1. Background
The basic idea of NAT offload extension to DS-lite, is to reuse the
basic DS-Lite infrastructure, including tunneling transport and
provisioning method, and ICMP and fragmentation processing as well.
The NAT offload extension makes the AFTR table scales with customer
number other than traffic sessions. Based on this NAT offload
extension, log entries for per subscriber instead of per session is
achievable. IPv4 address utilization efficiency depends on port
allocation strategies, e.g., per port on demand, or a buck of ports
pre-allocation, which would be elaborated in Section 5.
Besides, this method allows unique IPv6 address for delivery both
IPv4 over IPv6 traffic and native IPv6 traffic without introduce any
IPv4 addressing/rouging into IPv6 address/routing, as it reuses Dual
Stack Lite tunneling transport infrastructure, unlike stateless
solutions with port set allocation such as aplusp and 4rd, that
either requires two IPv6 addresses separately for either IPv4 traffic
over IPv6 or native IPv6 traffic, or require carefully design to
avoid introduce IPv4 routing to IPv6 routing when using unique IPv6
address to transport both IPv4 over IPv6 traffic and native IPv6
traffic.
2. NAT offload extended DS-Lite Overview and terminologies
Figure 1 provides an overview of the NAT offload extended DS-Lite.
DBC Expires May 31, 2012 [Page 3]
Internet-Draft Lightweight extension to DS-Lite October 2011
+-------------------------+
| IPv6 ISP Network |
| |
| |
+-------------------------+
|
| +-----------+ +----------+
| |NAT offload| | IPv4 |
+--------+ | IPv4-in-IPv6 |AFTR |---| Internet |
| | +---------+ | | | |
|IPv4 LAN|--|NATed |===============+-----------+ +----------+
| | |B4 |CPE/HOST |
+--------+ +---------+ |
| |
| |
+-------------------------+
Figure 1 : NAT offload extended DS-Lite Overview
NATed B4: A NAT offload extended B4 which is called NATed B4 in this
document can be either an IPv6 hosts or a CPE. NATed B4 performs IP
address and port translation function, besides establishment of IPv4
in IPv6 tunnel with AFTR.
NAT offload AFTR: A NAT offload extended AFTR which is called NAT
offload AFTR is responsible for establishing IPv4 in IPv6 tunneling
with NATed B4 to transport IPv4 over IPv6 while the NAT translation
function is offloaded to NATed B4.
A NATed B4 uses IPv4 address with a restricted port set for this IPv4
connectivity, which may be provisioned via either DHCPv4 with the
AFTR, or via PCP with the PCP server. The AFTR keeps the mapping
between B4's IPv6 address, allocated IPv4 address, and a restricted
port set ID on a per customer basis.
For host NATed B4 case, the host gets public address directly. It is
also suggested that the host run a local NAT to map randomly
generated ports into the restricted port set. Private to public
address translation would not be needed in this NAT. Another
DBC Expires May 31, 2012 [Page 4]
Internet-Draft Lightweight extension to DS-Lite October 2011
solution is to have the IP stack to only assign ports within the
restricted port set to applications. Either way the host guarantees
that every port number in the packets sent out by itself falls into
the allocated port set.
3. NATed B4 Behavior
The NATed B4 is responsible for performing NAT and/ALG functions,
basic B4 functions, as well as supporting NAT Traversal mechanisms
(e.g., UPnP or NAT-PMP).
The tunneling provisioning of the B4 element should reuse what has
defined in [I-D.ietf-softwire-dual-stack-lite].
3.1. Plain IPv4 Address
A NATed B4 MAY be assigned with a plain IPv4 address.
When a plain, IPv4 address is assigned, the NAT operations are
enforced as per current legacy CPEs. The NAT in the AFTR is disabled
for that user.IPv4 datagrams are encapsulated in IPv6 as specified in
[I-D.ietf-softwire-dual-stack-lite].
3.2. Restricted IPv4 Address and port set provisioning
3.2.1. Restricted port allocation strategies and requirements
Restricted port allocation strategies for this approach could either
be allocating per port on demand, or be pre-allocating a port set (no
matter a continuous port range, or multiple non-continuous sub port
sets),which leads to trade-off between provisioning efficiency and
IPv4 utilization efficiency.
Note that efficiency on log is reported by operators as a practical
requirement for AFTR, hence port set decoding should take this
requirement into account, no matter which port allocation strategy is
adopt.
DBC Expires May 31, 2012 [Page 5]
Internet-Draft Lightweight extension to DS-Lite October 2011
Unlike stateless 4over6 solutions such as [I-D.murakami-softwire-
4rd], the restricted port sets allocation for NAT offload extended
DS-Lite has no requires on careful planning of the IPv6 and IPv4
addressing together. It therefore offers more flexibility for ISPs,
when it comes to managing the IPv6 access network, and introduces no
impact on IPv6 routing.
3.2.2. Restricted IPv4 Address and port set provisioning method
Either DHCP for example, [I-D.bajko-pripaddrassign] or PCP would be
candidate for delivery Restricted IPv4 and port set.
With PCP, The basic PCP protocol allows per port on demand allocation,
while an extension to PCP [I-D.tsou-pcp-natcoord] supports pre-
allocate bulk of ports.
3.3. Outgoing Packets Processing
Upon receiving an IPv4 packet, the B4 performs NAT using the public
IPv4 address and port set assigned to it. Then B4 encapsulates the
resulting IPv4 packet into an IPv6 packet, and delivers it through
IPv6 connectivity to AFTR which will then decapsulate the
encapsulated packet and forward it through IPv4. The destination
IPv6 address used for encapsulation should be the AFTR's address.
3.4. Incoming Packets Processing
Upon receipt of IPv4-in-IPv6 packet from AFTR, B4 will decapsulate
the packet and translate the public IPv4 address to the private IPv4
address. Finally, it delivers the packet to the host using the
translated IPv4 address. The source IPv6 address used for
encapsulation at AFTR is the AFTR's address, and the destination
address is set to the external address of B4.
3.4.1. Incoming Ports considerations on a given restricted IPv4 address
As described in [I-D.ietf-intarea-shared-addressing-issues], a bulk
of incoming ports can be reserved as a centralized resource shared by
all subscribers using a given restricted IPv4 address. In order to
DBC Expires May 31, 2012 [Page 6]
Internet-Draft Lightweight extension to DS-Lite October 2011
distribute incoming ports as fair as possible among subscribers
sharing a given restricted IPv4 address, other than allocating a
continuous range of ports to each, a solution to distribute bulks of
non-continuous ports among subscribers, which also takes port
randomization into account, is elaborated in Section 3.1.
4. NAT offload AFTR Behaviour
The NAT offload AFTR may be co-located with IP and /or restricted
port set allocation server (e.g., a DHCP server, or a PCP server).
The AFTR only maintains a static mapping entry per customer consist
of IPv6 address, IPv4 address and port set ID, other than maintains
NAT entries per session.
4.1. Outgoing Packets Processing
For outgoing packets, the NAT offload AFTR simply decapsulates it and
forwards it to IPv4 Internet.
4.2. Incoming Packets Processing
For inbound traffic, NAT offload AFTR would use the IPv4 destination
address and port as the index to retrieve mapping table in order to
find a destination IPv6 address, and then encapsulates it into IPv6,
so that native IPv6 routing could be used to forward the IPv4 in IPv6
traffic.
5. Fragmentation and Reassembly and DNS
No change to Section 5.3 of [I-D.ietf-softwire-dual-stack-lite. The
DNS behavior is the same as described in [I-D.ietf-softwire-dual-
stack-lite].
DBC Expires May 31, 2012 [Page 7]
Internet-Draft Lightweight extension to DS-Lite October 2011
6. Security Considerations
As port randomization is one protection among others against blind
attacks, a simple non-contiguous port sets distribution mechanism is
therefore proposed to distribute bulks of non-continuous ports among
subscribers, and to enable subscribers operating port randomized NAT.
In this section, a non-continuous restricted port set
encoding/decoding and an algorithm of random ephemeral port selection
within the allocated restricted port set example proves that port
randomization is applicable this approach.
On every external IPv4 address, according to port set size N, log2(N)
bits are randomly choosing by NAT offload AFTR as subscribers
identification bits(s bit) among 1st and 16th bits. Take a sharing
ration 1:32 for example, Figure 1 shows an example of 5 random
selected bits of s bits.
|1st |2nd |3rd |4th |5th |6th |7th | 8th|
+----+----+----+----+----+----+----+----+
| 0 | s | 0 | 0 | s | 0 | s | 0 |
+----+----+----+----+----+----+----+----+
|9th |10th|11th|12th|13th|14th|15th|16th|
+----+----+----+----+----+----+----+----+
| s | 0 | s | 0 | 0 | 0 | 0 | 0 |
+----+----+----+----+----+----+----+----+
Figure 2 : A s bit selection example (on a sharing ration 1:32
address).
Subscriber ID pattern is formed by setting all the s bits to 1 and
other trivial bits to 0. Figure 2 illustrates an example of
subscriber ID pattern on a sharing ration 1:32 address. Note that
the subscriber ID pattern will be different, guaranteed by the random
s bit selection, on every restricted IP address no matter whether the
sharing ratio varies.The NAT offload AFTR can use subscriber ID
pattern as port set ID on a per restricted IPv4 address basis, which
allows log entries scale on a subscriber basis, hence meets the log
efficiency requirements described in Section 3.1.2.
DBC Expires May 31, 2012 [Page 8]
Internet-Draft Lightweight extension to DS-Lite October 2011
|1st |2nd |3rd |4th |5th |6th |7th | 8th|
+----+----+----+----+----+----+----+----+
| 0 | 1 | 0 | 0 | 1 | 0 | 1 | 0 |
+----+----+----+----+----+----+----+----+
|9th |10th|11th|12th|13th|14th|15th|16th|
+----+----+----+----+----+----+----+----+
| 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 |
+----+----+----+----+----+----+----+----+
Figure 3 : A subscriber ID pattern example (on a sharing ration 1:32
address).
Subscribers ID value is then assigned by setting subscriber ID
pattern bits (s bits shown in the following example) according to a
customer value and setting other trivial bits to 1.
|1st |2nd |3rd |4th |5th |6th |7th | 8th|
+----+----+----+----+----+----+----+----+
| 1 | s | 1 | 1 | s | 1 | s | 1 |
+----+----+----+----+----+----+----+----+
|9th |10th|11th|12th|13th|14th|15th|16th|
+----+----+----+----+----+----+----+----+
| s | 1 | s | 1 | 1 | 1 | 1 | 1 |
+----+----+----+----+----+----+----+----+
Figure 4 : A subscriber ID value example (0# subscriber on this
restricted address).
Subscriber ID pattern and subscriber ID value together uniquely
defines a non-overlapping port set on a restricted IP address.
Pseudo-code shown in the Figure 4 describe how to use subscriber ID
pattern and subscriber ID value to implement a random ephemeral port
selection function in a restricted port set.
DBC Expires May 31, 2012 [Page 9]
Internet-Draft Lightweight extension to DS-Lite October 2011
do{
restricted_next_ephemeral = (random()| customer_ID_pattern)
& customer_ID_value;
if(five-tuple is unique)
return restricted_next_ephemeral;
}
Figure 5 : Random ephemeral port selection of restricted port set
algorithm.
7. IANA Considerations
TBD.
8. References
8.1. Normative References
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.bajko-pripaddrassign]
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment",
draft-bajko-pripaddrassign-03 (work in progress),
September 2010.
DBC Expires May 31, 2012 [Page 10]
Internet-Draft Lightweight extension to DS-Lite October 2011
[I-D.bsd-softwire-stateless-port-index-analysis]
Boucadair, M., Skoberne, N., and W. Dec, "Analysis of
Port Indexing Algorithms",
draft-bsd-softwire-stateless-port-index-analysis-00
(work in progress), September 2011.
[I-D.cui-softwire-dhcp-over-tunnel]
Cui, Y., Wu, P., and J. Wu, "DHCPv4 Behavior over IP-IP
tunnel", draft-cui-softwire-dhcp-over-tunnel-01 (work
in progress), July 2011.
[I-D.cui-softwire-host-4over6]
Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
Lee, "Public IPv4 over Access IPv6 Network",
draft-cui-softwire-host-4over6-06 (work in progress),
July 2011.
[I-D.murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "IPv4
Residual Deployment on IPv6 infrastructure - protocol
specification", draft-murakami-softwire-4rd-01 (work in
progress), September 2011.
DBC Expires May 31, 2012 [Page 11]
Internet-Draft Lightweight extension to DS-Lite October 2011
[I-D.sun-v6ops-laft6]
Sun, Q. and C. Xie, "LAFT6: NAT offload address family
transition for IPv6", draft-sun-v6ops-laft6-01 (work in
progress), March 2011.
9. Acknowledgments
Thank Alain Durand, Ole Troan and Ralph Dorm for their valuable
feedback and discussion to this appraoch, and thanks to Qiong Sun for
a discussion from operators needs' perspective.
Appendix A. Variants of this approach
A.1. Introduction
This section defines variants of deployment for this NAT offload DS-
Lite approach. A.2 describes its combination with stateless
encapsulation.
A.2 Stateless Encapsulation
B4 may implement the stateless encapsulation specified in Section 4.4
of [I-D.ymbk-aplusp].
DBC Expires May 31, 2012 [Page 12]
Internet-Draft Lightweight extension to DS-Lite October 2011
Authors' Addresses
Xiaohong Deng
France Telecom
Email: xiaohong.deng@orange.com
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange.com
Cathy Zhou
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Phone:
Email: cathyzhou@huawei.com
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tena@huawei.com
Gabor Bajko
Nokia
Email: gabor.bajko@nokia.com
DBC Expires May 31, 2012 [Page 13]