One document matched: draft-lowekamp-mmusic-ice-tcp-framework-00.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1928 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1928.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3089 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3089.xml'>
<!ENTITY rfc3103 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3103.xml'>
<!ENTITY rfc4250 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4250.xml'>
<!ENTITY rfc4251 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml'>
<!ENTITY rfc4252 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4252.xml'>
<!ENTITY rfc4253 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4253.xml'>
<!ENTITY rfc4254 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4254.xml'>
<!ENTITY rfc4380 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml'>
<!ENTITY rfc4540 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4540.xml'>
<!ENTITY rfc5190 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5190.xml'>
<!ENTITY draft-ietf-behave-rfc3489bis PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-rfc3489bis-16.xml'>
<!ENTITY draft-ietf-mmusic-ice PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mmusic-ice-19.xml'>
<!ENTITY draft-ietf-mmusic-ice-tcp PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mmusic-ice-tcp-07.xml'>
<!ENTITY draft-ietf-behave-turn-tcp PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-turn-tcp-00.xml'>
<!ENTITY draft-denis-udp-transport PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-denis-udp-transport-00.xml'>
<!ENTITY draft-cheshire-nat-pmp PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-cheshire-nat-pmp-03.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc category="std" ipr="full3978" docName="draft-lowekamp-mmusic-ice-tcp-framework-00">
<front>
<title abbrev="ICE-TCP as a Framework">
A Proposal to Define Interactive Connectivity Establishment
for the Transport Control Protocol (ICE-TCP) as an Extensible Framework
</title>
<author initials="A. B." surname="Roach" fullname="Adam Roach">
<organization>Tekelec</organization>
<address>
<postal>
<street>17210 Campbell Rd.</street>
<street>Suite 250</street>
<city>Dallas</city> <region>TX</region> <code>75252</code>
<country>US</country>
</postal>
<email>adam@nostrum.com</email>
</address>
</author>
<author fullname="Bruce B. Lowekamp" initials="B. B." surname="Lowekamp">
<organization>SIPeerior Technologies</organization>
<address>
<postal>
<street>5251-18 John Tyler Highway #330</street>
<city>Williamsburg</city>
<region>VA</region>
<code>23185</code>
<country>USA</country>
</postal>
<phone>+1 757 565 0101</phone>
<email>bbl@lowekamp.net</email>
</address>
</author>
<date month="October" day="23" year="2008" />
<area>Real Time Applications and Infrastructure</area>
<workgroup>MMUSIC WG</workgroup>
<abstract>
<t>
The ICE-TCP mechanism is currently regarded as of limited
usefulness due to the low success rate of TCP simultaneous open
for NAT traversal. This document presents a vision of the
ICE-TCP document as an extensible framework for negotiating a
variety of approaches for establishing a TCP connection between
NATed hosts. This document further proposes significantly
extending the current set of collection mechanisms to encompass
a wide variety of technologies that are currently available,
including UPnP, SOCKS, and Teredo. Because several of these
technologies are already widely deployed, the direct connection
rate should be significantly higher than using straight TCP
alone. We envision that as future TCP connection establishment
techniques are developed, they too will specify an ICE encoding
that will allow their negotiation.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The ICE-TCP document <xref target="I-D.ietf-mmusic-ice-tcp" />
currently relies on a closed set of technologies for gathering
candidates. While there is no prohibition on the use of alternate
technologies, ICE-TCP limits its discussion to those technologies
discussed in the base ICE specification
<xref target='I-D.ietf-mmusic-ice' />. Specifically, this
approach discusses the use of host candidates, server reflexive
candidates, and relayed candidates (with a focus on TURN).
</t>
<t>
Unfortunately, this focus has led to the impression that ICE-TCP
must either use relayed candidates or rely on the "simultaneous
open" approach that is known to have a low chance of success.
In fact, both ICE and ICE-TCP can be extended to leverage any of
a myriad of NAT traversal technologies.
</t>
<t>
The most appealing feature of these technologies is that many of
them are already widely deployed. For example:
</t>
<t> </t>
<t>
<list style="hanging">
<t hangText="Teredo:">
Teredo establishes a UDP tunnel for other transport
protocols that is visible to applications on a host as an
IPv6 address. It is included in all current distributions
of Windows and available for Mac OS X, Linux, and most BSD
platforms as a freely installable package.
</t>
<t> </t>
<t hangText="UPnP:">
deployed on the majority of
residential-grade NAT/Firewall devices and allows hosts behind
the NAT to request a publicly accessible TCP port.
</t>
<t> </t>
<t hangText="SOCKS:">
Widely available as a relaying protocol, it has also been
extended to act as a NAT traversal solution in many NATs.
</t>
</list>
</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">RFC
2119</xref>.
</t>
</section>
<section title="Proposal">
<t>
The authors propose that the ICE-TCP document be modified
and expanded to clarify the way that candidates are gathered
and prioritized.
</t>
<section title="Gathering Candidates">
<t>
The current version of ICE-TCP discusses the use
of STUN and TURN for gathering Server Reflexive and Relayed
candidates, respectively. We propose this be written in a
way that clarifies that such candidates can be gathered
via myriad mechanisms, and gives advice on which types
of candidates to gather.
</t>
<t>
To that end, we propose to replace the following text
in section 3.1:
</t>
<t>
<list style='hanging'>
<t>
<vspace blanklines="1" />
Next, the agent SHOULD take all host TCP candidates for
a component that have the same foundation (there will
typically be two - a passive and a simultaneous-open),
and amongst them, pick two arbitrarily. These two host
candidates will be used to obtain relayed and server
reflexive candidates. To do that, the agent initiates
a TCP connection from each candidate to the TURN server
(resulting in two TCP connections). On each connection,
it issues an Allocate request. One of the resulting
relayed candidate is used as a passive relayed candidate,
and the other, as a simultaneous-open relayed candidate.
In addition, the Allocate responses will provide the
agent with a server reflexive candidate for their
corresponding host candidate.
</t>
<t>
<vspace blanklines="1" />
For all of the remaining host candidates, if any, the
agent only needs to obtain server reflexive candidates.
To do that, it initiates a TCP connection from each
host candidate to a STUN server, and uses a Binding
request over that connection to learn the server reflexive
candidate corresponding to that host candidate.
</t>
<t>
<vspace blanklines="1" />
Once the Allocate or Binding request has completed, the
agent MUST keep the TCP connection open until ICE processing
has completed. See Section 1 for important implementation
guidelines.
</t>
</list>
</t>
<t>
With:
</t>
<list style='hanging'>
<t>
<vspace blanklines="1" />
Next, the agent SHOULD take all host TCP candidates for
a component that have the same foundation (there will
typically be two - a passive and a simultaneous-open),
and amongst them, pick two arbitrarily. These two host
candidates will be used to obtain two
Relayed Candidates (see <xref target='relayed-candidates' />).
<t>
</t>
<vspace blanklines="1" />
The agent should then obtain one or more non-relayed NAT
candidates (see <xref target='nat-candidates' />).
The mechanisms for establishing such candidates and the
number of candidates to collect vary from
technique to technique. These considerations are discussed
in the relevant sections, below.
</t>
<t>
<vspace blanklines="1" />
Once the relayed candidates and non-relayed NAT candidates
have been prepared, the agent MUST keep the TCP connection
open until ICE processing has completed. See Section 1 for
important implementation guidelines.
</t>
</list>
<t>
(Note that, in the preceding text, references to
<xref target='relayed-candidates' /> and
<xref target='nat-candidates' /> refer to sections in this
document, not to sections in draft-ietf-mmusic-ice-tcp.)
</t>
</section>
<section title="Prioritization">
<t>
The current prioritization scheme defined in ICE-TCP
favors simultaneous-open candidates over active and
passive candidates. This prioritization is presumably
based on the prospect that non-relayed connections
are the exclusive domain of STUN-discovered Server
Reflexive Candidates. Such candidates necessarily
rely on "fooling" the NAT into allowing TCP connections
through; and one might assume that simultaneous open
has a higher chance of succeeding in doing so.
</t>
<t>
Empirical evidence on the simultaneous open technique
described in ICE-TCP has shown that, while it has a
relatively high chance of establishing the proper state
in a NAT, it suffers from a high failure rate on the
actual endpoints.
</t>
<t>
Several NAT traversal techniques, both deployed and proposed,
provide means for discovering NAT-allocated address/port
combinations in such a way that the NAT is actively
participating in the TCP establishment effort instead of
impeding it. Others leverage the behavior of UDP binding in
NATs to carry TCP traffic over UDP. In such cases, normal
active and passive candidates actually have a higher chance of
success than simultaneous-open candidates.
</t>
<t>
To reflect this reality, we propose that the prioritization
scheme for ICE-TCP be revised. Specifically, we propose to
replace the following text in section 3.2:
</t>
<list style='hanging'>
<t>
<vspace blanklines="1" />
It is RECOMMENDED that, for all connection-oriented media,
simultaneous-open candidates have a direction-pref of 7,
active of 5 and passive of 2.
</t>
</list>
<t>
With:
</t>
<list style='hanging'>
<t>
<vspace blanklines="1" />
It is RECOMMENDED that, for all connection-oriented media,
candidates have a direction-pref assigned as follows:
</t>
<list style='hanging'>
<t><vspace blanklines="1" /></t>
<t hangText='7'>NAT-Assisted Active Candidate</t>
<t hangText='6'>NAT-Assisted Passive Candidate</t>
<t hangText='5'>UDP-Tunneled Active Candidate</t>
<t hangText='4'>UDP-Tunneled Passive Candidate</t>
<t hangText='3'>Simultaneous Open Candidate</t>
<t hangText='2'>Non-NAT-Assisted Active Candidate</t>
<t hangText='1'>Non-NAT-Assisted Passive Candidate</t>
</list>
<t>
It is RECOMMENDED that the type preference for NAT-Assisted
candidates be set higher than that for server-reflexive
candidates and that the type preference for UDP-Tunneled
candidates be set lower than that for server-reflexive
candidates. The RECOMMENDED values are 105 for NAT-Assisted
candidates and 75 for UDP-Tunneled candidates.
</t>
<t>
TODO: The same information probably doesn't need to be
encoded in both the type-pref and direction-pref. More work
is needed to iron out how to represent appropriate
priorities.
</t>
</list>
</section>
</section>
<section title="Initial Set of Candidate Collection Technologies"
anchor='set'>
<t>
(The authors propose that the entirety of this
<xref target='set'/> and its subsections, with the exception
of this parenthetical paragraph, be included in ICE-TCP.)
</t>
<t>
The following sections discuss a number of techniques that can
be used to obtain candidates for use with ICE-TCP. It is
critical to note that this list is not intended to be exhaustive,
nor is implementation of any specific technique considered
mandatory. Implementors are encouraged to implement as many
of the following techniques from the following list as is
practical, as well as to explore additional NAT-traversal
techniques beyond those discussed in this document.
</t>
<section title="Host Candidates">
<t>
For each TCP capable media stream the agent wishes to use
(including ones, like RTP, which can either be UDP or TCP),
the agent SHOULD obtain two host candidates (each on a
different port) for each component of the media stream on
each interface that the host has - one for the simultaneous
open, and one for the passive candidate. If an agent is
not capable of acting in one of these modes it would omit
those candidates.
</t>
<t>
For maximum interoperability with the techniques described
below, implementors should take particular care to include
both IPv4 and IPv6 candidates as part of the process of
gathering candidates. If the local network or host does not
support IPv6 addressing, then clients SHOULD make use of
Teredo (<xref target='teredo'/>) or SOCKS IPv4-IPv6 Gatewaying
(<xref target='socks-ipv6'/>).
</t>
</section>
<section title="Non-Relayed NAT Candidates" anchor="nat-candidates">
<t>
The following techniques can be used to gather
candidates that represent NAT traversal, while
not going through any additional relays.
This includes Server Reflexive Candidates (non-NAT-assisted),
candidates established in cooperation with
the NAT (NAT-assisted), and candidates tunnel TCP over UDP
to leverage widespread NAT UDP binding behavior (UDP-tunneling).
</t>
<t>
Generally, when several options are available, clients
should favor NAT-assisted techniques over UDP-tunneling
techniques, and UDP-tunneling techniques over non-NAT-assisted
techniques.
</t>
<section title="NAT-Assisted">
<t>
To traverse NATs, the best approach is to work with the NATs
themselves, rather than trying to "game" their behavior
with tricks and relays. To that end, clients behind
NATs should favor approaches that work with NATs whenever
possible.
</t>
<t>
Because these techniques interact with the NAT directly to
acquire a publicly accessible transport address, once
obtained these candidates are encoded as normally TCP
candidates (typically tcp-pass) as specified in
Section 3.4 of ICE-TCP.
</t>
<section title="UPnP IGD">
<t>
The UPnP forum's Internet Gateway Device (IGD)
protocol <xref target="UPnP-IGD" /> is designed
to facilitate client configuration of NAT port
forwarding behavior. IGD is deployed on a majority
of residential-grade NAT/Firewall devices, and is
available for Linux- and FreeBSD-based firewalls.
</t>
<t>
Clients wishing to use IGD-obtained
addresses as candidates do so by retrieving
the ExternalIPAddress state variable; then, they use
the AddPortMapping command to establish a new TCP
binding at the NAT. The client is responsible for establishing
the binding so that it corresponds to a Host Candidate,
and for periodically refreshing the port mapping to
keep the lease from expiring. When the IGD-acquired
candidate is no longer necessary, the client SHOULD
remove the binding with a DeletePortMapping command.
</t>
</section>
<section title="MIDCOM SNMP">
<t>
The MIDCOM MIB <xref target="RFC5190" /> defines
an SNMP-based mechanism for controlling NATs, Firewalls,
and other middleboxes.
</t>
<t>
TODO: add application notes about how to obtain candidates
</t>
</section>
<section title="SOCKS">
<t>
Although originally designed as a relaying protocol, SOCKS
<xref target="RFC1928" /> has been incorporated in a number
of NATs as a NAT-assisted traversal technique. The approach
for using SOCKS for NAT-assisted traversal is identical to
that for using it as a relay protocol (see <xref target="socks" />).
</t>
<t>
If the ICE agent is aware that SOCKS is being used as a
NAT-assisted protocol instead of a relay protocol, it
SHOULD set the local-preference accordingly.
</t>
</section>
<section title="RSIP">
<t>
The Realm Specific IP (RSIP) protocol <xref target="RFC3103" />
is an experimental protocol designed to allow clients within
a realm to communicate with gateways on the edge of that
realm so as to lease globally-visible resources on those gateways.
</t>
<t>
TODO: add application notes about how to obtain candidates
</t>
<t>
TODO: examine RSIP as a v4/v6 bridging technology
</t>
</section>
<section title="SIMCO">
<t>
The SIMCO protocol <xref target="RFC4540" />
an experimental mechanism for controlling NATs, Firewalls,
and other middleboxes.
</t>
<t>
TODO: add application notes about how to obtain candidates
</t>
</section>
<section title="NAT-PMP">
<t>
The NAT Port Mapping Protocol (PMP)
<xref target="I-D.cheshire-nat-pmp" /> is designed to
allow clients to determine the external IP address of
a NAT, learn about any changes in that IP address, and
create and refresh UDP and TCP bindings on the NAT.
NAT-PMP is currently supported in a number of
field-deployed products, such as the Apple Airport
Express, Apple Airport Extreme, and Apple Time Capsule,
as well as a large number of primarily peer-to-peer
software applications.
</t>
<t>
Clients wishing to use PMP-obtained
addresses as candidates do so by retrieving
the external IP address, using the PMP opcode 0;
then, they use
the PMP opcode 2 to establish a new TCP
binding at the NAT. The client is responsible for establishing
the binding so that it corresponds to a Host Candidate,
and for periodically refreshing the port mapping to
keep the lease from expiring. When the PMP-obtained
candidate is no longer necessary, the client SHOULD
remove the binding with a PMP opcode 2 with the port
mapping lifetime set to 0.
</t>
</section>
</section>
<section title="UDP Tunneled">
<section title="Teredo" anchor='teredo'>
<t>
The Teredo protocol <xref target="RFC4380" />
defines a system allow nodes behind one or more
NATs to obtain IPv6 addresses by tunneling IPv6 over
UDP. Teredo it included in all modern Windows
operating systems by default, and is available
for most other major operating systems, such as
Linux, OS X, and *BSD.
</t>
<t>
Teredo essentially provides a UDP tunnel for other
transport protocols that is visible to the host
application as an IPv6 address. Therefore, Teredo
candidates are encoded as IPv6 addresses in the SDP.
</t>
<t>
The Teredo framework includes provisions for routing
between Teredo IPv6 addresses and native IPv6 addresses;
therefore, the efficacy of Teredo tunneling will be
significantly improved for each ICE-TCP implementation
that advertises at least one globally-routable IPv6
address candidate (whether Teredo, SOCKS tunneled,
6-to-4 relayed, IPv6 tunneled, or native).
</t>
<t>
TODO: add application notes about how to obtain candidates
<!--
Here's the description I posted to BEHAVE; it needs cleaning up
to be used in the draft:
After Rémi pointed out Teredo, I did a little bit of digging, and
it looks just about ideal for solving this problem. Here's the
high-level view of how it would work:
During ICE candidate gathering, the client would collect its
Teredo address. This might be a long-standing Teredo address that
the machine has lying around, or it could be one that the client
causes to become active during candidate gathering.
For background; when a Teredo client starts up, it sends something
very similar to a STUN packet to its configured Teredo server,
and finds out its local address. So, for example, using the Teredo
address that my laptop just pulled up... I have a provisioned
Teredo server of 130.129.19.226; and the IP/port that it told me
I'm sending from is 130.129.19.226:55419. My machine takes this
information an synthesizes an IPv6 address of
2001::53aa:64c:0:2784:7d7e:ec1d. Here's what that means:
2001:: - Teredo Prefix
53aa:64c: - 130.129.19.226 (my Teredo server)
0: - Flags (0 = no NAT)
2784: - XORed port; 2784 xor FFFF = 55419
7d7e:ec1d - XORed IP addr; 7D7EEC1D xor FFFF = 130.129.19.226
So, my ICE client takes this IPv6 address
(2001::53aa:64c:0:2784:7d7e:ec1d) and adds it to the candidate
list, with a priority somewhere between a NATted address and a
relayed address.
During candidate gathering, the other side does the same thing,
and gives me its Teredo-generated address (in this example, we'll
say the address is 2001::53aa:64c:308c:7996:b906:6402)
Now, when my client goes to send to the other client, it will try
sending to 2001::53aa:64c:308c:7996:b906:6402. The Teredo layer
extracts the "7996:b906:6402" from this, converts it into the IP
address and port of the remote Teredo layer (70.249.155.253:34409),
and sends the Teredo-encapsulated IPv6 packet to that UDP port.
As long as the remote host isn't behind a symmetric NAT, that UDP
packet gets through, hits the remote Teredo layer, gets unencapsulated,
and is presented to that client as a normal "just arrived over
an IPv6 interface" packet. With *my* Teredo address as the source.
And data going in the other direction simply reverses this entire
process.
So, we basically have a free-and-clear IP channel at this point
between the clients. We can send TCP, UDP, SCTP, DCCP, ICMP, IKE,
ESP, whatever the heck we *want* over this channel.
And this all just *works* for Windows by default, an for OS X,
Linux, and most BSDs by installing a freely-available package.
It's out there. I'm using it. It's dirt simple. It's deployed.
There are also some really, *really* neat implications when you
consider interworking Teredo with real IPv6 clients on real IPv6
networks, but I don't want to muddy the waters with all that
niftiness until people understand how Teredo solves the issue
with hosts that are attached with only IPv4.
-->
</t>
</section>
<section title="TCP over UDP">
<t>
TODO: Describe TCP/UDP/IP, as defined in <xref target="I-D.denis-udp-transport" />.
</t>
<t>
TODO: add application notes about how to obtain candidates;
need to include discussion of SDP extensions necessary to
specify encoding for TCP over UDP.
</t>
</section>
</section>
<section title="Non-NAT-Assisted">
<section title="STUN">
<t>
TODO: Describe STUN, as defined in <xref target="I-D.ietf-behave-rfc3489bis" />.
</t>
<t>
To obtain STUN server reflexive candidates, the agent
initiates a TCP connection from two
host candidates to a STUN server, and uses a Binding
request over that connection to learn the server reflexive
candidate corresponding to that host candidate.
</t>
</section>
</section>
</section>
<section title="Relayed Candidates" anchor='relayed-candidates'>
<section title="SOCKS" anchor='socks'>
<t>
TODO: Describe SOCKS, as defined in <xref target="RFC1928" />
</t>
<t>
TODO: add application notes about how to obtain candidates
</t>
</section>
<section title="SOCKS IPv4-IPv6 Gateway" anchor='socks-ipv6'>
<t>
TODO: Describe IPv4/IPv6 bridging technique described in <xref target="RFC3089" />
</t>
<t>
TODO: add application notes about how to obtain candidates
</t>
</section>
<section title="SSH Tunnels">
<t>
TODO: Describe SSH Tunneling technique described in
<xref target="RFC4250" />
<xref target="RFC4251" />
<xref target="RFC4252" />
<xref target="RFC4253" />
<xref target="RFC4254" />
</t>
<t>
TODO: add application notes about how to obtain candidates
</t>
</section>
<section title="TURN TCP">
<t>
TODO: Describe TURN TCP protocol described in <xref target="I-D.ietf-behave-turn-tcp" />
</t>
<t>
To acquire TURN TCP candidates, the agent initiates
a TCP connection from two host candidates to the TURN server
(resulting in two TCP connections). On each connection,
it issues an Allocate request. One of the resulting
relayed candidate is used as a passive relayed candidate,
and the other, as a simultaneous-open relayed candidate.
In addition, the Allocate responses will provide the
agent with a server reflexive candidate for their
corresponding host candidate.
</t>
</section>
</section>
</section>
</middle>
<back>
<references title='References'>
&rfc1928;
&rfc2119;
&rfc3089;
&rfc3103;
&rfc4250;
&rfc4251;
&rfc4252;
&rfc4253;
&rfc4254;
&rfc4380;
&rfc4540;
&rfc5190;
&draft-ietf-behave-rfc3489bis;
&draft-ietf-mmusic-ice;
&draft-ietf-mmusic-ice-tcp;
&draft-ietf-behave-turn-tcp;
&draft-denis-udp-transport;
&draft-cheshire-nat-pmp;
<reference anchor='UPnP-IGD'>
<front>
<title>Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0</title>
<date month='November' year='2001' />
<author initials='U.' surname='Warrier' />
<author initials='P.' surname='Iyer' />
<author initials='F.' surname='Pennerath' />
<author initials='G.' surname='Marynissen' />
<author initials='M.' surname='Schmitz' />
<author initials='W.' surname='Siddiqi' />
<author initials='M.' surname='Blaszczak' />
</front>
<format type='ZIP' octets='1480572' target='http://www.upnp.org/standardizeddcps/documents/UPnP_IGD_1.0.zip' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:10:28 |