Softwire Working Group Y. Cui
Internet-Draft Tsinghua University
Intended status: Standards Track Q. Sun
Expires: August 5, 2012 China Telecom
M. Boucadair
France Telecom
T. Tsou
Huawei Technologies
Y. Lee
Comcast
February 2, 2012
Lightweight 4over6: An Extension to DS-Lite Architecture
draft-cui-softwire-b4-translated-ds-lite-05
Abstract
This document specifies an extension to DS-Lite called lightweight
4over6. This mechanism moves the translation function from the
tunnel concentrator (AFTR) to initiators (B4s), and hence reduces the
mapping scale on the concentrator to per-subscriber level. To
delegate the NAT function to the initiators, port-restricted IPv4
addresses are allocated to the initiators.
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."
This Internet-Draft will expire on August 5, 2012.
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
Cui, et al. Expires August 5, 2012 [Page 1]
Internet-Draft B4-translated DS-Lite February 2012
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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Lightweight 4over6 Overview . . . . . . . . . . . . . . . . . 7
5. Port-Restricted IPv4 Address Allocation . . . . . . . . . . . 8
6. Lightweight 4over6 Initiator Behavior . . . . . . . . . . . . 9
7. Lightweight 4over6 Concentrator Behavior . . . . . . . . . . . 10
8. Fragmentation and Reassembly . . . . . . . . . . . . . . . . . 11
9. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. ICMP processing . . . . . . . . . . . . . . . . . . . . . . . 13
11. Mechanism Analysis . . . . . . . . . . . . . . . . . . . . . . 14
12. Security Consideration . . . . . . . . . . . . . . . . . . . . 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
14. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 17
15. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
16.1. Normative References . . . . . . . . . . . . . . . . . . 20
16.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Cui, et al. Expires August 5, 2012 [Page 2]
Internet-Draft B4-translated DS-Lite February 2012
1. Introduction
Dual-Stack Lite technique (DS-Lite, [RFC6333]) provides IPv4 access
over an IPv6 network relying on two functional elements: B4 and AFTR.
The B4 element establishes an IPv4-in-IPv6 softwire to an AFTR and
encapsulates IPv4 packets in IPv6 packets. When the AFTR receives
theses IPv6 packets, it decapsulates them and then performs NAT44
[RFC3022]. This procedure allows AFTR to dynamically assign port
numbers to requesting users; hence, increases port-sharing ratio and
utilization (see [RFC6269]). There is a trade-off, though: the AFTR
is required to maintain active NAT sessions. In the centralized
deployment model where one AFTR serves thousands of users, the large
numbers of NAT sessions may become a performance bottleneck. 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 consumes more memory space.
To address these issues, this document proposes an extension to DS-
Lite technique. The extension is designed to simplify the AFTR
element by distributing NAT function among B4 elements. The B4
element is provisioned with an IPv6 address, an IPv4 address and a
port-set. The IPv6 address is used to create the Softwire, while the
IPv4 address and port-set is used for NAT44 in the home gateway
(CPE). The CPE performs NAPT on end user's packets with the IPv4
address and port-set. IPv4 packets are forwarded between the CPE and
the AFTR using IPv6 encapsulation. The AFTR maintains a mapping
entry with the CPE's IPv6 address, IPv4 address and port-set per
subscriber. For inbound IPv4 packets received on AFTR, it uses the
IPv4 destination address and port to match the IPv6 encapsulation
destination in the mapping table. The AFTR does not maintain any NAT
session entry. Therefore, this extension removes the NAT module from
the AFTR and significantly reduce the AFTR's mapping table size, and
it also relaxes the requirement to create a log entry per active NAT
session. In fact, the mechanism is an extended case which covers
addressing sharing for [I-D.ietf-softwire-public-4over6].
Compared to stateless solutions with port-set allocation such as
MAP[I-D.mdt-softwire-mapping-address-and-port], 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 when subscriber requested, the
dynamic allocation of IPv4 address and port-set makes more efficient
usage of IPv4 resource. Another example is an operator may only have
many small and discontinuous IPv4 blocks available to provide IPv4
over IPv6, rather than few large IPv4 blocks. This mechanism
preserves the dynamic feature of IPv4/IPv6 address binding as in DS-
Lite, so it won't require to administrate and manage many MAP domains
in the network and mapping rules in the CPEs.
Cui, et al. Expires August 5, 2012 [Page 3]
Internet-Draft B4-translated DS-Lite February 2012
This document is a variant of A+P called Binding Table Mode (see
Section 4.4 of [RFC6346]).
Cui, et al. Expires August 5, 2012 [Page 4]
Internet-Draft B4-translated DS-Lite February 2012
2. Conventions
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 [RFC2119].
Cui, et al. Expires August 5, 2012 [Page 5]
Internet-Draft B4-translated DS-Lite February 2012
3. Terminology
The document defines the following terms:
o Lightweight 4over6: lightweight 4over6 is an IPv4-over-IPv6 hub
and spoke mechanism, which supports address sharing [RFC6269] and
performs the IPv4 translation (NAT44) on the initiator (spoke)
side.
o Lightweight 4over6 initiator (or "initiator" for short): the
tunnel initiator in lightweight 4over6 mechanism. The lightweight
4over6 initiator may be a host directly connected to an IPv6
network, or a dual-stack CPE connecting an IPv4 local network to
an IPv6 network. It is collocated with a NAT44 function in
addition to IPv4-in-IPv6 encapsulation and de-capsulation
functions.
o Lightweight 4over6 concentrator (or "concentrator" for short): the
tunnel concentrator in lightweight 4over6 mechanism. The
lightweight 4over6 concentrator tunnels IPv4 packets to the IPv4
Internet over an IPv6 network. It provides IPv4-in-IPv6
encapsulation and decapsulation functions but not NAT function.
o Port-restricted IPv4 address: A public IPv4 address with
restricted port-set. In lightweight 4over6, multiple initiators
may share the same IPv4 address, while the port-sets must be non-
overlapping. Source ports of IPv4 packets sent by the initiator
must belong to the assigned port-set.
Cui, et al. Expires August 5, 2012 [Page 6]
Internet-Draft B4-translated DS-Lite February 2012
4. Lightweight 4over6 Overview
Lightweight 4over6 initiators and a lightweight 4over6 concentrator
are connected through an IPv6-enabled network. Both use IPv4-in-IPv6
encapsulation scheme to deliver IPv4 connectivity services. An
initiator uses port-restricted IPv4 address for IPv4 services
provisioned by the network. This address may be provisioned via PCP,
DHCPv4, DHCPv6, PPP IPCP, etc.(See Section 5 for further detail).
The concentrator keeps the mapping between the initiator's IPv6
address and the allocated IPv4 address + port-set.
+-------------------------+
| IPv6 ISP Network |
| Host |
+---------+ |
|LW 4over6| |
|Initiator|===============+---------+ +-----------+
+---------+ |LW 4over6| | IPv4 |
+--------+ | IPv4-in-IPv6 |Concen- |---| Internet |
| | +---------+ |trator | | |
|IPv4 LAN|--|LW 4over6|===============+---------+ +-----------+
| | |Initiator| DHCPv4/PCP |
+--------+ +---------+ |
| CPE |
| |
+-------------------------+
Figure 1 Lightweight 4over6 overview
Cui, et al. Expires August 5, 2012 [Page 7]
Internet-Draft B4-translated DS-Lite February 2012
5. Port-Restricted IPv4 Address Allocation
In lightweight 4over6, an initiator needs to be provisioned with the
public address and port-set. Different mechanisms can be used here
for port-restricted IPv4 address provisioning, e.g., DHCPv4, DHCPv6,
PCP, PPP IPCP, and even manual configuration.
Below are listed examples of implementing the provisioning through
the above mechanisms. They are not mandatory requirements, and the
specific protocol extensions is out of scope in this document.
o DHCPv4: the DHCPv4 protocol should be extended to support port-set
allocation [I-D.bajko-pripaddrassign]. Besides, the DHCP message
should send to the concentrator over IPv6. The concentrator can
be the DHCP server or DHCP relay
agent[I-D.ietf-dhc-dhcpv4-over-ipv6].
o PCP[I-D.ietf-pcp-base]: an initiator can launch multiple PCP
requests simultaneously to acquire a number ports within the same
IPv4 address, or use [I-D.tsou-pcp-natcoord] for one-time port-set
allocation.
o DHCPv6: the DHCPv6 protocol should be extended to support port-set
allocation [I-D.boucadair-dhcpv6-shared-address-option].
o IPCP: IPCP should be extended to carry the port-set. [RFC6431]
gives an example.
When using dynamic provisioning mechanism such as DHCP or PCP, the
initiator gets the IPv4 address and port-set allocated dynamically
from the concentrator. While provisioning the initiator, the
concentrator records the dynamic mapping rule between the IPv4
address, port-set and the IPv6 address simultaneously. The port-
restricted address allocation in lightweight 4over6 does not couple
with IPv6 addressing. Hence, there is no requirement for IPv4-IPv6
mapping relationship such as IPv4 address encoding, IPv6 prefix
length, multiplexing ratio, etc.
Cui, et al. Expires August 5, 2012 [Page 8]
Internet-Draft B4-translated DS-Lite February 2012
6. Lightweight 4over6 Initiator Behavior
A lightweight 4over6 initiator must discover the concentrator's IPv6
address. This IPv6 address can be learned through a variety of
mechanisms, ranging from an out-of-band mechanism, manual
configuration, DHCPv6, etc. The mechanism is out of scope in this
document.
A lightweight 4over6 initiator should support dynamic port-restricted
IPv4 address provisioning, by means of implementing the appropriate
mechanism (e.g., DHCP, PCP, etc.). The mechanism must be align
between the initiator and the concentrator (i.e. the PCP Server,
DHCPv4 server, etc.), which may be co-located with the concentrator.
The data plane functions of the initiator include address translation
(NAT44) and encapsulation/de-capsulation. The initiator runs a
standard NAT44 [RFC3022] using the allocated port-restricted address
as external IP and port numbers. Internal connected hosts source
IPv4 packets with a [RFC1918] address. When the initiator receives
the IPv4 packet, it performs NAT44 function on the source address and
port by using the public IPv4 address and a port number from the
allocated port-set. Then, it encapsulates the packet. The
destination IPv6 address is the concentrator's IPv6 address and the
source IPv6 address is the initiator's IPv6 address. Finally, the
initiator forwards the encapsulated packet to the configured
concentrator. When the initiator receives an IPv4-in-IPv6 packet
from the concentrator, it de-capsulates the IPv6 packet to retrieve
the embedded IPv4 packet. Then it performs NAT44 function and
translates the destination address and port based on the available
information in its local NAPT44 table.
If the initiator is acting as a CPE, it is responsible for performing
ALG functions (e.g., SIP, FTP), and other NAT traversal mechanisms
(e.g., UPnP, NAT-PMP, manual mapping configuration, PCP) for the
connected hosts. This is the same requirement for typical NAT44
gateways available today.
If the initiator is collocated in the host, the host will be
provisioned with the public IPv4 address and port-set directly. Some
applications relies on the socket API to allocate IPv4 source port,
the API will randomly allocate an available port to the application.
To ensure the port is from the provisioned port-set, the host should
either implement a local NAT to map the randomly generated port by
the API to the restricted port-set or modify the API to return a port
from the restricted port-set. Both options enable the host to source
IPv4 packet using the restricted port-set without modifying the IPv4
applications.
Cui, et al. Expires August 5, 2012 [Page 9]
Internet-Draft B4-translated DS-Lite February 2012
7. Lightweight 4over6 Concentrator Behavior
The lightweight 4over6 concentrator must create a table in which each
entry contains a public IPv4 address, a port-set and an initiator's
IPv6 address. The concentrator MUST synchronize the port-restricted
address provisioning process such as DHCP and PCP used by the
Initiator. This synchronization is deployment-specific (e.g., embed
PCP Server, DHCP relay or Server, RADIUS, etc.) When the IPv4
address and port-set is successfully provisioned to the Initiator,
the concentrator simultaneously creates a map entry in its table.
This entry contains the public IPv4 address, the port-set and the
initiator's IPv6 address. The lifetime is determined by the
provisioning mechanism. The IPv6 address in the map entry is used as
the index for encapsulating inbound packets. This map entry will be
deleted when the lifetime expires. The lifetime of the map entry
should be refreshed when the initiator renews/extends the allocation.
The data plane functions of the concentrator are encapsulation and
de-capsulation. When the concentrator receives an IPv4-in-IPv6
packet from an initiator, it de-capsulates the IPv6 header and
verifies the source port and address in the table. If the source
port and address matches the Initiator's IPv6 address in the table,
the concentrator forwards the packet to the IPv4 destination. If
not, the concentrator must discard the packet.
When the concentrator receives an IPv4 packet from the Internet, it
uses the destination address and port to lookup the destination
initiator's IPv6 address in the table. If a match is found, the
concentrator encapsulates the IPv4 Packet. The source is the
concentrator's IPv6 address and the destination is the initiator's
IPv6 address. Then, the concentrator forwards the packet to the
initiator natively over the IPv6 network. When no match is found,
the concentrator must discard the packet.
Cui, et al. Expires August 5, 2012 [Page 10]
Internet-Draft B4-translated DS-Lite February 2012
8. Fragmentation and Reassembly
Same considerations as Section 5.3 and Section 6.3 of [RFC6333] are
to be taken into account.
Cui, et al. Expires August 5, 2012 [Page 11]
Internet-Draft B4-translated DS-Lite February 2012
9. DNS
Section 5.5 and Section 6.4 of [RFC6333] are to be followed.
Cui, et al. Expires August 5, 2012 [Page 12]
Internet-Draft B4-translated DS-Lite February 2012
10. ICMP processing
ICMP does not work through NAT44 [RFC6269]). When implementing
lightweight 4over6, ICMP Identifier MUST be treated as port number
for UDP/TCP. Therefore, when the initiator generates an ICMP packet,
it MUST use an available port from its port-set as the ICMP
identifier. When the concentrator receives an ICMP reply packet from
the IPv4 network, it must use the identifier as the port number and
search its table. If a match is found, it must forward the ICMP
reply packet to the initiator stored in the entry. The lookup
process is identical to normal TCP/UDP lookup. For inbound ICMP
request packet, the concentrator may be configured in two modes:
o Forward the request to the appropriate initiator using the
Identifier field when a mapping entry is found; if not the ICMP
request is silently dropped.
o Discard all inbound ICMP requests.
The ICMP policy is determined by service providers.
Cui, et al. Expires August 5, 2012 [Page 13]
Internet-Draft B4-translated DS-Lite February 2012
11. Mechanism Analysis
Compared with original DS-Lite, lightweight 4over6 move the
translation function from the concentrator and distribute it to
initiators. This reduces states on the concentrator from per-session
level down to per-subscriber level. This potentially reduces the
concentrator complexity to manage a relatively large NAT table. In
theory, the concentrator should scale better and serve more
subscribers on the same hardware platform.
The initiator is provisioned with a public IPv4 address and port-set,
and translation is performed only once, so it is a single NAT
architecture.
When the initiator acts as a CPE, it is required to implement ALG and
NAT referral problem. These problems are solved today by combination
of UPnP, NAT-PmP, etc. Many existing CPEs have already implemented
these functionalities. So lightweight 4over6 initiator can leverage
these existing mechanisms to address the same problems.
When the AFTR performs per-session log, the volume could increase
rapidly because each new session may create a new log entry. Some
optimization has been discussed to reduce log volume
[I-D.donley-behave-deterministic-cgn]. When the concentrator
performs per-subscriber tunnel log, each subscriber creates only one
log. This is identical to logging subscriber by IPv4 address. This
mechanism is widely used today. Service providers can re-use the
same mechanism with minor modification.
Lightweight 4over6 does not couple port-restricted address and the
IPv6 addressing. No specific IPv6 address format is required. IPv4
and IPv6 addressing and routing remain separated. The service
provider can provide IPv4 in a flexible, on-demand way, as well as
manage the native IPv6 network without the influence of IPv4-over-
IPv6 requirements. This would ease to achieve future adjustment of
IPv4 address pool.
The trade-offs of lightweight 4over6 are possibility of lower IPv4
address utilization ratio and extra signaling behavior for
provisioning. When compared to stateless solutions, lightweight
4over6 still keeps subscriber-level states rather than becoming
purely stateless.
Cui, et al. Expires August 5, 2012 [Page 14]
Internet-Draft B4-translated DS-Lite February 2012
12. Security Consideration
As the port space for a subscriber shrinks significantly due to the
address sharing, the randomness for the port numbers of the
subscriber is decreased significantly. In other words, it is more
easier for an attacker to guess the port number used, which results
in attacks ranging from throughput reduction to broken connections or
data corruption. Here the port-set for a subscriber can be a bulk of
contiguous ports or non-contiguous ports. Contiguous port-set can't
help the situation, while with non-contiguous port-set (which may be
generated in a pseudo-random way [RFC6431]), the randomness of the
port number is improved, provided that the attacker is outside the
lightweight 4over6 domain and hence doesn't know the port-set
generation algorithm.
More considerations of IP address sharing discussed in Section 13 of
[RFC6269] are applicable to this solution.
Cui, et al. Expires August 5, 2012 [Page 15]
Internet-Draft B4-translated DS-Lite February 2012
13. IANA Considerations
This document does not include any IANA request.
Cui, et al. Expires August 5, 2012 [Page 16]
Internet-Draft B4-translated DS-Lite February 2012
14. Author List
The following are extended authors who contributed to the effort:
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
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: weapon@csnet1.cs.tsinghua.edu.cn
Chongfeng Xie
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552116
Cui, et al. Expires August 5, 2012 [Page 17]
Internet-Draft B4-translated DS-Lite February 2012
Email: xiechf@ctbri.com.cn
Xiaohong Deng
France Telecom
Email: xiaohong.deng@orange.com
Cathy Zhou
Huawei Technologies
Section B, Huawei Industrial Base, Bantian Longgang Shenzhen
518129
P.R.China
Email: cathyzhou@huawei.com
Cui, et al. Expires August 5, 2012 [Page 18]
Internet-Draft B4-translated DS-Lite February 2012
15. Acknowledgement
The authors would like to thank Alain Durand, Ole Troan, Ralph Droms
for their comments and feedback.
This document is a merge of two documents:
[I-D.cui-softwire-b4-translated-ds-lite] and
[I-D.zhou-softwire-b4-nat].
Cui, et al. Expires August 5, 2012 [Page 19]
Internet-Draft B4-translated DS-Lite February 2012
16. References
16.1. Normative References
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
T. Tsou, "Huawei Port Range Configuration Options for PPP
IP Control Protocol (IPCP)", RFC 6431, November 2011.
16.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.
[I-D.boucadair-dhcpv6-shared-address-option]
Boucadair, M., Levis, P., Grimault, J., Savolainen, T.,
and G. Bajko, "Dynamic Host Configuration Protocol
(DHCPv6) Options for Shared IP Addresses Solutions",
draft-boucadair-dhcpv6-shared-address-option-01 (work in
progress), December 2009.
[I-D.cui-softwire-b4-translated-ds-lite]
Cui, Y., Wu, J., Wu, P., Sun, Q., Xie, C., Zhou, C., Lee,
Y., and T. ZOU), "Lightweight 4over6 in access network",
Cui, et al. Expires August 5, 2012 [Page 20]
Internet-Draft B4-translated DS-Lite February 2012
draft-cui-softwire-b4-translated-ds-lite-04 (work in
progress), October 2011.
[I-D.donley-behave-deterministic-cgn]
Donley, C., Grundemann, C., Sarawat, V., and K.
Sundaresan, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments",
draft-donley-behave-deterministic-cgn-01 (work in
progress), January 2012.
[I-D.ietf-dhc-dhcpv4-over-ipv6]
Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6
Transport", draft-ietf-dhc-dhcpv4-over-ipv6-00 (work in
progress), November 2011.
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-22 (work in progress), January 2012.
[I-D.ietf-softwire-public-4over6]
Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
Lee, "Public IPv4 over Access IPv6 Network",
draft-ietf-softwire-public-4over6-00 (work in progress),
September 2011.
[I-D.mdt-softwire-mapping-address-and-port]
Troan, O., Matsushima, S., Murakami, T., Li, X., and C.
Bao, "Mapping of Address and Port (MAP)",
draft-mdt-softwire-mapping-address-and-port-03 (work in
progress), January 2012.
[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.
[I-D.tsou-pcp-natcoord]
Zhou, C., Tsou, T., Deng, X., Boucadair, M., and Q. Sun,
"Using PCP To Coordinate Between the CGN and Home Gateway
Via Port Allocation", draft-tsou-pcp-natcoord-04 (work in
progress), January 2012.
[I-D.zhou-softwire-b4-nat]
Deng, X., Boucadair, M., and C. Zhou, "NAT offload
extension to Dual-Stack lite",
draft-zhou-softwire-b4-nat-04 (work in progress),
October 2011.
Cui, et al. Expires August 5, 2012 [Page 21]
Internet-Draft B4-translated DS-Lite February 2012
Authors' Addresses
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
Qiong Sun
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552936>
Email: sunqiong@ctbri.com.cn
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Tina Tsou
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1-408-330-4424
Email: tena@huawei.com
Yiu L. Lee
Comcast
One Comcast Center
Philadelphia, PA 19103
USA
Email: yiu_lee@cable.comcast.com
Cui, et al. Expires August 5, 2012 [Page 22]