One document matched: draft-ietf-behave-turn-ipv6-10.xml

<?xml version="1.0"?>
<?rfc symrefs="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="trust200902" category="std" docName="draft-ietf-behave-turn-ipv6-10">

<front>
<title abbrev="TURN Extension for IPv4/IPv6 transition">
Traversal Using Relays around NAT (TURN) Extension for IPv6
</title> 

<author initials="G." surname="Camarillo" fullname="Gonzalo Camarillo">
  <organization>Ericsson</organization>
  <address>
    <postal>
      <street>Hirsalantie 11</street>
      <code>02420</code> 
      <city>Jorvas</city> 
      <country>Finland</country>
    </postal>
    <email>Gonzalo.Camarillo@ericsson.com</email>
  </address>
</author>

<author initials="O." surname="Novo" fullname="Oscar Novo">
  <organization>Ericsson</organization>
  <address>
    <postal>
      <street>Hirsalantie 11</street>
      <code>02420</code> 
      <city>Jorvas</city> 
      <country>Finland</country>
    </postal>
    <email>Oscar.Novo@ericsson.com</email>
  </address>
</author>

<author initials="S." surname="Perreault" fullname="Simon Perreault"
  role="editor">
  <organization>Viagénie</organization>
  <address>
    <postal>
      <street>2600 boul. Laurier, suite 625</street>
      <city>Québec</city>
      <region>QC</region>
      <code>G1V 4W1</code>
      <country>Canada</country>
    </postal>
    <phone>+1 418 656 9254</phone>
    <email>simon.perreault@viagenie.ca</email>
    <uri>http://www.viagenie.ca</uri>
  </address>
</author>

<date year="2010" />

<area>Transport</area>
<workgroup>BEHAVE</workgroup>
<keyword>STUN, TURN, IPv6</keyword>

<abstract>
<t>
This document adds IPv6 support to Traversal Using Relays around NAT
(TURN). IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6, and
IPv6-to-IPv4 relaying. This document defines the
REQUESTED-ADDRESS-FAMILY attribute for TURN. The REQUESTED-ADDRESS-FAMILY
attribute allows a client to explicitly request the address type the
TURN server will allocate (e.g., an IPv4-only node may request the
TURN server to allocate an IPv6 address).
</t>
</abstract>

</front>

<middle>

<section title="Introduction">
<t>
Traversal Using Relays around NAT (TURN) <xref
target="I-D.ietf-behave-turn"/> is a protocol that allows for an
element behind a NAT to receive incoming data over UDP or TCP. It is
most useful for elements behind NATs without Endpoint-Independent Mapping <xref
  target="RFC4787"/> that wish to be on the receiving end of a connection to a
single peer.
</t>
<t>
The base specification of TURN <xref target="I-D.ietf-behave-turn"/>
only defines IPv4-to-IPv4 relaying. This document adds IPv6 support to
TURN, which includes IPv4-to-IPv6, IPv6-to-IPv6, and IPv6-to-IPv4
relaying. This document defines the REQUESTED-ADDRESS-FAMILY attribute,
which is an extension to TURN that allows a client to explicitly
request the address type the TURN server will allocate (e.g., an
IPv4-only node may request the TURN server to allocate an IPv6
address). This document also defines and registers new error
response codes.
</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"/>.
</t>
</section>

<section title="Overview of Operation">
<t>
When a user wishes a TURN server to allocate an address of a specific
type, it sends an Allocate Request to the TURN server with a
REQUESTED-ADDRESS-FAMILY attribute. TURN can run over UDP and TCP, and it
allows for a client to request address/port pairs for receiving both
UDP and TCP.
</t>
<t>
After the request has been successfully authenticated,
the TURN server allocates a transport address of the type indicated in
the REQUESTED-ADDRESS-FAMILY attribute. This address is called the
relayed transport address.
</t>
<t>
The TURN server returns the relayed transport address in the response to the
Allocate Request. This response contains a XOR-RELAYED-ADDRESS
attribute indicating the IP address and port that the server allocated
for the client.
</t>
<t>
TURN servers allocate a single relayed transport address per
allocation request. Therefore, Allocate Requests cannot carry more
than one REQUESTED-ADDRESS-FAMILY attribute. Consequently, a client that
wishes to allocate more than one relayed transport address at a TURN server (e.g., an
IPv4 and an IPv6 address) needs to perform several allocation requests
(one allocation request per relayed transport address).
</t>
<t>
A TURN server that supports a set of address families is assumed to be
able to relay packets between them. If a server does not support the
address family requested by a client, the server returns a 440
(Address Family not Supported) error response.
</t>

