Skip to main content

Lightweight 4over6: An Extension to the DS-Lite Architecture
draft-cui-softwire-b4-translated-ds-lite-07

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Yong Cui , Qiong Sun , Mohamed Boucadair , Tina Tsou (Ting ZOU) , Yiu Lee , Ian Farrer
Last updated 2012-07-13
Replaced by draft-ietf-softwire-lw4over6, RFC 7596
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-cui-softwire-b4-translated-ds-lite-07
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]