<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-schwartz-tram-turnbyname-00" ipr="trust200902">
  <front>
    <title abbrev="TURN-BY-NAME">
      TURN by name: an extension to TURN for contacting an endpoint by its DNS name.
    </title>

    <author fullname="Benjamin M. Schwartz" initials="B. M." surname="Schwartz">
      <organization abbrev="Google">Google, Inc.</organization>

      <address>
        <postal>
          <street>111 8th Ave</street>

          <city>New York</city>

          <region>NY</region>

          <code>10011</code>

          <country>USA</country>
        </postal>

        <email>bemasc@webrtc.org</email>
      </address>
    </author>

    <author fullname="Justin Uberti" initials="J." surname="Uberti">
      <organization abbrev="Google">Google, Inc.</organization>

      <address>
        <postal>
          <street>747 6th Street South</street>

          <city>Kirkland</city>

          <region>WA</region>

          <code>98033</code>

          <country>USA</country>
        </postal>
        <email>justin@uberti.name</email>
      </address>
    </author>

    <date day="5" month="March" year="2015" />

    <area>TSV</area>

    <abstract>
      <t>When tunneling traffic through TURN, a client may sometimes desire to
      contact a remote endpoint that it knows by its DNS name, not its IP address.
      This document describes an extension to TURN that allows such a client to
      contact a named endpoint.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
<t>The <xref target="RFC5766">TURN standard</xref> extends STUN to allow proxying connections directly through the server.  Clients send messages to the server in order to request the allocation of ports on the server, and identify the remote peers with whom they want to exchange packets.  These remote peers are identified by an XOR-PEER-ADDRESS attribute, which includes the remote peer’s IP address and port.</t>

<t>TURN is most commonly used as a component of an <xref target="RFC5245">ICE</xref> implementation, to allow communication between endpoints that each send their own transport address to the other in the form of an ICE candidate.  These candidates are typically constructed using STUN, or by direct interrogation of the network interfaces, so they normally contain IP addresses, although domain names are also allowed.</t>

<t>However, TURN is now attracting a wider range of use cases, especially on enterprise networks and in conjunction with WebRTC.  Some use cases employ TURN as an “escape hatch” in an otherwise tightly restricted network, with the intention that users would tunnel much or all of their UDP traffic through the TURN server.  On some restricted networks, DNS access is also restricted, which may prevent users from determining the IP address of a domain (e.g. an application-specified TURN server, for <xref target="I-D.schwartz-rtcweb-return">RETURN</xref>, or an ICE candidate that contains a domain name) that they wish to contact through the escape-hatch TURN server.</t>

