Network Working Group Xiaohong Deng
Internet Draft M. Boucadair
Intended status: Standards Track France Telecom
Expires: April 2012 P. Wu
Tsinghua University
Q. Sun
China Telecom
C. Zhou
Huawei Technologies
October 25, 2011
Lightweight extension to Dual-Stack lite
draft-zhou-softwire-b4-nat-03
Abstract
The dual-stack lite mechanism provide an IPv4 access method over IPv6
ISP network for end users. Dual-Stack Lite enables an IPv6 provider
to share IPv4 addresses among customers by combining IPv4-in-IPv6
tunnel and Carrier Grade NAT technologies. However, with basic Dual-
stack Lite approach, CGN has to maintain active NAT sessions, which
requires processing performance, memory size for NAT sessions and log
abilities scale with number of sessions from subscribers, and hence
result in increasing of CAPEX for operators when traffic increase.
This document propose the lightweight extensions to DS-Lite, which
allows offloading NAT translation function from centralized network
side (AFTR) to distributed customer equipments (B4), thereby offering
flexibilities for ISPs to adjust trade-off between CAPEX (e.g. less
performance requirements on AFTR device), OPEX (e.g., easy and fast
deployment of Dual-Stack Lite). The ability of easily co-deploying
with basic Dual-Stack Lite is essential to lightweight 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/.
DBW Expires April 25, 2012 [Page 1]
Internet-Draft Lightweight extension to DS-Lite October 2011
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."
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. Introduction.....................................................3
2. Lightweight extended DS-Lite Overview and terminologies..........4
3. NATed B4 Behavior................................................5
3.1. Plain IPv4 Address..........................................6
3.2. Restricted IPv4 Address and port set provisioning...........6
3.2.1. Restricted port allocation strategies and requirements.6
3.2.2. Restricted IPv4 Address and port set provisioning method
.............................................................6
3.3. Outgoing Packets Processing.................................7
3.4. Incoming Packets Processing.................................7
3.4.1. Incoming Ports considerations on a given restricted IPv4
address.......................................................7
4. Lightweight AFTR Behaviour.......................................8
5. Fragmentation and Reassembly and DNS.............................8
6. ICMP processing..................................................9
DBW Expires April 25, 2012 [Page 2]
Internet-Draft Lightweight extension to DS-Lite October 2011
7. Security Considerations..........................................9
8. IANA Considerations.............................................11
9. References......................................................12
9.1. Normative References.......................................12
9.2. Informative References.....................................12
10. Acknowledgments................................................13
1. Introduction
Dual-stack lite technology [RFC6333] provides IPv4 access over IPv6
access network. Dual-Stack lite (DS-lite) also mitigates IPv4 address
exhaustion by sharing public IPv4 addresses amongst users.The B4
element establishes an IPv4-in-IPv6 softwire to the AFTR and
encapsulates the IPv4 packets into the softwire. When AFTR receives
the IPv6 packets, it will decapsulate them and perform NAT-44 on the
packets.
The AFTR is required to maintain active NAT sessions. In a
centralized deployment models where one AFTR serves thousands of
users, the large numbers of NAT sessions may become performance
bottom-neck. First, maintaining active NAT sessions requires AFTR
constantly creating and purging NAT sessions. Second, a large NAT
table demands more processing power for searching and more memory
space. In addition, dynamic session-based NAT will create large
number of log entries, which will also be a challenging problem.
To address these issues, we propose an extension to DS-lite. The B4
element will be provisioned with an IPv6 address, an IPv4 address
and restricted port sets, so that address and port translation can be
performed at the customer side, e.g.,CPE, with only one requirement
that port translation should inside the restricted port sets.
The IPv4 traffic over IPv6 transport would reuse the basic DS-Lite
infrastructure, including tunneling transport and provisioning method
as well, and share basic idea of using mapping table on a per IPv6
address basis to initiate customers. The AFTR will then only maintain
a static mapping entry between the IPv6 address, IPv4 address and
port set ID, instead of maintain NAT entries per session. For inbound
IPv4 packet on AFTR, it would use the IPv4 destination address and
port as the index and use the forwarding rule in the mapping table to
encapsulate the packets to the destination CPE.
Compared to DS-lite, this lightweight extension makes the AFTR table
scales with customer number other than traffic sessions. Based on
this lightweight extension, log entries for per subscriber instead of
per session is also achiveble.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.
DBW Expires April 25, 2012 [Page 3]
Internet-Draft Lightweight extension to DS-Lite October 2011
Compared to stateless solutions with port set allocation such as 4rd,
this mechanism is suitable for operators who prefer to keep IPv6 and
IPv4 addressing separated. For example, an operator may want to
provide IPv4 with an on-demand way in its IPv6 network, the dynamic
allocation of IPv4 address and port makes more efficient usage of
IPv4 resource. Another example is that an operator may only have
many small and discontinuous IPv4 blocks available to provide IPv4
over IPv6, rather than a few big IPv4 blocks. This mechanism keeps
dynamic feature of IPv4-IPv6 address binding as in DS-Lite, so it
won't require administrating and managing many 4rd domains in the
network and mapping rules in the CPEs.
2. Lightweight extended DS-Lite Overview and terminologies
Figure 1 provides an overview of the lightweight extended DS-Lite.
+-------------------------+
| IPv6 ISP Network |
| |
| |
+-------------------------+
|
| +-----------+ +----------+
| |Lightweight| | IPv4 |
+--------+ | IPv4-in-IPv6 |AFTR |---| Internet |
| | +---------+ | | | |
|IPv4 LAN|--|NATed |===============+-----------+ +----------+
| | |B4 |CPE/HOST |
+--------+ +---------+ |
| |
| |
+-------------------------+
Figure 1 : Lightweight extended DS-Lite Overview
DBW Expires April 25, 2012 [Page 4]
Internet-Draft Lightweight extension to DS-Lite October 2011
NATed B4: A Lightweight 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.
Lightweight AFTR: A Lightweight extended AFTR which is called
Lightweight 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
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].
DBW Expires April 25, 2012 [Page 5]
Internet-Draft Lightweight extension to DS-Lite October 2011
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.
Unlike stateless 4over6 solutions such as [I-D.murakami-softwire-
4rd], the restricted port sets allocation for Lightweight extended
DS-Lite has no requires on careful planning of the IPv6 domain range,
IPv4/IPv6 mapping relationship, prefix length and multiplex ratio,
etc. 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
One is extending DHCP to support address allocation with port range
embedded. [I-D.bajko-pripaddrassign] discusses this DHCP usage. In
this special context, we need to build the DHCPv4 procedure over IPv6
[I-D.cui-softwire-dhcp-over-tunnel].
DBW Expires April 25, 2012 [Page 6]
Internet-Draft Lightweight extension to DS-Lite October 2011
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.
Adopting either method, An NATed B4 can have a restricted port set
with an IPv4 addresses allocated from the lightweight AFTR.
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
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. Lightweight AFTR Behaviour
DBW Expires April 25, 2012 [Page 7]
Internet-Draft Lightweight extension to DS-Lite October 2011
The lightweight AFTR should either allocate port restricted addresses
directly (perform an extended DHCPv4 server, or a basic or/extended
PCP server), or leave the allocation to dedicated DHCP/PCP server
(and perform a relay in DHCP case).
When accomplishing one such allocation, the lightweight AFTR
simultaneously install a mapping entry into the mapping table. This
entry consists of the public IPv4 address the port set ID and NATed's
IPv6 address. Its lifetime is set as per restricted IPv4 provisioning
method. It'll be used for encapsulation of inbound packets. This
mapping entry would be deleted when the lifetime expires, and refresh
its lifetime when the NATed B4 renews/extends the allocation.
The data plane function of the lightweight AFTR is purely
encapsulation and decapsulation. When receiving an IPv4-in-IPv6
packet from an NATed B4, the lightweight AFTR decapsulates it and
forwards it to IPv4 Internet. When receiving an IPv4 packet from the
Internet, it uses the destination address and port from this packet
to lookup the destination NATed B4's IPv6 address in the mapping
table. Then the lightweight AFTR encapsulates this packet using the
IPv6 address found in the table as IPv6 destination address, and
forwards it to the correct NATed B4 based on native IPv6 routing.
Since basic DS-Lite transporting infrastructure is re-used, no
influence introduced from IPv4 routing to the IPv6 routing.
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].
6. ICMP processing
ICMP availability would become a challenge in port restricted address
environment. To support ICMP "session" initiated from a NATed B4,
the mechanism divides ICMP id field in the same way with dividing
port space, i.e. each NATed B4 will get the ICMP id range which is
identical to the allocated port range. A NATed B4only uses the
DBW Expires April 25, 2012 [Page 8]
Internet-Draft Lightweight extension to DS-Lite October 2011
allocated address and restricted id range when send out an ICMP
request. Hence the lightweight AFTR can encapsulate the
corresponding ICMP reply correctly according to the ICMP id field.
The inbound ICMP request would be left unsupported on the NATed AFTR,
which is the similar behavior of NAT/CGN. See details about ICMP
processing in section 4.2 of [I-D.sun-v6ops-laft6]
7. 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 lightweight 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).
DBW Expires April 25, 2012 [Page 9]
Internet-Draft Lightweight extension to DS-Lite October 2011
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 lightweight 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.
|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).
DBW Expires April 25, 2012 [Page 10]
Internet-Draft Lightweight extension to DS-Lite October 2011
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.
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.
8. IANA Considerations
TBD.
9. References
9.1. Normative References
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[I-D.bajko-pripaddrassign]
DBW Expires April 25, 2012 [Page 11]
Internet-Draft Lightweight extension to DS-Lite October 2011
Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
"Port Restricted IP Address Assignment",
draft-bajko-pripaddrassign-03 (work in progress),
September 2010.
[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
DBW Expires April 25, 2012 [Page 12]
Internet-Draft Lightweight extension to DS-Lite October 2011
Residual Deployment on IPv6 infrastructure - protocol
specification", draft-murakami-softwire-4rd-01 (work in
progress), September 2011.
[I-D.sun-v6ops-laft6]
Sun, Q. and C. Xie, "LAFT6: Lightweight address family
transition for IPv6", draft-sun-v6ops-laft6-01 (work in
progress), March 2011.
10. Acknowledgments
TBD
Appendix A. Variants of this approach
A.1. Introduction
This section defines variants of deployment for this lightweight 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].
DBW Expires April 25, 2012 [Page 13]
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
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62603059
Email: yong@csnet1.cs.tsinghua.edu.cn
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
DBW Expires April 25, 2012 [Page 14]
Internet-Draft Lightweight extension to DS-Lite October 2011
Beijing 100084
P.R.China
Phone: +86-10-62785983
Email: jianping@cernet.edu.cn
Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62785822
Email: peng-wu@foxmail.com
Qiong Sun
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552936>
Email: sunqiong@ctbri.com.cn
Chongfeng Xie
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
USA
Email: yiu_lee@cable.comcast.com
Gabor Bajko
Nokia
Email: gabor.bajko@nokia.com
DBW Expires April 25, 2012 [Page 15]