One document matched: draft-ietf-pcp-port-set-13.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. -->
]>
<?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="std" docName="draft-ietf-pcp-port-set-13" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
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 PORT_SET">Port Control Protocol (PCP) Extension for
Port Set Allocation</title>
<author fullname="Qiong Sun" initials="Q." surname="Sun">
<organization>China Telecom</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>P.R.China</country>
</postal>
<phone>86 10 58552936</phone>
<email>sunqiong@ctbri.com.cn</email>
</address>
</author>
<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.com</email>
</address>
</author>
<author fullname="Senthil Sivakumar" initials="S." surname="Sivakumar">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7100-8 Kit Creek Road</street>
<city>Research Triangle Park</city>
<region>North Carolina</region>
<code>27709</code>
<country>USA</country>
</postal>
<phone>+1 919 392 5158</phone>
<email>ssenthil@cisco.com</email>
</address>
</author>
<author fullname="Cathy Zhou" initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<code>518129</code>
<country>P.R. China</country>
</postal>
<phone></phone>
<email>cathy.zhou@huawei.com</email>
</address>
</author>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization>Huawei Technologies (USA)</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara, CA 95050</city>
<code></code>
<country>USA</country>
</postal>
<phone>+1 408 330 4424</phone>
<email>Tina.Tsou.Zouting@huawei.com</email>
</address>
</author>
<author fullname="Simon Perreault" initials="S." surname="Perreault">
<organization>Jive Communications</organization>
<address>
<postal>
<street></street>
<city>Quebec</city>
<region>QC</region>
<country>Canada</country>
</postal>
<email>sperreault@jive.com</email>
</address>
</author>
<date />
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>IPv4 service continuity</keyword>
<keyword>IPv4 address shortage</keyword>
<keyword>A+P</keyword>
<keyword>AplusP</keyword>
<keyword>address plus port</keyword>
<keyword>MAP</keyword>
<keyword>Port range</keyword>
<keyword>Port Range Router</keyword>
<keyword>MAP-E</keyword>
<keyword>port set mapping</keyword>
<keyword>port bulk</keyword>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this 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. -->
<abstract>
<t>In some use cases, e.g., Lightweight 4over6, the client may require
not just one port, but a port set. This document defines an extension to
the Port Control Protocol (PCP) allowing clients to manipulate sets of
ports as a whole. This is accomplished by a new MAP option:
PORT_SET.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document extends Port Control Protocol (PCP) <xref
target="RFC6887"></xref> with the ability to retrieve a set of ports
using a single request. It does so by defining a new PORT_SET
option.</t>
<t>This section describes a few (and non-exhaustive) envisioned use
cases. Note that the PCP extension defined in this document is generic
and is expected to be applicable to other use cases.</t>
<section title="Applications Using Port Sets">
<t>Some applications require not just one port, but a port set. One
example is a Session Initiation Protocol (SIP) User Agent Server (UAS)
<xref target="RFC3261"></xref> expecting to handle multiple concurrent
calls, including media termination. When it receives a call, it needs
to signal media port numbers to its peer. Generating individual PCP
MAP requests for each of the media ports during call setup would
introduce unwanted latency and increased signaling load. Instead, the
server can pre-allocate a set of ports such that no PCP exchange is
needed during call setup.</t>
</section>
<section title="Lightweight 4over6">
<t>In the Lightweight 4over6 (lw4o6) <xref target="RFC7596"></xref>
architecture, shared global addresses can be allocated to customers.
It allows moving the Network Address Translation (NAT) function,
otherwise accomplished by a Carrier-Grade NAT (CGN) <xref
target="RFC6888"></xref>, to the Customer-Premises Equipment (CPE).
This provides more control over the NAT function to the user, and more
scalability to the Internet Service Provider (ISP).</t>
<t>In the lw4o6 architecture, the PCP-controlled device corresponds to
the Lightweight AFTR (lwAFTR), and the PCP client corresponds to the
Lightweight B4 (lwB4). The PCP client sends a PCP MAP request
containing a PORT_SET option to trigger shared address allocation on
the Lightweight AFTR (lwAFTR). The PCP response contains the shared
address information, including the port set allocated to the
Lightweight B4 (lwB4).</t>
</section>
<section title="Firewall Control">
<t>Port sets are often used in firewall rules. For example, defining a
range for Real-time Transport Protocol (RTP) <xref
target="RFC3550"></xref> traffic is common practice. The PCP MAP
request can already be used for firewall control. The PORT_SET option
brings the additional ability to manipulate firewall rules operating
on port sets instead of single ports.</t>
</section>
<section title="Discovering Stateless Port Set Mappings">
<t>A PCP MAP request can be used to retrieve a mapping from a
stateless device (i.e., one that does not establish any per-flow
state, and simply rewrites the address and/or port in a purely
algorithmic fashion, including no rewriting). Similarly, a PCP MAP
request with a PORT_SET request can be used to discover a port set
mapping from a stateless device. See <xref
target="stateless_example"></xref> for an example.</t>
</section>
</section>
<section title="The need for PORT_SET">
<t>Multiple PCP MAP requests can be used to manipulate a set of ports,
having roughly the same effect as a single use of a PCP MAP request with
a PORT_SET option. However, use of the PORT_SET option is more efficient
when considering the following aspects: <list style="hanging">
<t hangText="Network Traffic:">A single request uses less network
resources than multiple requests.</t>
<t hangText="Latency:">Even though PCP MAP requests can be sent in
parallel, we can expect the total processing time to be longer for
multiple requests than a single one.</t>
<t hangText="Server-side efficiency:">Some PCP-controlled devices
can allocate port sets in a manner such that data passing through
the device is processed much more efficiently than the equivalent
using individual port allocations. For example, a CGN having a
"bulk" port allocation scheme (see <xref target="RFC6888"></xref>,
Section 5) often has this property.</t>
<t hangText="Server-side scalability:">The number of state table
entries in PCP-controlled devices is often a limiting factor.
Allocating port sets in a single request can result in a single
mapping entry being used, therefore allowing greater
scalability.</t>
</list></t>
<t>Therefore, while it is functionally possible to obtain the same
results using plain MAP, the extension proposed in this document allows
greater efficiency, scalability, and simplicity, while lowering latency
and necessary network traffic.</t>
<t>In addition, PORT_SET supports parity preservation. Some protocols
(e.g., RTP <xref target="RFC3550"></xref>) assign meaning to a port
number's parity. When mapping sets of ports for the purpose of using
such kind of protocol, preserving parity can be necessary.</t>
</section>
<section title="Terminology">
<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"></xref>.</t>
</section>
<section anchor="PORT_SET" title="The PORT_SET Option">
<t><list style="hanging">
<t hangText="Option Name:">PORT_SET</t>
<t hangText="Number:">TBD (see <xref target="IANA"></xref>)</t>
<t hangText="Purpose:">To map sets of ports.</t>
<t hangText="Valid for Opcodes:">MAP</t>
<t hangText="Length:">5 bytes</t>
<t hangText="May appear in:">Both requests and responses</t>
<t hangText="Maximum occurrences:">1</t>
</list></t>
<t>The PORT_SET option indicates that the PCP client wishes to reserve a
set of ports. The requested number of ports in that set is indicated in
the option.</t>
<t>The maximum occurrences of the PORT_SET option MUST be limited to 1.
The reason is that the suggested external port set depends on the data
contained in the MAP Opcode header. Having two PORT_SET options with a
single MAP Opcode header would imply having two overlapping suggested
external port sets.</t>
<t>Note that the option number is in the "optional to process" range
(128-191), meaning that a PCP MAP request with a PORT_SET option will be
interpreted by a PCP server that does not support PORT_SET as a
single-port PCP MAP request, as if the PORT_SET option was absent.</t>
<t>The PORT_SET Option is formatted as shown in <xref
target="format"></xref>.</t>
<figure anchor="format" title="PORT_SET 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=TBD| Reserved | Option Length=5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Set Size | First Internal Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |P|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The fields are as follows: <list style="hanging">
<t hangText="Port Set Size:">A 16-bit unsigned integer. Number of
ports requested. MUST NOT be zero.</t>
<t hangText="First Internal Port:">In a request, this field MUST be
set equal to the Internal Port field in the MAP opcode by the PCP
client. In a response, this field indicates the first internal port
of the port set mapped by the PCP server, which may differ from the
value sent in the request. That is to be contrasted to the Internal
Port field, which by necessity is always identical in matched
requests and responses.</t>
<t hangText="Reserved:">MUST be set to zero when sending, MUST be
ignored when receiving.</t>
<t hangText="P:">1 if parity preservation is requested, 0 otherwise.
See <xref target="RFC4787"></xref>, Section 4.2.2.</t>
</list></t>
<t>The Internal Port Set is defined as being the range of Port Set Size
ports starting from the First Internal Port. The Suggested External Port
Set is defined as being the range of Port Set Size ports starting from
the Suggested External Port. Similarly, the Assigned External Port Set
is defined as being the range of Port Set Size ports starting from the
Assigned External Port. The Internal Port Set returned in a response and
the Assigned External Port Set have the same size.</t>
<t>The Suggested External Port corresponds to the first port in the
suggested External Port Set. Its purpose is for clients to be able to
regenerate previous mappings after state loss. When such an event
happens, clients may attempt to regenerate identical mappings by
suggesting the same External Port Set as before the state loss. Note
that there is no guarantee that the allocated External Port Set will be
the one suggested by the client.</t>
<section title="Client Behavior">
<t>To retrieve a set of ports, the PCP client adds a PORT_SET option
to its PCP MAP request. If parity preservation is required (i.e., an
even port to be mapped to an even port, and an odd port to be mapped
to an odd port), the PCP client MUST set the parity bit (to 1) to ask
the PCP server to preserve the port parity.</t>
<t>The PCP client MUST NOT include more than one PORT_SET option in a
PCP MAP request. If several port sets are needed, the PCP client MUST
issue separate PCP MAP requests, each potentially including a PORT_SET
option. These individual PCP MAP requests MUST include distinct
Internal Ports.</t>
<t>If the PCP client does not know the exact number of ports it
requires, it MAY then set the Port Set Size to 0xffff, indicating that
it is willing to accept as many ports as the PCP server can offer.</t>
<t>A PCP client SHOULD NOT send a PORT_SET option for single-port PCP
MAP requests (including creation, renewal, and deletion), because that
needlessly increases processing on the server.</t>
<t>PREFER_FAILURE MUST NOT appear in a request with PORT_SET option.
As a reminder PREFER_FAILURE was specifically designed for the
Universal Plug and Play (UPnP) Internet Gateway Device - Port Control
Protocol Interworking Function (IGD-PCP IWF) <xref
target="RFC6970"></xref>. The reasons for not recommending the use of
PREFER_FAILURE are discussed in Section 13.2 of <xref
target="RFC6887"></xref>.</t>
<t>When the PCP-controlled device supports multiple port-sets
delegation for a given PCP client, the PCP client MAY re-initiate a
PCP request to get another port set when it has exhausted all the
ports within the port-set.</t>
</section>
<section title="Server Behavior">
<t>In addition to regular PCP MAP request processing, the following
checks are made upon receipt of a PORT_SET option with non-zero
Requested Lifetime: <list style="symbols">
<t>If multiple PORT_SET options are present in a single PCP MAP
request, a MALFORMED_OPTION error is returned.</t>
<t>If the Port Set Size is zero, a MALFORMED_OPTION error is
returned.</t>
<t>If PREFER_FAILURE option is present, a MALFORMED_OPTION error
is returned.</t>
</list></t>
<t>The PCP server MAY map fewer ports than the value of Port Set Size
from the request. It MUST NOT map more ports than the PCP client asked
for. Internal ports outside the range of Port Set Size ports starting
from the Internal Port MUST NOT be mapped by the PCP server.</t>
<t>If the requested port set cannot be fully satisfied, the PCP server
SHOULD map as many ports as possible, and SHOULD map at least one port
(which is the same behavior as if Port Set Size is set to 1).</t>
<t>If the PCP server ends up mapping only a single port, for any
reason, the PORT_SET option MUST NOT be present in the response. In
particular, if the PCP server receives a single-port PCP MAP request
that includes a PORT_SET option, the PORT_SET option is silently
ignored and the request is handled as a single-port PCP MAP
request.</t>
<t>If the port parity preservation is requested (P = 1), the PCP
server MAY preserve port parity. In that case, the External Port is
set to a value having the same parity as the First Internal Port.</t>
<t>If the mapping is successful, the MAP response's Assigned External
Port is set to the first port in the External Port Set, and the
PORT_SET option's Port Set Size is set to number of ports in the
mapped port set. The First Internal Port field is set to the first
port in the Internal Port Set.</t>
</section>
<section title="Absence of Capability Discovery">
<t>A PCP client that wishes to make use of a port set includes the
PORT_SET option. If no PORT_SET option is present in the response, the
PCP client cannot conclude that the PCP server does not support the
PORT_SET option. It may just be that the PCP server does support
PORT_SET but decided to allocate only a single port, for reasons that
are its own. If the client wishes to obtain more ports, it MAY send
additional PCP MAP requests (see <xref target="fewer"></xref>), which
the PCP server may or may not grant according to local policy.</t>
<t>If port set capability is added to or removed from a running PCP
server, the server MAY reset its Epoch time and send an ANNOUNCE
message as described in the PCP specification ([RFC6887], Section
14.1). This causes PCP clients to retry, and those using PORT_SET will
now receive a different response.</t>
</section>
<section title="Port Set Renewal and Deletion">
<t>Port set mappings are renewed and deleted as a single entity. That
is, the lifetime of all port mappings in the set is set to the
Assigned Lifetime at once.</t>
<t>A PCP client attempting to refresh or delete a port set mapping
MUST include the PORT_SET option in its request.</t>
<section anchor="overlap" title="Overlap Conditions">
<t>Port set PCP MAP requests can overlap with existing single port
or port set mappings. This can happen either by mistake or after a
PCP client becomes out of sync with server state.</t>
<t>If a PCP server receives a PCP MAP request, with or without a
PORT_SET option, that tries to map one or more internal ports or
port sets belonging to already existing mappings, then the request
is considered to be a refresh request applying those mappings. Each
of the matching port or port set mappings is processed
independently, as if a separate refresh request had been received.
The processing is as described in Section 15 of <xref
target="RFC6887"></xref>. The PCP server sends a Mapping Update
message for each of the mappings.</t>
</section>
</section>
</section>
<section title="Examples">
<section title="Simple Request on NAT44">
<t>An application requires a range of 100 IPv4 UDP ports to be mapped
to itself. The application running on the host has created sockets
bound to IPv4 UDP ports 50,000 to 50,099 for this purpose. It does not
care about which external port numbers are allocated. The PCP client
sends a PCP request with the following parameters over IPv4: <list
style="symbols">
<t>MAP opcode <list style="hanging">
<t hangText="Mapping Nonce:"><a random nonce></t>
<t hangText="Protocol:">17</t>
<t hangText="Internal Port:">50,000</t>
<t hangText="Suggested External Port:">0</t>
<t
hangText="Suggested External IP Address:">::ffff:0.0.0.0</t>
</list></t>
<t>PORT_SET Option <list style="hanging">
<t hangText="Port Set Size:">100</t>
<t hangText="First Internal Port:">50,000</t>
<t hangText="P:">0</t>
</list></t>
</list></t>
<t>The PCP server is unable to fulfill the request fully: it is
configured by local policy to only allocate 32 ports per user. Since
the PREFER_FAILURE option is absent from the request, it decides to
map UDP ports 37,056 to 37,087 on external address 192.0.2.3 to
internal ports 50,000 to 50,031. After setting up the mapping in the
NAT44 device it controls, it replies with the following PCP response:
<list style="symbols">
<t>MAP opcode <list style="hanging">
<t hangText="Mapping Nonce:"><copied from the
request></t>
<t hangText="Protocol:">17</t>
<t hangText="Internal Port:">50,000</t>
<t hangText="Assigned External Port:">37,056</t>
<t
hangText="Assigned External IP Address:">::ffff:192.0.2.3</t>
</list></t>
<t>PORT_SET Option <list style="hanging">
<t hangText="Port Set Size:">32</t>
<t hangText="First Internal Port:">50,000</t>
<t hangText="P:">0</t>
</list></t>
</list></t>
<t>Upon receiving this response, the host decides that 32 ports is
good enough for its purposes. It closes sockets bound to ports 50,032
to 50,099, sets up a refresh timer, and starts using the port range it
has just been assigned.</t>
</section>
<section anchor="stateless_example" title="Stateless Mapping Discovery">
<t>A host wants to discover a stateless NAT44 mapping pointing to it.
To do so, it sends the following request over IPv4: <list
style="symbols">
<t>MAP opcode <list style="hanging">
<t hangText="Mapping Nonce:"><a random nonce></t>
<t hangText="Protocol:">0</t>
<t hangText="Internal Port:">1</t>
<t hangText="Suggested External Port:">0</t>
<t
hangText="Suggested External IP Address:">::ffff:0.0.0.0</t>
</list></t>
<t>PORT_SET Option <list style="hanging">
<t hangText="Port Set Size:">65,535</t>
<t hangText="First Internal Port:">1</t>
<t hangText="P:">0</t>
</list></t>
</list></t>
<t>The PCP server sends the following response: <list style="symbols">
<t>MAP opcode <list style="hanging">
<t hangText="Mapping Nonce:"><copied from the
request></t>
<t hangText="Protocol:">0</t>
<t hangText="Internal Port:">1</t>
<t hangText="Assigned External Port:">26,624</t>
<t
hangText="Assigned External IP Address:">::ffff:192.0.2.5</t>
</list></t>
<t>PORT_SET Option <list style="hanging">
<t hangText="Port Set Size:">2048</t>
<t hangText="First Internal Port:">26,624</t>
<t hangText="P:">0</t>
</list></t>
</list></t>
<t>From this response, the host understands that a 2048-port stateless
mapping is pointing to itself, starting from port 26,624 on external
IP address 192.0.2.5.</t>
</section>
<section title="Resolving Overlap">
<t>This example relates to <xref target="overlap"></xref>.</t>
<t>Suppose internal port 100 is mapped to external port 100 and port
set 101-199 is mapped to external port set 201-299. The PCP server
receives a PCP MAP request with Internal Port = 100, External Port =
0, and a PORT_SET option with Port Set Size = 100. The request's
Mapping Nonce is equal to those of the existing single port and port
set mappings. This request is therefore treated as two refresh
requests, the first one applying to the single port mapping and the
second one applying to the port set mapping. The PCP server updates
both mapping's lifetimes as usual then sends two responses: the first
one contains Internal Port = 100, External Port = 100, and no PORT_SET
option, while the second one contains Internal Port = 101, External
Port = 201, and a PORT_SET option with Port Set Size = 99.</t>
</section>
</section>
<section title="Operational Considerations">
<section anchor="quota" title="Limits and Quotas">
<t>It is up to the PCP server to determine the port-set quota, if any,
for each PCP client.</t>
<t>If the PCP server is configured to allocate multiple port-set
allocations for one subscriber, the same Assigned External IP Address
SHOULD be assigned to the subscriber in multiple port-set
responses.</t>
<t>To optimize the number of mapping entries maintained by the PCP
server, it is RECOMMENDED to configure the PCP server to assign the
maximum allowed port set size in a single response. This policy SHOULD
be configurable.</t>
</section>
<section title="High Availability">
<t>The failover mechanism in MAP (Section 14 in <xref
target="RFC6887"></xref>) can also be applied to port sets.</t>
</section>
<section title="Idempotence">
<t>A core, desirable property of the PCP protocol is idempotence. In a
nutshell, requests produce the same results whether they are executed
once or multiple times. This property is preserved with the PORT_SET
attribute, with the following caveat: the order in which the PCP
server receives requests with overlapping Internal Port Sets will
affect the mappings being created and the responses received.</t>
<t>For example suppose these two requests are sent by a PCP client:
<list style="hanging">
<t hangText="Request A:">Internal Port Set 1-10</t>
<t hangText="Request B:">Internal Port Set 5-14</t>
</list> The PCP server's actions will depend on which request is
received first. Suppose that A is received before B: <list
style="hanging">
<t hangText="Upon reception of A:">Internal ports 1-10 are mapped.
A success response containing the following fields is sent: <list
style="hanging">
<t hangText="Internal Port:">1</t>
<t hangText="First Internal Port:">1</t>
<t hangText="Port Set Size:">10</t>
</list></t>
<t hangText="Upon reception of B:">The request matches mapping A.
The request is interpreted as a refresh request for mapping A, and
a response containing the following fields is sent: <list
style="hanging">
<t hangText="Internal Port:">5</t>
<t hangText="First Internal Port:">1</t>
<t hangText="Port Set Size:">10</t>
</list></t>
</list> If the order of reception is reversed (B before A), the
created mapping will be different, and the First Internal Port in both
responses would then be 5.</t>
<t>To avoid surprises, PCP clients MUST ensure that port set mapping
requests do not inadvertently overlap. For example, a host's operating
system could include a central PCP client process through which port
set mapping requests would be arbitrated. Alternatively, individual
PCP clients running on the same host would be required to acquire the
internal ports from the operating system (e.g., a call to the bind()
function from the BSD API) before trying to map them with PCP.</t>
</section>
<section anchor="fewer"
title="What Should a PCP Client Do When It Receives Fewer Ports than Requested?">
<t>Suppose a PCP client asks for 16 ports and receives 8. What should
it do? Should it consider this a final answer? Should it try a second
request, asking for 8 more ports? Should it fall back to 8 individual
PCP MAP requests? This document leaves the answers to be
implementation-specific, but describes issues to be considered when
answering them.</t>
<t>First, the PCP server has decided to allocate 8 ports for some
reason. It may be that allocation sizes have been limited by the PCP
server's administrator. It may be that the PCP client has reached a
quota. It may be that these 8 ports were the last contiguous ones
available. Depending on the reason, asking for more ports may or may
not be likely to actually yield more ports. However, the PCP client
has no way of knowing.</t>
<t>Second, not all PCP clients asking for N ports actually need all N
ports to function correctly. For example, a DNS resolver could ask for
N ports to be used for source port randomization. If fewer than N
ports are received, the DNS resolver will still work correctly, but
source port randomization will be slightly less efficient, having
fewer bits to play with. In that case, it would not make much sense to
ask for more ports.</t>
<t>Finally, asking for more ports could be considered abuse. External
ports are a resource that is to be shared among multiple PCP clients.
A PCP client trying to obtain more than its fair share could trigger
countermeasures according to local policy.</t>
<t>In conclusion, it is expected that for most applications, asking
for more ports would not yield benefits justifying the additional
costs.</t>
</section>
</section>
<section title="Security Considerations">
<t>The security considerations discussed in <xref
target="RFC6887"></xref> apply to this extension.</t>
<t>As described in <xref target="overlap"></xref>, a single PCP request
using the PORT_SET option may result in multiple responses. For this to
happen it is necessary that the request contain the nonce associated to
multiple mappings on the server. Therefore, an on-path attacker could
use an eavesdropped nonce to mount an amplification attack. Use of PCP
authentication (<xref target="RFC6887"></xref>, Section 18) eliminates
this attack vector.</t>
<t>In order to prevent a PCP client from controlling all ports bound to
a shared IP address, port quotas should be configured on the PCP server
(Section 17.2 of <xref target="RFC6887"></xref>).</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA has allocated value TBD (note to IANA: to be allocated from the
range 128-191) in the "PCP Options" registry at
http://www.iana.org/assignments/pcp-parameters for the new PCP option
defined in <xref target="PORT_SET"></xref>.</t>
</section>
<section title="Contributors">
<t>The following are extended authors who contributed to the effort:</t>
<t>Yunqing Chen</t>
<t>China Telecom</t>
<t>Room 502, No.118, Xizhimennei Street</t>
<t>Beijing 100035</t>
<t>P.R.China</t>
<t></t>
<t>Chongfeng Xie</t>
<t>China Telecom</t>
<t>Room 502, No.118, Xizhimennei Street</t>
<t>Beijing 100035</t>
<t>P.R.China</t>
<t></t>
<t>Yong Cui</t>
<t>Tsinghua University</t>
<t>Beijing 100084</t>
<t>P.R.China</t>
<t>Phone: +86-10-62603059</t>
<t>Email: yong@csnet1.cs.tsinghua.edu.cn</t>
<t></t>
<t>Qi Sun</t>
<t>Tsinghua University</t>
<t>Beijing 100084</t>
<t>P.R.China</t>
<t>Phone: +86-10-62785822</t>
<t>Email: sunqibupt@gmail.com</t>
<t></t>
<t>Gabor Bajko</t>
<t>Mediatek Inc.</t>
<t>Email: gabor.bajko@mediatek.com</t>
<t></t>
<t>Xiaohong Deng</t>
<t>France Telecom</t>
<t>Email: xiaohong.deng@orange-ftgroup.com</t>
</section>
<section title="Acknowledgements">
<t>The authors would like to show sincere appreciation to Alain Durand,
Cong Liu, Dan Wing, Dave Thaler, Peter Koch, Reinaldo Penno, Sam
Hartman, Stuart Cheshire, Ted Lemon, Yoshihiro Ohba, Meral Shirazipour,
Jouni Korhonen, and Ben Campbell for their useful comments and
suggestions.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<reference anchor="RFC6887">
<front>
<title>Port Control Protocol (PCP)</title>
<author fullname="D. Wing" initials="D." surname="Wing">
<organization></organization>
</author>
<author fullname="S. Cheshire" initials="S." surname="Cheshire">
<organization></organization>
</author>
<author fullname="M. Boucadair" initials="M." surname="Boucadair">
<organization></organization>
</author>
<author fullname="R. Penno" initials="R." surname="Penno">
<organization></organization>
</author>
<author fullname="P. Selkirk" initials="P." surname="Selkirk">
<organization></organization>
</author>
<date month="April" year="2013" />
<abstract>
<t>The Port Control Protocol allows an IPv6 or IPv4 host to
control how incoming IPv6 or IPv4 packets are translated and
forwarded by a Network Address Translator (NAT) or simple
firewall, and also allows a host to optimize its outgoing NAT
keepalive messages.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6887" />
<format octets="221314"
target="http://www.rfc-editor.org/rfc/rfc6887.txt" type="TXT" />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<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 RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.7596'?>
<?rfc include='reference.RFC.6970'?>
<reference anchor="RFC4787">
<front>
<title>Network Address Translation (NAT) Behavioral Requirements for
Unicast UDP</title>
<author fullname="F. Audet" initials="F." surname="Audet">
<organization></organization>
</author>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization></organization>
</author>
<date month="January" year="2007" />
<abstract>
<t>This document defines basic terminology for describing
different types of Network Address Translation (NAT) behavior when
handling Unicast UDP and also defines a set of requirements that
would allow many applications, such as multimedia communications
or online gaming, to work consistently. Developing NATs that meet
this set of requirements will greatly increase the likelihood that
these applications will function properly. This document specifies
an Internet Best Current Practices for the Internet Community, and
requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="127" />
<seriesInfo name="RFC" value="4787" />
<format octets="68693"
target="http://www.rfc-editor.org/rfc/rfc4787.txt" type="TXT" />
</reference>
<reference anchor="RFC6888">
<front>
<title>Common Requirements for Carrier-Grade NATs (CGNs)</title>
<author fullname="S. Perreault" initials="S." surname="Perreault">
<organization></organization>
</author>
<author fullname="I. Yamagata" initials="I." surname="Yamagata">
<organization></organization>
</author>
<author fullname="S. Miyakawa" initials="S." surname="Miyakawa">
<organization></organization>
</author>
<author fullname="A. Nakagawa" initials="A." surname="Nakagawa">
<organization></organization>
</author>
<author fullname="H. Ashida" initials="H." surname="Ashida">
<organization></organization>
</author>
<date month="April" year="2013" />
<abstract>
<t>This document defines common requirements for Carrier-Grade
NATs (CGNs). It updates RFC 4787.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="127" />
<seriesInfo name="RFC" value="6888" />
<format octets="32484"
target="http://www.rfc-editor.org/rfc/rfc6888.txt" type="TXT" />
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization></organization>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization></organization>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization></organization>
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization></organization>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization></organization>
</author>
<date month="June" year="2002" />
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an
application-layer control (signaling) protocol for creating,
modifying, and terminating sessions with one or more participants.
These sessions include Internet telephone calls, multimedia
distribution, and multimedia conferences. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261" />
<format octets="647976"
target="http://www.rfc-editor.org/rfc/rfc3261.txt" type="TXT" />
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H."
surname="Schulzrinne">
<organization></organization>
</author>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization></organization>
</author>
<author fullname="R. Frederick" initials="R." surname="Frederick">
<organization></organization>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization></organization>
</author>
<date month="July" year="2003" />
<abstract>
<t>This memorandum describes RTP, the real-time transport
protocol. RTP provides end-to-end network transport functions
suitable for applications transmitting real-time data, such as
audio, video or simulation data, over multicast or unicast network
services. RTP does not address resource reservation and does not
guarantee quality-of- service for real-time services. The data
transport is augmented by a control protocol (RTCP) to allow
monitoring of the data delivery in a manner scalable to large
multicast networks, and to provide minimal control and
identification functionality. RTP and RTCP are designed to be
independent of the underlying transport and network layers. The
protocol supports the use of RTP-level translators and mixers.
Most of the text in this memorandum is identical to RFC 1889 which
it obsoletes. There are no changes in the packet formats on the
wire, only changes to the rules and algorithms governing how the
protocol is used. The biggest change is an enhancement to the
scalable timer algorithm for calculating when to send RTCP packets
in order to minimize transmission in excess of the intended rate
when many participants join a session simultaneously.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64" />
<seriesInfo name="RFC" value="3550" />
<format octets="259985"
target="http://www.rfc-editor.org/rfc/rfc3550.txt" type="TXT" />
<format octets="630740"
target="http://www.rfc-editor.org/rfc/rfc3550.ps" type="PS" />
<format octets="504117"
target="http://www.rfc-editor.org/rfc/rfc3550.pdf" type="PDF" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:37:38 |