One document matched: draft-matthews-p2psip-id-loc-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" docName="draft-matthews-p2psip-id-loc-00" ipr="full3978">
<front>
<title abbrev="ID/Loc">An ID/Locator Architecture for P2PSIP</title>
<author fullname="Eric Cooper" initials="E." surname="Cooper">
<organization>Avaya</organization>
<address>
<postal>
<street>1135 Innovation Drive</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K2K 3G7</code>
<country>Canada</country>
</postal>
<phone>+1 613 592 4343 x228</phone>
<email>ecooper@avaya.com</email>
</address>
</author>
<author fullname="Alan Johnston" initials="A." surname="Johnston">
<organization>Avaya</organization>
<address>
<postal>
<street></street>
<city>St. Louis</city>
<region>MO</region>
<code>63124</code>
<country>USA</country>
</postal>
<email>alan@sipstation.com</email>
</address>
</author>
<author fullname="Philip Matthews" initials="P." surname="Matthews">
<organization>Avaya</organization>
<address>
<postal>
<street>100 Innovation Drive</street>
<city>Ottawa</city>
<region>Ontario</region>
<code>K2K 3G7</code>
<country>Canada</country>
</postal>
<phone>+1 613 592 4343 x224</phone>
<email>philip_matthews@magma.ca</email>
</address>
</author>
<date day="11" month="November" year="2007" />
<area>Real-Time Applications Infrastructure Area</area>
<workgroup>P2PSIP Working Group</workgroup>
<abstract>
<t>This document describes an architecture where peers in an overlay use
special IP addresses to identify other peers. Two of the advantages of
this approach are that (a) most existing applications can run in an
overlay without needing any changes and (b) peer mobility and NAT
traversal are handled in a way that is transparent to most
applications.</t>
</abstract>
<note title="Terminology">
<t>Descriptions of the basic concepts and terminology used in this
document can be found in the P2PSIP Concepts and Terminology document
<xref target="Concepts"></xref>.</t>
<!-- **** Commented out for now. ***
<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>
*** End commented out portion. **** -->
</note>
</front>
<middle>
<section title="Introduction">
<t>This document describes an architecture where nodes use IP addresses
drawn from a special range to uniquely identify other peers and clients
in the overlay. These IP addresses, called "identifiers" in the rest of
this document, are drawn from a special address range and are thus
distinct from the actual IP addresses assigned to peers and clients.
These identifiers are used by the application and the
application’s transport protocol (e.g., TCP or UDP) in place of a
peer’s real address. These identifiers are distinguishable from
real addresses (because they are drawn from a special range), but most
applications do not know or care about the difference.</t>
<t>Using IP addresses as identifiers in this manner brings the following
advantages:<list style="symbols">
<t>The identifiers are stable and unique.</t>
<t>The identifiers can be used in the Socket API without
changes.</t>
<t>Applications do not need to worry about NAT traversal, mobility,
or multi-homing.</t>
<t>Most applications do not need to be aware that they are running
in an overlay. Only applications that want to take advantage of the
special properties that the overlay provides need to be aware.</t>
</list></t>
<t>To implement this architecture, the identifiers are intercepted
(using one of a variety of implementation techniques) just below the
transport layer and replaced with a real address before the packet is
sent. The mapping of an identifier to the associated real address is
handled the Peer Protocol <xref target="Concepts"></xref>. For peers and
clients behind NATs, this application uses the ICE protocol <xref
target="ICE"></xref> to establish connections through the NATs. This
application also handles case where a peer changes its real address for
mobility or multi-homing reasons.</t>
<t>Applications learn these identifiers in various ways. Applications
that use the distributed database function in the overlay receive
identifiers rather than real addresses as responses to queries.
Applications that use the gethostbyname() function are returned
identifiers rather than real addresses when the destination is known to
be in the overlay. And applications may learn identifiers from other
applications.</t>
<t>This approach can be compared with the approach taken by most of the
other proposals in P2PSIP (e.g., RELOAD, ASP, P2PP, and XPP/PCAN). In
these proposals, peers are identified with bitstrings that do not look
like addresses, forcing applications that want to run in an overlay to
use a new (as yet unspecified) API, rather than the existing Socket API.
Furthermore, though these proposals handle NAT traversal for the Peer
protocol, they do not handle NAT traversal for applications, forcing
each application to invent its own ICE variation. None of these
proposals currently consider mobility at all. All of this means that any
application that wants to run in an overlay requires significant
modification.</t>
<t>The exceptions to the problems described in the previous paragraph
are the two P2PSIP proposals based on HIP: HIP-HOP <xref
target="HIP-HOP"></xref> and WITH-HIP <xref target="WITH-HIP"></xref>.
Both of these proposals include the id/location split concept, and thus
share the advantages of this concept.</t>
<t>This proposal takes the features of HIP that the authors feel are
most beneficial to P2PSIP, while leaving for further investigation the
possible adoption of other HIP features (as proposed in HIP-HOP and
WITH-HIP). More details on the relationship of this work to HIP is given
in <xref target="Relationship-to-HIP"></xref>.</t>
</section>
<section title="Details">
<t>Figure X shows the conceptual relationship between the parts
discussed in this section.</t>
<figure>
<artwork align="center"><![CDATA[ _______________ _______________
| | |
| Peer Protocol | SIP | Other Apps ...
|_______________|_______________|_________________
| |
| TCP, UDP, etc |
|_________________________________________________|
| |
| Shim layer |
|_________________________________________________|
| |
| IP (v4 or v6) |
|_________________________________________________|
]]></artwork>
</figure>
<t>In this architecture, the Peer Protocol is responsible for creating
the mapping between identifiers and real addresses, while the Shim layer
is responsible for doing the translation on a packet-by-packet basis as
well as adding any necessary encapsulation. More details on these roles
can be found below.</t>
<section title="Identifiers">
<t>Identifiers are IPv4 or IPv6 addresses selected from a special
range in the IPv4 or IPv6 space respectively. For IPv4, this is the
TBD range; for IPv6, this is the TBD range.</t>
<t>These identifiers can be freely intermixed with ordinary
(“real”) addresses. Applications are free to use
identifiers to talk with application on other nodes in the overlay,
and real addresses to talk with applications off the overlay.</t>
<t><list>
<t>OPEN ISSUE: For IPv6, getting a range of addresses should be
quite do-able. HIP is currently using the ORCHID space, and this
may well be a reasonable choice for this architecture.</t>
<t>But is it realistic to assume that we will be able to get a
range of IPv4 addresses to use for this purpose? HIP
implementations currently use the 1/8 range (which is marked as
"reserved" by IANA) which has 2^24 addresses available in it. If
IPv4 identifiers just have local scope, then 2^24 is probably more
than required, and a /14 or /16 is probably quite sufficient.</t>
</list></t>
<t><list>
<t>OPEN ISSUE: What is the scope of this identifier (e.g., local
node only, overlay-wide, or global)? The IPv4 identifiers probably
have to be local, since are not enough to be global and maybe not
enough to be overlay-wide. The IPv6 identifiers could be global
(and be either identical to, or similar to, HIP’s Host
Identity Tags (HITs)) or they could be just overlay-wide, however,
either would introduce a difference between the IPv4 and IPv6
identifiers which might be undesirable.</t>
</list><list>
<t>OPEN ISSUE: Is this identifier the same as a peer id <xref
target="Concepts"></xref>? In the case of IPv4 identifiers, it
seems pretty clear that the answer is “no”, because
the space of IPv4 identifiers simply isn’t large enough. For
IPv6, the space is likely large enough, but there are difficulties
if the identifier is both globally scoped and is a peer id.</t>
</list></t>
</section>
<section title="Peer Protocol">
<t>The job of the Peer Protocol in this architecture is (in addition
to its other duties of managing the overlay and implementing the
Distributed Database <xref target="Concepts"></xref>) to establish
connections between peers and to manage the mappings between
identifiers and real addresses. To do this, the Peer Protocol does an
ICE exchange with the destination peer to negotiate a set of addresses
and ports to use for the data traffic.</t>
<t>The stimulus for doing this ICE exchange is an indication from the
Shim layer saying that is has no set of real addresses to use for a
given destination identifier (cf. an ARP cache miss). The Peer
Protocol then does an ICE exchange with the destination peer, routing
the Offer/Answer though other peers in the overlay. Once the exchange
has completed, the Peer Protocol installs the appropriate mapping
entry into the Shim layer.</t>
</section>
<section title="Shim Layer">
<t>The shim layer is a new layer introduced between the IP layer and
the transport layer. It has two functions: translating identifiers
to/from real addresses, and adding any necessary encapsulation.</t>
<t>There are two forms of encapsulation: null encapsulation and
outer-UDP encapsulation. </t>
<figure>
<artwork align="center"><![CDATA[ _____________________________ ___________________________
| | | |
| Application data | | Application data |
|_____________________________| |___________________________|
| | | |
| Transport (TCP or UDP only) | | Transport header |
|_____________________________| |___________________________|
| | | |
| Demux header | | IP header (v4 or v6) |
|_____________________________| |___________________________|
| |
| UDP header | Null Encapsulation
|_____________________________|
| |
| IP header (v4 or v6) |
|_____________________________|
Outer-UDP Encapsulation
]]></artwork>
</figure>
<figure>
<preamble>The Demux header looks like:</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Here the protocol field indicates which transport (or other)
protocol follows, and uses the same codepoints as used for the
‘protocol’ field in the IPv4/IPv6 header.</t>
<t>The null encapsulation adds no extra bytes but simply translates
identifiers to real addresses and modifies port numbers as necessary
to traverse NATs. The null encapsulation is very similar to existing
protocol stacks, but requires more work to set up and maintain because
each connection requires its own set of ICE connectivity checks.</t>
<t>By contrast, the Outer-UDP encapsulation adds a UDP header plus a
4-byte demux header between the IP header and the transport header.
The Outer-UDP encapsulation multiplexes all connections between two
given nodes inside a single UDP "pipe". Because intervening NATs see
only the outer UDP header, this encapsulation requires only one ICE
exchange (to set up the outer pipe), regardless of how many
connections there are inside the pipe.</t>
<t> The Outer-UDP encapsulation can be used with all transport
protocols, while the null encapsulation can only be used with UDP and
TCP.</t>
<t>To explain the mapping and encapsulations in more detail, consider
a transport layer PDU is sent from X:x to Y:y, where X is the
identifier of the local host, Y is the identifier of the remote host,
and x and y are the port numbers allocated off of these identifiers.
For both encapsulations, the Peer Protocol will have used ICE to
determine a corresponding set of real addresses and ports.</t>
<t>For the null encapsulation, each transport layer 5-tuple (transport
protocol,X,x,Y,y) will have a corresponding set of real addresses and
ports (X’,x’,Y’,y’). When sending, the port
numbers x and y in the transport header are replaced with x’ and
y’, and an IP header is added containing addresses X’ and
Y’ is added. (TBD: Are the addresses in the transport layer
pseudo-header also replaced?). The reverse replacement is done when
receiving a PDU.</t>
<t>If either X or Y change their real address, then an ICE exchange is
required to determine a new 5-tuple for each connection. For UDP, this
new 5-tuple is simply used in place of the old.</t>
<t><list>
<t>OPEN ISSUE: For TCP, this doesn’t work, since generating
the new 5-tuple requires a new TCP handshake. This seems to imply
that the TCP layer has to be aware of the change in address. So
what do we do? Do we just say “don’t use null
encapsulation for TCP if you want mobility to work”? Or do
we figure out how to make this work?</t>
</list></t>
<t>For the outer-UDP encapsulation, there is a single 5-tuple
(UDP,X’,x’,Y’,y’) for each (X,Y) pair. When
sending, the transport header is not modified, instead a demux header
and a outer UDP header is added. Ports x’ and y’ are
inserted in the outer UDP header, and an IP header containing
addresses X’ and Y’ is added.</t>
<t>Mobility is simpler with the Outer-UDP encapsulation. In this case,
only a single ICE exchange is required, and the new 5-tuple is simply
used in place of the old. There are no TCP concerns in this case,
since the TCP header is never modified.</t>
<t>See <xref target="Implementing"></xref> for a discussion of how to
implement the mapping layer.</t>
</section>
</section>
<section title="Domain Names">
<t>In this section, we briefly describe how the identifier concept might
be extended to tie in with domain names in an attractive way. This idea
is not core to this draft, but helps simplify the example that
follows.</t>
<t>Briefly, the idea is to define a new top-level domain, called
“.p2p”. This domain is reserved for use in peer-to-peer
overlays. An overlay is then given a name underneath this top-level
domain:<list>
<t><overlay-name>.p2p</t>
</list>and individual peers are allocated names underneath the overlay
name:<list>
<t><peer-name>.<overlay-name>.p2p</t>
</list>For example, a peer named “mars” in an overlay
called “solar-system” would have the name:<list>
<t>mars.solar-system.p2p</t>
</list>By storing the mapping between peer names and peer ids in the
Distributed Database, this scheme allows users to use human-friendly
names for peers in place of peer ids or identifiers.</t>
<t>To make this scheme even more powerful, gethostbyname() is modified
to look for domain names ending in “.p2p” and look them up
in the Distributed Database rather than in the DNS. When the resource
record is returned, an identifier is allocated to the peer and that
identifier is returned from gethostbyname(). In that way, the user can
type, for example, “http://mars.solar-system.p2p” into her
web browser to contact a web server running on “mars”.</t>
<t>More details on how this works can be found in the example of the
next section.</t>
</section>
<section title="Example">
<t>In this section, we show a SIP call between two UAs in an
overlay.</t>
<t>This example illustrates how this architecture allows applications to
work in an overlay without being aware of that fact. The two SIP UAs in
this example use standard client-server SIP to communicate, without
needing any SIP extensions.</t>
<t>IMPORTANT NOTE: Without extensions to SIP, there is no way to do an
AOR to contact URI lookup using the Distributed Database. So in this
example, Wilma calls Fred by specifying Fred’s machine name, using
the domain name scheme described in the previous section. With this
caveat, everything works with SIP as it is today.</t>
<t>Figure X shows the call flow for this example.</t>
<figure>
<artwork><![CDATA[Wilma Fred
Venus Earth Mars
| | |
|- DD query for mars.solar-system.p2p ->| |
|<--------------- DD response ----------| |
| | |
|----------- Msg w/ICE Offer ---------->| |
| |----- Msg w/ICE Offer ---->|
| |<---- Msg w/ICE Ans -------|
|<---------- Msg w/ ICE Ans ------------| |
| |
|<=================== ICE Connectivity Checks =====================>|
| |
|<-------------------- TCP and TLS handshake ---------------------->|
| |
|<------------- SIP transaction over TLS connection --------------->|
| |
]]></artwork>
</figure>
<t>This example shows three machines, named “Venus”,
“Earth”, and “Mars” which are part of a larger
overlay named “solar-system.p2p”. Wilma is on Venus, and
Fred is on Mars.</t>
<t>Wilma initiates the call by typing in sips:fred@mars.solar-system.p2p
into her UA. Wilma’s UA does a gethostbyname() call to resolve
“mars.solar-system.p2p” and this is resolved by doing a
Distributed Database lookup. In this example, it turns out that the
corresponding resource record is stored on the machine "Earth". As a
result, an identifier for the peer Mars is returned from the
gethostbyname() call to Wilma’s UA.</t>
<t><list>
<t>NOTE: If identifiers are the same as peer ids, then the peer id
from the resource record is just returned as the identifier.
Otherwise, (which is more likely if Wilma's UA is using IPv4
identifiers) the Peer Protocol allocates an identifier and remembers
that it maps to the machine named "mars.solar-system.p2p" which has
the peer id learned from the response.</t>
</list></t>
<t>Wilma’s UA then issues a connect() to this identifier. This
causes TCP to send a SYN to this identifier. Since there is currently no
direct connection between Venus and Mars, the Shim layer finds no
mapping for this identifier and thus generates an indication to the Peer
Protocol.</t>
<t>The Peer Protocol layer on Venus now does an ICE offer/answer
exchange with the Peer Protocol layer on Mars. The Offer is sent on the
existing connection to Earth, which forwards it to Mars, and the Answer
is returned in the same way. ICE connectivity checks are then done, and
the result is a tuple of real addresses and ports for the
connection.</t>
<t>If null encapsulation is used, then the TCP connection was
established as part of the ICE connectivity checks. This new connection
is used only for SIP signaling, and subsequent connections require a new
offer/answer exchange.</t>
<t>But if Outer-UDP encapsulation is used, then all the ICE connectivity
checks do is establish a UDP "pipe" between the two peers, and the TCP
and TLS handshakes must still be done inside that pipe (as shown above).
However, this UDP pipe can be used for all traffic between Venus and
Mars, including subsequent RTP packets) without the need of subsequent
offer/answer exchanges.</t>
</section>
<section anchor="Relationship-to-HIP" title="Relationship to HIP">
<t>The fundamental concept in this document, that of an identifier for a
node which is distinct from the node’s real addresses, has been
adopted from HIP. In HIP, this identifier (known as a HIT <xref
target="HIP-Base"></xref>)is always an IPv6 identifier, and has global
scope and cryptographic properties, making it computationally hard for
an second node to steal a node’s identity. (Current HIP
implementations also implement an IPv4 identifier as a local identifier,
but the properties of this IPv4 identifier are not currently specified
anywhere).</t>
<t>HIP also introduces a number of other concepts, whose applicability
to p2p overlays is less obvious.</t>
<t>The first is the use of ESP. In HIP, all data packets flowing between
two nodes use ESP to encrypt and integrity protect the traffic <xref
target="HIP-ESP"></xref>. At present, this is done for all traffic, even
if the traffic is already protected at a higher layer (e.g., using TLS
or application-level encryption). Does we want to encrypt and
integrity-protect *all* traffic, or should this decision be made on a
per-application basis? Do we want some way to avoid double encryption:
if so, how is this done?</t>
<t>The second is the use of computational puzzles to prevent denial of
service attacks. Since all traffic is encrypted, when setting up a HIP
connection the two endpoints do a Diffie-Hellman exchange to agree on a
shared encryption key. Since this is computationally expensive, the node
initiating the connection must first solve a computational puzzle
generated by the destination, in order to make it more difficult for a
hostile initiator to cause the destination to do a lot of work. However,
it is not immediately clear how to extend this concept to a peer-to-peer
overlay where there are many more connections involved and the different
ways of launching denial-of-service attacks seem larger.</t>
<t>Finally, HIP has its own signaling protocol (also called HIP), and
the proper relationship of that protocol to the Peer Protocol is not
immediately clear. Should the functionality of HIP simply be added to
the Peer Protocol? Should HIP signaling be kept as a distinct protocol
and carried inside Peer Protocol messages (as proposed in <xref
target="WITH-HIP"></xref>)? Or should HIP signaling be used to create
connections in the overlay instead of the Peer Protocol (as proposed in
<xref target="HIP-HOP"></xref>)? </t>
</section>
<section anchor="Implementing" title="Implementing the Shim Layer">
<t>A frequent reaction to people hearing about this architecture for the
first time is: But how do I implement it? This section provides some
guidance, drawing on the experience of the HIP community in implementing
HIP.</t>
<t>There are three kinds of implementations: kernel, user-space, and
library.</t>
<t>In a kernel implementation, the shim layer is implemented in the
kernel.</t>
<t>In a user-space implementation, the packet is intercepted at the link
layer and sent up to a user-space process which modifies the packet as
required and then the packet is returned to the kernel for further
processing.</t>
<t>In a library implementation, the transport and shim layers are
implemented in a library (e.g., libc) which is either statically or
dynamically linked with the application.</t>
<t>Currently, HIP implementations of the kernel kind exist for Linux and
FreeBSD, and of the user-space kind for Linux, OS X, and Windows. Note
that the user-space implementations run on operating systems where
kernel modifications are not possible. The authors are not currently
aware of any libary implementations, but these would be easy to produce.
</t>
</section>
<section title="IANA Considerations">
<t>TBD.</t>
</section>
<!-- "IANA Considerations" -->
<section title="Security Considerations">
<t>TBD.</t>
</section>
<!-- "Security Considerations" -->
</middle>
<back>
<references title="Informative References">
<reference anchor="HIP-Base">
<front>
<title>Host Identity Protocol</title>
<author initials="R." surname="Moskowitz"></author>
<author initials="P." surname="Nikander"></author>
<author initials="P." surname="Jokela"></author>
<author initials="T." surname="Henderson"></author>
<date month="June" year="2007" />
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-hip-base-08" />
</reference>
<reference anchor="HIP-ESP">
<front>
<title>Using ESP transport format with HIP</title>
<author initials="P." surname="Jokela"></author>
<author initials="R." surname="Moskowitz"></author>
<author initials="P." surname="Nikander"></author>
<date month="June" year="2007" />
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-hip-esp-06" />
</reference>
<!-- *** Commented out for now.
<?rfc include="reference.RFC.2119"?> "Defn of MUST, SHOULD, ...
*** End of commented out section. *** -->
<reference anchor="HIP-HOP">
<front>
<title>A Distributed Transport Function in P2PSIP using HIP for
Multi-Hop Overlay Routing</title>
<author initials="E." surname="Cooper">
<organization></organization>
</author>
<author initials="A." surname="Johnston">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="P." surname="Matthews">
<organization>John</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date day="16" month="June" year="2007" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-matthews-p2psip-hip-hop-00" />
</reference>
<reference anchor="WITH-HIP">
<front>
<title>Utilizing HIP (Host Identity Protocol) for P2PSIP
(Peer-to-peer Session Initiation Protocol)</title>
<author initials="J." surname="Hautakorpi">
<organization>Hau</organization>
</author>
<author initials="G." surname="Camarillo">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<author initials="J." surname="Koskella">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="November" year="2007" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-hautakorpi-p2psip-with-hip-01 (to appear)" />
</reference>
<reference anchor="Concepts">
<front>
<title>Concepts and Terminology for Peer to Peer SIP</title>
<author initials="D." surname="Bryan"></author>
<author initials="P." surname="Matthews"></author>
<author initials="E." surname="Shim"></author>
<author initials="D." surname="Willis"></author>
<date month="March" year="2007" />
</front>
<seriesInfo name="Internet Draft"
value="draft-willis-p2psip-concepts-04" />
</reference>
<reference anchor="ICE">
<front>
<title>Interactive Connectivity Establishment (ICE): A Methodology
for Network Address Translator (NAT) Traversal for Offer/Answer
Protocols</title>
<author initials="J." surname="Rosenberg" />
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-mmusic-ice" />
</reference>
<!-- *** Commented out for now ***
<reference anchor="STUN-bis">
<front>
<title>Simple Traversal Underneath Network Address Translators (NAT) (STUN)</title>
<author initials="J." surname="Rosenberg" />
<author initials="C." surname="Huitema" />
<author initials="R." surname="Mahy" />
<author initials="D." surname="Wing" />
</front>
<seriesInfo name="Internet Draft" value="draft-ietf-behave-rfc3489bis (Work in Progress)" />
</reference>
*** End commented out section. *** -->
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 06:00:55 |