PCP Third Party ID Option
draft-ietf-pcp-third-party-id-option-04

Internet Engineering Task Force                                 A. Ripke
Internet-Draft                                                 R. Winter
Updates: 6887 (if approved)                                     T. Dietz
Intended status: Standards Track                              J. Quittek
Expires: April 21, 2016                                              NEC
                                                             R. da Silva
                                                          Telefonica I+D
                                                        October 19, 2015

                       PCP Third Party ID Option
                draft-ietf-pcp-third-party-id-option-04

Abstract

   This document describes a new Port Control Protocol (PCP) option
   called THIRD_PARTY_ID.  It is designed to be used in combination with
   the THIRD_PARTY option specified in RFC 6887 but can also be used
   without it.  The THIRD_PARTY_ID serves to identify a Third Party in
   situations where a third party's IP address contained in the
   THIRD_PARTY option does not provide sufficient information to create
   requested mappings in a PCP-controlled device.

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 April 21, 2016.

Copyright Notice

   Copyright (c) 2015 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

Ripke, et al.            Expires April 21, 2016                 [Page 1]
Internet-Draft               Third Party ID                 October 2015

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Target Scenarios  . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Carrier-hosted UPnP IGD-PCP IWF . . . . . . . . . . . . .   6
     3.2.  Carrier Web Portal  . . . . . . . . . . . . . . . . . . .   7
   4.  Format  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Result Codes  . . . . . . . . . . . . . . . . . . . . . .   9
   5.  Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Generating a Request  . . . . . . . . . . . . . . . . . .  10
     5.2.  Processing a Request  . . . . . . . . . . . . . . . . . .  10
     5.3.  Processing a Response . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The IETF has specified the Port Control Protocol (PCP) [RFC6887] to
   control how packets are translated and forwarded by a PCP-controlled
   device such as a network address translator (NAT) or firewall.

   This document focuses on the scenarios where the PCP client sends
   requests that concern internal addresses other than the address of
   the PCP client itself.

   There is already an option defined for this purpose in the RFC 6887
   [RFC6887] called the THIRD_PARTY option.  The THIRD_PARTY option
   carries the IP address of a host for which a PCP client requests an
   action at the PCP server.  The THIRD_PARTY option can, for example,
   be used if port mapping requests for a carrier-grade NAT (CGN) are
   not sent from PCP clients at subscriber's terminals, but, for
   example, from a PCP Interworking Function which requests port
   mappings.

Ripke, et al.            Expires April 21, 2016                 [Page 2]
Internet-Draft               Third Party ID                 October 2015

   In some cases, the THIRD_PARTY option is not sufficient and further
   means are needed for identifying the third party.  Such cases are
   addressed by the THIRD_PARTY_ID option, that is specified in this
   document.

   The primary issue addressed by the THIRD_PARTY_ID option is that
   there are CGN deployments that do not distinguish internal hosts by
   their IP address alone, but use further identifiers (IDs) for unique
   subscriber identification.  This is, for example, the case if a CGN
   supports overlapping private or shared IP address spaces
   [RFC1918][RFC6598] for internal hosts of different subscribers.  In
   such cases, different internal hosts are identified and mapped at the
   CGN by their IP address and/or another ID, for example, the ID of a
   tunnel between the CGN and the subscriber.  In these scenarios (and
   similar ones), the internal IP address contained in the THIRD_PARTY
   option is not sufficient to de-multiplex connections from internal
   hosts.  An additional identifier needs to be present in the PCP
   message in order to uniquely identify an internal host.  The
   THIRD_PARTY_ID option is used to carry this ID.

   This applies to some of the PCP deployment scenarios that are listed
   in Section 2.1 of RFC 6887 [RFC6887], in particular to a Layer-2
   aware NAT which is described in more detail in Section 3, or GI-DS-
   Lite [RFC6674] and ds-extra-lite [RFC6619].

   The THIRD_PARTY_ID option is defined for the PCP opcodes MAP and
   PEER.  It can be used independently or in combination with the
   THIRD_PARTY option for the PCP opcodes MAP and PEER.

