One document matched: draft-ripke-pcp-tunnel-id-option-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml-rfcs/reference.RFC.2629.xml">
<!ENTITY RFC1918 SYSTEM "http://xml.resource.org/public/rfc/bibxml-rfcs/reference.RFC.1918.xml">
<!ENTITY RFC6887 SYSTEM "http://xml.resource.org/public/rfc/bibxml-rfcs/reference.RFC.6887.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml-rfcs/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-pcp-description-option SYSTEM "http://xml.resource.org/public/rfc/bibxml-ids/reference.I-D.ietf-pcp-description-option.xml">
]>
<!-- taken from http://xml.resource.org/public/rfc/bibxml3/ -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ripke-pcp-tunnel-id-option-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="PCP-ID">PCP Tunnel-ID Option</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Andreas Ripke" initials="A.R." surname="Ripke">
<organization>NEC</organization>
<address>
<postal>
<street></street>
<code></code>
<city>Heidelberg</city>
<country>Germany</country>
</postal>
<email>ripke@neclab.eu</email>
</address>
</author>
<author fullname="Thomas Dietz" initials="T.D." surname="Dietz">
<organization>NEC</organization>
<address>
<postal>
<street></street>
<code></code>
<city>Heidelberg</city>
<country>Germany</country>
</postal>
<email>dietz@neclab.eu</email>
</address>
</author>
<author fullname="Juergen Quittek" initials="J.Q." surname="Quittek">
<organization>NEC</organization>
<address>
<postal>
<street></street>
<code></code>
<city>Heidelberg</city>
<country>Germany</country>
</postal>
<email>quittek@neclab.eu</email>
</address>
</author>
<author fullname="Rafael Lopez da Silva" initials="R.L.S." surname="da Silva">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street></street>
<code></code>
<city>Madrid</city>
<country>Spain</country>
</postal>
<email>ralds@tid.es</email>
</address>
</author>
<date month="February" year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>PCP, option, tunnel-id</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t>
The IETF has specified the Port Control Protocol (PCP)
(<xref target="RFC6887"></xref>) to control how packets
are translated and forwarded by a PCP-controlled device
such as a network address translator (NAT) or firewall.
</t> <t>
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.
</t> <t>
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
<xref target="RFC1918"></xref> 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.
</t> <t>
The TUNNEL_ID option is defined for use in combination
with the THIRD_PARTY option for the PCP opcodes MAP and PEER.
</t>
</section> <!-- Introduction -->
<section anchor="Terminology" title="Terminology">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t> <t>
The terminology defined in the specification of PCP
<xref target="RFC6887"></xref> applies.
</t>
</section> <!-- Terminology -->
<section anchor="sec-scenario" title="Target Scenario">
<t>
This section illustrates the use of the TUNNEL_ID option
in a scenario for a port mapping requests via a carrier portal.
</t>
<t>
The scenario shown in <xref target="fig-scenario"></xref> 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.
</t>
<figure title="Carrier portal for port mapping requests"
anchor="fig-scenario">
<artwork>
+----------------+
| 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
| +----------+ | | +------------+ |
+--------------+ +----------------+
</artwork>
</figure>
<t>
The internal hosts use private IP addresses as specified in
<xref target="RFC1918"></xref>. Since there is no NAT between
the internal host and the CGN, 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
identifiers for this purpose. A very good candidate for this
additional identifier at the CGN is the ID of the tunnel that
connects the CGN to the subscriber's network.
</t> <t>
Requests for port mappings from the portal 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 TUNNEL_ID option is
introduced for carrying the additional (tunnel) information
needed to identify the internal host in this scenario.
</t> <t>
The additional identifier for internal hosts needs to be
included in MAP requests from the PCP client in order to uniquely
identify the internal host that should have its address mapped.
This is the purpose that the new TUNNEL_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 client's mapping
requests by using the THIRD_PARTY option.
</t> <t>
The information carried by the TUNNEL_ID is not just
needed to identify an internal host in a PCP request. The CGN
needs this information in its internal mapping tables for
translating packet addresses and for forwarding packets to
subscriber-specific tunnels.
</t>
</section> <!-- Target Scenarios -->
<section anchor="format" title="Format">
<t>
The TUNNEL_ID option is formatted as shown
in <xref target="tunnel_id_option"></xref>.
</t>
<figure anchor="tunnel_id_option" title="TUNNEL_ID Option">
<artwork><![CDATA[
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>
<list style="symbols"> <!-- rfc2629 -->
<t>Option Name: TUNNEL_ID</t>
<t>Number: TBD</t>
<t>Purpose: Identifies a request
of an external IP address and port.</t>
<t>Valid for opcodes: MAP, PEER, and all other for which the
THIRD_PARTY option is valid for.</t>
<t>Length: 16 octets</t>
<t>May appear in: Request. Must appear in response if it
appeared in the associated request.</t>
<t>Maximum occurrences: 1</t>
</list>
</t>
<t>
The fields are as follows:
<list style="symbols">
<t>TUNNEL_ID: A vendor specific tunnel identifier that can
be used to identify a subscriber's CGN session and the
port ranges to apply this request to.</t>
</list>
</t>
<t>
The tunnel identifier field can contain any vendor specific value to
identify a tunnel.
The option number is in the mandatory-to-process range
(0-127), meaning that a request with a TUNNEL_ID option
is executed by the PCP server if and only if the TUNNEL_ID
option is supported by the PCP server.
</t>
</section> <!-- Format -->
<section anchor="behavior" title="Behavior">
<t>
The following sections describe the operations of a PCP client
and a PCP server when generating the request and processing
the request and response.
</t>
<section anchor="GeneratingRequest" title="Generating a Request">
<t>
In addition to generating a PCP request that is described
in <xref target="RFC6887"></xref> the following has to be
applied.
The TUNNEL_ID option can be used together either
with a PCP MAP or PEER opcode. It MUST be used in
combination with the THIRD_PARTY option which
provides an IP address and port entered by the subscriber.
The TUNNEL_ID option holds the respective tunnel identifier to
allow the CGN to uniquely identify the internal host (specified
in the THIRD_PARTY option) for which
the port mapping is to be established or modified.
If the tunnel identifier is shorter than 128 bits then
the TUNNEL_ID option field is to be filled up with leading
zeros up to 128 bits.
</t>
</section> <!-- GeneratingRequest -->
<section anchor="ProcessRequest" title="Processing a Request">
<t>
The TUNNEL_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 TUNNEL_ID is unknown/unavailable the PCP server
MUST return a TUNNEL_ID_UNKNOWN response.
</t>
</section> <!-- ProcessRequest -->
<section anchor="ProcessResponse" title="Processing a Response">
<t>
If the PCP client receives a TUNNEL_ID_UNKNOWN response back for
its previous request it SHOULD report an error message.
To where to report an error message is implementation
dependent.
</t>
</section> <!-- ProcessResponse -->
</section> <!-- Behavior -->
<section anchor="alternative" title="Alternative">
<t>
An alternative to identify a tunnel affiliation in the given scenario
could be using the DESCRIPTION
(<xref target="I-D.ietf-pcp-description-option"></xref>)
option to carry a tunnel ID option.
The DESCRIPTION option is to allow a
text description to be attached to a port mapping.
But using the DESCRIPTION option for a tunnel ID might
not be appropriate because it specifies using UTF-8 and
another requirement is that the description text must
not be null terminated, which cannot always be met.
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>
The following PCP Option Code is to be allocated in the
mandatory-to-process range:
</t>
<t>
TUNNEL_ID
</t>
<t>
[NOTE for IANA: Please allocate a PCP Option Code at
http://www.iana.org/assignments/pcp-parameters/pcp-parameters.xml#option-rules]
</t>
<t>
The following PCP Result Code is to be allocated:
</t>
<t>
TUNNEL_ID_UNKNOWN
</t>
<t>
[NOTE for IANA: Please allocate a PCP Result Code at
http://www.iana.org/assignments/pcp-parameters/pcp-parameters.xml#result-codes]
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
As this option is related to the use of the THIRD_PARTY option the
corresponding security considerations apply.
Especially, the network on which the PCP messages are sent must be
fully trusted.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC1918;
&RFC2119;
&RFC6887;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&I-D.ietf-pcp-description-option;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:56:51 |