</section>

<section title="Creating an Allocation">
<t>
The behavior specified here affects the processing defined in Section
6 of <xref target="I-D.ietf-behave-turn"/>.
</t>

<section title="Sending an Allocate Request">
<t>
A client that wishes to obtain a relayed transport address of a specific
address type includes a REQUESTED-ADDRESS-FAMILY attribute, which is
defined in <xref target="sec-attribute"/>, in the Allocate Request
that it sends to the TURN server. Clients MUST NOT include more than one
REQUESTED-ADDRESS-FAMILY attribute in an Allocate Request. The
mechanisms to formulate an Allocate Request are described in Section
6.1 of <xref target="I-D.ietf-behave-turn"/>.
</t>
<t>
Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an
Allocate request that contains a RESERVATION-TOKEN attribute.
</t>

<section title="The REQUESTED-ADDRESS-FAMILY Attribute"
anchor="sec-attribute">
<t>
The REQUESTED-ADDRESS-FAMILY attribute is used by clients to request the
allocation of a specific address type from a server. The following is
the format of the REQUESTED-ADDRESS-FAMILY attribute. Note that
TURN attributes are TLV (Type-Length-Value) encoded, with a 16 bit
type, a 16 bit length, and a variable-length value.
</t>
<figure title="Format of REQUESTED-ADDRESS-FAMILY Attribute"
anchor="fig-arch">
<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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Type                  |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Family    |            Reserved                           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork>
</figure>
<t>
Type: the type of the REQUESTED-ADDRESS-FAMILY attribute is 0x0017.  As
specified in <xref target="RFC5389"/>, attributes
with values between 0x0000 and 0x7FFF are comprehension-required, 
which means that the client or server cannot successfully process the
message unless it understands the attribute.
</t>
<t>
Length: this 16-bit field contains the length of the attribute in
bytes. The length of this attribute is 4 bytes.
</t>
<t>
    Family: there are two values defined for this field and specified in <xref
        target="RFC5389"/>, Section 15.1: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses.
</t>
<t>
Reserved: at this point, the 24 bits in the reserved field MUST be
set to zero by the client and MUST be ignored by the server.
</t>
<t>
The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
Requests.
</t>
</section>

</section>

<section title="Receiving an Allocate Request">
<t>
Once a server has verified that the request is authenticated and has not been tampered with,
the TURN server processes the Allocate request. If it contains both a
RESERVATION-TOKEN and a REQUESTED-ADDRESS-FAMILY, the server replies with a 400
(Bad Request) Allocate Error Response. Following the rules in <xref
    target="RFC5389"/>, if the server does not understand the
REQUESTED-ADDRESS-FAMILY attribute, it generates an Allocate Error Response,
which includes an ERROR-CODE attribute with response code 420 (Unknown
Attribute). This response will contain an UNKNOWN-ATTRIBUTE attribute listing
the unknown REQUESTED-ADDRESS-FAMILY attribute.
</t>
<t>
If the server can successfully process the request, it allocates a
transport address for the TURN client, called the relayed transport
address, and returns it in the response to the Allocate Request.
</t>
<t>
As specified in <xref target="I-D.ietf-behave-turn"/>, the Allocate
Response contains the same transaction ID contained in the Allocate
Request and the XOR-RELAYED-ADDRESS attribute is set to the relayed transport
address.
</t>
<t>
The XOR-RELAYED-ADDRESS attribute indicates the allocated IP address
and port.  It is encoded in the same way as the XOR-MAPPED-ADDRESS
<xref target="RFC5389"/>.
</t>
<t>
If the REQUESTED-ADDRESS-FAMILY attribute is absent, the server MUST
allocate an IPv4 relayed transport address for the TURN client. If allocation of IPv4
addresses is disabled by local policy, the server returns a a 440 (Address
Family not Supported) Allocate Error Response.
</t>
<t>
If the server does not support the address family requested by the client, 
it MUST generate an Allocate Error Response, and it MUST include an 
ERROR-CODE attribute with the 440 (Address Family not Supported)
response code, which is defined in <xref target="sec-440"/>.
</t>


<section title="Unsupported Address Family"
anchor="sec-440">
<t>
This document defines the following new error response code:
</t>
<t>
<list style="hanging">
<t hangText="440 (Address Family not Supported):"> The server did not
support the address family requested by the client. 
</t>
</list>
</t>
</section>

</section>


<section title="Receiving an Allocate Error Response">
<t>
If the client receives an Allocate error response with the 440
(Unsupported Address Family) error code, the client MUST NOT retry
its request.
</t>
</section>