2.  Terminology

   The terminology defined in the specification of PCP [RFC6887]
   applies.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

3.  Target Scenarios

   This section describes two scenarios that illustrate the use of the
   THIRD_PARTY_ID option:

   1.  a UPnP IGD-PCP IWF (Universal Plug and Play Internet Gateway
       Device - Port Control Protocol Interworking Function [RFC6970]),

   2.  a carrier web portal for port mapping.

Ripke, et al.            Expires April 21, 2016                 [Page 3]
Internet-Draft               Third Party ID                 October 2015

   The scenarios serve as examples.  This document does not restrict the
   applicability of the THIRD_PARTY_ID to certain scenarios.  The
   THIRD_PARTY_ID can include any Layer-2 identifier like a MAC address
   or other subscriber identifiers as, for example, mentioned in section
   6 of [I-D.boucadair-pcp-sfc-classifier-control].  The THIRD_PARTY_ID
   can also be used for the firewall control, including the case of a
   virtual CPE, see section 3 of [I-D.lee-vhs-usecases].

   This document focuses on scenarios where the THIRD_PARTY_ID option is
   used in combination with the THIRD_PARTY option and where the
   information carried by the THIRD_PARTY option alone is ambiguous.
   However, the THIRD_PARTY_ID option can be used in further cases where
   a specified identification is potentially ambiguous for the PCP
   server and where an additional THIRD_PARTY_ID option can make it
   unambiguous.

   Such use cases are not necessarily bound to requests where the
   THIRD_PARTY option is used.  Also envisioned is the use of the
   THIRD_PARTY_ID option in requests that do not contain a THIRD_PARTY
   option.  An example is its use in combination with the proposed
   TSELECT opcode as described in [I-D.reddy-pcp-sdn-firewall].

   Both scenarios elaborated in this document are refinements of the
   same basic scenario shown in Figure 1 which is considered as a PCP
   deployment scenario employing Layer-2 aware NATs as listed in
   Section 2.1 of [RFC6887].  It has a carrier operating a CGN and a
   Port Control Protocol Interworking Function (PCP IWF) [RFC6970] for
   subscribers to request port mappings at the CGN.  The PCP IWF
   communicates with the CGN using PCP.  For this purpose the PCP IWF
   contains a PCP client serving multiple subscribers and the CGN is co-
   located with a PCP server.  The way subscribers interact with the PCP
   IWF for requesting port mappings for their internal hosts is not
   specified in this basic scenario, but it is elaborated on more in the
   specific scenarios in Section 3.1 and Section 3.2.

   The CGN operates as a Layer-2 aware NAT.  Unlike a standard NAT, it
   includes a subscriber identifier in addition to the source IP address
   in entries of the NAT mapping table.

Ripke, et al.            Expires April 21, 2016                 [Page 4]
Internet-Draft               Third Party ID                 October 2015

   +--------------+    +------------------+
   | Subscriber   |    | Carrier          |    ==== L2 connection(s)
   |              |    | +--------------+ |         between subscriber
   |              +......+ PCP          | |         and CGN
   | +----------+ |    | | Interworking | |    #### PCP communication
   | | Internal | |    | | Function     | |    .... Subscriber - IWF
   | | Host     | |    | +-----#--------+ |         interaction
   | +----+-----+ |    |       #          |         (elaborated
   |      |       |    | +-----#--------+ |         in specific
   | +----+-----+ |    | | PCP Server   | |         scenarios below)
   | |  CPE     | |    | |              | |
   | |          +-+======+ CGN L2NAT    +--------- Public Internet
   | +----------+ |    | +--------------+ |
   +--------------+    +------------------+

        Figure 1: Carrier hosted PCP IWF for port mapping requests

   Internal hosts in the subscriber's network use private IP addresses
   ([RFC1918]).  There is no NAT between the internal host and the CGN,
   and there is an overlap of addresses used by internal hosts at
   different subscribers.  That is why the CGN needs more than just the
   internal host's IP address to distinguish internal hosts at different
   subscribers.  A commonly deployed method for solving this issue is
   using an additional identifier for this purpose.  A natural candidate
   for this additional identifier at the CGN is the ID of the tunnel
   that connects the CGN to the subscriber's network.  The subscriber's
   CPE operates as a Layer-2 bridge.

   Requests for port mappings from the PCP IWF to the CGN need to
   uniquely identify the internal host for which a port mapping is to be
   established or modified.  Already existing for this purpose is the
   THIRD_PARTY option that can be used to specify the internal host's IP
   address.  The THIRD_PARTY_ID option is introduced for carrying the
   additional third party information needed to identify the internal
   host in this scenario.

   The additional identifier for internal hosts needs to be included in
   MAP requests from the PCP IWF in order to uniquely identify the
   internal host that should have its address mapped.  This is the
   purpose that the new THIRD_PARTY_ID serves in this scenario.  It
   carries the additional identifier, that is the tunnel ID, that serves
   for identifying an internal host in combination with the internal
   host's (private) IP address.  The IP address of the internal host is
   included in the PCP IWF's mapping requests by using the THIRD_PARTY
   option.

   The information carried by the THIRD_PARTY_ID is not just needed to
   identify an internal host in a PCP request.  The CGN needs this

