Network Working Group C. Xie
Internet-Draft China Telecom
Intended status: Standards Track S. Perreault
Expires: December 06, 2013 Viagénie
C. Zhou
Huawei Technologies
June 04, 2013

Provisioning Lightweight 4over6 (lw4o6) with the Port Control Protocol (PCP)
draft-perreault-softwire-lw4over6-pcp-00

Abstract

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

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 December 06, 2013.

Copyright Notice

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

Lightweight 4over6 (lw4o6) [I-D.ietf-softwire-lw4over6] 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 [RFC6887] is used to manipulate port mappings in a NAT, firewall, port range router, or similar equipment. It is extended in [I-D.ietf-pcp-port-set] 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).

2. Terminology

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].

Terminology defined in [I-D.ietf-softwire-lw4over6] is used extensively in this document.

3. Lightweight B4 Provisioning with PCP

The elements that are needed for lwB4 provisioning are listed in Section 5.1 of [I-D.ietf-softwire-lw4over6].

3.1. Setting Up the Tunnel

The lwB4 initiates the provisioning procedure by requesting the OPTION_AFTR_NAME DHCPv6 option as indicated in [RFC6334]. 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:

IPv6 destination:
value of OPTION_AFTR_NAME, after resolution of the name
IPv6 source:
derived from the IPv6 destination by applying Default Address Selection [RFC3484]
IPv4 source:
192.0.0.2
IPv4 destination:
192.0.0.1

The IPv4 addresses correspond to the well-known B4 and AFTR addresses defined in Section 5.7 of [RFC6333].

3.2. Configuration of the NAT44

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.

Note:
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 [I-D.ietf-softwire-lw4over6]. The lwB4 is now provisioned.

The lwB4 needs to periodically refresh the port set it obtained with PCP as described in [RFC6887] section 15 for as long as the lw4over6 tunnel is to be operational.

3.3. PCP Proxy

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.

3.4. Failover Mechanism

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 [I-D.ietf-softwire-lw4over6].

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.

4. Security Considerations

TO BE COMPLETED

5. IANA Considerations

This document has no IANA actions.

6. Acknowledgements

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.

7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R. and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[I-D.ietf-pcp-port-set] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T. and S. Perreault, "Port Control Protocol (PCP) Extension for Port Set Allocation", Internet-Draft draft-ietf-pcp-port-set-00, March 2013.
[I-D.ietf-softwire-lw4over6] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y. and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", Internet-Draft draft-ietf-softwire-lw4over6-00, April 2013.

7.2. Informative References

[RFC6333] Durand, A., Droms, R., Woodyatt, J. and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.

Authors' Addresses

Chongfeng Xie China Telecom Room 708 No.118, Xizhimenneidajie Beijing, 100035 P.R.China EMail: xiechf@ctbri.com.cn
Simon Perreault Viagénie 246 Aberdeen Québec, QC G1R 2E1 Canada Phone: +1 418 656 9254 EMail: simon.perreault@viagenie.ca URI: http://viagenie.ca
Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen, 518129 P.R. China EMail: cathy.zhou@huawei.com