</section>

<section title="Refreshing an Allocation">
<t>
The behavior specified here affects the processing defined in Section
7 of <xref target="I-D.ietf-behave-turn"/>.
</t>

<section title="Sending a Refresh Request">
<t>
To perform an allocation refresh, the client generates a Refresh Request
as described in Section 7.1 of <xref target="I-D.ietf-behave-turn"/>.
The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in
its Refresh Request.
</t>
</section>

<section title="Receiving a Refresh Request">
<t>
If a server receives a Refresh Request with a REQUESTED-ADDRESS-FAMILY
attribute, and the attribute's value doesn't match the address family of the
allocation, the server MUST reply with a 443 (Peer Address Family Mismatch)
Refresh Error Response.
</t>
</section>

</section>


<section title="CreatePermission">
<t>
The behavior specified here affects the processing defined in Section
9 of <xref target="I-D.ietf-behave-turn"/>.
</t>

<section title="Sending a CreatePermission Request">
<t>
The client MUST only include XOR-PEER-ADDRESS attributes with
addresses of the same address family as the relayed transport address
for the allocation.
</t>
</section>

<section title="Receiving a CreatePermission request">
<t>
If an XOR-PEER-ADDRESS attribute contains an address of an address
family different than the relayed transport address for the
allocation, the server MUST generate an error response with the
443 (Peer Address Family Mismatch) response code, which is defined in
<xref target="sec-443"/>.
</t>

<section title="Peer Address Family Mismatch"
anchor="sec-443">
<t>
This document defines the following new error response code:
</t>
<t>
<list style="hanging">
<t hangText="443 (Peer Address Family Mismatch):"> A peer address was
of a different address family than the relayed transport address of
the allocation.
</t>
</list>
</t>

</section>

</section>

</section>



<section title="Channels">
<t>
The behavior specified here affects the processing defined in Section
11 of <xref target="I-D.ietf-behave-turn"/>.
</t>

<section title="Sending a ChannelBind Request">
<t>
The client MUST only include a XOR-PEER-ADDRESS attribute with
an address of the same address family as the relayed transport address
for the allocation.
</t>
</section>

<section title="Receiving a ChannelBind Request">
<t>
If the XOR-PEER-ADDRESS attribute contains an address of an address
family different than the relayed transport address for the
allocation, the server MUST generate an error response with the
443 (Peer Address Family Mismatch) response code, which is defined in
<xref target="sec-443"/>.
</t>
</section>

</section>


<section title="Packet Translations">
<t>
The TURN specification <xref target="I-D.ietf-behave-turn"/> describes
how TURN relays should relay traffic consisting of IPv4 packets (i.e.,
IPv4-to-IPv4 translations). The relay translates the IP addresses and
port numbers of the packets based on the allocation's state data. How
to translate other header fields is also specified in <xref
target="I-D.ietf-behave-turn"/>. This document addresses IPv4-to-IPv6,
IPv6-to-IPv4, and IPv6-to-IPv6 translations.
</t>
<t>
TURN relays performing any translation MUST translate the IP addresses
and port numbers of the packets based on the allocation's state
information as specified in <xref
target="I-D.ietf-behave-turn"/>. The following sections specify how to
translate other header fields.
</t>
<t>
As discussed in Section 2.6 of <xref target="I-D.ietf-behave-turn"/>,
translations in TURN are designed so that a TURN server can be
implemented as an application that runs in userland under commonly
available operating systems and that does not require special
privileges. The translations specified in the following sections
follow this principle.
</t>
<t>The descriptions below have two parts: a preferred behavior and an alternate
  behavior.  The server SHOULD implement the preferred behavior.  Otherwise, the
  server MUST implement the alternate behavior and MUST NOT do anything else.</t>
<t>
<list style="hanging">
<t>
Note that the use of the behaviors specified in the following sections
is at the "should" level. Having its use at the "should" level instead
of at the "must" level makes it possible to use different translation
algorithms that may be developed in the future.
</t>
</list>

</t>

<section title="IPv4-to-IPv6 Translations">

  <t>Traffic Class</t>
  <t>
    <list>
      <t/>
      <t>Preferred behavior: as specified in Section 3 of <xref
          target="I-D.ietf-behave-v6v4-xlate"/>.</t>
      <t/>
      <t>Alternate behavior: the relay sets the Traffic Class to the default
        value for outgoing packets.</t>
    </list>
  </t>