Ripke, et al.            Expires April 21, 2016                 [Page 5]
Internet-Draft               Third Party ID                 October 2015

   information in its internal mapping tables for translating packet
   addresses and for forwarding packets to subscriber-specific tunnels.

   How the carrier PCP IWF is managing port mappings, such as, for
   example, automatically extending the lifetime of a mapping, is beyond
   the scope of this document.

3.1.  Carrier-hosted UPnP IGD-PCP IWF

   This scenario further elaborates the basic one above by choosing
   UPnP-IGD as the communication protocol between the subscriber and the
   carrier's PCP IWF.  Then obviously, the PCP IWF is realized as a UPnP
   IGD-PCP IWF as specified in [RFC6970].

   As shown in Figure 2 it is assumed here that the UPnP IGD-PCP IWF is
   not embedded in the subscriber premises router, but offered as a
   service to the subscriber.  Further, it is assumed that the UPnP IGD-
   PCP IWF is not providing NAT functionality.

   This requires that the subscriber is able to connect to the UPnP IGD-
   PCP IWF to request port mappings at the CGN using UPnP-IGD as
   specified in [RFC6970].  In this scenario the connection is provided
   via (one of the) tunnel(s) connecting the subscriber's network to the
   BRAS and an extension of this tunnel from the BRAS to the UPnP IGD-
   PCP IWF.  Note that there are other alternatives that can be used for
   providing the connection to the UPnP IGD-PCP IWF.  The tunnel
   extension used in this scenario can, for example, be realized by a
   forwarding function for UPnP messages at the BRAS that forwards such
   messages through per-subscriber tunnels to the UPnP IGD-PCP IWF.
   Depending on an actual implementation, the UPnP IGD-PCP IWF can then
   either use the ID of the tunnel in which the UPnP message arrived
   directly as THIRD_PARTY_ID for PCP requests to the CGN or it uses the
   ID of the tunnel to retrieve the THIRD_PARTY_ID from the AAA server.

   To support the latter option, the BRAS needs to register the
   subscriber's tunnel IDs at the AAA Server at the time it contacts the
   AAA server for authentication and/or authorization of the subscriber.
   The tunnel IDs to be registered per subscriber at the AAA server may
   include the tunnel between CPE and BRAS, between BRAS and UPnP IGD-
   PCP IWF, and between BRAS and CGN.  The UPnP IGD-PCP IWF queries the
   AAA Server for the ID of the tunnel between BRAS and CGN, because
   this is the identifier to be used as the THIRD_PARTY_ID in the
   subsequent port mapping request.