<t>Extending TURN to support named peers allows TURN to work for clients who are attempting to contact an endpoint by name, on networks where resolving those names is not otherwise possible.</t>
    </section>

    <section title="New Address Family for DNS names">
      <t>The Address Family 0x03 is defined to indicate that the specified address is a DNS name.  This family is only permitted under certain circumstances, detailed below.</t>
    </section>

    <section title="Extension to the XOR-PEER-ADDRESS attribute format">
      <t>STUN/TURN attributes are Type-Length-Value encoded (<xref target="RFC5389"></xref>, Section 15). For both of the existing Families, the attribute’s encoded length is a known constant, because the length of the address is constant. For the newly defined Family 0x03, the length is variable, and the indicated length from the TLV encoding is necessary in order to parse the attribute.</t>

      <t>The DNS name is transmitted in the X-Address field, and is encoded by the following procedure:
      <list style="numbers">
        <t>Define the “legacy transaction ID” as a 128-bit value consisting of the 32-bit magic cookie followed by the 96-bit transaction ID.</t>
        <t>Define the DNS name as a standard dot-separated UTF-8 byte-string (not null-terminated).</t>
        <t>Compute the encoded address (X-Address) by XOR’ing each byte of the DNS name with the corresponding byte of the legacy transaction ID.
        <list style="symbols">
          <t>If the DNS name is longer than 128 bits, the corresponding byte with which to XOR wraps around to the beginning of the legacy transaction ID.</t>
        </list>
        </t>
      </list>
      </t>

      <t>This procedure is an extension of the encoding for families 0x01 and 0x02, so all three XOR-PEER-ADDRESS families can be encoded and parsed by a single procedure, without any special cases.</t>
    </section>

    <section title="Changes to TURN server behavior">
      <section title="Servers that do not support the extension">
        <t>Servers are NOT REQUIRED to support this extension. No change is required to servers that do not support the extension. Upon receiving a message containing an XOR-PEER-ADDRESS attribute with Family 0x03, existing compliant servers MUST reply with Error 440 (Address Family not Supported).</t>
        <t>Servers that do support this extension MUST comply with the requirements that follow in this section.</t>
      </section>

      <section title="Supported attributes">
        <t>Address Family 0x03 is only permitted in the context of the XOR-PEER-ADDRESS attribute. All other attributes that use address families remain restricted to families 0x01 and 0x02. The server MUST respond with Error 440 (Address Family not Supported) when encountering this address family in an attribute where it is not supported.</t>
      </section>

      <section title="Supported messages">
        <t>The XOR-PEER-ADDRESS attribute may only have family 0x03 in the context of a CreatePermission, Send, Data, or ChannelBind message. If the server encounters this address family in the context of any other message type, it MUST respond with Error 440 (Address Family not Supported).</t>

        <t>If a TURN server supports address family 0x03 in one of these messages, it MUST support it in all of these messages.</t>
      </section>

      <section title="Name mapping storage">
        <t>Baseline TURN servers must store two kinds of state for each Allocation: Permissions and Channel Bindings. This extension adds a third kind of state: Name Mappings. Each DNS Name Mapping consists of:
        <list style="symbols">
          <t>a DNS name</t>
          <t>an IP address</t>
          <t>a reference count, which is always either 1 or 2</t>
        </list>
        </t>

        <t>Name Mappings do not have an expiration time, but the server MUST delete them if their reference count falls to zero.  Like Permissions and Channel Bindings, Name Mappings are scoped to a single Allocation.</t>

        <t>Each IP address appears in only one Name Mapping for an Allocation. The requirements for CreatePermission and ChannelBind are structured to maintain this invariant.</t>

        <t>Server implementations SHOULD implement Name Mappings in a way that enables fast bidirectional lookup.</t>
      </section>

      <section title="Lookup behavior">
        <t>When a DNS name lookup is required, the server’s behavior depends on the current Allocation. Each supported message is associated with an Allocation, whose address family is IPv4, <xref target="RFC6156">IPv6</xref>, or Both (via <xref target="I-D.ietf-tram-turnbis">ADDITIONAL-ADDRESS-FAMILY</xref>).</t>

        <t>If the address family is IPv4, then the server MUST search for an A record for the name, and similarly if the address family is IPv6, the server MUST search for a AAAA record. The server MUST handle errors as follows:
        <list style="symbols">
          <t>If resolution fails due to a server error (e.g. DNS SERVFAIL), reply with error code 500 (Server Error).</t>

          <t>If the resolution fails because there is no record of the required type (e.g. DNS NOERROR), respond with error code 443 (Peer Address Family Mismatch).</t>

          <t>For all other DNS errors, return error code 447 (Connection timeout or failure).</t>
        </list>
        </t>

        <t>The TURN server implementation MAY use a high-level DNS resolution API, such as gethostbyname or getaddrinfo, to perform the lookup.</t>

        <t>If the Allocation has both address families, then it MUST look for an IPv6 address, and fall back to IPv4 only if a AAAA record is not found.</t>
      </section>

      <section title="CreatePermission">
        <t>In baseline TURN, each CreatePermission message creates or renews a Permission to send and receive messages to some specified IP address. With this extension, a Permission may indicate either an IP address or a DNS name. Both types of Permissions are subject to the same expiration policy.</t>

        <t>At any given time, there is at most one Permission that specifies any IP address, or any DNS name, but there may be a Permission specifying a DNS name that resolves to an IP address that is specified in another Permission.</t>

        <t>Upon receiving a CreatePermission message on an Allocation, the server MUST perform these steps:
        <list style="numbers">
          <t>If the CreatePermission message contains a peer address of family 0x01 or 0x02, create or update a Permission for the given address. (No change from baseline.)</t>
          <t>If the CreatePermission message contains peer address of family 0x03:
          <list style="letters">
            <t>Look for an existing Permission with the given DNS name. If one exists, refresh its expiration time and return success.</t>
            <t>Otherwise, check if there is a Name Mapping for the DNS name.
            <list style="format %i.">
              <t>If one exists, increment its reference count.</t>
              <t>Otherwise, perform a DNS lookup for the name. If it succeeds, add a DNS name mapping for the name and the resolved address, with reference count 1.</t>
            </list>
            </t>
            <t>Install a new permission for the DNS name.</t>
          </list>
          </t>
        </list>
        </t>

        <t>When a Permission containing a DNS name expires, the server MUST decrement the reference count on the Name Mapping for this DNS name, and delete the Name Mapping if its reference count falls to zero.</t>

        <section title="Implications of this permission model">
          <t>As long as a permission is regularly refreshed with the same DNS name, the effective IP address will not change.</t>

          <t>Permission refreshes for an IP address do not extend the lifetime of DNS resolutions to that address.</t>

          <t>Permission requests for an IP address are not sufficient to allow Send requests to a DNS name that resolves to that IP address, and vice versa.</t>
        </section>
      </section>

      <section title="Send">
        <t>Upon receiving a Send message on an Allocation, the server MUST perform these steps:
        <list style="numbers">
          <t>If the Send message contains a peer address of family 0x01 or 0x02, check for a Permission that indicates that IP address. (There will be at most one.) If a Permission matches, send the packet; otherwise silently drop it. (No change from baseline.)</t>
          <t>If the Send message contains a peer address of family 0x03, check if there is a Permission for the given DNS name. (There will be at most one.) If one exists, send the packet to the IP address indicated for that DNS name in its Name Mapping; otherwise silently drop it.</t>
        </list>
        </t>
      </section>

      <section title="Channel Binding">
        <t>In baseline TURN, each ChannelBind message creates or renews a channel binding, which consists of a transport ID, a peer’s IP address, and a port on that address. It also creates or renews a permission for the peer’s IP address, exactly as if a CreatePermission message had been received for that IP address.</t>

        <t>In this extension, each channel binding includes either an IP address or a DNS name.</t>

        <t>Upon receiving a ChannelBind message on an Allocation, the server MUST perform these steps:
        <list style="numbers">
          <t>If the ChannelBind indicates a peer address of family 0x01 or 0x02
          <list style="letters">
            <t>If a binding already exists with the specified transport ID, IP address, and port, refresh the binding.</t>
            <t>If a binding already exists for the specified transport ID with a different or unspecified IP address or port, report Error 400 (Bad Request).</t>
            <t>If a binding already exists with this port and this IP address, or a DNS name that maps to this IP address, report Error 400 (Bad Request) and include a CHANNEL-NUMBER attribute that indicates the number of the conflicting channel.</t>
            <t>Otherwise, create a binding.</t>
            <t>Install or refresh a permission for the originally indicated peer IP address.</t>
          </list>
          </t>
          <t>If the ChannelBind indicates a peer address of family 0x03
          <list style="letters">
            <t>If a binding already exists with the specified transport ID, DNS name, and port, refresh the binding, including the IP address.</t>
            <t>Otherwise, resolve the DNS name to an IP address, using the name mapping table if it exists, and performing a DNS lookup only if no name mapping exists for this DNS name.
            <list style="format %i.">
              <t>If a binding already exists for the specified transport ID with a different IP address or port, report Error 400 (Bad Request).</t>
              <t>If a binding already exists with a different transport ID, for this port, and this IP address or a DNS name that is mapped to this IP address, report Error 400 (Bad Request) and include a CHANNEL-NUMBER attribute that indicates the number of the conflicting channel.</t>
            </list>
            </t>

            <t>Install a channel binding with the specified transport ID, DNS name, and port.</t>
            <t>Increment the name mapping’s reference count, or Install a new name mapping if one does not already exist for this DNS name.</t>
            <t>Perform the steps required when receiving a CreatePermission message for this DNS name.</t>
          </list>
          </t>
        </list>
        </t>

        <t>When a channel binding that indicates a DNS name expires, the server MUST decrement the reference count on the matching name mapping, and delete the mapping if the reference count falls to zero.</t>

        <section title="Implications of this channel binding model">
          <t>As long as a channel is refreshed before it times out, it will continue to resolve to a constant address.</t>

          <t>There can never be two channels bound to the same remote transport address. If that were possible, it would result in traffic amplification (sending each received packet to all matching channels) or other strange behaviors (e.g. selecting one arbitrary channel to receive the packet).</t>

          <t>Each time a new channel is bound for a DNS name, it checks for a Name Mapping before doing any external resolution, so the resolved IP address is guaranteed to be consistent with the active Permission for this DNS name, if one exists. As a result, DNS resolution results can persist indefinitely within an Allocation, longer than the DNS TTL or any individual connection, if they are maintained by ChannelBind or CreatePermission calls to different ports on the same remote peer that overlap in time.</t>

          <t>If two ChannelBind requests are received for the same port on two different DNS names that resolve to the same IP address, the second request will fail with a generic error code (400), but will also let the client know which existing channel to use instead. The same is true of collisions between IP and DNS channel binding requests.</t>

          <t>Installing a channel binding to a DNS name also enables Send messages to the DNS name, but not to the resolved IP address.</t>
        </section>
      </section>

      <section title="Receiving Data">
        <t>Upon receiving an incoming packet on an Allocation, the server MUST perform these steps:
        <list style="numbers">
          <t>Check if there is a channel binding to this source port and IP address, or a DNS name that is mapped to this IP address.  (There will be at most one such channel.) If there is, let the channel handle the packet.</t>
          <t>Otherwise, check if there is any DNS permission that is mapped to the source IP address. If there is, produce a Data message with that DNS name.</t>
          <t>Otherwise, check if there is any IP permission that matches the source IP address. If there is, produce a Data message with the source IP address; otherwise discard the packet.</t>
        </list>
        </t>

        <section title="Implications of this data receipt model">
          <t>If a name mapping exists for an IP address, all packets received from that address will be labeled with the DNS name, not the IP address. Clients never learn the IP address for a DNS name unless they provoke a conflict, similar to the naming model used by <xref target="RFC1928">SOCKS5</xref>.</t>

          <t>If a channel is bound for a port on a peer, all packets from that port will be routed to the channel exclusively.</t>
        </section>
      </section>
    </section>

    <section title="Changes to TURN client behavior">
      <t>Clients are NOT REQUIRED to support this extension. No change is required to existing clients. The requirements in this section only apply to clients that opt to support the extension.</t>

      <section title="When to use this extension">
        <t>When the client receives a request to contact an endpoint that is identified by its DNS name, the client SHOULD attempt to use this extension to reach that endpoint, and SHOULD NOT attempt to perform a local DNS lookup for the name, so that connections may succeed even if the local DNS server fails to return a correct result.</t>

        <t>If the TURN server responds with Error 440 (Address Family Not Supported), then the TURN client application SHOULD attempt to perform a local DNS lookup for the name, and retry the connection by IP address. (This functionality is logically separable from the TURN protocol itself, and might best be implemented by having a TURN client library that indicates the error, leaving the DNS lookup to be the responsibility of the application that uses the library.)</t>
      </section>

      <section title="Issuing Send, CreatePermission, and ChannelBind requests for DNS names">
        <t>When attempting to contact an endpoint by its DNS name, the client SHOULD transmit a CreatePermission or ChannelBind request whose XOR-PEER-ADDRESS attribute contains family 0x03, conveying the DNS name formatted as described above.</t>

        <t>If the server responds with Error 440 (Address family not supported), then the client SHOULD abandon all requests using DNS, because the server does not support this extension.</t>

        <t>If a ChannelBind request fails with Error 400, but includes a CHANNEL-NUMBER attribute, then that channel is already bound to the remote transport address.</t>
      </section>

      <section title="Receiving Data indications">
        <t>Clients MAY send CreatePermission requests for both an IP address and a DNS name that maps to that IP address, and both requests will succeed.  However, all Data messages from the remote peer will be marked as being received from the DNS name.  Therefore, clients MUST NOT assume that replies from a Send to an IP address are labeled with that IP address.</t>
      </section>

      <section title="Handling dynamic addressing">
        <t>The IP address to which a DNS name resolves is not a constant. It may change occasionally due to address reassignment, or it may even change on every lookup, in the case of round-robin DNS.</t>

        <t>The TURN server ensures that the IP address associated with a permission or channel binding does not change as long as the permission or binding is refreshed before it expires. Therefore, clients that need to send messages to a stable IP address MUST refresh their DNS name permissions and channel bindings even while they are not in use, to ensure that they do not expire and later resolve to a different IP address.</t>

        <t>If the client has previously connected to a DNS name on an Allocation, and wishes to connect again to the same DNS name with an up-to-date IP address resolution, it SHOULD request a new Allocation, and connect to the DNS name on the new Allocation.</t>
      </section>

      <section title="Dual-stack behavior">
        <t>If a specific address family is not indicated for the remote endpoint, and the server does not support dual allocation (e.g. <xref target="I-D.ietf-tram-turnbis">ADDITIONAL-ADDRESS-FAMILY</xref>]), then the client’s behavior is implementation-defined.  For example, when processing a request to send the first packet to a DNS name, the client MAY use an approach inspired by <xref target="RFC6555">Happy Eyeballs</xref>:
        <list style="symbols">
          <t>Create an Allocation for the system’s preferred address family (e.g. IPv6).</t>
          <t>Attempt to connect to the DNS name on this Allocation using a ChannelBind message.
          <list style="symbols">
            <t>If the server replies with error code 443 (Peer Address Family Mismatch), immediately discard the Allocation and try again with an Allocation of the other family.</t>
            <t>If a response message is received before some timeout (e.g. 300 ms), use this Allocation</t>
            <t>If no response message is received before some timeout (e.g. 300 ms), attempt to connect using a new Allocation of the other address family, and use whichever Allocation receives a response first. Discard the other Allocation.</t>
          </list>
          </t>
        </list>
        </t>
      </section>
    </section>

    <section title="Examples">
      <figure anchor="bind_figure"
          title="Using DNS names with ChannelBind">
        <artwork><![CDATA[
TURN                                 TURN           Peer          DNS
client                               server          A          Server
  |                                    |             |             |
  |-- ChannelBind req ---------------->|             |             |
  | (peer-a.example.com to 0x4001)     |             |             |
  |                                    |======= DNS query ========>|
  |                                    |     (peer-a.example.com)  |
  |                                    |<=======DNS result=========|
  |                                    |     (192.0.2.15)          |
  |<---------- ChannelBind succ resp --|             |             |
  |                                    |             |             |
  |-- [0x4001] data ------------------>|             |             |
  |                                    |=== data ===>|             |
  |                                    |             |             |
  |                                    |<== data ====|             |
  |<------------------ [0x4001] data --|             |             |
]]></artwork>
      </figure>
      <figure anchor="permission_figure"
          title="Using DNS names with CreatePermission and Send">
        <artwork><![CDATA[
TURN                                 TURN           Peer          DNS
client                               server          A          Server
  |                                    |             |             |
  |----- CreatePermission req -------->|             |             | 
  |      (peer-a.example.com)          |             |             |
  |                                    |======= DNS query ========>|
  |                                    |     (peer-a.example.com)  |
  |                                    |<=======DNS result=========|
  |                                    |     (192.0.2.15)          |
  |<-- CreatePermission success resp --|             |             |
  |                                    |             |             |
  |-- Send ind (peer-a.example.com) -->|             |             |
  |                                    |=== data ===>|             |
  |                                    |             |             |
  |                                    |<== data ====|             |
  |<-- Data ind (peer-a.example.com) --|             |             |
  |                                    |             |             |
]]></artwork>
      </figure>
      <figure anchor="permission_and_bind_figure"
          title="Sharing DNS names between CreatePermission and ChannelBind">
        <artwork><![CDATA[
TURN                                 TURN           Peer          DNS
client                               server          A          Server
  |                                    |             |             |
  |------- CreatePermission req ------>|             |             |
  |        (peer-a.example.com)        |             |             |
  |                                    |======= DNS query ========>|
  |                                    |     (peer-a.example.com)  |
  |                                    |<=======DNS result=========|
  |                                    |     (192.0.2.15)          |
  |<-- CreatePermission success resp --|             |             |
  |                                    |             |             |
  |------- ChannelBind req ----------->|             |             |
  |  (peer-a.example.com to 0x4001)    |             |             |
  |                                    |             |             |
  |<---- ChannelBind succ resp --------|             |             |
  |                                    |             |             |
  |-- Send ind (peer-a.example.com) -->|             |             |
  |                                    |=== data ===>|             |
  |                                    |             |             |
  |                                    |<== data ====|             |
  |<---------- [0x4001] data ----------|             |             |
  |                                    |             |             |
]]></artwork>
      </figure>
    </section>

    <section title="Security Considerations">
      <t>TURN servers that implement this specification can be made to parse arbitrary DNS records. They should make sure to use secure, well-tested DNS client implementations.</t>

      <t>Clients can cause the TURN server to perform an arbitrary number of DNS lookups. Server implementations MAY limit the rate at which an individual client can trigger lookups, and return Error 508 (Insufficient Capacity) when a client exceeds the limit.</t>

      <t>A malicious server could forward messages to the wrong IP address for a specified domain name, but this does not represent a change in security relative to the basic TURN standard.</t>

      <t>To provide this functionality, the server is required to store a number of DNS Name Mappings that is at most the number of active permissions or channels. Implementers should take care to avoid resource leaks in the DNS mapping implementation, to maintain this bound.</t>
    </section>

    <section title="IANA Considerations">
      <t>This draft adds a new STUN address family, 0x03 (DNS name).</t>
    </section>

    <section title="Acknowledgements">
      <t>Thanks to Warren Kumari for his early review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="RFC5245">
        <front>
          <title>Interactive Connectivity Establishment (ICE): A Protocol for
          Network Address Translator (NAT) Traversal for Offer/Answer
          Protocols</title>

          <author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
            <organization>jdrosen.net</organization>
          </author>

          <date month="April" year="2010" />
        </front>

        <seriesInfo name="RFC" value="5245" />

        <format target="http://www.rfc-editor.org/rfc/rfc5245.txt" type="TXT" />
      </reference>

      <reference anchor="RFC5766">
        <front>
          <title>Traversal Using Relays around NAT (TURN): Relay Extensions to
          Session Traversal Utilities for NAT (STUN)</title>

          <author fullname="Rohan Mahy" initials="R." surname="Mahy">
            <organization></organization>
          </author>

          <author fullname="Philip Matthews" initials="P." surname="Matthews">
            <organization>Alcatel-Lucent</organization>
          </author>

          <author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
            <organization>jdrosen.net</organization>
          </author>

          <date month="April" year="2010" />
        </front>

        <seriesInfo name="RFC" value="5766" />

        <format target="http://www.rfc-editor.org/rfc/rfc5245.txt" type="TXT" />
      </reference>

      <reference anchor="RFC6156">
        <front>
          <title>Traversal Using Relays around NAT (TURN) Extension for
          IPv6</title>

          <author fullname="Gonzalo Camarillo" initials="G."
              surname="Camarillo">
            <organization>Ericsson</organization>
          </author>

          <author fullname="Oscar Novo" initials="O." surname="Novo">
            <organization>Ericsson</organization>
          </author>

          <author fullname="Simon Perreault" initials="S." surname="Perreault">
            <organization>Viagenie</organization>
          </author>

          <date month="April" year="2011" />
        </front>

        <seriesInfo name="RFC" value="6156" />

        <format target="http://www.rfc-editor.org/rfc/rfc6156.txt" type="TXT" />
      </reference>

      <reference anchor="RFC5389">
        <front>
          <title>Session Traversal Utilities for NAT (STUN)</title>

          <author fullname="Jonathan Rosenberg" initials="J" surname="Rosenberg">
            <organization>Cisco</organization>
          </author>

          <author fullname="Rohan Mahy" initials="R" surname="Mahy">
            <organization>Unaffiliated</organization>
          </author>

          <author fullname="Philip Matthews" initials="P" surname="Matthews">
            <organization>Unaffiliated</organization>
          </author>

          <author fullname="Dan Wing" initials="D." surname="Wing">
            <organization>Cisco</organization>
          </author>

          <date month="October" year="2008" />
        </front>

        <seriesInfo name="RFC" value="5389" />

        <format target="http://www.rfc-editor.org/rfc/rfc5389.txt" type="TXT" />
      </reference>

      <reference anchor="I-D.ietf-tram-turnbis">
        <front>
          <title>
            Traversal Using Relays around NAT (TURN): Relay Extensions to Session
            Traversal Utilities for NAT (STUN)
          </title>

          <author fullname="Tirumaleswar Reddy" initials="T" surname="Reddy">
            <organization>Cisco Systems, Inc.</organization>
          </author>

          <author fullname="Alan Johnston" initials="A" surname="Johnston">
            <organization>Avaya</organization>
          </author>

          <author fullname="Philip Matthews" initials="P" surname="Matthews">
            <organization>Alcatel-Lucent</organization>
          </author>

          <author fullname="Jonathan Rosenberg" initials="J" surname="Rosenberg">
            <organization>jdrosen.net</organization>
          </author>

          <date day="3" month="February" year="2015" />

          <abstract>
            <t>If a host is located behind a NAT, then in certain situations it can
            be impossible for that host to communicate directly with other hosts
            (peers).  In these situations, it is necessary for the host to use
            the services of an intermediate node that acts as a communication
            relay.  This specification defines a protocol, called TURN (Traversal
            Using Relays around NAT), that allows the host to control the
            operation of the relay and to exchange packets with its peers using
            the relay.  TURN differs from some other relay control protocols in
            that it allows a client to communicate with multiple peers using a
            single relay address.</t>

            <t>The TURN protocol was designed to be used as part of the ICE
            (Interactive Connectivity Establishment) approach to NAT traversal,
            though it also can be used without ICE.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-ietf-tram-turnbis-02" />

        <format target="http://www.ietf.org/internet-drafts/draft-ietf-tram-turnbis-02.txt"
                type="TXT" />
      </reference>
    </references>

    <references title="Informative References">
      <reference anchor="RFC1928">
        <front>
          <title>SOCKS Protocol Version 5</title>

          <author fullname="Marcus Leech" initials="M." surname="Leech">
            <organization>Bell-Northern Research Ltd</organization>
          </author>

          <author initials="M." surname="Ganis">
            <organization>International Business Machines</organization>
          </author>

          <author initials="Y." surname="Lee">
            <organization>NEC Systems Laboratory</organization>
          </author>

          <author initials="R." surname="Kuris">
            <organization>Unify Corporation</organization>
          </author>

          <author initials="D." surname="Koblas">
            <organization></organization>
          </author>

          <author initials="L." surname="Jones">
            <organization>Hewlett-Packard Company</organization>
          </author>

          <date month="March" year="1996" />
        </front>

        <seriesInfo name="RFC" value="5766" />

        <format octets="285120"
                target="http://www.rfc-editor.org/rfc/rfc1928.txt" type="TXT" />
      </reference>

      <reference anchor="RFC6555">
        <front>
          <title>Happy Eyeballs: Success with Dual-Stack Hosts</title>

          <author fullname="Dan Wing" initials="D." surname="Wing">
            <organization>Cisco Systems, Inc.</organization>
          </author>

          <author fullname="Andrew Yourtchenko" initials="A."
              surname="Yourtchenko">
            <organization>Cisco Systems, Inc.</organization>
          </author>

          <date month="April" year="2012" />
        </front>

        <seriesInfo name="RFC" value="6555" />

        <format target="http://www.rfc-editor.org/rfc/rfc6555.txt" type="TXT" />
      </reference>

      <reference anchor="I-D.schwartz-rtcweb-return">
        <front>
          <title>
            Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in
            WebRTC
          </title>

          <author fullname="Benjamin M. Schwartz" initials="B" surname="Schwartz">
            <organization>Google, Inc.</organization>
          </author>

          <author fullname="Justin Uberti" initials="J" surname="Uberti">
            <organization>Google, Inc.</organization>
          </author>

          <date day="10" month="November" year="2014" />

          <abstract>
            <t>In the context of WebRTC, the concept of a local TURN proxy has been
            suggested, but not reviewed in detail. WebRTC applications are already
            using TURN to enhance connectivity and privacy. This document explains how
            local TURN proxies and WebRTC applications can work together.</t>
          </abstract>
        </front>

        <seriesInfo name="Internet-Draft" value="draft-schwartz-return-04" />

        <format target="http://www.ietf.org/internet-drafts/draft-schwartz-rtcweb-return-04.txt"
                type="TXT" />
      </reference>
    </references>

  </back>
</rfc>
