One document matched: draft-boucadair-pcp-extensions-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-boucadair-pcp-extensions-00"
ipr="trust200902">
<front>
<title abbrev="Extensions to PCP">Some Extensions to Port Control Protocol
(PCP)</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N Mathilda Avenue</street>
<city>Sunnyvale</city>
<region>California</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>rpenno@juniper.net</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date day="20" month="May" year="2011" />
<abstract>
<t>This document extends Port Control Protocol (PCP) with some useful
features.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>This document extends the <xref target="I-D.ietf-pcp-base">base PCP
protocol</xref> with various PCP Options.</t>
<t>Some of these options may be defined as new PCP OpCodes. </t>
<t>The main goal of this document is to kick-off discussions on the need
to define some useful PCP options which are not part of base PCP.</t>
</section>
<section title="DESCRIPTION">
<t>This option (Code TBA, <xref target="desc"></xref>) MAY be included
in a PCP MAPx request to include a description associated with a
requested mapping. This option is optional to be supported by PCP
Servers and PCP Clients. The maximum length SHOULD be a configurable
option in the PCP Server. If a PCP Client includes a Description PCP
option with a length exceeding the maximum length supported by the PCP
Server, only the portion of the Description field fitting that maximum
length is stored by the PCP Server.</t>
<t>This option can be used by a user to indicate a description
associated with a given mapping such as "My mapping for my FTP server"
or "My remote access to my CP router", etc. In addition, in the some
deployment scenarios, this field can be used for troubleshooting
purposes and can be used to convey values as the ones listed
hereafter:<list style="symbols">
<t>"This is the mapping for my specific IPsec implementation"</t>
<t>"This is the mapping for subscriber bob@example.com"</t>
<t>"This is the mapping for special subscriber
adsl-line-1234@example.com"</t>
<t>"This is the mapping that failed before due to XYZ"</t>
</list></t>
<t>Issues related to the usage of this field for troubleshooting or for
any further usage are out of scope of this document.</t>
<t><figure anchor="desc" title="Description Option">
<preamble></preamble>
<artwork><![CDATA[
This Option:
Name: Description Option (DESCRIPTION)
Number: TBA (IANA)
Purpose: Used to associate a text description with a mapping
is valid for OpCodes: MAP4, MAP6
Length: Variable (multiple of 4)
May appear in: both request and response
Maximum occurrences: 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESCRIPTION | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
</section>
<section title="DSCP_POLICY">
<t>In some scenarios, the DSCP marking in the internal interface (i.e.,
customer-facing interface) and the external one (i.e., Internet-facing
interface) of the PCP-controlled device may be distinct. A Service
Provider MAY allow its customers to configure their DSCP marking
policies in an upstream device. Distinct DSCP marking policies can be
implemented in the internal and external sides of the PCP-controlled
device. A PCP Client MAY issue a PCP MAPx request indicating its
internal DS code point and the external DSCP value. Instructed
forwarding policies are applied only for packets marked with a given
DSCP value.</t>
<t>A Service Provider may not support DSCP re-marking feature and adopt
a transparent scheme to QoS policy enforcement, that is, not
controllable by subscribers. Generic QoS enforcement policies can be
enforced for all customers: such as leave DSCP field values
unchanged.</t>
<t>This option (Code TBA, <xref target="dscp"></xref>) allows to:<list
style="symbols">
<t>Re-write any DSCP value to a specific value;</t>
<t>Re-write a specific DSCP value to another specific value.</t>
</list></t>
<t><figure anchor="dscp" title="DSCP Marking option">
<preamble></preamble>
<artwork><![CDATA[
This Option:
Name: PCP DSCP Marking Policy Option (DSCP_POLICY)
Number: TBA (IANA)
Purpose: Associated a DSCP re-marking policy with a mapping
is valid for OpCodes: MAP4, MAP6
Length: 0x04
May appear in: both request and response
Maximum occurrences: none
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP_POLICY | Reserved | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DIR| Int DSCP | Ext DSCP | 00...00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DIR : Indicates the direction:
0 for Inbound
1 for Outbound
2 for Both
Int DSCP: Indicates the DSCP value in the customer-faced interface.
0x3F is used to indicate ANY value.
Ext DSCP: Indicates the DSCP value in the Internet-faced interface.
0x3F is used to indicate ANY value.
]]></artwork>
<postamble></postamble>
</figure></t>
<t></t>
</section>
<section anchor="capability_ie" title="CAPABILITY">
<t>The CAPABILITY option (Code: TBA, <xref target="capability"></xref>)
is used by a PCP Server to indicate to a requesting PCP Client the
capabilities it supports with regards to port forwarding operations.
Several Capability options MAY be conveyed in the same PCP response
message if several functions are co-located in the same PCP-controlled
device (e.g., NAT44 and NAT64, NAT44 and ports set assignment
capability, etc.).</t>
<t>This option, when received from a PCP Server, is used by a PCP Client
to constraint the content of its requests and therefore avoid errors.
</t>
<t><figure anchor="capability" title="Capability option">
<preamble></preamble>
<artwork><![CDATA[
This Option:
Name: PCP Capabilities Option (CAPABILITY)
Number: TBA (IANA)
Purpose: Retrieve the capabilities of a PCP-controlled device
is valid for OpCodes: can be returned in a error message
Length: 0x04
May appear in: both request and response
Maximum occurrences: None
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAPABILITY | Reserved | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F T P A S C I O| 00...00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>Below is provided a description of the F, T, P, A, S, C, I and O
bits:</t>
<texttable style="headers">
<ttcol align="center">Name</ttcol>
<ttcol>Description</ttcol>
<c>F</c>
<c>This bit indicates the address family of the source address issued
by internal hosts</c>
<c>T</c>
<c>This bit indicates the address family of the source address of the
packets forwarded in the external side of the PCP-controlled
device</c>
<c>P</c>
<c>This bit indicates whether the source port number is translated or
not.</c>
<c>A</c>
<c>This bit indicates whether the source IP address is translated or
not.</c>
<c>S</c>
<c>This bit indicates whether the controlled device supports the
ability to assign a set or ports</c>
<c>C</c>
<c>This bit indicates whether the PCP-controlled devices inspects the
received packets and if it can block them</c>
<c>I</c>
<c>This bit indicates whether incoming packets are rejected unless an
explicit rule is enforced in the PCP-controlled device</c>
<c>O</c>
<c>This bit indicates whether outbound packets are inspected or not
before being granted to leave the internal realm.</c>
</texttable>
<t>The value of the F, T, P, A, S, C, I and O bits are as follows:</t>
<texttable style="headers">
<ttcol align="center">Position</ttcol>
<ttcol>Name</ttcol>
<ttcol>Meaning</ttcol>
<c>1</c>
<c>From (F)</c>
<c>0=from IPv4, 1=from IPv6</c>
<c>2</c>
<c>To (T)</c>
<c>0=to IPv4, 1=to IPv6</c>
<c>3</c>
<c>Port-Xlate (P)</c>
<c>1=translated, 0=not translated</c>
<c>4</c>
<c>Addr-Xlate (A)</c>
<c>1=translated, 0=not translated</c>
<c>5</c>
<c>Port-Set (S)</c>
<c>1=enabled, 0=not supported</c>
<c>6</c>
<c>Packet-Control (C)</c>
<c>1=enabled, 0=not supported</c>
<c>7</c>
<c>Direction-Out (I)</c>
<c>1=enabled, 0=disabled</c>
<c>8</c>
<c>Direction-In (O)</c>
<c>1=enabled, 0=disabled</c>
</texttable>
<t></t>
<t>A stateless NAT64 <xref target="RFC6145"></xref> would have the
following values:<figure>
<preamble></preamble>
<artwork><![CDATA[ From=0 (IPv4)
To=1 (IPv6)
Port-Xlate=0 (No)
Addr-Xlate=1 (Yes)
Port-Set=0 (No)
Packet-control=0 (No)
Direction-out (0) (No)
Direction-In=0 (No)
]]></artwork>
<postamble></postamble>
</figure>A stateful NAT64 <xref target="RFC6146"></xref> would have
the following values:</t>
<t><figure>
<preamble></preamble>
<artwork><![CDATA[ From=0 (IPv4)
To=1 (IPv6)
Port-Xlate=1 (Yes)
Addr-Xlate=1 (Yes)
Port-Set=0 (No)
Packet-control=0 (No)
Direction-out (0) (No)
Direction-In=0 (No)
]]></artwork>
<postamble></postamble>
</figure></t>
<t>A NAT44 would be characterized as follows:</t>
<t><figure>
<preamble></preamble>
<artwork><![CDATA[ From=0 (IPv4)
To=0 (IPv4)
Port-Xlate=1 (Yes)
Addr-Xlate=1 (Yes)
Port-Set=0 (No)
Packet-control=0 (No)
Direction-out (0) (No)
Direction-In=0 (No)
]]></artwork>
<postamble></postamble>
</figure></t>
<t></t>
</section>
<section title="PERCEIVED_ADDRESS">
<t>This option (Code TBA, <xref target="perceived"></xref>) is used by a
PCP Server to indicate in a PCP Response the perceived IPv6/IPv4 address
and port of PCP messages received from a PCP Client. A PCP Client uses
this information to detect whether a NAT is present in the path to reach
its PCP Server. </t>
<t>A PCP Client MAY include this option to learn the IP address and port
as perceived by the PCP Server. When this option is received by the PCP
Server, it uses the source IP address and port of the received PCP
request to set the Perceived Port and Perceived IP Address. </t>
<t><figure anchor="perceived"
title="Perceived IP address/port PCP option">
<preamble></preamble>
<artwork><![CDATA[
This Option:
Name: PCP Perceived IP address/port Option (PERCEIVED_ADDR )
Number: TBA (IANA)
Purpose: Detect the presence of a NAT in the path
is valid for OpCodes: MAP4, MAP6
Length: 0x08
May appear in: both request and response
Maximum occurrences: 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PERCEIVED_ADDR | Reserved | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Perceived Port |Address Family | 00...00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Perceived IPv4/IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Perceived Port: The source port number of a PCP request as seen
by the PCP Server.
Address Family: The Address Family of the perceived IP address.
Perceived IPv4/IPv6 Address: If the Address Family is IPv4,
an IPv4 address followed by 96 zero bits. If the Address Family
is IPv6, an IPv6 address. This field includes the source IP
address of a PCP request as seen by the PCP Server.
]]></artwork>
<postamble></postamble>
</figure></t>
<t>An example of the use of this option is illustrated in the following
figure where there is a NAT in the path between the PCP Client and the
PCP Server. </t>
<t><figure align="center">
<preamble></preamble>
<artwork><![CDATA[ webcam-------+
|
+----------+ | +----+ +----------+
|PCP Client|====+====|NAT1|=========|PCP Server|
+----------+ +----+ +----------+
NAT2]]></artwork>
<postamble></postamble>
</figure>An example of instructing mappings in the PCP Server is as
follows:<list style="symbols">
<t>NAT1 is detected in the path between the PCP Client and the PCP
Server owing to the use of the PERCEIVED_ADDR Option;</t>
<t>After learning about that NAT, the PCP Client uses UPnP IGD (or
NAT-PMP) to interact with NAT1 and open the necessary port on NAT1
(e.g., IP address= IPx, port=X);</t>
<t>The PCP Client then sends PCP message to the PCP Server,
indicating IPx and X as the internal IP address and port. The PCP
Server opens pinhole towards IPx and X.</t>
</list></t>
</section>
<section title="SCOPE">
<t>The Scope Option (Code TBA, <xref target="scope"></xref>) is used by
a PCP Client to indicate to the PCP Server the scope of the flows that
will use a given mapping. This object is meant to be used in the context
of cascaded PCP Servers/NAT levels. Two values are defined:</t>
<texttable style="headers">
<ttcol align="center">Value</ttcol>
<ttcol align="left">Meaning</ttcol>
<c>0x00</c>
<c>Internet</c>
<c>0x01</c>
<c>Internal</c>
</texttable>
<t>When 0x00 value is used, the PCP Proxy MUST propagate the mapping
request to its upstream PCP Server. When 0x01 value is used, the mapping
is to be instantiated only in the first PCP-controlled device; no
mapping is instantiated in the upstream PCP-controlled device.</t>
<t>When no Scope Option is included in a PCP message, this is equivalent
to including a Scope Option with a scope value of "Internet".</t>
<t><figure anchor="scope" title="Scope Option">
<preamble></preamble>
<artwork><![CDATA[
This Option:
Name: PCP Scope Policy Option (SCOPE)
Number: TBA (IANA)
Purpose: Restrict the scope of PCP requests
is valid for OpCodes: MAP4, MAP6
Length: 0x04
May appear in: both request and response
Maximum occurrences: 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCOPE | Reserved | 0x04 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope | 00...00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
</section>
<section title="REPORT">
<t>The Report PCP Option (Code TBA, <xref target="report"></xref>) is
used by a PCP Client to report a set of useful information to the PCP
Server. Several Report Options with distinct Report Sub-Code values MAY
be conveyed in the same PCP message. Only report data associated with
the PCP Server to which this option is sent MUST be included in a Report
Option. </t>
<t>This option can be used for troubleshooting or diagnose purposes.</t>
<t><figure align="center" anchor="report" title="Report Option">
<preamble></preamble>
<artwork><![CDATA[
This Option:
Name: PCP Report Option (REPORT)
Number: TBA (IANA)
Purpose: Send a set of report data
is valid for OpCodes: MAP4, MAP6
Length: Variable
May appear in: both request and response
Maximum occurrences: Multiple
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCOPE | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Sub-Code | 00...00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Report Data |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>The following Report Sub-Code values are defined:</t>
<texttable style="headers">
<ttcol align="center">Position</ttcol>
<ttcol>Meaning</ttcol>
<c>0x00</c>
<c>Time since last reboot/boot</c>
<c>0x01</c>
<c>Count of transmitted PCP messages to the PCP Server since last
boot</c>
<c>0x02</c>
<c>Count of retransmitted PCP messages to the PCP Server since last
boot</c>
<c>0x03</c>
<c>Count of received PCP Error messages from the PCP Server</c>
</texttable>
<t></t>
</section>
<section anchor="id" title="CLIENT_IDENTIFIER">
<t>PCP CLIENT_ID (Code TBA, <xref target="client_id"></xref>) is a token
randomly <xref target="RFC4086"></xref> generated by the PCP Client.
Only one CLIENT_ID Option MUST be present in a PCP message. The PCP
Client and PCP Server MUST store the value included in this Option in a
PCP MAPx request.</t>
<t><list style="symbols">
<t>The CLIENT_ID MUST be generated by the PCP Client and not the PCP
Server;</t>
<t>Upon change of the IP address of the PCP Client (or a third party
on behalf of which a mapping has been created), the CLIENT_ID is
used to update related mappings (e.g., PCP MAP delete request and
PCP MAP create request);</t>
<t>The same CLIENT_ID MUST be used for all requested mappings,
unless a new CLIENT_ID is generated by the PCP Client (e.g., reboot,
OS crash, etc.);</t>
<t>The CLIENT_ID is stored by the PCP Server for all mappings
(persistent storage);</t>
</list></t>
<t><figure align="center" anchor="client_id"
title="CLIENT_ID PCP Option">
<preamble></preamble>
<artwork><![CDATA[
This Option:
Name: PCP Client Identifier Option (CLIENT_ID)
Number: TBA (IANA)
Purpose: Associate an identifier with the mappings
is valid for OpCodes: MAP4, MAP6
Length: Variable
May appear in: both request and response
Maximum occurrences: 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CLIENT_ID | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client Identifier |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<postamble></postamble>
</figure></t>
<t>The length of the CLIENT_ID is encoded in the Length field in bytes.
The length of the CLIENT_ID MUST be at least 4 bytes and MUST NOT exceed
16 bytes. </t>
<t>The RECOMMENDED value is 16 bytes so as to have a robust random
CLIENT_ID. If a CLIENT_ID longer than 16 bytes or shorter than 4 bytes
is received, the PCP Server MUST issue a PCP Error message with an error
cause equal to "Invalid Client-ID".</t>
<t>For sanity checks, a PCP Server maintains the same CLIENT_ID value
(which is used in the latest PCP request) for a given PCP Client for all
mappings associated with the same internal IP address belonging to the
same subscriber. Indeed, the PCP Server maintains an additional
identifier denoted as subscriber-Id. A subscriber-is can be an IP
address, IPv6 prefix or a subscriber identifier configured locally. </t>
</section>
<section anchor="security" title="Security Considerations">
<t>Security considerations discussed in <xref
target="I-D.ietf-pcp-base"></xref> must be considered. The use of
CLIENT_ID option allows to soften issues related to stale mappings.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>The following PCP Option Code are to be allocated:<list style="empty">
<t>DESCRIPTION</t>
<t>DSCP_POLICY</t>
<t>CAPABILITY</t>
<t>PERCEIVED_ADDRESS</t>
<t>SCOPE</t>
<t>REPORT</t>
<t>CLIENT_IDENTIFIER</t>
</list></t>
</section>
<section title="Acknowledgements">
<t>TBC.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.4086'?>
<?rfc include='reference.I-D.ietf-pcp-base'?>
<?rfc include='reference.RFC.6145'?>
<?rfc include='reference.RFC.6146'?>
</references>
<!--
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:32 |