PCP Working Group F. Dupont Internet-Draft Internet Systems Consortium Intended status: Standards Track T. Tsou Expires: May 2, 2012 Huawei Technologies J. Qin ZTE Corporation October 30, 2011 The Port Control Protocol in Dual-Stack Lite environments draft-dupont-pcp-dslite-01 Abstract This document specifies the so-called "plain mode" for the use of the Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite) environments. 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 May 2, 2012. Copyright Notice Copyright (c) 2011 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 Dupont, et al. Expires May 2, 2012 [Page 1] Internet-Draft PCP DS-Lite October 2011 described in the Simplified BSD License. 1. Introduction The Dual-Stack Lite (DS-Lite, [RFC6333]) is a technology which 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). Typically, the home gateway embeds a Basic Bridging BroadBand (B4) capability that encapsulates IPv4 traffic into a IPv6 tunnel to the carrier-grade NAT, named the Address Family Transition Router (AFTR). AFTRs are run by service providers. The Port Control Protocol (PCP, [I-D.ietf-pcp-base] allows customer applications to create mappings in a NAT for new inbound communications destined to machines located behind a NAT. In a DS- Lite environment, PCP servers control AFTR devices. Two different modes of operations were proposed: the plain and the encapsulation modes. This document selects the plain mode as the one to use. 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 [RFC2119]. 2. Plain Mode In the plain mode the B4, the customer end-point of the DS-Lite IPv6 tunnel, implements a PCP proxy ([I-D.bpw-pcp-proxy]) function and uses UDP over IPv6 with the AFTR to send PCP requests and receive PCP responses. The B4 MUST source PCP requests with the IPv6 address of its DS-Lite tunnel end-point and MUST use a THIRD PARTY option either empty or carrying the IPv4 internal address of the mappings. In the plain mode the PCP discovery ([I-D.ietf-pcp-base] section 7.1 "General PCP Client: Generating a Request") is changed into: 1. if a PCP server is configured (e.g., in a configuration file or via DHCPv6), that single configuration source is used as the list of PCP Server(s), else; 2. use the IPv6 address of the AFTR. To summary: the first rule remains the same with the precision that DHCP is DHCPv6, in the second rule the default router list is Dupont, et al. Expires May 2, 2012 [Page 2] Internet-Draft PCP DS-Lite October 2011 replaced by the AFTR. 3. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 4. Security Considerations The plain mode provides a control point inside the home network where any policy on PCP requests can be applied, e.g.: o restrict the use of THIRD PARTY options to the B4 o apply an access-list on internal addresses and/or ports At the opposite the encapsulation mode Appendix A by default is fully transparent for the B4: PCP requests are blindly encapsulated as any other IPv4 packets to the Internet. So to apply a policy on them requires heavier and far less flexible tools. 5. Acknowledgments Reinaldo Penno who checks the validity of the argument about the relative complexity of the encapsulation mode at the AFTR side. Christian Jacquenet and Mohammed Boucadair who proposed improvements to the document, including the PCP server discovery by Mohammed. 6. References 6.1. Normative References [I-D.ietf-pcp-base] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp-base-16 (work in progress), October 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. Dupont, et al. Expires May 2, 2012 [Page 3] Internet-Draft PCP DS-Lite October 2011 6.2. Informative References [I-D.bpw-pcp-proxy] Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port Control Protocol (PCP) Proxy Function", draft-bpw-pcp-proxy-02 (work in progress), September 2011. [I-D.bpw-pcp-upnp-igd-interworking] Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port Control Protocol (PCP) Interworking Function", draft-bpw-pcp-upnp-igd-interworking-02 (work in progress), February 2011. Appendix A. Encapsulation Mode The encapsulation mode deals at the B4 side with PCP traffic as any IPv4 traffic: it is encapsulated to and decapsulated from the AFTR over the DS-Lite IPv4 over IPv6 tunnel. At the AFTR side things are a bit more complex because the PCP server needs the context, here the source IPv6 address, for both to manage mappings and to send back response. So the AFTR MUST tag PCP requests with the source IPv6 address after decapsulation and before forwarding them to the PCP server, and use the same tag to encapsulate PCP responses to correct B4s. (the term "tag" is used to describe the private convention between the AFTR and the PCP server). Appendix B. Justification We believe most customers will run a PCP proxy on the B4 because: o they want a control point where to apply security (Section 4) o they run an InterWorking Function (IWF) for other protocols ([I-D.bpw-pcp-upnp-igd-interworking]) on the B4 so the proxy is just part of a bigger system BTW when the home network has only one node (dual-stack capable with embedded B4 element) attached, it is the PCP client. For a PCP proxy to use IPv4 (encapsulation mode) or IPv6 (plain mode) does not make a sensible difference, so from an implementation point of view the real difference is on the PCP server / AFTR side: the encapsulation mode require an Application Level Gateway (ALG) to tag PCP request with the corresponding customer after decapsulation, when the plain mode is fully transparent. Dupont, et al. Expires May 2, 2012 [Page 4] Internet-Draft PCP DS-Lite October 2011 Authors' Addresses Francis Dupont Internet Systems Consortium Email: fdupont@isc.org Tina Tsou Huawei Technologies 2330 Central Expressway Santa Clara USA Phone: +1-408-330-4424 Email: tina.tsou.zouting@huawei.com Jacni Qin ZTE Corporation Shanghai P.R.China Email: jacni@jacni.com Dupont, et al. Expires May 2, 2012 [Page 5]