China Telecom

Room 708 No.118, Xizhimenneidajie Beijing 100035 P.R.China xiechf@ctbri.com.cn

Viagénie

246 Aberdeen Québec QC G1R 2E1 Canada +1 418 656 9254 simon.perreault@viagenie.ca http://viagenie.ca

Huawei Technologies

Bantian, Longgang District Shenzhen 518129 P.R. China cathy.zhou@huawei.com

This memo defines the procedures that a Lightweight B4 uses for provisioning its parameters with the Port Control Protocol.

Lightweight 4over6 (lw4o6) defines a model for providing IPv4 access over an IPv6 network in which the Network Address Translation (NAT) function is performed by the Customer-Premises Equipment (CPE) instead of being centralized on a Carrier-Grade NAT (CGN). Separately, the Port Control Protocol is used to manipulate port mappings in a NAT, firewall, port range router, or similar equipment. It is extended in with the ability to manipulate sets of ports instead of individual ports. This document describes how PCP is used to provision a Lightweight B4 (lwB4) with its port set and how to establish a tunnel to the Lightweight AFTR (lwAFTR).

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 . Terminology defined in is used extensively in this document.

The elements that are needed for lwB4 provisioning are listed in Section 5.1 of . Note (to be removed before publication): These elements can be provisioned with plain mode or encapsulation mode. In the plain mode, PCP port-set request is sent using native IPv6 packet, while in the encapsulation mode, PCP Port-set request is sent using ip-in-ip tunnel. In this draft, encapsulation mode is recommended to guarantee that the same lwAFTR/PCP server would be selected for PCP requests and subsequent ip-in-ip traffic.

The lwB4 initiates the provisioning procedure by requesting the OPTION_AFTR_NAME DHCPv6 option as indicated in . This option provides the IPv6 address for the lwAFTR. Once this address is known, the lwB4 sets up an IPv4-in-IPv6 tunnel with the following characteristics: value of OPTION_AFTR_NAME, after resolution of the name derived from the IPv6 destination by applying Default Address Selection 192.0.0.2 192.0.0.1 The IPv4 addresses correspond to the well-known B4 and AFTR addresses defined in Section 5.7 of .

Once the tunnel is up, the lwB4 sends a PCP MAP request with a PORT_SET option. The request is sent inside the tunnel to 192.0.0.1. The source is accordingly set to 192.0.0.2. The MAP request's Internal Port is set to 1 and the PORT_SET option's Port Set Size field is set to 65535, indicating that the lwB4 is prepared to accept a maximal size port set. Practically, the server will reply with a port set size corresponding to its configuration. Since there is no NAT in the lwAFTR, the internal port is always equal to the external port. The PCP server cannot change the internal port that the client sends. How can we overcome this? Add an offset parameter in the PORT_SET option? The PORT_SET option's P bit is set to 0. When a success response is received from the PCP server, the lwB4 extracts the external IPv4 address and port set from the response and uses them to configure its NAT44 function as described in . The lwB4 is now provisioned. The lwB4 needs to periodically refresh the port set it obtained with PCP as described in section 15 for as long as the lw4over6 tunnel is to be operational.

The lwB4 SHOULD implement a back-to-back PCP server-client. The PCP port-set client in lwB4 would get a public address and port-set from the PCP port-set server, and then the PCP server in the lwB4 will setup the mapping for the host behind the lwB4 and response with PCP client. The lwB4 MAY also implement a PCP proxy in case the host initiates a port-set request directly. It would forward the port-set request to PCP server to get a new port-set mapping or refresh an existing mapping.

This document considers two failover mechanisms: ICMP and PCP ANNOUNCE. In the ICMP case, when the lwB4 receives an ICMP error message from the lwAFTR, the lwB4 MAY re-initiate the dynamic port-restricted provisioning process. The detailed ICMP processing is introduced in . In the PCP case, when the lwAFTR receives traffic it doesn't have before, lwAFTR MAY send back a PCP unicast ANNOUNCE message. The lwB4 then will re-initiate the PCP Port-set request after receiving the ANNOUNCE message. In the case when there are large amount of lwB4s, an optimization of this mechanism MAY be needed to achieve fast failure recovery. Since it is layer 2 network between lwB4 and BNG, A BNG device MAY act a PCP proxy to receive unicast ANNOUNCE message from lwAFTR. It will then replace the unicast address of itself with the lwb4's multicast address and sends multicast ANNOUNCE message to the lwB4s.

TO BE COMPLETED

This document has no IANA actions.

Special thanks to Qiong Sun for her many contributions to this document. The authors would like to thank the following individuals who have participated in the drafting, review, and discussion of this memo: Jean-Philippe Dionne, Marc Blanchet, and Tina Tsou.

Harvard University

1350 Mass. Ave. Cambridge MA 02138 - +1 617 495 3864 sob@harvard.edu

General keyword In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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 RFC 2119. Note that the force of these words is modified by the requirement level of the document in which they are used. This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. [STANDARDS-TRACK] This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR). [STANDARDS-TRACK] The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages. This document defines an extension to PCP allowing clients to manipulate sets of ports as a whole. This is accomplished by a new MAP option: PORT_SET. DS-Lite [RFC6333] describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address Translation function from the DS-Lite AFTR to the B4, removing the requirement for a Carrier Grade NAT function in the AFTR. This reduces the amount of centralized state that must be held to a per- subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the B4s. This document revisits the dual-stack model and introduces the Dual- Stack Lite technology aimed at better aligning the costs and benefits of deploying IPv6 in service provider networks. Dual-Stack Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4- in-IPv6) and Network Address Translation (NAT). [STANDARDS-TRACK]