Ripke, et al.            Expires April 21, 2016                 [Page 6]
Internet-Draft               Third Party ID                 October 2015

   +--------------+    +------------------------------------+
   | Subscriber   |    | Carrier                            |
   |              |    | +----------------------------+     |
   |              |    | |          AAA Server        |     |
   |              |    | +-----+---------------+------+     |
   |              |    |       |               |            |
   | +----------+ |    | +-----+---+     +-----+------+     |
   | | Internal | |    | |         +=====+            |     |
   | | Host     | |    | |    ...........| UPnP IGD   |     |
   | +----+-----+ |    | |    .    +=====+ PCP IWF    |     |
   |      |  .    |    | |    .    |     +-----#------+     |
   | +----+--.--| |    | |    .    |           #            |
   | |    |  .  +========+    .    |     +-----#------+     |
   | |    |  ..................    +=====+ PCP Server |     |
   | |    +------------------------------|            |     |
   | |  CPE     +========+  BRAS   +=====+ CGN L2NAT  +------- Public
   | +----------+ |    | +---------+     +------------+     |  Internet
   +--------------+    +------------------------------------+
   ==== L2 tunnel borders between subscriber, BRAS, IWF, and CGN
   .... UPnP communication
   #### PCP communication

                        Figure 2: UPnP IGD-PCP IWF

   A potential extension to [RFC6970] regarding an additional state
   variable for the THIRD_PARTY_ID and regarding an additional error
   code for a mismatched THIRD_PARTY_ID and its processing might be a
   logical next step.  However, this is not in the scope of this
   document.

3.2.  Carrier Web Portal

   This scenario shown in Figure 3 is different from the previous one
   concerning the protocol used between the subscriber and the IWF.
   Here, HTTP(S) is the protocol that the subscriber uses for port
   mapping requests.  The subscriber may make requests manually using a
   web browser or automatically - as in the previous scenario - with
   applications in the subscriber's network issuing port mapping
   requests on demand.  The Web Portal queries the AAA Server for the
   subscriber's tunnel ID of tunnel(BRAS, CGN) which was reported by the
   BRAS.  The returned tunnel ID of tunnel(BRAS, CGN) is used as the
   THIRD_PARTY_ID in the subsequent port mapping request.

Ripke, et al.            Expires April 21, 2016                 [Page 7]
Internet-Draft               Third Party ID                 October 2015

   +--------------+    +------------------------------------+
   | Subscriber   |    | Carrier                            |
   |              |    |                 +------------+     |
   |              |    | +------------+  | Web Portal |     |
   | +----------+ |    | | AAA Server +--+            +--+  |
   | | Internal | |    | +-----+------+  | PCP Client |  |  |
   | | Host     | |    |       |         +-----#------+  |  |
   | +----+-----+ |    |       |               #         |  |
   |      |       |    | +-----+---+     +-----#------+  |  |
   | +----+-----+ |    | |         |     | PCP Server |  |  |
   | |  CPE     | |    | |  BRAS   |     |            |  |  |
   | |          +-+======+         +=====+ CGN L2NAT  +--+---- Public
   | +----------+ |    | +---------+     +------------+     |  Internet
   +--------------+    +------------------------------------+
   ==== L2 tunnel(s) between subscriber, BRAS, and CGN
   #### PCP communication

                       Figure 3: Carrier Web Portal

   The PCP IWF is realized as a combination of a web server and a PCP
   Client.

4.  Format

   The THIRD_PARTY_ID option as shown in Figure 4 uses the format of PCP
   options as specified in [RFC6887]:

