One document matched: draft-ietf-pcp-port-set-01.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-01" 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 initials="S." surname="Sivakumar" fullname="Senthil 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>Viagenie</organization>
<address>
<postal>
<street>246 Aberdeen</street>
<city>Quebec</city>
<region>QC</region>
<code>G1R 2E1</code>
<country>Canada</country>
</postal>
<phone>+1 418 656 9254</phone>
<email>simon.perreault@viagenie.ca</email>
</address>
</author>
<date/>
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- 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>This document defines an extension to 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 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="Lightweight 4over6">
<t>In the Lightweight 4over6 <xref
target="I-D.ietf-softwire-lw4over6"/> 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"/>, to the Customer-Premises Equipment (CPE). This
provides more control over the NAT function to the user, and more
scalability to the ISP.</t>
<t>In the lw4o6 architecture, the PCP-controlled device corresponds to
the lwAFTR, and the PCP client corresponds to the lwB4. The client
sends a PCP MAP request containing a PORT_SET option to trigger shared
address allocation on the lwAFTR. The PCP response contains the shared
address information, including the port set allocated to the lwB4.</t>
</section>
<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"/> 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. Instead, the server can pre-allocate a set
of ports such that no PCP exchange is needed during call setup.</t>
<t>Using PORT_SET, an application can manipulate port sets much more
efficiently than with individual MAP requests.</t>
<t>Another example of an application using port sets is that of a busy
back-to-back PCP server/client <xref
target="I-D.cheshire-recursive-pcp"/>, handling many requests per
second. It could benefit from PORT_SET by obtaining ports from
upstream in big chunks. Then it would manage those chunks like port
pools from which it would allocate to downstream clients. That could
be more efficient than obtaining ports from upstream with individual
MAP requests.</t>
</section>
<section title="Firewall Control">
<t>Port sets are often used in firewall rules. For example, defining a
range for RTP <xref target="RFC3550"/> traffic is common practice. The
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 MAP request can be used to discover a stateless mapping. Similarly,
a MAP request with a PORT_SET request can be used to discover a
stateless port set mapping. Hence, PORT_SET is applicable for port set
mapping discovery in Stateless NAT44 <xref
target="I-D.tsou-stateless-nat44"/>.</t>
</section>
</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"/>.</t>
</section>
<section title="The need for PORT_SET">
<t>Multiple MAP requests can be used to manipulate a set of ports, having
roughly the same effect as a single use of a 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 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="Client-side simplicity:">The logic that is necessary for
maintaining a set of ports using a single port set entity is much
simpler than that required for maintaining individual ports,
especially when considering failures, retransmissions, lifetime
expiration, and re-allocations.</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"/> section 5) often has
this property.</t>
<t hangText="Server-side scalability:">The number of mapping 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. In a nutshell, PORT_SET is a necessary
optimization.</t>
<t>In addition, PORT_SET supports parity preservation. Some protocols
(e.g. RTP <xref target="RFC3550"/>) 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="The PORT_SET Option" anchor="PORT_SET">
<t>
<list style="hanging">
<t hangText="Option Name:">PORT_SET</t>
<t hangText="Number:">TBD</t>
<t hangText="Purpose:">To map sets of ports.</t>
<t hangText="Valid for Opcodes:">MAP</t>
<t hangText="Length:">3 bytes</t>
<t hangText="May appear in:">Both requests and responses</t>
<t hangText="Maximum occurrences:">1</t>
</list>
</t>
<t>
<list>
<t>NOTE TO IANA (to be removed prior to publication as an RFC): The
number is to be assigned by IANA in the range 128-191 (i.e.,
optional to process and created via Standards Action).</t>
</list>
</t>
<t>The PORT_SET Option indicates that the client wishes to reserve a set
of ports. The requested number of ports in that set is indicated in the
option.</t>
<t>The PORT_SET Option is formatted as shown in <xref
target="format"/>.</t>
<figure anchor="format" title="PORT_SET Option">
<artwork>
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=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Set Size | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The fields are as follows:
<list style="hanging">
<t hangText="Port Set Size:">Number of ports requested. MUST NOT be
zero.</t>
<t hangText="P:">1 if parity preservation is requested, 0
otherwise.</t>
</list>
</t>
<t>
<list>
<t>NOTE: In its current form, PORT_SET does not support allocating
discontinuous port sets. That feature could be added in the future
depending on input from the working group.</t>
</list>
</t>
<t>The Internal Port Set is defined as being the range of Port Set Size
ports starting from the Internal Port. The External Port Set is
respectively defined as being the range of Port Set Size ports starting
from the Assigned External Port. The two ranges always have the same
size (i.e., the Port Set Size returned by the server).</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 port preservation is required, the PCP Client
MUST set the parity bit (to 1) to ask the server to preserve the port
parity (i.e., the Assigned External Port and Internal Port have the
same parity). The PCP client MUST indicate a suggested Port Set Size.
A non-null value MUST be used.</t>
<t>The PCP Client MUST NOT include more than one PORT_SET option in a
MAP request. If several port sets are needed, the PCP client MUST
issue as many MAP requests each of them include a PORT_SET option.
These individual MAP requests MUST include distinct Internal Port.</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 server can offer.</t>
<t>If the PORT_SET option is not supported by the server, the PCP client
will receive a response with no PORT_SET option. The PCP client will
then have to issue individual MAP requests with no PORT_SET option to
achieve similar functionality.</t>
</section>
<section title="Server Behavior">
<t>In addition to regular 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 MAP request,
a MALFORMED_OPTION error is returned.</t>
<t>If the Port Set Size is zero, a MALFORMED_OPTION error is
returned.</t>
</list>
</t>
<t>If the PREFER_FAILURE option is present and the server is unable to
map all ports in the requested External Port Set or is unable to
preserve parity (P = 1), the CANNOT_PROVIDE_EXTERNAL error is
returned.</t>
<t>If the PREFER_FAILURE option is absent, the server MAY map fewer
ports than the value of Port Set Size from the request. It MUST NOT
map more ports than the client asked for. The Internal Port Set always
begins from the Internal Port indicated by the client and extends for
a number of ports less than or equal to the requested Port Set Size.</t>
<t>If the port mapping fails because of the unavailability of ports, the
PCP Server SHOULD reserve only one external port if possible. That is,
the PCP server ignores the PORT_SET option and falls back to ordinary
MAP request processing.</t>
<t>If the server ends up mapping only a single port, for any reason, the
PORT_SET option MUST NOT be present in the response.</t>
<t>If the PREFER_FAILURE option is absent and port parity preservation
is requested (P = 1), the server MAY preserve port parity. In that
case, the External Port is set to a value having the same parity as
the 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.</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 client attempting to refresh or delete a port set mapping MUST
include the PORT_SET option in its request.</t>
<section title="Overlap Conditions">
<t>Port set map requests can overlap with existing single port or port
set mappings. This can happen either by mistake or after a client
becomes out of sync with server state.</t>
<t>If a server receives a MAP request, with or without a PORT_SET
option, that tries to map one or more internal ports or port sets
already belonging to other mappings, then the request is considered
to be a refresh request applying to those other mappings. The nonce
check MUST be performed independently for each mapping, and only
those whose nonce matches the one from the request are refreshed.
For each port or port set mapping that is thus refreshed, the server
MUST send a separate response. Each response will contain the
Internal and External Ports pertaining to that particular mapping,
with also a PORT_SET option in case of a port set.
<list>
<t>Example: suppose internal port 100 is mapped to external port
100 and port set 101-199 is mapped to external port set 201-299.
The server receives a 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 a two refresh requests, the first one
applying to the single port mapping and the second one applying
to the port set mapping. The server updates both mapping's
lifetimes as usual then sends two MAP 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>
<t>Note (to be removed before publication): It is possible to
enumerate mappings with this mechanism. Is it a problem,
security- or other-wise?</t>
</list>
</t>
</section>
</section>
</section>
<section title="Operational Considerations">
<t>It is totally up to the PCP server to determine the port-set quota
for each PCP client. In addition, 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>
<t>If the PCP server is configured to allocate multiple port-set
allocation for one subscriber, the same Assigned External IP Address
SHOULD be assigned to one subscriber in multiple port-set requests.</t>
<t>To optimize the number of mapping entries maintained by the PCP
server, it is RECOMMENDED to configure the server to assign the
maximum allowed port set in a single response. This policy SHOULD be
configurable.</t>
<t>The failover mechanism in MAP [section 14 in <xref
target="RFC6887"></xref>] and <xref
target="I-D.boucadair-pcp-failure"></xref> can also be applied to port
sets.</t>
</section>
<section title="Security Considerations">
<t>It is believed that no additional security considerations beyond those
discussed in <xref target="RFC6887"></xref> apply to this extension.</t>
</section>
<section title="IANA Considerations">
<t>IANA shall allocate a code in the range 1-63 for the new PCP option
defined in <xref target="PORT_SET"/>.</t>
</section>
<section title="Authors List">
<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>Nokia</t>
<t>Email: gabor.bajko@nokia.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,
Dan Wing,
Dave Thaler,
Reinaldo Penno,
Sam Hartman,
Stuart Cheshire,
and Yoshihiro Ohba,
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 initials='D.' surname='Wing' fullname='D. Wing'>
<organization /></author>
<author initials='S.' surname='Cheshire' fullname='S. Cheshire'>
<organization /></author>
<author initials='M.' surname='Boucadair' fullname='M. Boucadair'>
<organization /></author>
<author initials='R.' surname='Penno' fullname='R. Penno'>
<organization /></author>
<author initials='P.' surname='Selkirk' fullname='P. Selkirk'>
<organization /></author>
<date year='2013' month='April' />
<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 type='TXT' octets='221314' target='http://www.rfc-editor.org/rfc/rfc6887.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott 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 year='1997' month='March' />
<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 type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
</references>
<references title="Informative References">
<reference anchor='I-D.ietf-softwire-lw4over6'>
<front>
<title>Lightweight 4over6: An Extension to the DS-Lite Architecture</title>
<author initials='Y' surname='Cui' fullname='Yong Cui'>
<organization />
</author>
<author initials='Q' surname='Sun' fullname='Qiong Sun'>
<organization />
</author>
<author initials='M' surname='Boucadair' fullname='Mohamed Boucadair'>
<organization />
</author>
<author initials='T' surname='Tsou' fullname='Tina Tsou'>
<organization />
</author>
<author initials='Y' surname='Lee' fullname='Yiu Lee'>
<organization />
</author>
<author initials='I' surname='Farrer' fullname='Ian Farrer'>
<organization />
</author>
<date month='April' day='10' year='2013' />
<abstract><t>DS-Lite [RFC6333] describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address Translation function from the DS-Lite AFTR to the B4, removing the requirement for a Carrier Grade NAT function in the AFTR. This reduces the amount of centralized state that must be held to a per- subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the B4s.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-softwire-lw4over6-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-softwire-lw4over6-00.txt' />
</reference>
<reference anchor='I-D.boucadair-pcp-failure'>
<front>
<title>Analysis of Port Control Protocol (PCP) Failure Scenarios</title>
<author initials='M' surname='Boucadair' fullname='Mohamed Boucadair'>
<organization />
</author>
<author initials='R' surname='Penno' fullname='Reinaldo Penno'>
<organization />
</author>
<date month='May' day='16' year='2013' />
<abstract><t>This document identifies and analyzes several PCP failure scenarios. Identifying these failure scenarios is useful to assess the efficiency of the protocol and also to decide whether new PCP extensions are needed.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-boucadair-pcp-failure-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-boucadair-pcp-failure-06.txt' />
</reference>
<reference anchor='RFC6888'>
<front>
<title>Common Requirements for Carrier-Grade NATs (CGNs)</title>
<author initials='S.' surname='Perreault' fullname='S. Perreault'>
<organization /></author>
<author initials='I.' surname='Yamagata' fullname='I. Yamagata'>
<organization /></author>
<author initials='S.' surname='Miyakawa' fullname='S. Miyakawa'>
<organization /></author>
<author initials='A.' surname='Nakagawa' fullname='A. Nakagawa'>
<organization /></author>
<author initials='H.' surname='Ashida' fullname='H. Ashida'>
<organization /></author>
<date year='2013' month='April' />
<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 type='TXT' octets='32484' target='http://www.rfc-editor.org/rfc/rfc6888.txt' />
</reference>
<reference anchor='RFC3261'>
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='G.' surname='Camarillo' fullname='G. Camarillo'>
<organization /></author>
<author initials='A.' surname='Johnston' fullname='A. Johnston'>
<organization /></author>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'>
<organization /></author>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='E.' surname='Schooler' fullname='E. Schooler'>
<organization /></author>
<date year='2002' month='June' />
<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 type='TXT' octets='647976' target='http://www.rfc-editor.org/rfc/rfc3261.txt' />
</reference>
<reference anchor='RFC3550'>
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='S.' surname='Casner' fullname='S. Casner'>
<organization /></author>
<author initials='R.' surname='Frederick' fullname='R. Frederick'>
<organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'>
<organization /></author>
<date year='2003' month='July' />
<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 type='TXT' octets='259985' target='http://www.rfc-editor.org/rfc/rfc3550.txt' />
<format type='PS' octets='630740' target='http://www.rfc-editor.org/rfc/rfc3550.ps' />
<format type='PDF' octets='504117' target='http://www.rfc-editor.org/rfc/rfc3550.pdf' />
</reference>
<reference anchor='I-D.cheshire-recursive-pcp'>
<front>
<title>Recursive PCP</title>
<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'>
<organization />
</author>
<date month='March' day='10' year='2013' />
<abstract><t>The Port Control Protocol (PCP) allows clients to request explicit dynamic inbound and outbound port mappings in their closest on-path NAT, firewall, or other middlebox. However, in today's world, there may be more than one NAT on the path between a client and the public Internet. This document describes how the closest on-path middlebox generates a corresponding upstream PCP request to the next closest on-path middlebox, to request an appropriate explicit dynamic port mapping in that middlebox too. Applied recursively, this generates the necessary chain of port mappings in any number of middleboxes on the path between the client and the public Internet.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-cheshire-recursive-pcp-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-cheshire-recursive-pcp-02.txt' />
</reference>
<reference anchor='I-D.tsou-stateless-nat44'>
<front>
<title>Stateless IPv4 Network Address Translation</title>
<author initials='T' surname='Tsou' fullname='Tina Tsou'>
<organization />
</author>
<author initials='W' surname='Liu' fullname='Will Liu'>
<organization />
</author>
<author initials='S' surname='Perreault' fullname='Simon Perreault'>
<organization />
</author>
<author initials='R' surname='Penno' fullname='Reinaldo Penno'>
<organization />
</author>
<author initials='M' surname='Chen' fullname='Maoke Chen'>
<organization />
</author>
<date month='October' day='22' year='2012' />
<abstract><t>This memo describes a protocol for decentralizing IPv4 NAT to the customer-premises equipment (CPE) such that no state information is kept on the central NAT device. The CPE uses a restricted source port set that is encoded in its provisioned IPv4 WAN address. The NAT device performs only strictly stateless address (not port) translation.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-tsou-stateless-nat44-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-tsou-stateless-nat44-02.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:50:41 |