PCP Tunnel-ID Option
draft-ripke-pcp-tunnel-id-option-00

Abstract

This document describes a new Port Control Protocol (PCP) option called TUNNEL_ID. It serves for identifying a Third Party in addition to the means that PCP's THIRD_PARTY option already provides for that purpose.

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 August 17, 2014.

Copyright Notice

Copyright (c) 2014 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
• 2. Terminology
• 3. Target Scenario
• 4. Format
• 5. Behavior
• 5.1. Generating a Request
• 5.2. Processing a Request
• 5.3. Processing a Response
• 6. Alternative
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

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 draft focuses on the application of PCP's THIRD_PARTY option that is used when the PCP client sends requests that concern other internal hosts than the host of the PCP client. This is, for example, the case if port mapping requests for a carrier grade NAT (CGN) are not sent from PCP clients at the subscribers, but from a portal of the carrier at which subscribers can request port mappings.

The issue addressed by the TUNNEL_ID option is that there are CGN deployments that do not distinguish internal hosts by their IP address only, but use further identifiers for unique subscriber identification. This is, for example, the case if a CGN supports overlapping private IP address spaces according to [RFC1918] for internal hosts of different subscribers. Then different internal hosts are identified and mapped at the CGN by their IP address and an additional ID, for example, the ID of a tunnel between the CGN and the subscriber. In such cases, the IP address contained in the THIRD_PARTY option is not sufficient. An additional identifier needs to be carried by the PCP protocol in order to uniquely identify the Internal Host. The TUNNEL_ID option serves this purpose.

The TUNNEL_ID option is defined for use in combination with the THIRD_PARTY option for the PCP opcodes MAP and PEER.

2. Terminology

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

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

3. Target Scenario

This section illustrates the use of the TUNNEL_ID option in a scenario for a port mapping requests via a carrier portal.

The scenario shown in Figure 1 has a carrier operating a CGN and a portal for subscribers to request port mappings at the CGN. The portal communicates with the CGN using PCP. For this purpose the portal is co-located with a PCP client and the CGN is co-located with a PCP server. The way subscribers interact with the portal for requesting port mapping for their internal hosts is not specified in this scenario.

 
                    +----------------+
                    | Carrier        |    ==== IP packet tunnel(s)
                    | +------------+ |         between subscriber
+--------------+    | | Subscriber | |         and CGN
| Subscriber   +......+ Portal     | |    #### PCP communication
|              |    | |            | |    .... Subscriber - portal  
|              |    | | PCP Client | |         interaction
|              |    | +-----#------+ |         (unspecified)
|              |    |       #        |   
|              |    | +-----#------+ |        
| +----------+ |    | | PCP Server | |
| | Internal | |    | |            | |
| | Host     +-+======+ CGN        +--------- Public Internet
| +----------+ |    | +------------+ |
+--------------+    +----------------+
	      

 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   |  Reserved     |   Option Length=16            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                     TUNNEL_ID (128 bits)                      |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+