[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 draft-ietf-pcp-dslite

PCP Working Group                                              F. Dupont
Internet-Draft                               Internet Systems Consortium
Intended status: Standards Track                                 T. Tsou
Expires: February 17, 2012                           Huawei Technologies
                                                                  J. Qin
                                                         ZTE Corporation
                                                         August 16, 2011

       The Port Control Protocol in Dual-Stack Lite environments


   This document specifies the so-called "plain mode" for the use of the
   Port Control Protocol (PCP) in Dual-Stack Lite (DS-Lite)

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 February 17, 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 February 17, 2012               [Page 1]

Internet-Draft                 PCP DS-Lite                   August 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, named the Basic Bridging BroadBand (B4)
   encapsulates IPv4 packets into a IPv6 tunnel to the carrier-grade
   NAT, named the Address Family Transition Router (AFTR) run by the
   Internet Service Provider (ISP).

   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.  Here the
   PCP server controls the AFTR.

   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",
   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

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

3.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

Dupont, et al.          Expires February 17, 2012               [Page 2]

Internet-Draft                 PCP DS-Lite                   August 2011

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.

6.  References

6.1.  Normative References

              Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)",
              draft-ietf-pcp-base-13 (work in progress), July 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.

6.2.  Informative References

              Boucadair, M., Penno, R., Wing, D., and F. Dupont, "Port
              Control Protocol (PCP) Proxy Function",
              draft-bpw-pcp-proxy-01 (work in progress), March 2011.

              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.

Dupont, et al.          Expires February 17, 2012               [Page 3]

Internet-Draft                 PCP DS-Lite                   August 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.

Authors' Addresses

   Francis Dupont
   Internet Systems Consortium

   Email: fdupont@isc.org

Dupont, et al.          Expires February 17, 2012               [Page 4]

Internet-Draft                 PCP DS-Lite                   August 2011

   Tina Tsou
   Huawei Technologies
   2330 Central Expressway
   Santa Clara

   Phone: +1-408-330-4424
   Email: tina.tsou.zouting@huawei.com

   Jacni Qin
   ZTE Corporation

   Email: jacni@jacni.com

Dupont, et al.          Expires February 17, 2012               [Page 5]

Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/