Ripke, et al.            Expires April 21, 2016                 [Page 8]
Internet-Draft               Third Party ID                 October 2015

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Option Code=TBD|  Reserved     |      Option Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                      THIRD_PARTY_ID                           |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Option Name: THIRD_PARTY_ID
       Option Code: TBD-1
       Purpose: Identifies a third party for which a request for an
                external IP address and port is made.
       Valid for Opcodes: MAP, PEER
       Length: Variable,  maximum 1016 octets.
       May appear in: request. May appear in response only if it
                      appeared in the associated request.
       Maximum occurrences: 1

 RFC EDITOR NOTE: Replace TBD and TBD-1 with the value assigned by IANA.

                      Figure 4: THIRD_PARTY_ID Option

   The "Reserved" field and the "Option length" field are to be set As
   specified in Section 7.3 of [RFC6887].

   The "THIRD_PARTY_ID" field contains a deployment specific identifier
   that can be used to identify a subscriber's session on a PCP-
   controlled device.  It has no semantics other than as a qualifier to
   uniquely identify a host.

   The "THIRD_PARTY_ID" is not bound to any specific identifier.  It can
   contain any deployment specific value the PCP client and the PCP
   server agree on.  How this agreement is reached if both PCP server
   and client are not administered by the same entity is beyond the
   scope of this document.

   The option number is in the mandatory-to-process range (0-127),
   meaning that a request with a THIRD_PARTY_ID option is processed by
   the PCP server if and only if the THIRD_PARTY_ID option is supported
   by the PCP server.

4.1.  Result Codes

   The following PCP Result Codes are new:

Ripke, et al.            Expires April 21, 2016                 [Page 9]
Internet-Draft               Third Party ID                 October 2015

   TBD-2:  THIRD_PARTY_ID_UNKNOWN: The provided identifier in a
      THIRD_PARTY_ID option is unknown/unavailable to the PCP server.
      This is a long lifetime error.

   TBD-3:  THIRD_PARTY_MISSING_OPTION: This error occurs if both
      THIRD_PARTY and THIRD_PARTY_ID options are expected in a request
      but one option is missing.  This is a long lifetime error.

   TBD-4:  UNSUPP_THIRD_PARTY_ID_LENGTH: The received option length is
      not supported.  This is a long lifetime error.

5.  Behavior

   The following sections describe the operations of a PCP client and a
   PCP server when generating the request and processing the request and
   response.

5.1.  Generating a Request

   In addition to generating a PCP request that is described in
   [RFC6887] the following has to be applied.  The THIRD_PARTY_ID option
   MAY be included either in a PCP MAP or PEER opcode.  It MAY be used
   independently or in combination with the THIRD_PARTY option which
   provides an IP address.  The THIRD_PARTY_ID option holds an
   identifier to allow the PCP-controlled device to uniquely identify
   the internal host (specified in the THIRD_PARTY option) for which the
   port mapping is to be established or modified.  The padding rules
   described in Section 7.3 of [RFC6887] apply.

5.2.  Processing a Request

   The THIRD_PARTY_ID option is in the mandatory-to-process range and if
   the PCP server does not support this option it MUST return an
   UNSUPP_OPTION response.  If the provided identifier in a
   THIRD_PARTY_ID option is unknown/unavailable the PCP server MUST
   return a THIRD_PARTY_ID_UNKNOWN response.  If the PCP server receives
   a request with a not supported THIRD_PARTY_ID option length, it MUST
   return a UNSUPP_THIRD_PARTY_ID_LENGTH response.  If the PCP server
   expects both THIRD_PARTY and THIRD_PARTY_ID options but receives only
   one option, it MUST return a THIRD_PARTY_MISSING_OPTION response.

   Upon receiving a valid request with a legal THIRD_PARTY_ID option
   identifier the message is processed as specified in [RFC6887], except
   that the THIRD_PARTY_ID option identifier used in addition when
   accessing a mapping table.

Ripke, et al.            Expires April 21, 2016                [Page 10]
Internet-Draft               Third Party ID                 October 2015

5.3.  Processing a Response

   In addition to the response processing described in [RFC6887] if the
   PCP client receives a THIRD_PARTY_ID_UNKNOWN or a
   UNSUPP_THIRD_PARTY_ID_LENGTH or a THIRD_PARTY_MISSING_OPTION response
   back for its previous request it SHOULD report an error.  To where to
   report an error is implementation dependent.

