Softwire Working Group Y. Cui
Internet-Draft Tsinghua University
Intended status: Standards Track Q. Sun
Expires: January 14, 2013 China Telecom
M. Boucadair
France Telecom
T. Tsou
Huawei Technologies
Y. Lee
Comcast
I. Farrer
Deutsche Telekom AG
July 13, 2012
Lightweight 4over6: An Extension to the DS-Lite Architecture
draft-cui-softwire-b4-translated-ds-lite-07
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 a per-subscriber level. To
delegate the NAPT 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 January 14, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Cui, et al. Expires January 14, 2013 [Page 1]
Internet-Draft B4-translated DS-Lite July 2012
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. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Lightweight 4over6 Overview . . . . . . . . . . . . . . . . . 5
5. Port-Restricted IPv4 Address Allocation . . . . . . . . . . . 5
6. Lightweight 4over6 Initiator Behavior . . . . . . . . . . . . 6
6.1. Initiator Provisioning . . . . . . . . . . . . . . . . . . 6
6.2. Initiator Data Plane Behavior . . . . . . . . . . . . . . 7
7. Lightweight 4over6 Concentrator Behavior . . . . . . . . . . . 7
7.1. Binding Table Maintenance . . . . . . . . . . . . . . . . 7
7.2. Concentrator Data Plane Behavior . . . . . . . . . . . . . 8
8. Fragmentation and Reassembly . . . . . . . . . . . . . . . . . 9
9. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. ICMP Processing . . . . . . . . . . . . . . . . . . . . . . . 9
11. Security Consideration . . . . . . . . . . . . . . . . . . . . 10
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
13. Author List . . . . . . . . . . . . . . . . . . . . . . . . . 10
14. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
15. Appendix: Alternatives for Port-Restricted Address
Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . 13
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
16.1. Normative References . . . . . . . . . . . . . . . . . . . 13
16.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Cui, et al. Expires January 14, 2013 [Page 2]
Internet-Draft B4-translated DS-Lite July 2012
1. Introduction
Dual-Stack Lite (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 the AFTR and
encapsulates IPv4 packets within IPv6 packets. When the AFTR
receives these IPv6 packets, it de-capsulates them and then performs
NAPT44 [RFC3022] on the IPv4 packets. This procedure allows the AFTR
to dynamically assign port numbers to requesting hosts; hence,
increasing the port-sharing ratio and utilization (see [RFC6269]).
There is a trade-off, however: the AFTR is required to maintain
active NAPT sessions. In the centralized deployment model where one
AFTR serves a large number of hosts, the huge number of NAPT sessions
may become a performance bottleneck. A large NAPT table demands more
processing power for maintaining and searching, as well as consumes
more memory space. On the other hand, NAPT44 function is already
widely supported and used in today's CPE devices. By leveraging this
existing NAPT function and perform NATPT44 on the CPEs, the binding
table in the centralized AFTR can be significantly reduced, and the
AFTR can offload the NAPT functionality.
This document proposes such an extension to the DS-Lite model. The
extension is designed to simplify the AFTR element by moving NAPT
functionality to the B4 elements. The B4 element is provisioned with
an IPv6 prefix, an IPv4 address and a port-set. An IPv6 address from
the assigned prefix is used to create the softwire, while the IPv4
address and port-set is used for NAPT44 in the home gateway (CPE).
The CPE performs NAPT on the end user's packets with the IPv4 address
and port-set. IPv4 packets are forwarded between the CPE and the
AFTR using IPv4-in-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 by the AFTR, the IPv4
destination address and port are used to find the IPv6 encapsulation
destination in the binding table. The AFTR does not maintain any
NAPT session entries.
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
architectures separated. They can administer native IPv6 network
addressing without the influence of IPv4-over-IPv6 requirements. For
example, an operator may want to provide IPv4 as an on-demand service
in its IPv6 network, based on subscriber requests. The dynamic
allocation of IPv4 addresses and port-sets makes more efficient usage
of IPv4 resources than stateless solutions in this case.
Another example is: An operator may only have many small and non-
contiguous IPv4 blocks available to provide IPv4 over IPv6, rather
Cui, et al. Expires January 14, 2013 [Page 3]
Internet-Draft B4-translated DS-Lite July 2012
than a few large contiguous IPv4 blocks. This mechanism preserves
the dynamic feature of IPv4/IPv6 address binding as in DS-Lite, so it
does not require the administration and management of many MAP
domains in the network and corresponding mapping rules in the CPEs.
The model that is presented here offers a solution for a hub-and-
spoke architecture only. It does not offer meshed IPv4 connectivity
between subscribers. The simplicity and flexibility of IPv4/v6
address planning and provisioning described here are a tradeoff for
this reduced functionality: the subscriber does not need the
information of other subscribers.
This document is an extended case, which covers address sharing for
[I-D.ietf-softwire-public-4over6]. It is also a variant of A+P
called Binding Table Mode (see Section 4.4 of [RFC6346]).
This document focuses on architectural considerations and
particularly on the expected behavior of involved functional elements
and their interfaces. Deployment-specific issues are discussed in a
companion document. As such, discussions about redundancy and
provisioning policy are out of scope.
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].
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 (NAPT44) on the initiator (spoke)
side.
o Lightweight 4over6 initiator (or "initiator"): the tunnel
initiator in the 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 NAPT44 function in
addition to IPv4-in-IPv6 encapsulation and de-capsulation
functions.
Cui, et al. Expires January 14, 2013 [Page 4]
Internet-Draft B4-translated DS-Lite July 2012
o Lightweight 4over6 concentrator (or "concentrator"): the tunnel
concentrator in the 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 de-
capsulation functions but does not perform a NAPT function.
o Port-restricted IPv4 address: A public IPv4 address with a
restricted port-set. In Lightweight 4over6, multiple initiators
may share the same IPv4 address, however, their port-sets must be
non-overlapping. Source ports of IPv4 packets sent by the
initiator must belong to the assigned port-set.
4. Lightweight 4over6 Overview
Lightweight 4over6 initiators and a Lightweight 4over6 concentrator
are connected through an IPv6-enabled network (Figure 1). Both use
an IPv4-in-IPv6 encapsulation scheme to deliver IPv4 connectivity
services. An initiator uses a port-restricted IPv4 address for IPv4
services delivered over the IPv6-enabled network (See Section 5 for
further detail). The concentrator keeps the binding 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
5. Port-Restricted IPv4 Address Allocation
In Lightweight 4over6, an initiator is provisioned with a public
address and port-set. Different mechanisms can be used for port-
restricted IPv4 address provisioning, e.g.- DHCPv4, DHCPv6, PCP, PPP
IPCP. The mechanism described in this document uses DHCPv4 as it is
Cui, et al. Expires January 14, 2013 [Page 5]
Internet-Draft B4-translated DS-Lite July 2012
widely deployed in services providers networks and supports all IPv4
and IPv6 addressing models.
DHCPv4 messages between the initiator and the DHCPv4 server MUST be
sent over IPv6 [I-D.ietf-dhc-dhcpv4-over-ipv6], and
[I-D.bajko-pripaddrassign] MUST be supported for port-set allocation.
Other optional alternatives to retrieve the public address and port-
set also exist. The specific protocol extensions are out of scope in
this document, however some alternatives are mentioned in the
Appendix Section.
6. Lightweight 4over6 Initiator Behavior
6.1. Initiator Provisioning
To configure the IPv4-in-IPv6 tunnel, the Lightweight 4over6
initiator MUST have 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. In
order to guarantee interoperability, a Lightweight 4over6 initiator
SHOULD implement the DHCPv6 option defined in [RFC6334]. The
initiator MUST use its WAN interface for sourcing the DHCPv6 request
as defined in [RFC6333].
Multi-homed CPE devices connected to two or more service providers
are not covered as part of this document.
A Lightweight 4over6 initiator MUST support dynamic port-restricted
IPv4 address provisioning, by means of implementing the DHCPv4
mechanism (including [I-D.ietf-dhc-dhcpv4-over-ipv6] and
[I-D.bajko-pripaddrassign]). The IPv6 address of the DHCPv4 server/
relay can be configured using a variety of methods, too, ranging from
an out-of-band mechanism, manual configuration, a variety of DHCPv6
options, or taking the concentrator address configuration when
collocating with concentrator. In order to guarantee
interoperability, an initiator SHOULD implement the DHCPv6 option
defined in [I-D.mrugalski-softwire-dhcpv4-over-v6-option]. If the
DHCPv4 over IPv6 client has multiple IPv6 addresses assigned to it's
WAN interface, the mechanisms defined in RFC3484 MUST be applied for
selecting the correct address as the source of the DHCPv4 over IPv6
request. A DHCPv4 over IPv6 client embedded within the initiator
MUST use the same IPv6 address as the data plane encapsulation source
address for all DHCPv4 over IPv6 requests. In the event the
encapsulation source address is changed for any reason (such as the
DHCP lease expiring), the DHCPv4 over IPv6 process MUST be re-
initiated.
Cui, et al. Expires January 14, 2013 [Page 6]
Internet-Draft B4-translated DS-Lite July 2012
6.2. Initiator Data Plane Behavior
The data plane functions of the initiator include address translation
(NAPT44), encapsulation and de-capsulation. The initiator runs
standard NAPT44 [RFC3022] using the allocated port-restricted address
as its external IP and port numbers.
Internally connected hosts source IPv4 packets with an [RFC1918]
address. When the initiator receives such an IPv4 packet, it
performs a NAPT44 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 with an IPv6 header. 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 IPv4 packet from the IPv6 packet.
Then, it performs the NAPT44 function and translates the destination
address and port, based on the available information in its local
NAPT44 table.
Tunneling MUST be done in accordance with [RFC2473] and [RFC4213].
The initiator is responsible for performing ALG functions (e.g., SIP,
FTP), and other NAPT traversal mechanisms (e.g., UPnP, NAPT-PMP,
manual mapping configuration, PCP) for the internal hosts. This is
the same requirement for typical NAPT44 gateways available today.
It's possible that an initiator is co-located in a host. In this
case, the functions of NAPT44 and encapsulation/de-capsulation are
implemented inside the host.
7. Lightweight 4over6 Concentrator Behavior
7.1. Binding Table Maintenance
The Lightweight 4over6 concentrator MUST maintain an address binding
table. Each entry in the table contains a public IPv4 address, a
port-set and an IPv6 address for a single initiator. The entry has
two functions: IPv6 encapsulation of inbound IPv4 packets destined to
the initiator and validation of outbound IPv4-in-IPv6 packets
received from the initiator for de-capsulation.
The concentrator MUST synchronize the binding information with the
port-restricted address provisioning process. With DHCPv4 as the
Cui, et al. Expires January 14, 2013 [Page 7]
Internet-Draft B4-translated DS-Lite July 2012
provisioning method, the initiators send DHCP messages to the DHCP
server or relay agent over IPv6. If the concentrator implements a
local DHCPv4 server or relay agent, the initiators MAY send the
messages to the concentrator; then the concentrator is able to learn
the bindings between IPv6 address and IPv4 address with port set
directly. If the concentrator does not participate in the port-
restricted address provisioning process, the binding MUST be
synchronized through other methods (e.g. out-of-band static update).
The exact mechanism for this is deployment-specific and out of scope.
For all provisioning processes, the lifetime of binding table entries
MUST be synchronized with the lifetime of address allocations.
7.2. Concentrator Data Plane Behavior
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 addresses and port in the binding table. If the
source addresses and port match an entry in the binding table (that
is to say, the source IPv6 address in the IPv6 header is identical to
the IPv6 address of the entry, the source IPv4 address in the IPv4
header is identical to the IPv4 address of the entry, and the source
port falls into the port-set of the entry), the concentrator forwards
the packet to the IPv4 destination. If no match is found (e.g., not
authorized IPv4 address, port out of range, etc.), the concentrator
MUST discard the packet. An ICMP error message MAY be sent back to
the requesting initiator. The ICMP policy SHOULD be configurable.
When the concentrator receives an inbound IPv4 packet, it uses the
IPv4 destination address and port to lookup the destination
initiator's IPv6 address in the binding 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 from the matched entry. Then, the concentrator forwards
the packet to the initiator natively over the IPv6 network. If no
match is found, the concentrator MUST discard the packet. An ICMP
error message MAY be sent back. The ICMP policy SHOULD be
configurable.
Tunneling MUST be done in accordance with [RFC2473] and [RFC4213].
The concentrator MUST support hairpinning of traffic between two
initiators, by performing de-capsulation and re-encapsulation of
packets.
Cui, et al. Expires January 14, 2013 [Page 8]
Internet-Draft B4-translated DS-Lite July 2012
8. Fragmentation and Reassembly
The same considerations as described in Section 5.3 and Section 6.3
of [RFC6333] are to be taken into account.
9. DNS
The procedure described in Section 5.5 and Section 6.4 of [RFC6333]
is to be followed.
10. ICMP Processing
ICMP does not work in an address sharing environment without special
handling [RFC6269]. When implementing Lightweight 4over6, the
following behaviour SHOULD be implemented to provide basic remote
IPv4 service diagnostics for a port restricted CPE: For inbound ICMP
messages, the concentrator MAY behave in two modes:
Either:
1. Check the ICMP Type field.
2. If the ICMP type is set to 8 (echo request), then the
concentrator MUST discard the packet.
3. If the ICMP field is set to 0 (echo reply), then the concentrator
must take the value of the ICMP identifier field as the source
port.
4. If the ICMP type field is set to any other value, then the
concentrator MUST use the method described in REQ-3 of [RFC5508]
to locate the source port within the transport layer header in
ICMP packet's data field. The destination IPv4 address and
source port extracted from the ICMP packet are then used to make
a lookup in the binding table. If a match is found, it MUST
forward the ICMP reply packet to the IPv6 address stored in the
entry.
Or:
o Discard all inbound ICMP requests.
The ICMP policy SHOULD be configurable.
The initiator should implement the requirements defined in [RFC5508]
for ICMP forwarding. For ICMP echo request packets originating from
Cui, et al. Expires January 14, 2013 [Page 9]
Internet-Draft B4-translated DS-Lite July 2012
the private IPv4 network, the initiator SHOULD implement the method
described in [RFC6346] and use an available port from it's port-set
as the ICMP Identifier.
For both the concentrator and the initiator, ICMPv6 MUST be handled
as described in [RFC2473].
11. 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 much
easier for an attacker to guess the port number used, which could
result in attacks ranging from throughput reduction to broken
connections or data corruption. The port-set for a subscriber can be
a set of contiguous ports or non-contiguous ports. Contiguous port-
sets do not reduce this threat. However, 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 does not know the
port-set generation algorithm.
More considerations about IP address sharing are discussed in Section
13 of [RFC6269], which is applicable to this solution.
12. IANA Considerations
This document does not include any IANA request.
13. 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
Cui, et al. Expires January 14, 2013 [Page 10]
Internet-Draft B4-translated DS-Lite July 2012
Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-62785822
Email: pengwu.thu@gmail.com
Chongfeng Xie
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552116
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
Alain Durand
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA 94089-1206
USA
Email: adurand@juniper.net
Cui, et al. Expires January 14, 2013 [Page 11]
Internet-Draft B4-translated DS-Lite July 2012
Reinaldo Penno
Cisco
Email: repenno@cisco.com
Alex Clauberg
Deutsche Telekom AG
GTN-FM4
Landgrabenweg 151
Bonn, CA 53227
Germany
Email: axel.clauberg@telekom.de
Lionel Hoffmann
Bouygues Telecom
TECHNOPOLE
13/15 Avenue du Marechal Juin
Meudon 92360
France
Email: lhoffman@bouyguestelecom.fr
Maoke Chen
FreeBit Co., Ltd.
13F E-space Tower, Maruyama-cho 3-6
Shibuya-ku, Tokyo 150-0044
Japan
Email: fibrib@gmail.com
14. Acknowledgement
The authors would like to thank Ole Troan, Ralph Droms for their
comments and feedback.
This document is a merge of three documents:
[I-D.cui-softwire-b4-translated-ds-lite], [I-D.zhou-softwire-b4-nat]
and [I-D.penno-softwire-sdnat].
Cui, et al. Expires January 14, 2013 [Page 12]
Internet-Draft B4-translated DS-Lite July 2012
15. Appendix: Alternatives for Port-Restricted Address Allocation
Besides DHCPv4, other alternatives for address and port-set
provisioning, e.g.- PCP, DHCPv6, IPCP, MAY also be implemented.
o PCP[I-D.ietf-pcp-base]: an initiator MAY use
[I-D.tsou-pcp-natcoord] to retrieve a restricted IPv4 address and
a set of ports.
o DHCPv6: the DHCPv6 protocol MAY be extended to support port-set
allocation [I-D.boucadair-dhcpv6-shared-address-option], along
with IPv6-mapped IPv4 address allocation.
o IPCP: IPCP MAY be extended to carry the port-set (e.g.,
[RFC6431]).
In a Lightweight 4over6 domain, the same provisioning mechanism MUST
be enabled in the initiator, the concentrator and the provisioning
server.
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.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
Cui, et al. Expires January 14, 2013 [Page 13]
Internet-Draft B4-translated DS-Lite July 2012
June 2011.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite",
RFC 6334, 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-04 (work in progress),
April 2012.
[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., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the DS-Lite
Architecture", draft-cui-softwire-b4-translated-ds-lite-06
(work in progress), May 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-03 (work in
progress), May 2012.
[I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-26 (work in progress), June 2012.
Cui, et al. Expires January 14, 2013 [Page 14]
Internet-Draft B4-translated DS-Lite July 2012
[I-D.ietf-softwire-public-4over6]
Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
Lee, "Public IPv4 over IPv6 Access Network",
draft-ietf-softwire-public-4over6-01 (work in progress),
March 2012.
[I-D.mdt-softwire-mapping-address-and-port]
Bao, C., Troan, O., Matsushima, S., Murakami, T., and X.
Li, "Mapping of Address and Port (MAP)",
draft-mdt-softwire-mapping-address-and-port-03 (work in
progress), January 2012.
[I-D.mrugalski-softwire-dhcpv4-over-v6-option]
Mrugalski, T. and P. Wu, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for DHCPv4 over IPv6
Transport",
draft-mrugalski-softwire-dhcpv4-over-v6-option-00 (work in
progress), April 2012.
[I-D.penno-softwire-sdnat]
Penno, R., Durand, A., Hoffmann, L., and A. Clauberg,
"Stateless DS-Lite", draft-penno-softwire-sdnat-02 (work
in progress), March 2012.
[I-D.tsou-pcp-natcoord]
Sun, Q., Boucadair, M., Deng, X., Zhou, C., and T. Tsou,
"Using PCP To Coordinate Between the CGN and Home Gateway
Via Port Allocation", draft-tsou-pcp-natcoord-05 (work in
progress), March 2012.
[I-D.zhou-softwire-b4-nat]
Zhou, C., Boucadair, M., and X. Deng, "NAT offload
extension to Dual-Stack lite",
draft-zhou-softwire-b4-nat-04 (work in progress),
October 2011.
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
Cui, et al. Expires January 14, 2013 [Page 15]
Internet-Draft B4-translated DS-Lite July 2012
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
Ian Farrer
Deutsche Telekom AG
GTN-FM4,Landgrabenweg 151
Philadelphia, Bonn 53227
Germany
Email: ian.farrer@telekom.de
Cui, et al. Expires January 14, 2013 [Page 16]