<t>
Flow Label
</t>
<t>
<list>
<t></t>
<t> 
Preferred behavior: The relay sets the Flow label to 0. The relay can
choose to set the Flow label to a different value if it supports <xref
target="RFC3697"/>.
</t>
<t></t>
<t>
Alternate behavior: the relay sets the Flow label to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Hop Limit
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: as specified in Section 3 of <xref
target="I-D.ietf-behave-v6v4-xlate"/>.
</t>
<t></t>
<t>
Alternate behavior: the relay sets the Hop Limit to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Fragmentation
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: as specified in Section 3 of <xref
target="I-D.ietf-behave-v6v4-xlate"/>.
</t>
<t></t>
<t>
Alternate behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
</t>
<t></t>
<t>For both preferred and alternate behavior, the DONT-FRAGMENT attribute (<xref target="I-D.ietf-behave-turn"/>, Section 14.8) MUST
    be ignored by the server.</t>
</list>
</t>

<t>
Extension Headers
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: the relay sends outgoing packet without any IPv6
extension headers, with the exception of the Fragmentation header as
described above.
</t>
<t></t>
<t>
Alternate behavior: same as preferred.
</t>
</list>
</t>

</section>

<section title="IPv6-to-IPv6 Translations">
<t>
Flow Label
</t>
<t>
The relay should consider that it is handling two different IPv6
flows. Therefore, the Flow label <xref target="RFC3697"/> SHOULD NOT
be copied as part of the translation.
</t>