6.  IANA Considerations

   The following PCP Option Code is to be allocated in the mandatory-to-
   process range:

      TBD-1: THIRD_PARTY_ID

   [NOTE for IANA: Please allocate a PCP Option Code at
   http://www.iana.org/assignments/pcp-parameters/pcp-
   parameters.xml#option-rules]

   The following PCP Result Codes are to be allocated:

      TBD-2: THIRD_PARTY_ID_UNKNOWN

      TBD-3: THIRD_PARTY_MISSING_OPTION

      TBD-4: UNSUPP_THIRD_PARTY_ID_LENGTH

   [NOTE for IANA: Please allocate PCP Result Codes at
   http://www.iana.org/assignments/pcp-parameters/pcp-
   parameters.xml#result-codes]

7.  Security Considerations

   As this option is related to the use of the THIRD_PARTY option the
   corresponding security considerations in Section 18.1.1 of RFC 6887
   [RFC6887] apply.  Especially, the network on which the PCP messages
   are sent must be fully trusted.  The THIRD_PARTY_ID option might
   carry privacy information like location or profile information.
   Means to protect unauthorized access to this information should be
   put in place.

8.  Acknowledgments

   Thanks to Mohamed Boucadair, Dave Thaler, Tom Taylor, and Dan Wing
   for their comments and review.

   Thanks to Mohamed Boucadair for many references and suggesting a
   variable length for the THIRD_PARTY_ID.

Ripke, et al.            Expires April 21, 2016                [Page 11]
Internet-Draft               Third Party ID                 October 2015

9.  References

9.1.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <http://www.rfc-editor.org/info/rfc1918>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
              Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
              2012, <http://www.rfc-editor.org/info/rfc6598>.

   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              DOI 10.17487/RFC6887, April 2013,
              <http://www.rfc-editor.org/info/rfc6887>.

9.2.  Informative References

   [I-D.boucadair-pcp-sfc-classifier-control]
              Boucadair, M., "PCP as a Traffic Classifier Control
              Protocol", draft-boucadair-pcp-sfc-classifier-control-01
              (work in progress), October 2014.

   [I-D.lee-vhs-usecases]
              Lee, Y. and C. Xie, "Virtual Home Services Use Cases",
              draft-lee-vhs-usecases-02 (work in progress), November
              2014.

   [I-D.reddy-pcp-sdn-firewall]
              Reddy, T., Patil, P., and M. Boucadair, "PCP Firewall
              Control in Managed Networks", draft-reddy-pcp-sdn-
              firewall-00 (work in progress), December 2014.

   [RFC6619]  Arkko, J., Eggert, L., and M. Townsley, "Scalable
              Operation of Address Translators with Per-Interface
              Bindings", RFC 6619, DOI 10.17487/RFC6619, June 2012,
              <http://www.rfc-editor.org/info/rfc6619>.

Ripke, et al.            Expires April 21, 2016                [Page 12]
Internet-Draft               Third Party ID                 October 2015

   [RFC6674]  Brockners, F., Gundavelli, S., Speicher, S., and D. Ward,
              "Gateway-Initiated Dual-Stack Lite Deployment", RFC 6674,
              DOI 10.17487/RFC6674, July 2012,
              <http://www.rfc-editor.org/info/rfc6674>.

   [RFC6970]  Boucadair, M., Penno, R., and D. Wing, "Universal Plug and
              Play (UPnP) Internet Gateway Device - Port Control
              Protocol Interworking Function (IGD-PCP IWF)", RFC 6970,
              DOI 10.17487/RFC6970, July 2013,
              <http://www.rfc-editor.org/info/rfc6970>.

Authors' Addresses

   Andreas Ripke
   NEC
   Heidelberg
   Germany

   Email: ripke@neclab.eu

   Rolf Winter
   NEC
   Heidelberg
   Germany

   Email: winter@neclab.eu

   Thomas Dietz
   NEC
   Heidelberg
   Germany

   Email: dietz@neclab.eu

   Juergen Quittek
   NEC
   Heidelberg
   Germany

   Email: quittek@neclab.eu

Ripke, et al.            Expires April 21, 2016                [Page 13]
Internet-Draft               Third Party ID                 October 2015

   Rafael Lopez da Silva
   Telefonica I+D
   Madrid
   Spain

   Email: ralds@tid.es

Ripke, et al.            Expires April 21, 2016                [Page 14]