One document matched: draft-wing-pcp-proposed-packet-format-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="info" docName="draft-wing-pcp-proposed-packet-format-00"
ipr="trust200902">
<front>
<title abbrev="Proposed PCP Packet Format">Proposed PCP Packet
Format</title>
<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>
<!--
<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="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>
-->
<date />
<workgroup>PCP Working Group</workgroup>
<abstract>
<t>A proposed packet format for PCP.</t>
<t>This document is for discussion purposes. It is not intended
to be published as an RFC.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t><xref target="I-D.cheshire-nat-pmp">NAT-PMP</xref> is a lightweight,
UDP-based request/response protocol that forms a good basis to obtain
mappings from a NAT. This document proposes a packet format, based
on NAT-PMP, which provides the necessary extensions and support
for PCP.</t>
<t>This document is for discussion purposes. It is not intended to
be published as an RFC.</t>
</section>
<section title="Request and Response Packet Format">
<t>The request and response packet formats take the same space and
layout. It is intended to be backwards compatible with NAT-PMP, so
that if a PCP message is sent to a NAT-PMP server it will be rejected
with an error code we can parse. The PCP request uses Version=1,
which if processed by a NAT-PMP server will cause a version conflict
(the NAT-PMP server will see this as NAT-PMP version 16) and an error
returned in the same place we're looking for it (last couple of bits
of the 4th byte).</t>
<section title="Request">
<figure align="center" anchor="request"
title="Request Packet Format">
<preamble></preamble>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=1 |reserve| OpCode | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Internal IP address (32 or 128) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Requested external IP address (32 or 128) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | requested external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Informational Elements :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The Informational Elements (IE) allow extending PCP, without
defining a new PCP version and without consuming additional opcodes.
They can be used in requests and responses, and are defined in
documents specific to each IE. An IANA registry will be created for
IEs. IEs are useful in a request when additional information is being
specified in the request. Examples that have been discussed, which
might be standardized in the future, include mapping DSCP bits,
indicating which interface is requested for a mapping on a
multi-interface NAT (e.g., internal corporate network address versus
an Internet-facing address). IEs will use a Type-Length-Value format.
IEs that aren't understood by the server are ignored.</t>
<figure anchor="opcode"
title="Opcode format">
<preamble>the Opcode has the following format:</preamble>
<artwork align="center"><![CDATA[
+-+-+-+-+-+-+-+-+
|P|0|0|I|E|proto|
+-+-+-+-+-+-+-+-+
P=Request=0, Response=1
two zero bits
I, Internal address: 0=IPv4, 1=IPv6
E, External address: 0=IPv4, 1=IPv6
proto: 1=UDP, 2=TCP, 0=all (used only for delete)
which yields the following values:
1 = NAT44 or IPv4 firewall, UDP
2 = NAT44 or IPv4 firewall, TCP
9 = NAT46, UDP
10 = NAT46, TCP
17 = NAT64, UDP
18 = NAT64, TCP
25 = IPv6 firewall, UDP
26 = IPv6 firewall, TCP
]]></artwork>
</figure>
</section>
<section title="Response">
<figure align="center" anchor="response"
title="Response Packet Format">
<preamble></preamble>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver=1 |reserve| Opcode+128 | Reserved | Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Internal IP address (32 or 128) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Assigned external IP address (32 or 128) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assigned lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| internal port | assigned external port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (optional) Informational Elements :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
</section>
<section title="NAT-PMP Backwards Compatibility">
<t>Because NAT-PMP and PCP share the same port, it is important that a
NAT-PMP client receive a NAT-PMP error message. This is done by
examining the version number of the incoming PCP message; if it is
zero, the message is from a NAT-PMP client. A valid NAT-PMP response
(rather than a PCP response) is necessary, shown below.</t>
<t>A server which supports both NAT-PMP and PCP would be
able to process both NAT-PMP and PCP requests normally,
and (if necessary) proxy between the protocols.</t>
<figure align="center" anchor="nat-pmp-response"
title="NAT-PMP response">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | OP = 128 + x | Result Code=1 (unsupp. vers.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 0 (96 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>TBD.</t>
</section>
<!--
<section title="Acknowledgments">
<t>Thanks to Francis Dupont, Alain Durand, and Christian Jacquenet for
their comments and review.</t>
</section>
-->
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.I-D.cheshire-nat-pmp'?>
</references>
<!--
<references title="Informative References">
<?rfc include='reference.I-D.nishitani-cgn'?>
<reference anchor="UPnP-IGD"
target="http://www.upnp.org/standardizeddcps/igd.asp">
<front>
<title>Universal Plug and Play Internet Gateway Device</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date year="2000" />
</front>
</reference>
</references>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:25:03 |