<t>
<list>
<t> 
Preferred behavior: The relay sets the Flow label to 0. The relay can
choose to set the Flow label to a different value if it supports <xref
target="RFC3697"/>.
</t>
<t></t>
<t>
Alternate behavior: the relay sets the Flow label to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Hop Limit
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: the relay acts as a regular router with respect to
decrementing the Hop Limit and generating an ICMPv6 error if it
reaches zero.
</t>
<t></t>
<t>
Alternate behavior: the relay sets the Hop Limit to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Fragmentation
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: If the incoming packet did not include a Fragment
header and the outgoing packet size does not exceed the outgoing
link's MTU, the relay sends the outgoing packet without a Fragment
header.
</t>
<t></t>
<t>
If the incoming packet did not include a Fragment header and the
outgoing packet size exceeds the outgoing link's MTU, the relay drops
the outgoing packet and send an ICMP message of type 2 code 0 ("Packet
too big") to the sender of the incoming packet.  If the packet is
being sent to the peer, the relay reduces the MTU reported in the ICMP
message by 48 bytes to allow room for the overhead of a Data
indication.
</t>
<t></t>
<t>
If the incoming packet included a Fragment header and the outgoing
packet size (with a Fragment header included) does not exceed the
outgoing link's MTU, the relay sends the outgoing packet with a
Fragment header. The relay sets the fields of the Fragment header as
appropriate for a packet originating from the server.
</t>
<t></t>
<t>
If the incoming packet included a Fragment header and the outgoing
packet size exceeds the outgoing link's MTU, the relay MUST fragment
the outgoing packet into fragments of no more than 1280 bytes. The
relay sets the fields of the Fragment header as appropriate for a
packet originating from the server.
</t>
<t></t>
<t>
Alternate behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
</t>
<t></t>
<t>For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST
    be ignored by the server.</t>
</list>
</t>

<t>
Extension Headers
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: the relay sends outgoing packet without any IPv6
extension headers, with the exception of the Fragmentation header as
described above.
</t>
<t></t>
<t>
Alternate behavior: same as preferred.
</t>
</list>
</t>

</section>

<section title="IPv6-to-IPv4 Translations">

<t>
Type of Service and Precedence
</t>
<t>
<list>
<t></t>
<t> 
Preferred behavior: as specified in Section 4 of <xref
target="I-D.ietf-behave-v6v4-xlate"/>.
</t>
<t></t>
<t>
Alternate behavior: the relay sets the Type of Service and
Precedence to the default value for outgoing packets.
</t>
</list>
</t>

<t>
Time to Live
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: as specified in Section 4 of <xref
target="I-D.ietf-behave-v6v4-xlate"/>.
</t>
<t></t>
<t>
Alternate behavior: the relay sets the Time to Live to the default
value for outgoing packets.
</t>
</list>
</t>

<t>
Fragmentation
</t>
<t>
<list>
<t></t>
<t>
Preferred behavior: as specified in Section 4 of <xref
target="I-D.ietf-behave-v6v4-xlate"/>.  Additionally, when the outgoing packet's size
exceeds the outgoing link's MTU, the relay needs to generate an ICMP
error (ICMPv6 Packet Too Big) reporting the MTU size. If the packet is
being sent to the peer, the relay SHOULD reduce the MTU reported in
the ICMP message by 48 bytes to allow room for the overhead of a Data
indication.
</t>
<t></t>
<t>
Alternate behavior: the relay assembles incoming fragments. The
relay follows its default behavior to send outgoing packets.
</t>
<t></t>
<t>For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST
    be ignored by the server.</t>
</list>
</t>

</section>

</section>


<section title="Security Considerations">
  <t>Translation between IPv4 and IPv6 creates a new way for clients to obtain
    IPv4 or IPv6 access which they did not have before. For example, an
    IPv4-only client having access to a TURN server implementing this
    specification is now able to access the IPv6 internet. This needs to be
    considered when establishing security and monitoring policies.</t>
  <t>The loop attack described in <xref target="I-D.ietf-behave-turn"/> Section
    17.1.7 may be more easily done in cases where address spoofing is easier to
    accomplish over IPv6. Mitigation of this attack over IPv6 is the same as for
    IPv4.</t>
<t>
All the security considerations applicable to STUN <xref target="RFC5389"/> and
TURN <xref target="I-D.ietf-behave-turn"/> are applicable to this document as well.
</t>
<section title="Tunnel Amplification Attack">
  <t>An attacker might attempt to cause data packets to loop numerous times
    between a TURN server and a tunnel between IPv4 and IPv6. The attack goes
    as follows.</t>
  <t>Suppose an attacker knows that a tunnel endpoint will forward encapsulated
    packets from a given IPv6 address (this doesn't necessarily need to be the
    tunnel endpoint's address).  Suppose he then spoofs two packets from this
    address:
    <list style="numbers">
      <t>An allocate request asking for a v4 address, and</t>
      <t>A ChannelBind request establishing a channel to the IPv4 address of the
        tunnel endpoint</t>
    </list>
  </t>
  <t>Then he has set up an amplification attack:
    <list style="symbols">
      <t>The TURN relay will re-encapsulate IPv6 UDP data in v4 and send it to
        the tunnel endpoint</t>
      <t>The tunnel endpoint will decapsulate packets from the v4 interface and
        send them to v6</t>
    </list>
  </t>
  <t>So if the attacker sends a packet of the following form...
    <figure>
      <artwork>
  IPv6: src=2001:DB9::1 dst=2001:DB8::2
  UDP:  <ports>
  TURN: <channel id>
  IPv6: src=2001:DB9::1 dst=2001:DB8::2
  UDP:  <ports>
  TURN: <channel id>
  IPv6: src=2001:DB9::1 dst=2001:DB8::2
  UDP:  <ports>
  TURN: <channel id>
  ...
      </artwork>
    </figure>
    Then the TURN relay and the tunnel endpoint will send it back and forth
    until the last TURN header is consumed, at which point the TURN relay will
    send an empty packet, which the tunnel endpoint will drop.</t>
  <t>The amplification potential here is limited by the MTU, so it's not huge:
    IPv6+UDP+TURN takes 334 bytes, so you could get a four-to-one amplification
    out of a 1500-byte packet.  But the attacker could still increase traffic
    volume by sending multiple packets or by establishing multiple channels
    spoofed from different addresses behind the same tunnel endpoint.</t>
  <t>The attack is mitigated as follows. It is RECOMMENDED that TURN relays not
    accept allocation or channel binding requests from addresses known to be
    tunneled, and that they not forward data to such addresses.  In particular,
    a TURN relay MUST NOT accept Teredo or 6to4 addresses in these requests.</t>
</section>
</section>

<section title="IANA Considerations">
<t>
The IANA is requested to register the following values under the STUN
Attributes registry and under the STUN Error Codes registry.
</t>
<section title="New STUN Attribute">
<t>
    <figure>
        <artwork>
  0x0017: REQUESTED-ADDRESS-FAMILY
        </artwork>
    </figure>
</t>
</section>

<section title="New STUN Error Codes">
<t>
    <figure>
        <artwork>
  440  Address Family not Supported
  443  Peer Address Family Mismatch
        </artwork>
    </figure>
</t>
</section>
</section>
<section title="Acknowledgements">
<t>
The authors would like to thank Alfred E. Heggestad, Dan Wing, Magnus
Westerlund, Marc Petit-Huguenin, Philip Matthews, and Rémi Denis-Courmont for
their feedback on this document.
</t>
</section>

</middle>

<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3697"?>
<?rfc include="reference.RFC.5389"?>
<?rfc include="reference.I-D.ietf-behave-turn"?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate"?>
</references>

<references title="Informative References">
  <?rfc include="reference.RFC.4787"?>
</references>

</back>
</rfc>