<?xml version="1.0" encoding="utf-8"?>
<?rfc symrefs="yes"?> version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
     category="exp"
  docName="draft-ietf-hip-native-nat-traversal-33"> docName="draft-ietf-hip-native-nat-traversal-33"
     obsoletes="" updates="" submissionType="IETF" xml:lang="en"
     symRefs="true" tocInclude="true" sortRefs="true" version="3"
     number="9028" consensus="true">

  <front>
    <title abbrev="HIP Native NAT Traversal Mode">
       Native NAT Traversal Mode for the Host&nbsp;Identity&nbsp;Protocol Host Identity Protocol
    </title>
    <seriesInfo name="RFC" value="9028"/>
    <author fullname="Ari Keranen" Keränen" initials="A." surname="Keranen"> surname="Keränen">
      <organization abbrev="Ericsson">Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <city>02420 Jorvas</city>
          <city>Jorvas</city>
	  <code>02420</code>
          <country>Finland</country>
        </postal>
        <email>ari.keranen@ericsson.com</email>
      </address>
    </author>
    <author initials="J." fullname="Jan Mel&eacute;n" surname="Mel&eacute;n"> Melén" surname="Melén">
      <organization abbrev="Ericsson">Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <city>02420 Jorvas</city>
          <city>Jorvas</city>
	  <code>02420</code>
          <country>Finland</country>
        </postal>
        <email>jan.melen@ericsson.com</email>
      </address>
    </author>
    <author fullname="Miika Komu" initials="M.K.T." initials="M." surname="Komu" role="editor">
      <organization abbrev="Ericsson">Ericsson</organization>
      <address>
        <postal>
          <street>Hirsalantie 11</street>
          <city>02420 Jorvas</city>
          <city>Jorvas</city>
	  <code>02420</code>
          <country>Finland</country>
        </postal>
        <email>miika.komu@ericsson.com</email>
      </address>
    </author>
    <date year="2020" /> month="June" year="2021"/>
    <area>Internet</area>
    <workgroup>HIP Working Group</workgroup>
    <keyword>HIP, NAT, NAT
    <workgroup>HIP</workgroup>
    <keyword>HIP</keyword>
    <keyword>NAT</keyword>
    <keyword>NAT traversal</keyword>
    <abstract>
      <t> This document specifies a new Network Address Translator (NAT)
      traversal mode for the Host Identity Protocol (HIP). The new mode is
      based on the Interactive Connectivity Establishment (ICE) methodology
      and UDP encapsulation of data and signaling traffic. The main difference
      from the previously specified modes is the use of HIP messages instead
      of ICE for all NAT traversal procedures due to the kernel-space
      dependencies of HIP.
      </t>
    </abstract>
  </front>

  <!-- XX FIXME: CHECK NEW ICE SPECS? -->

  <middle>

    <!-- ***************************************************************** -->
    <section title="Introduction" anchor="sec:intro"> anchor="sec_intro" numbered="true" toc="default">
      <name>Introduction</name>
      <t> The Host Identity Protocol (HIP) <xref
      target="RFC7401"/> target="RFC7401"
      format="default"/> is specified to run directly on top of IPv4 or
      IPv6. However, many middleboxes found in the Internet, such as NATs and
      firewalls, often allow only UDP or TCP traffic to pass <xref
      target="RFC5207"/>.
      target="RFC5207" format="default"/>. Also, NATs usually require the host
      behind a NAT to create a forwarding state in the NAT before other hosts
      outside of the NAT can contact the host behind the NAT. To overcome this
      problem, different methods, commonly referred to as NAT traversal
      techniques, have been developed. </t>
      <t>As one solution, the HIP experiment report <xref target="RFC6538" />
      format="default"/> mentions Teredo-based NAT traversal for HIP and
      related ESP Encapsulating Security Payload (ESP) traffic (with double
      tunneling overhead). Another solution is specified in <xref target="RFC5770"/>,
      target="RFC5770" format="default"/>, which will be referred to as
      "Legacy ICE-HIP" in this document. The experimental Legacy ICE-HIP
      specification combines the Interactive Connectivity Establishment (ICE)
      protocol (originally <xref target="RFC5245"/> target="RFC5245" format="default"/>) with
      HIP, HIP so that basically
      basically, ICE is responsible for NAT traversal and connectivity
      testing, while HIP is responsible for end-host authentication and IPsec
      key management. The resulting protocol uses HIP, STUN Session Traversal
      Utilities for NAT (STUN), and ESP messages tunneled over a single UDP
      flow. The benefit of using ICE and its STUN/TURN STUN / Traversal Using Relays
      around NAT (TURN) messaging formats is
      that one can re-use reuse the NAT traversal infrastructure already available
      in the Internet, such as STUN and TURN servers. Also, some middleboxes
      may be STUN-aware STUN aware and may be able to do something "smart" when they see
      STUN being used for NAT traversal.</t>

      <t>HIP poses a unique challenge to using standard ICE, due not only due to
      kernel-space dependencies of HIP, but also due to its close integration
      with kernel-space IPSec; IPsec; and, that while <xref target="RFC5770" />
      format="default"/> provides a technically workable path, it HIP incurs
      unacceptable performance drawbacks for kernel-space
      implementations. Also, implementing and integrating a full ICE/STUN/TURN
      protocol stack as specified in Legacy ICE-HIP results in a considerable
      amount of effort and
      code code, which could be avoided by re-using reusing and
      extending HIP messages and state machines for the same purpose. Thus,
      this document specifies an alternative NAT traversal mode referred to as
      "Native ICE-HIP" that employs the HIP messaging format instead of STUN
      or TURN for the connectivity checks, keepalives keepalives, and data relaying.
      Native ICE-HIP also specifies how mobility management works in the
      context of NAT traversal, which is missing from the Legacy ICE-HIP
      specification. The native specification is also based on HIPv2, whereas
      the legacy specification is based on HIPv1. The differences to the Legacy
      ICE-HIP are further elaborated in <xref target="sec:ice_diff" />.</t>

      <t>Similarly as target="sec_ice_diff"
      format="default"/>.</t>

      <t>Similar to Legacy ICE-HIP, also this specification builds on the HIP
      registration extensions <xref target="RFC8003" /> format="default"/> and
      the base exchange procedure <xref target="RFC7401" /> format="default"/>
      and its closing procedures, so procedures; therefore, the reader is recommended to get
      familiar with the relevant specifications. In a nutshell, the
      registration extensions allow a HIP Initiator (usually a "client" host)
      to ask for specific services from a HIP Responder (usually a "server"
      host). The registration parameters are included in a base exchange,
      which is essentially a four-way Diffie-Hellman key exchange
      authenticated using the public keys of the end-hosts. end hosts. When the hosts
      negotiate support for ESP <xref target="RFC7402" /> format="default"/>
      during the base exchange, they can deliver ESP protected ESP-protected application
      payload to each other.  When either of the hosts moves and changes its
      IP address, the two hosts re-establish connectivity using the mobility
      extensions <xref target="RFC8046" />. format="default"/>. The reader is also
      recommended to get familiar with the mobility
      extensions, but basically it extensions; basically,
      the process is a three-way procedure, procedure where the mobile host first
      announces its new location to the peer, and
      then peer; then, the peer tests
      for connectivity (so called (the so-called return routability check), for which check); and then, the
      mobile hosts host must respond to the announcement in order to activate its
      new location. This specification builds on the mobility procedures, but
      modifies it them to be compatible with ICE. The differences to in the mobility
      extensions are specified in <xref target="sec:hip_diff" />. target="sec_hip_diff"
      format="default"/>. It is worth noting that multihoming support as
      specified in <xref target="RFC8047" /> format="default"/> is left for
      further study.
      </t> study.</t>

      <t>This specification builds heavily on the ICE methodology, so it is
      recommended that the reader is familiar with the ICE specification <xref
      target="RFC8445" /> format="default"/> (especially the overview). However, native
      Native ICE-HIP does not implement all the features in ICE, and, ICE; hence,
      the different features of ICE are cross referenced using <xref
      target="RFC2119"/>
      target="RFC2119" format="default"/> terminology for clarity. <xref
      target="sec:ice_diff" />
      target="sec_ice_diff" format="default"/> explains the differences to
      ICE, and it is recommended that the reader would read also this section
      in addition to the ICE specification.
      </t>

      <!--
      <t>Two HIP specific NAT traversal techniques for HIP are specified in <xref
      target="RFC5770"/>. One of them uses only UDP encapsulation, while the
      other uses also the Interactive Connectivity Establishment (ICE) <xref
      target="RFC8445"/> protocol, which in turn uses Session Traversal
      Utilities for NAT (STUN) <xref target="RFC5389"/> and Traversal Using
      Relays around NAT (TURN) <xref target="RFC5766"/> protocols to achieve a
      reliable NAT traversal solution. </t> --> specification.</t>

    </section>

    <!-- ***************************************************************** -->

    <section title="Terminology">

      <!-- numbered="true" toc="default">
      <name>Terminology</name>

        <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> -->

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174" /> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      <t>This document borrows terminology from <xref target="RFC5770"/>, target="RFC5770"
      format="default"/>, <xref target="RFC7401"/>, target="RFC7401" format="default"/>, <xref
      target="RFC8046"/>,
      target="RFC8046" format="default"/>, <xref target="I-D.ietf-hip-rfc4423-bis"/>,
      target="RFC9068" format="default"/>, <xref
      target="RFC8445"/>,
      target="RFC8445" format="default"/>, and <xref target="RFC5389"/>. target="RFC8489"
      format="default"/>. The following terms recur in the text:
        <list style="hanging">

          <!--
          <t hangText="Rendezvous server:"><vspace blankLines="0"/> A host
          that forwards I1 packets to the Responder.<vspace
          blankLines="0"/></t> -->

          <t hangText="ICE:"><vspace blankLines="0"/>
	  Interactive text:</t>
      <dl newline="true" spacing="normal">

	<dt>ICE:</dt>
        <dd>Interactive Connectivity Establishment (ICE) protocol as specified
	in <xref
	  target="RFC8445"/>
	  <vspace blankLines="0"/></t>

          <t hangText="Legacy ICE-HIP:"><vspace blankLines="0"/>
          Refers target="RFC8445" format="default"/>.</dd>
        <dt>Legacy ICE-HIP:</dt>
        <dd>Refers to the "Basic Host Identity Protocol (HIP) Extensions for
	Traversal of Network Address Translators" as specified in <xref
	target="RFC5770" />. format="default"/>. The protocol specified in this
	document offers an alternative to Legacy ICE-HIP.<vspace
          blankLines="0"/></t>

          <t hangText="Native ICE-HIP:"><vspace blankLines="0"/>
	  The ICE-HIP.</dd>
        <dt>Native ICE-HIP:</dt>
        <dd>The protocol specified in this document (Native NAT Traversal Mode
	for HIP).
	  <vspace blankLines="0"/></t>

          <t hangText="Initiator:"><vspace
          blankLines="0"/> The Initiator is the HIP).</dd>
        <dt>Initiator:</dt>
        <dd>The host that initiates the base exchange using
	I1 message <xref target="RFC7401" />.
          </t>

          <t hangText="Responder:"><vspace
          blankLines="0"/> format="default"/>.</dd>
        <dt>Responder:</dt>
        <dd> The Responder is the host that receives the I1 packet from the
	Initiator <xref target="RFC7401" />.
          </t>

          <t hangText="Control format="default"/>.</dd>
        <dt>Control Relay Server"><vspace blankLines="0"/> A Server</dt>
        <dd>A registrar host that forwards any kind of HIP control plane
	packets between the Initiator and the Responder. This host is critical
	because it relays the locators between the Initiator and the Responder,
	Responder so that they can try to establish a direct communication
	path with each other. This host is used to replace HIP rendezvous servers Rendezvous
	Servers <xref target="RFC8004" /> format="default"/> for hosts operating
	in private address realms. In the Legacy ICE-HIP specification <xref
	target="RFC5770" />, format="default"/>, this host is denoted as "HIP
	Relay Server".
          <vspace blankLines="0"/></t>

          <t hangText="Control Server".</dd>
        <dt>Control Relay Client:"><vspace blankLines="0"/>
	  A Client:</dt>
        <dd>A requester host that registers to a Control Relay Server
	requesting it to forward
          control-plane control plane traffic (i.e. (i.e., HIP control
	messages). In the Legacy ICE-HIP specification <xref target="RFC5770" />,
	format="default"/>, this is denoted as "HIP Relay Client".
	  <vspace blankLines="1"/></t>

          <t hangText="Data Client".</dd>
        <dt>Data Relay Server:"><vspace blankLines="0"/> A Server:</dt>
        <dd>A new entity introduced in this document; a registrar host that
	forwards HIP related data plane packets, such as Encapsulating
	Security Payload (ESP) <xref target="RFC7402"/>, target="RFC7402" format="default"/>,
	between two hosts. This host implements similar functionality as TURN servers.
          <vspace blankLines="0"/></t>

          <t hangText="Data
	servers.</dd>
        <dt>Data Relay Client:"><vspace blankLines="0"/>
	  A Client:</dt>
        <dd>A requester host that registers to a Data Relay Server requesting
	it to forward
          data-plane data plane traffic (e.g. ESP traffic). This
	functionality is a new and introduced in this
	  document.
	  <vspace blankLines="1"/></t>

          <!--
          <t hangText="TURN server:"><vspace blankLines="0"/> A server that
          forwards data traffic between two end-hosts as defined in <xref
          target="RFC5766"/>.<vspace blankLines="0"/></t> -->

          <t hangText="Locator:"><vspace blankLines="0"/> As document.</dd>

          <dt>Locator:</dt>
        <dd><t>As defined in <xref
          target="RFC8046"/>: target="RFC8046" format="default"/>: "A
        name that controls how the packet is routed through the network and
        demultiplexed by the end-host. end host. It may include a concatenation of
        traditional network addresses such as an IPv6 address and end-to-end
        identifiers such as an ESP Security Parameter Index (SPI). SPI. It may also include transport port
        numbers or IPv6 Flow Labels as demultiplexing context, or it may
        simply be a network address."
          <vspace blankLines="0"/></t>

          <t hangText="LOCATOR_SET
      </t>
	</dd>
        <dt>LOCATOR_SET (written in capital letters):"><vspace
          blankLines="0"/> Denotes letters):</dt>
        <dd>Denotes a HIP control packet parameter that bundles multiple
	locators together <xref target="RFC8046" />.  <vspace blankLines="0"/></t>

          <t hangText="HIP offer:"><vspace blankLines="0"/>
	  Before format="default"/>.</dd>
        <dt>HIP offer:</dt>
        <dd>Before two end-hosts end hosts can establish a communication channel using
        the NAT traversal procedures defined in this document, they need to
        exchange their locators (i.e. (i.e., candidates) with each other. In ICE,
        this procedure is called Candidate Exchange and Exchange; it does not specify how
        the candidates are exchanged exchanged, but Session Description Protocol (SDP)
        "offer/answer" is mentioned as an example. In contrast, the Candidate
        Exchange in HIP is the base exchange itself or a subsequent UPDATE prodecure
        procedure occurring after a handover. Following <xref target="RFC5770" />
        format="default"/> and
	  SDP related SDP-related naming conventions <xref
        target="RFC3264" />, format="default"/>, "HIP offer" is the the Initiator's
        LOCATOR_SET parameter in a HIP I2 or in an UPDATE control packet.
	  </t>

          <t hangText="HIP answer:"><vspace blankLines="0"/> packet.</dd>
        <dt>HIP answer:</dt>
        <dd> The Responder's LOCATOR_SET parameter in a HIP R2 or UPDATE
	control packet. Corresponds The HIP answer corresponds to the SDP answer parameter <xref
	target="RFC3264" />, format="default"/> but is HIP specific. Please refer
	also to the longer description of the "HIP offer" term above.</t>

          <t hangText="HIP above.</dd>
        <dt>HIP connectivity checks:"><vspace
          blankLines="0"/> checks:</dt>
        <dd> In order to obtain a direct end-to-end communication path
	(without employing a Data Relay Server), two communicating HIP hosts
	try to "punch holes" through their NAT boxes using this mechanism. It
	is similar to the ICE connectivity checks, checks but implemented using HIP
	return routability checks.
          </t>

          <t hangText="Controlling host:"><vspace
          blankLines="0"/>The checks.</dd>
        <dt>Controlling host:</dt>
        <dd>The controlling host <xref target="RFC8445" /> format="default"/> is
	always the Initiator in the context of this specification. It
	nominates the candidate pair to be used with the controlled host.
          </t>

          <t hangText="Controlled host:"><vspace
          blankLines="0"/>The host.</dd>
        <dt>Controlled host:</dt>
        <dd>The controlled host <xref target="RFC8445" /> format="default"/> is
	always the Responder in the context of this specification. It waits
	for the controlling host to nominate an address candidate pair.
          </t>

          <t hangText="Checklist:"><vspace blankLines="0"/>A pair.</dd>

        <dt>Checklist:</dt>
        <dd>A list of address candidate pairs that need to be tested for
	connectivity (same as in <xref target="RFC8445" />).<vspace
          blankLines="0"/></t>

          <t hangText="Transport address:"><vspace blankLines="0"/> Transport
          layer
	format="default"/>).</dd>
        <dt>Transport address:</dt>
        <dd>Transport-layer port and the corresponding IPv4/v6 address (same
	as in <xref target="RFC8445" />).<vspace
          blankLines="0"/></t>

          <t hangText="Candidate:"><vspace blankLines="0"/> A format="default"/>).</dd>
        <dt>Candidate:</dt>
        <dd>A transport address that is a potential point of contact for
	receiving data (same as in <xref target="RFC8445" />).<vspace
          blankLines="0"/></t>

          <t hangText="Host candidate:"><vspace blankLines="0"/> A
	format="default"/>).</dd>
        <dt>Host candidate:</dt>
        <dd>A candidate obtained by binding to a specific port from an IP
	address on the host (same as in <xref target="RFC8445" />).<vspace blankLines="0"/></t>

          <t hangText="Server reflexive candidate:"><vspace blankLines="0"/> A
	format="default"/>).</dd>
        <dt>Server-reflexive candidate:</dt>
        <dd>A translated transport address of a host as observed by a Control
	or Data Relay Server (same as in <xref target="RFC8445" />). <vspace blankLines="0"/></t>

          <t hangText="Peer reflexive candidate:"><vspace blankLines="0"/> A
	format="default"/>).</dd>
        <dt>Peer-reflexive candidate:</dt>
        <dd>A translated transport address of a host as observed by its peer
	(same as in <xref target="RFC8445" />).
          <vspace blankLines="0"/></t>

          <t hangText="Relayed candidate:"><vspace blankLines="0"/> A format="default"/>).</dd>
        <dt>Relayed candidate:</dt>
        <dd>A transport address that exists on a Data Relay Server. Packets
	that arrive at this address are relayed towards the Data Relay
	Client. The concept is the same as in <xref target="RFC8445" />,
	format="default"/>, but a Data Relay Server is used instead of a TURN server.</t>

          <t hangText="Permission:"><vspace blankLines="0"/> In
	server.</dd>
        <dt>Permission:</dt>
        <dd>In the context of Data Relay Server, permission refers to a
	concept similar to TURN's (<xref target="RFC5766" />) <xref target="RFC8656" format="default"/>
	channels. Before a host can use a relayed candidate to forward traffic
	through a Data Relay Server, the host must activate the relayed
	candidate with a specific peer host.
          <vspace blankLines="0"/></t>

          <t hangText="Base:"><vspace blankLines="0"/> Similarly as host.</dd>

        <dt>Base:</dt>
        <dd>Similar to that described in <xref target="RFC8445" />, format="default"/>, the
	base of a candidate is the local source address a host uses to send
	packets for the associated candidate. For example, the base of a
          server reflexive
	server-reflexive address is the local address the host used for
	registering itself to the associated Control or Data Relay Server. The
	base of a host candidate is equal to the host candidate itself.
	  <vspace blankLines="0"/></t>

        </list>
      </t>

    </section><!-- Terminology --> itself.</dd>
      </dl>
    </section>

    <section title="Overview numbered="true" toc="default">
      <name>Overview of Operation">

      <?rfc needLines="20" ?> Operation</name>
      <figure anchor="fig:overview"
        title="Example anchor="fig_overview">
        <name>Example Network Configuration"> Configuration</name>
        <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
               +--------------+
               |    Control   |
+--------+     | Relay Server |      +--------+
| Data   |     +----+-----+---+      | Data   |
| Relay  |         /       \         | Relay  |
| Server |        /         \        | Server |
+--------+       /           \       +--------+
                /             \
               /               \
              /                 \
             /  <- Signaling ->  \
            /                     \
      +-------+                +-------+
      |  NAT  |                |  NAT  |
      +-------+                +-------+
       /                              \
      /                                \
 +-------+                           +-------+
 | Init- |                           | Resp- |
 | iator |                           | onder |
 +-------+                           +-------+
]]></artwork>
      </figure>
      <t> In the example configuration depicted in <xref
      target="fig:overview"/>, target="fig_overview"
      format="default"/>, both Initiator and Responder are behind one or more
      NATs, and both private networks are connected to the public Internet. To
      be contacted from behind a NAT, at least the Responder must be
      registered with a Control Relay Server reachable on the public
      Internet. The Responder may have also registered to a Data Relay Server
      that can forward the data plane in case NAT traversal fails. While,
      strictly speaking, the Initiator does not need a Data Relay Server, it
      may act in the other role with other hosts, and hosts; connectivity with the
      Data Relay Server of the Responder may fail, so the Initiator may also
      need to register to a Cotrol Control and/or Data Relay Server. It is worth
      noting that a Control and Data Relay does not forge the source address
      of a passing packet, packet but always translates the source address and source
      port of a packet to be forwarded (to its own).</t>

      <t>
      We
      <t>We assume, as a starting point, that the Initiator knows both the
      Responder's Host Identity Tag (HIT) and the address(es) of the
      Responder's Control Relay Server(s) (how the Initiator learns of the
      Responder's Control Relay Server is outside of the scope of this
      document, but it may be learned through DNS or another name service). The first
      steps are for both the Initiator and Responder to register with a
      Control Relay Server (need not be the same one) and gather a set of
      address candidates. The hosts use either Control Relay Servers or Data
      Relay Servers for gathering the candidates. Next, the HIP base exchange
      is carried out by encapsulating the HIP control packets in UDP datagrams
      and sending them through the Responder's Control Relay Server.  As part
      of the base exchange, each HIP host learns of the peer's candidate
      addresses through the HIP offer/answer procedure embedded in the base
      exchange. <!--, which follows closely the ICE <xref target="RFC8445"/> protocol. -->
</t>

      <!-- WHAT ABOUT HICCUPS AND DATA RELAY ???
           Jeff: I think you can omit this, since RFC 6078 is for RFC 5201 (HIPv1). (Wait until if/when 6078 is updated for HIPv2.) -->

      <!-- send ESP transform -> hiccups incompatible (no need to defined here because hiccups is not HIPv2 compatible -Jeff) -->

      <t> Once the base exchange is completed, two HIP hosts have established
      a working communication session (for signaling) via a Control Relay
      Server, but the hosts still have to find a better path, preferably
      without a Data Relay Server, for the ESP data flow. For this,
      connectivity checks are carried out until a working pair of addresses is
      discovered.  At the end of the procedure, if successful, the hosts will
      have established a UDP-based tunnel that traverses both NATs, NATs with the
      data flowing directly from NAT to NAT or via a Data Relay Server. At
      this point, also the HIP signaling can also be sent over the same
      address/port pair, and is demultiplexed (or, in other words, separated)
      from IPsec as described in the UDP encapsulation standard for IPsec
      <xref target="RFC3948"/>. target="RFC3948" format="default"/>. Finally, the two hosts send
      NAT keepalives as needed in order keep their UDP-tunnel state active in
      the associated NAT boxes.</t>
      <t> If either one of the hosts knows that it is not behind a NAT, hosts
      can negotiate during the base exchange a different mode of NAT traversal
      that does not use HIP connectivity checks, but only UDP encapsulation of
      HIP and ESP. Also, it is possible for the Initiator to simultaneously try
      a base exchange with and without UDP encapsulation. If a base exchange
      without UDP encapsulation succeeds, no HIP connectivity checks or UDP
      encapsulation of ESP are needed. </t>
    </section>

    <!-- ***************************************************************** -->

    <section anchor="sec:protocol" title="Protocol Description">

      <!--
      <t> This section describes the normative behavior of the protocol
      extension. Examples of packet exchanges are provided for illustration
      purposes.</t> --> anchor="sec_protocol" numbered="true" toc="default">
      <name>Protocol Description</name>

      <t> This section describes the normative behavior of the "Native
      ICE-HIP" protocol extension. Most of the procedures are similar to what
      is defined in <xref
      target="RFC5770"/> target="RFC5770" format="default"/> but with
      different, or additional, parameter types and values. In addition, a new
      type of relaying server, Data Relay Server, is specified. Also, it
      should be noted that HIP version 2 <xref
      target="RFC7401"/> MUST target="RFC7401"
      format="default"/> <bcp14>MUST</bcp14> be used instead of HIPv1 with
      this NAT traversal mode. </t>
      <section anchor="sec:registration" title="Relay Registration"> anchor="sec_registration" numbered="true" toc="default">
        <name>Relay Registration</name>
        <t>In order for two hosts to communicate over NATted NATed environments,
	they need a reliable way to exchange information. To achieve this,
	"HIP Relay Server" is defined in <xref
        target="RFC5770"/>. target="RFC5770"
	format="default"/>. It supports the relaying of HIP control plane traffic
	over UDP in NATted environments, NATed environments and forwards HIP control packets
	between the Initiator and the Responder. In this document, the HIP
	Relay Server is denoted as "Control Relay Server" for better alignment
	with the rest of the terminology.  The registration to the Control
	Relay Server can be achieved using the RELAY_UDP_HIP parameter as
	explained later in this section.</t>

        <t>To guarantee also guarantee data plane delivery over varying types of NAT
	devices, a host MAY <bcp14>MAY</bcp14> also register for UDP encapsulated UDP-encapsulated
	ESP relaying using Registration Type RELAY_UDP_ESP (value [TBD by
        IANA: 3]). 3).  This service may be coupled with the Control Relay Server
	or offered separately on another server. If the server supports
	relaying of UDP
        encapsulated UDP-encapsulated ESP, the host is allowed to register for
	a data
        relaying data-relaying service using the registration extensions in Section 3.3 of <xref
        target="RFC8003"/>).
	target="RFC8003" sectionFormat="of" section="3.3"/>. If the server
	has sufficient relaying resources (free port numbers, bandwidth, etc.)
	available, it opens a UDP port on one of its addresses and signals the
	address and port to the registering host using the RELAYED_ADDRESS
	parameter (as defined in <xref
        target="sec:relayed_address"/> target="sec_relayed_address"
	format="default"/> in this document). If the Data Relay Server would
	accept the data relaying data-relaying request but does not currently have enough
	resources to provide data relaying data-relaying service, it
        MUST <bcp14>MUST</bcp14>
	reject the request with Failure Type "Insufficient resources" <xref target="RFC8003"/>.
	target="RFC8003" format="default"/>. </t>

	<!--
	A Control Relay Server MUST silently drop packets to a
        Control Relay Client that has not previously registered with
        the HIP relay (since it would not anyway know where to relay ). -->

        <t>
	The

        <t>The registration process follows the generic registration
	extensions defined in <xref target="RFC8003"/>. target="RFC8003" format="default"/>. The
	HIP control plane relaying registration follows <xref
        target="RFC5770"/>, target="RFC5770"
	format="default"/>, but the data plane registration is different. It
	is worth noting that if the HIP control and data plane relay services
	reside on different hosts, the client has to register separately to
	each of them. In the example shown in <xref target="fig:reg"/>, target="fig_reg"
	format="default"/>, the two services are coupled on a single host. The
	text uses "Relay Client" and "Relay Server" as a shorthand when the
	procedures apply both to control and data cases.</t>
        <figure anchor="fig:reg" title="Example anchor="fig_reg">
          <name>Example Registration with a HIP Relay"> Relay</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
  Control/Data                                           Control/Data
  Relay Client (Initiator)                   Relay Server (Responder)
  |   1. UDP(I1)                                                    |
  +---------------------------------------------------------------->|
  |                                                                 |
  |   2. UDP(R1(REG_INFO(RELAY_UDP_HIP,[RELAY_UDP_ESP])))           |
  |<----------------------------------------------------------------+
  |                                                                 |
  |   3. UDP(I2(REG_REQ(RELAY_UDP_HIP),[RELAY_UDP_ESP]))            |
  +---------------------------------------------------------------->|
  |                                                                 |
  |   4. UDP(R2(REG_RES(RELAY_UDP_HIP,[RELAY_UDP_ESP]), REG_FROM,   |
  |          [RELAYED_ADDRESS]))                                    |
  |<----------------------------------------------------------------+
  |                                                                 |
]]>
          </artwork>
]]></artwork>
        </figure>

        <t> In step 1, the Relay Client (Initiator) starts the registration
	procedure by sending an I1 packet over UDP to the Relay Server. It is RECOMMENDED
	<bcp14>RECOMMENDED</bcp14> that the Relay Client select a random
	source port number from the ephemeral port range 49152-65535 for
	initiating a base exchange.  Alternatively, a host MAY <bcp14>MAY</bcp14>
	also use a single fixed port for initiating all outgoing
	connections. However, the allocated port MUST <bcp14>MUST</bcp14> be
	maintained until all of the corresponding HIP Associations associations are
	closed. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the Relay Server listen
	to incoming connections at UDP port 10500. If some other port number
	is used, it needs to be known by potential Relay Clients.</t>
        <t> In step 2, the Relay Server (Responder) lists the services that it
        supports in the R1 packet. The support for HIP control plane over UDP
        relaying is denoted by the Registration Type value RELAY_UDP_HIP (see
        <xref
        target="sec:reg-types"/>). target="sec_reg-types" format="default"/>). If the server supports also
        supports the relaying of ESP traffic over UDP, it includes also includes
        the Registration type Type value RELAY_UDP_ESP.</t>
        <t> In step 3, the Relay Client selects the services for which it
	registers and lists them in the REG_REQ parameter. The Relay Client
	registers for the Control Relay service by listing the RELAY_UDP_HIP
	value in the request parameter. If the Relay Client requires also requires ESP
	relaying over UDP, it lists also RELAY_UDP_ESP.
        </t> RELAY_UDP_ESP.</t>
        <t> In step 4, the Relay Server concludes the registration procedure
	with an R2 packet and acknowledges the registered services in the
	REG_RES parameter. The Relay Server denotes unsuccessful registrations
	(if any) in the REG_FAILED parameter of R2. The Relay Server also
	includes a REG_FROM parameter that contains the transport address of
	the Relay Client as observed by the Relay Server (Server Reflexive (server-reflexive
	candidate). If the Relay Client registered to ESP relaying ESP-relaying service,
	the Relay Server includes a RELAYED_ADDRESS parameter that describes the
	UDP port allocated to the Relay Client for ESP relaying. It is worth
	noting that the Data Relay Client must first activate this UDP port by
	sending an UPDATE message to the Data Relay Server that includes a
	PEER_PERMISSION parameter as described in <xref target="sec:forwarding" />
	target="sec_forwarding" format="default"/> both after base exchange
	and handover procedures. Also, the Data Relay Server should follow the
	port allocation recommendations in <xref target="sec:reuse" />.
        </t> target="sec_reuse"
	format="default"/>.</t>
        <t>After the registration, the Relay Client sends periodically sends NAT
        keepalives to the Relay Server in order to keep the NAT bindings
        between the Relay Client and the relay alive. The keepalive extensions
        are described in <xref target="sec:nat-keepalives"/>.</t> target="sec_nat-keepalives"
        format="default"/>.</t>
        <t> The Data Relay Client MUST <bcp14>MUST</bcp14> maintain an active HIP
        association with the Data Relay Server as long as it requires the data relaying
        data-relaying service. When the HIP association is closed (or times
        out), or the registration lifetime passes without the Data Relay
        Client refreshing the registration, the Data Relay Server MUST
        <bcp14>MUST</bcp14> stop relaying packets for that host and close the
        corresponding UDP port (unless other Data Relay Clients are still
        using it). </t>
        <t> The Data Relay Server SHOULD <bcp14>SHOULD</bcp14> offer a different
	relayed address and port for each Data Relay Client because not doing
	so can cause problems with stateful firewalls (see <xref target="sec:reuse" />).
	target="sec_reuse" format="default"/>). </t>
        <t>When a Control Relay Client sends an UPDATE (e.g., due to host
	movement or to renew service registration), the Control Relay Server
	MUST
	<bcp14>MUST</bcp14> follow the general guidelines defined in <xref
	target="RFC8003" />, format="default"/>, with the difference that all
	UPDATE messages are delivered on top of UDP. In addition to this, the
	Control Relay Server MUST <bcp14>MUST</bcp14> include the REG_FROM
	parameter in all UPDATE responses sent to the Control Relay Client.
	This applies to both renewals of service registration and to host
	movement.  It is especially important for the case of host
	movement, as this is the mechanism that allows the Control Relay
	Client to learn its new server reflexive server-reflexive address candidate.
	</t> candidate.</t>
        <t>A Data Relay Client can request multiple relayed candidates from
	the Data Relay Server (e.g., for the reasons described in <xref target="sec:conflicting" />).
	target="sec_conflicting" format="default"/>). After the base exchange
	with registration, the Data Relay Client can request additional
	relayed candidates similarly as during the base exchange. The Data
	Relay Client sends an UPDATE message REG_REQ parameter requesting for
	the RELAY_UDP_ESP service. The UPDATE message MUST <bcp14>MUST</bcp14> also
	include a SEQ and a an ECHO_REQUEST_SIGNED parameter. The Data Relay
	Server MUST <bcp14>MUST</bcp14> respond with an UPDATE message that
	includes the corresponding response parameters: REG_RES, ACK and ECHO_REQUEST_SIGNED .
	ECHO_REQUEST_SIGNED. In case the Data Relay Server allocated a new
	relayed UDP port for the Data Relay Client, the REG_RES parameter MUST
	<bcp14>MUST</bcp14> list RELAY_UDP_ESP as a service and the UPDATE
	message MUST <bcp14>MUST</bcp14> also include a RELAYED_ADDRESS parameter
	describing the relayed UDP port. The Data Relay Server MUST
	<bcp14>MUST</bcp14> also include the Server
	Reflexive server-reflexive candidate in a
	REG_FROM parameter. It is worth mentioning that the Data Relay Client MUST
	<bcp14>MUST</bcp14> activate the UDP port as described in <xref target="sec:forwarding" />
	target="sec_forwarding" format="default"/> before it can be used for
	any ESP relaying.</t>

        <t>A Data Relay Client may unregister a relayed candidate in
	two ways. It can wait for its lifetime to expire or it can
	explicitly request it with zero lifetime using the UPDATE
	mechanism. The Data Relay Client can send an a REG_REQ parameter
	with zero lifetime to the Data Relay Server in order to expire
	all relayed candidates. To expire a specific relayed
	candidate, the Data Relay Client MUST <bcp14>MUST</bcp14> also include
	a RELAYED_ADDRESS parameter as sent by the server in the UPDATE
	message. Upon closing the HIP association (CLOSE-CLOSE-ACK
	procedure initiated by either party), the Data Relay Server
	MUST
	<bcp14>MUST</bcp14> also expire all relayed candidates.</t>
        <t>Please also refer to <xref target="sec:cross_protocol" /> target="sec_cross_protocol"
	format="default"/> for protection against cross-protocol attacks for
	both Control Relay Client and Server.</t>

	<!-- explained elsewhere...
	<t>As the relay is assumed to have a publicly-reachable
	address, it does not have to include a NAT_TRAVERSAL_MODE
	parameter in an R1 message, thus avoiding any NAT penetration
	procedures. This results in the HIP control and data plane
	being tunneled over UDP as described in <xref
	target="sec:minimal" />. In other words, a relay SHOULD NOT
	OFFER ICE-HIP-UDP mode, but it MAY offer UDP-ENCAPSULATION as
	NAT traversal mode in a NAT_TRAVERSAL_MODE parameter in an R1
	message (which has the same result as omitting the parameter).
	</t>
	-->

      </section> <!-- relay reg -->

      <section anchor="sec:gathering" title="Transport Address Candidate Gathering at

      </section>

      <section anchor="sec_gathering" numbered="true" toc="default">
        <name>Transport Address Candidate Gathering at the Relay Client"> Client</name>
        <t> An Initiator needs to gather a set of address candidates
        before contacting a (non-relay) Responder. The candidates are
        needed for connectivity checks that allow two hosts to
        discover a direct, non-relayed path for communicating with
        each other. One server reflexive server-reflexive candidate can be discovered
        during the registration with the Control Relay Server from the
        REG_FROM parameter (and another from Data Relay Server if one
        is employed). <!-- It should be noted discovering multiple address
        candidates in a multihoming configuration are left for further
        study. -->

 </t>
        <t> The candidate gathering can be done at any time, but it needs to be
        done before sending an I2 or R2 in the base exchange if ICE-HIP-UDP mode is to be
        used for the connectivity checks. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that all three
        types of candidates (host, server reflexive, and relayed) are gathered
        to maximize the probability of successful NAT traversal. However, if no
        Data Relay Server is used, and the host has only a single local IP address to
        use, the host MAY <bcp14>MAY</bcp14> use the local address as the only host candidate and
        the address from the REG_FROM parameter discovered during the Control Relay Server
        registration as a server reflexive server-reflexive candidate. In this case, no further
        candidate gathering is needed. </t>
        <t>A Data Relay Client MAY <bcp14>MAY</bcp14> register only a single
	relayed candidate that it uses with multiple other peers. However, it
	is
	RECOMMENDED <bcp14>RECOMMENDED</bcp14> that a Data Relay Client registers a new
	server relayed candidate for each of its peer peers for the reasons
	described in <xref
	target="sec:conflicting" />. target="sec_conflicting" format="default"/>. The
	procedures for registering multiple relayed candidates are described
	in <xref
	target="sec:registration" />.</t> target="sec_registration" format="default"/>.</t>
        <t> If a Relay Client has more than one network interface, it
        can discover additional server reflexive server-reflexive candidates by sending
        UPDATE messages from each of its interfaces to the Relay
        Server.  Each such UPDATE message MUST <bcp14>MUST</bcp14> include the following
        parameters: the registration request (REG_REQ) parameter with
        Registration Type CANDIDATE_DISCOVERY (value [TBD by IANA: 4]) 4)
        and the ECHO_REQUEST_SIGNED parameter.  When a Control Relay Server
        receives an UPDATE message with registration request
        containing a CANDIDATE_DISCOVERY type, it MUST <bcp14>MUST</bcp14> include a
        REG_FROM parameter, containing the same information as if this
        were a Control Relay Server registration, to the response (in
        addition to the mandatory ECHO_RESPONSE_SIGNED parameter). This request
        type SHOULD NOT <bcp14>SHOULD NOT</bcp14> create any state at the Control Relay
        Server.</t>
        <t>The rules in section 5.1.1 in <xref target="RFC8445" /> sectionFormat="of"
	section="5.1.1"/> for candidate gathering are followed here. A number
	of host candidates (loopback, anycast and others) should be excluded as
	described in section 5.1.1.1 of the ICE specification <xref (<xref target="RFC8445" />.
	sectionFormat="of" section="5.1.1.1"/>). Relayed candidates SHOULD
	<bcp14>SHOULD</bcp14> be gathered in order to guarantee successful NAT
	traversal, and implementations SHOULD <bcp14>SHOULD</bcp14> support this
	functionality even if it will not be used in deployments in order to
	enable it by software configuration update if needed at some point.

	<!-- A host SHOULD employ only a single
	server for gathering the candidates for a single HIP
	association; either one server providing both Control and Data Relay Server
	functionality, or one Control Relay Server and
	also Data Relay Server if the functionality is offered by another
	server. When the relay service is split between two hosts, the
	server reflexive candidate from the Control Relay Server SHOULD be used
	instead of the one provided by the Data Relay Server. -->

	<!-- If a relayed
	candidate is identical to a host candidate, the relayed
	candidate must be discarded. NAT64 considerations in section
	4.1.1.2 of <xref target="RFC8445" /> apply as well. -->

	Similarly

	Similarly, as explained in section 5.1.1.2 of the ICE specification <xref (<xref
	target="RFC8445" />, sectionFormat="of" section="5.1.1.2"/>), if an
	IPv6-only host is in a network that utilizes NAT64 <xref
	target="RFC6146" /> format="default"/> and DNS64 <xref target="RFC6147" />
	format="default"/> technologies, it may also gather IPv4 server-
	reflexive
	server-reflexive and/or relayed candidates from IPv4-only Control or
	Data Relay Servers.  IPv6-only hosts SHOULD <bcp14>SHOULD</bcp14> also
	utilize IPv6 prefix discovery <xref target="RFC7050" />
	format="default"/> to discover the IPv6 prefix used by NAT64 (if any)
	and generate server-reflexive candidates for each IPv6-only interface,
	accordingly.  The NAT64 server-reflexive candidates are prioritized
	like IPv4 server-reflexive candidates.

      </t>

      <t>HIP based candidates.</t>
        <t>HIP-based connectivity can be utilized by IPv4 applications using
	Local Scope Identifiers (LSIs) and by IPv6 based IPv6-based applications using
	HITs. The LSIs and HITs of the local virtual interfaces MUST
	<bcp14>MUST</bcp14> be excluded in the candidate gathering phase as
	well to avoid creating unnecessary loopback connectivity tests.</t>

        <!-- was: ..if STUN and *TURN* servers are available.. -->

      <t>Gathering of candidates MAY <bcp14>MAY</bcp14> also be performed by other
      means than described in this section. For example, the candidates could
      be gathered as specified in Section 4.2 of <xref
      target="RFC5770"/> target="RFC5770"
      sectionFormat="of" section="4.2"/> if STUN servers are available, or if
      the host has just a single interface and no STUN or Data Relay Server
      are available. </t>
        <t>Each local address candidate MUST <bcp14>MUST</bcp14> be assigned a
	priority.  The following recommended formula (as described in <xref
	target="RFC8445" />) SHOULD format="default"/>) <bcp14>SHOULD</bcp14> be used:

      <list style="empty">
        <t>priority
	used:</t>
        <t indent="3">
          priority = (2^24)*(type (2<sup>24</sup>)*(type preference) +
                      (2^8)*(local
                      (2<sup>8</sup>)*(local preference) +
                      (2^0)*(256
                      (2<sup>0</sup>)*(256 - component ID)</t>
      </list></t> ID)
        </t>
        <t>In the formula, the type preference follows the ICE specification
        (as defined in section 5.1.2.1 in <xref target="RFC8445" />): sectionFormat="of"
        section="5.1.2.1"/>): the RECOMMENDED <bcp14>RECOMMENDED</bcp14> values are 126
        for host candidates, 100 for server reflexive server-reflexive candidates, 110 for
      peer reflexive
        peer-reflexive candidates, and 0 for relayed candidates.  The highest
        value is 126 (the most preferred) and lowest is 0 (last resort). For
        all candidates of the same type, the preference type value MUST
        <bcp14>MUST</bcp14> be identical, and, correspondingly, the value MUST
        <bcp14>MUST</bcp14> be different for different types. For peer reflexive
        peer-reflexive values, the type preference value MUST <bcp14>MUST</bcp14>
        be higher than for server reflexive server-reflexive types. It should be noted that peer reflexive
        peer-reflexive values are learned later during connectivity checks, so a host cannot employ it
      during candidate gathering stage yet.</t>
        checks.</t>
        <t>Following the ICE specification, the local preference MUST
        <bcp14>MUST</bcp14> be an integer from 0 (lowest preference) to 65535
        (highest preference) inclusive. In the case the host has only a single
        address candidate, the value SHOULD <bcp14>SHOULD</bcp14> be 65535. In the
        case of multiple candidates, each local preference value MUST
        <bcp14>MUST</bcp14> be unique. Dual-stack considerations for IPv6
      apply also
        apply here as defined in <xref target="RFC8445" /> in section 5.1.2.2.</t> sectionFormat="of"
        section="5.1.2.2"/>.</t>
        <t>Unlike with SDP used in conjunction with ICE, this protocol only
	creates a single UDP flow between the two communicating hosts, so only
	a single component exists. Hence, the component ID value MUST
	<bcp14>MUST</bcp14> always be set to 1.</t>
        <t>As defined in section 14.3 in <xref target="RFC8445" />, sectionFormat="of"
	section="14.3"/>, the retransmission timeout (RTO) for address
	gathering from a Control/Data Relay Server SHOULD <bcp14>SHOULD</bcp14> be
	calculated as
      follows:

      <list style="empty">
        <t>RTO follows:</t>
        <t indent="3">
          RTO = MAX (1000ms, (1000 ms, Ta * (Num-Of-Cands))</t>
      </list> (Num-Of-Cands))
        </t>
        <t>where Ta is the value used for the connectivity check pacing and
	Num-Of-Cands is the number of server-reflexive and relay candidates. A
	smaller value than 1000 ms for the RTO MUST NOT <bcp14>MUST NOT</bcp14> be used.
      </t>
	used.</t>
      </section>
      <section anchor="sec:nat_traversal_mode"
        title="NAT anchor="sec_nat_traversal_mode" numbered="true" toc="default">
        <name>NAT Traversal Mode Negotiation"> Negotiation</name>
        <t> This section describes the usage of a non-critical parameter type
	called NAT_TRAVERSAL_MODE with a new mode called ICE-HIP-UDP. The
	presence of the new mode in the NAT_TRAVERSAL_MODE parameter in a HIP
	base exchange means that the end-host end host supports NAT traversal
	extensions described in this document. As the parameter is
	non-critical (as defined in Section 5.2.1
        of <xref target="RFC7401"/>), target="RFC7401" sectionFormat="of"
	section="5.2.1"/>), it can be ignored by a end-host, an end host, which means that
	the host is not required to support it or may decline to use it.</t>
        <t> With registration with a Control/Data Relay Server, it is usually
	sufficient to use the UDP-ENCAPSULATION mode of NAT traversal since
	the Relay Server is assumed to be in public address space. Thus, the
	Relay Server SHOULD <bcp14>SHOULD</bcp14> propose the UDP-ENCAPSULATION mode
	as the preferred or only mode.  The NAT traversal mode negotiation in
	a HIP base exchange is illustrated in <xref target="fig:nat_traversal_mode"/>.
	target="fig_nat_traversal_mode" format="default"/>. It is worth noting
	that the Relay Server could be located between the hosts, but is
	omitted here for simplicity.</t>
        <figure anchor="fig:nat_traversal_mode"
          title="Negotiation anchor="fig_nat_traversal_mode">
          <name>Negotiation of NAT Traversal Mode"> Mode</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
Initiator                                                  Responder
| 1. UDP(I1)                                                       |
+----------------------------------------------------------------->|
|                                                                  |
| 2. UDP(R1(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ..))              |
|<-----------------------------------------------------------------+
|                                                                  |
| 3. UDP(I2(.., NAT_TRAVERSAL_MODE(ICE-HIP-UDP), ENC(LOC_SET), ..))|
+----------------------------------------------------------------->|
|                                                                  |
| 4. UDP(R2(.., ENC(LOC_SET), ..))                                 |
|<-----------------------------------------------------------------+
|                                                                  |
]]>
          </artwork>
]]></artwork>
        </figure>
        <t> In step 1, the Initiator sends an I1 to the Responder. In Responder.</t>
        <t>In step 2,
	the Responder responds with an R1. As specified in  <xref target="RFC5770"/>,
	target="RFC5770" format="default"/>, the NAT_TRAVERSAL_MODE parameter
	in R1 contains a list of NAT traversal modes the Responder
	supports. The mode specified in this document is ICE-HIP-UDP (value [TBD by IANA: 3]).</t>
	3).</t>
        <t> In step 3, the Initiator sends an I2 that includes a
	NAT_TRAVERSAL_MODE parameter. It contains the mode selected by the
	Initiator from the list of modes offered by the Responder. If
	ICE-HIP-UDP mode was selected, the I2 also includes the "Transport
	address" locators (as defined in <xref target="sec:locator_format"/>) target="sec_locator_format"
	format="default"/>) of the Initiator in a LOCATOR_SET parameter
	(denoted here with LOC_SET). With ICE-HIP-UDP mode, the LOCATOR_SET
	parameter MUST <bcp14>MUST</bcp14> be encapsulated within an ENCRYPTED
	parameter (denoted here with ENC) according to the procedures in sections 5.2.18
	Sections <xref target="RFC7401" section="5.2.18"
	sectionFormat="bare"/> and 6.5 <xref target="RFC7401" section="6.5"
	sectionFormat="bare"/> in <xref target="RFC7401" />.
	format="default"/>. The locators in I2 are the "HIP offer".</t>
        <t> In step 4, the Responder concludes the base exchange with an R2
	packet. If the Initiator chose ICE-HIP-UDP traversal mode, the
	Responder includes a LOCATOR_SET parameter in the R2 packet. With
	ICE-HIP-UDP mode, the LOCATOR_SET parameter MUST <bcp14>MUST</bcp14> be
	encapsulated within an ENCRYPTED parameter according to the procedures
	in sections 5.2.18 Sections <xref target="RFC7401" section="5.2.18"
	sectionFormat="bare"/> and 6.5 <xref target="RFC7401" section="6.5"
	sectionFormat="bare"/> in <xref target="RFC7401" />.
	format="default"/>. The locators in R2, encoded like the locators in
	I2, are the "ICE answer". If the NAT traversal mode selected by the
	Initiator is not supported by the Responder, the Responder SHOULD
	<bcp14>SHOULD</bcp14> reply with a NOTIFY packet with type
	NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER and abort the base exchange.</t>
      </section>
      <section anchor="sec:check_pacing_neg"
        title="Connectivity anchor="sec_check_pacing_neg" numbered="true" toc="default">
        <name>Connectivity Check Pacing Negotiation"> Negotiation</name>
        <t> As explained in Legacy ICE-HIP <xref target="RFC5770"/>, target="RFC5770" format="default"/>, when a NAT
        traversal mode with connectivity checks is used, new transactions
        should not be started too fast to avoid congestion and overwhelming the
        NATs. For this purpose, during the base exchange, hosts can negotiate a
        transaction pacing value, Ta, using a TRANSACTION_PACING parameter in
        R1 and I2 packets. The parameter contains the minimum time (expressed
        in milliseconds) the host would wait between two NAT traversal
        transactions, such as starting a new connectivity check or retrying a
        previous check. The value that is used by both of the hosts is the higher
        of the two offered values.</t>
        <t> The minimum Ta value SHOULD <bcp14>SHOULD</bcp14> be configurable, and if
	no value is configured, a value of 50 ms MUST <bcp14>MUST</bcp14> be
	used. Guidelines for selecting a Ta value are given in <xref
        target="sec:selecting_pacing_value"/>.
	target="sec_selecting_pacing_value" format="default"/>.  Hosts MUST NOT
	<bcp14>MUST NOT</bcp14> use values smaller than 5 ms for the minimum
	Ta, since such values may not work well with some NATs (as explained
	in <xref
        target="RFC8445"/>). target="RFC8445" format="default"/>). The Initiator MUST NOT
	<bcp14>MUST NOT</bcp14> propose a smaller value than what the
	Responder offered.  If a host does not include the TRANSACTION_PACING
	parameter in the base exchange, a Ta value of 50 ms MUST
	<bcp14>MUST</bcp14> be used as that host's minimum value.</t>
      </section>
      <section anchor="sec:relay_bex"
        title="Base anchor="sec_relay_bex" numbered="true" toc="default">
        <name>Base Exchange via Control Relay Server"> Server</name>
        <t> This section describes how the Initiator and Responder perform a
	base exchange through a Control Relay Server. Connectivity pacing
	(denoted as TA_P here) was described in <xref target="sec:check_pacing_neg"/>
	target="sec_check_pacing_neg" format="default"/> and is not repeated
	here.  Similarly, the NAT traversal mode negotiation process (denoted
	as NAT_TM in the example) was described in <xref
        target="sec:nat_traversal_mode"/>
	target="sec_nat_traversal_mode" format="default"/> and is also not
	repeated here. If a Control Relay Server receives an R1 or I2 packet
	without the NAT traversal mode parameter, it MUST <bcp14>MUST</bcp14> drop
	it and SHOULD <bcp14>SHOULD</bcp14> send a NOTIFY error packet with type
	NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER to the sender of the R1 or I2.
        </t>
	I2.</t>
        <t> It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the Initiator send an I1 packet
        encapsulated in UDP when it is destined to an IP address of the
        Responder. Respectively, the Responder MUST <bcp14>MUST</bcp14> respond to such an I1
        packet with a UDP-encapsulated R1 packet, and also the rest of the communication
        related to the HIP association MUST <bcp14>MUST</bcp14> also use UDP encapsulation.</t>
        <t><xref target="fig:bex"/> target="fig_bex" format="default"/> illustrates a base
	exchange via a Control Relay Server. We assume that the Responder (i.e.
	(i.e., a Control Relay Client) has already registered to the Control
	Relay Server. The Initiator may have also registered to another (or
	the same Control Relay Server), but the base exchange will traverse
	always through the Control Relay Server of the Responder.
        </t> Responder.</t>
        <figure anchor="fig:bex" title="Base anchor="fig_bex">
          <name>Base Exchange via a HIP Relay Server"> Server</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
Initiator                  Control Relay Server             Responder
| 1. UDP(I1)                       |                                |
+--------------------------------->| 2. UDP(I1(RELAY_FROM))         |
|                                  +------------------------------->|
|                                  |                                |
|                                  | 3. UDP(R1(RELAY_TO, NAT_TM,    |
|                                  |        TA_P))                  |
| 4. UDP(R1(RELAY_TO, NAT_TM,      |<-------------------------------+
|        TA_P))                    |                                |
|<---------------------------------+                                |
|                                  |                                |
| 5. UDP(I2(ENC(LOC_SET)),         |                                |
|        NAT_TM, TA_P))            |                                |
+--------------------------------->| 6. UDP(I2(ENC(LOC_SET),        |
|                                  |      RELAY_FROM, NAT_TM, TA_P))|
|                                  +------------------------------->|
|                                  |                                |
|                                  | 7. UDP(R2(ENC(LOC_SET),        |
| 8. UDP(R2(ENC(LOC_SET),          |        RELAY_TO))              |
|        RELAY_TO))                |<-------------------------------+
|<---------------------------------+                                |
|                                  |                                |
]]>
          </artwork>
]]></artwork>
        </figure>
        <t> In step 1 of <xref target="fig:bex"/>, target="fig_bex" format="default"/>, the
	Initiator sends an I1 packet over UDP via the Control Relay Server to
	the Responder. In the HIP header, the source HIT belongs to the
	Initiator and the destination HIT to the Responder. The initiator Initiator
	sends the I1 packet from its IP address to the IP address of the
	Control Relay Server over UDP.</t>
        <t> In step 2, the Control Relay Server receives the I1 packet. If the
        destination HIT belongs to a successfully registered Control Relay
	Client (i.e., the host marked "Responder" in <xref target="fig:bex"/>), target="fig_bex"
	format="default"/>), the Control Relay Server processes the
	packet. Otherwise, the Control Relay Server MUST <bcp14>MUST</bcp14> drop
	the packet silently. The Control Relay Server appends a RELAY_FROM
	parameter to the I1 packet, which contains the transport source
	address and port of the I1 as observed by the Control Relay
	Server. The Control Relay Server protects the I1 packet with
	RELAY_HMAC, except that the parameter type is different as described
	in <xref target="sec:relay-hmac"/>. target="sec_relay-hmac" format="default"/>. The Control Relay
	Server changes the source and destination ports and IP addresses of
	the packet to match the values the Responder used when registering to
	the Control Relay Server, i.e., the reverse of the R2 used in the
	registration. The Control Relay Server MUST <bcp14>MUST</bcp14> recalculate
	the transport checksum and forward the packet to the Responder. </t>
        <t> In step 3, the Responder receives the I1 packet. The Responder
	processes it according to the rules in <xref target="RFC7401"/>. target="RFC7401"
	format="default"/>. In addition, the Responder validates the
	RELAY_HMAC according to <xref target="sec:relay-hmac"/> target="sec_relay-hmac"
	format="default"/> and silently drops the packet if the validation
	fails. The Responder replies with an R1 packet to which it includes
	RELAY_TO and NAT traversal mode parameters. The responder MUST Responder
	<bcp14>MUST</bcp14> include ICE-HIP-UDP in the NAT traversal
	modes. The RELAY_TO parameter MUST <bcp14>MUST</bcp14> contain the same
	information as the RELAY_FROM parameter, i.e., the Initiator's
	transport address, but the type of the parameter is different. The
	RELAY_TO parameter is not integrity protected by the signature of the
	R1 to allow pre-created R1 packets at the Responder. </t>
        <t> In step 4, the Control Relay Server receives the R1 packet. The
	Control Relay Server drops the packet silently if the source HIT
	belongs to a Control Relay Client that has not successfully
	registered. The Control Relay Server MAY <bcp14>MAY</bcp14> verify the
	signature of the R1 packet and drop it if the signature is
	invalid. Otherwise, the Control Relay Server rewrites the source
	address and port, and changes the destination address and port to
	match RELAY_TO information. Finally, the Control Relay Server
	recalculates the transport checksum and forwards the packet. </t>

	<!-- XX FIXME: remove HIP candidate term -->

        <t> In step 5, the Initiator receives the R1 packet and processes it
        according to <xref target="RFC7401"/>. target="RFC7401" format="default"/>. The Initiator MAY
        <bcp14>MAY</bcp14> use the address in the RELAY_TO parameter as a
        local peer-reflexive candidate for this HIP association if it is
        different from all known local candidates. The Initiator replies with
        an I2 packet that uses the destination transport address of R1 as the
        source address and port. The I2 packet contains a LOCATOR_SET
        parameter inside an ENCRYPTED parameter that lists all the HIP
        candidates (HIP offer) of the Initiator.  The candidates are encoded
        using the format defined in <xref target="sec:locator_format"/>. target="sec_locator_format"
        format="default"/>. The I2 packet MUST <bcp14>MUST</bcp14> also contain a
        NAT traversal mode parameter that includes ICE-HIP-UDP mode. The
        ENCRYPTED parameter along with its key material generation are is
        described in detail in sections 5.2.18 Sections <xref target="RFC7401"
        section="5.2.18" sectionFormat="bare"/> and 6.5 <xref target="RFC7401"
        section="6.5" sectionFormat="bare"/> in <xref target="RFC7401" />.</t>
        format="default"/>.</t>
        <t> In step 6, the Control Relay Server receives the I2 packet. The
	Control Relay Server appends a RELAY_FROM and a RELAY_HMAC to the I2
	packet similarly as similar to that explained in step 2, and forwards the packet to
	the Responder. </t>
        <t> In step 7, the Responder receives the I2 packet and processes it
        according to <xref target="RFC7401"/>. target="RFC7401" format="default"/>. The Responder
        validates the RELAY_HMAC according to <xref target="sec:relay-hmac"/> target="sec_relay-hmac"
        format="default"/> and silently drops the packet if the validation
        fails. It replies with an R2 packet and includes a RELAY_TO parameter
        as explained in step 3. The R2 packet includes a LOCATOR_SET parameter
        inside an ENCRYPTED parameter that lists all the HIP candidates (ICE
        answer) of the Responder. The RELAY_TO parameter is protected by the
        HMAC.
        Hashed Message Authentication Code (HMAC). The ENCRYPTED parameter
        along with its key material generation are is described in detail in sections 5.2.18
        Sections <xref target="RFC7401" section="5.2.18"
        sectionFormat="bare"/> and 6.5 <xref target="RFC7401" section="6.5"
        sectionFormat="bare"/> in <xref target="RFC7401" />.</t>
        format="default"/>.</t>
        <t> In step 8, the Control Relay Server processes the R2 as described
	in step 4. The Control Relay Server forwards the packet to the
	Initiator. After the Initiator has received the R2 and processed it
	successfully, the base exchange is completed. </t>
        <t> Hosts MUST <bcp14>MUST</bcp14> include the address of one or more
	Control Relay Servers (including the one that is being used for the
	initial signaling) in the LOCATOR_SET parameter in I2 and R2 messages
	if they intend to use such servers for relaying HIP signaling
	immediately after the base exchange completes. The traffic type of
	these addresses MUST <bcp14>MUST</bcp14> be "HIP signaling" (see <xref target="sec:locator_format" />)
	target="sec_locator_format" format="default"/>) and they
        MUST NOT <bcp14>MUST
	NOT</bcp14> be used for the connectivity tests described in <xref target="sec:conn_checks" />.
	target="sec_conn_checks" format="default"/>.  If the Control Relay
	Server locator used for relaying the base exchange is not included in
	I2 or R2 LOCATOR_SET parameters, it SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used
	after the base exchange. Instead, further HIP signaling SHOULD
	<bcp14>SHOULD</bcp14> use the same path as the data traffic. It is RECOMMENDED
	<bcp14>RECOMMENDED</bcp14> to use the same Control Relay Server
	throughout the lifetime of the host association that was used for
	forwarding the base exchange if the Responder includes it in the
	locator parameter of the R2 message.</t>
      </section> <!-- Base Exchange via HIP Relay Server -->

      <section anchor="sec:conn_checks" title="Connectivity Checks"> anchor="sec_conn_checks" numbered="true" toc="default">
        <name>Connectivity Checks</name>
        <t>When the Initiator and Responder complete the base exchange through
        the Control Relay Server, both of them employ the IP address of the
        Control Relay Server as the destination address for the packets. The
        address of the Control Relay Server MUST NOT <bcp14>MUST NOT</bcp14> be used as
        a destination for data plane traffic unless the server supports also supports
        Data Relay Server functionality, and the Client has successfully
        registered to use it. When NAT traversal mode with ICE-HIP-UDP was
        successfully negotiated and selected, the Initiator and Responder MUST
        <bcp14>MUST</bcp14> start the connectivity checks in order to attempt
        to obtain direct end-to-end connectivity through NAT devices. It is
        worth noting that the connectivity checks
        MUST <bcp14>MUST</bcp14> be
        completed even though no ESP_TRANSFORM would be negotiated and selected.
        </t>
        selected.</t>
        <t>The connectivity checks follow the ICE methodology <xref
        target="I-D.rosenberg-mmusic-ice-nonsip"/>,
        target="I-D.rosenberg-mmusic-ice-nonsip" format="default"/>, but UDP encapsulated
        UDP-encapsulated HIP control messages are used instead of ICE
        messages. As stated in the ICE specification, the basic procedure for
        connectivity checks has three phases: sorting the candidate pairs
        according to their priority, sending checks in the prioritized order order,
        and acknowledging the checks from the peer host.
        </t>

        <t>The Initiator MUST <bcp14>MUST</bcp14> take the role of controlling host
        host, and the Responder acts as the controlled host. The roles MUST
        <bcp14>MUST</bcp14> persist throughout the HIP associate lifetime (to
        be reused in
        the possibly even during mobility UPDATE procedures).  In the case in
        which both communicating nodes are initiating the communications communication to
        each other using an I1 packet, the conflict is resolved as defined in section 6.7 in
        <xref target="RFC7401" />: sectionFormat="of" section="6.7"/>; the host
        with the "larger" HIT changes to its Role role to Responder. In such a
        case, the host changing its role to Responder MUST <bcp14>MUST</bcp14> also
        switch to the controlled role.
	</t> role.</t>

        <t>The protocol follows standard HIP UPDATE sending and processing
        rules as defined in section 6.11 Sections <xref target="RFC7401" section="6.11"
        sectionFormat="bare"/> and 6.12 <xref target="RFC7401" section="6.12"
        sectionFormat="bare"/> in <xref target="RFC7401" />, format="default"/>,
        but some new parameters are introduced (CANDIDATE_PRIORITY, MAPPED_ADDRESS
        MAPPED_ADDRESS, NOMINATE, PEER_PERMISSION, and NOMINATE).</t> RELAYED_ADDRESS).</t>

        <section anchor="sec:conn_check_proc" title="Connectivity anchor="sec_conn_check_proc" numbered="true" toc="default">
          <name>Connectivity Check Procedure"> Procedure</name>
          <t><xref target="fig:cc1"/> target="fig_cc1" format="default"/> illustrates connectivity checks
          in a simplified scenario, scenario where the Initiator and Responder
          have only a single candidate pair to check. Typically, NATs
          drop messages until both sides have sent messages using the
          same port pair. In this scenario, the Responder sends a
          connectivity check first but the NAT of the Initiator drops
          it. However, the connectivity check from the Initiator
          reaches the Responder because it uses the same port pair as
          the first message. It is worth noting that the message flow
          in this section is idealistic, and, in practice, more
          messages would be dropped, especially in the beginning. For
          instance, connectivity tests always start with the
          candidates with the highest priority, which would be host
          candidates (which would not reach the recipient in this
          scenario).</t>

          <?rfc needLines="30" ?>
          <figure anchor="fig:cc1" title="Connectivity Checks"> anchor="fig_cc1">
            <name>Connectivity Checks</name>
            <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
Initiator  NAT1                                 NAT2        Responder
|             | 1. UDP(UPDATE(SEQ, CAND_PRIO,      |                |
|             |        ECHO_REQ_SIGN))             |                |
|             X<-----------------------------------+----------------+
|             |                                    |                |
| 2. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO))    |                |
+-------------+------------------------------------+--------------->|
|             |                                    |                |
| 3. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) |                |
|<------------+------------------------------------+----------------+
|             |                                    |                |
| 4. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO))    |                |
|<------------+------------------------------------+----------------+
|             |                                    |                |
| 5. UDP(UPDATE(ACK, ECHO_RESP_SIGN, MAPPED_ADDR)) |                |
+-------------+------------------------------------+--------------->|
|             |                                    |                |
| 6. Other connectivity checks using UPDATE over UDP                |
|<------------+------------------------------------+---------------->
|             |                                    |                |
| 7. UDP(UPDATE(SEQ, ECHO_REQ_SIGN, CAND_PRIO, NOMINATE))           |
+-------------+------------------------------------+--------------->|
|             |                                    |                |
| 8. UDP(UPDATE(SEQ, ACK, ECHO_REQ_SIGN, ECHO_RESP_SIGN,            |
|           NOMINATE))                             |                |
|<------------+------------------------------------+----------------+
|             |                                    |                |
| 9. UDP(UPDATE(ACK, ECHO_RESP_SIGN))              |                |
+-------------+------------------------------------+--------------->+
|             |                                    |                |
| 10. ESP data traffic over UDP                     |               |
+<------------+------------------------------------+--------------->+
|             |                                    |                |
]]>
            </artwork>
]]></artwork>
          </figure>
          <t>In step 1, the Responder sends a connectivity check to the
          Initiator that the NAT of the Initiator drops. The message includes
	  a number of parameters. As specified in <xref target="RFC7401" />),
	  format="default"/>, the SEQ parameter includes a running sequence
	  identifier for the connectivity check. The candidate priority
	  (denoted "CAND_PRIO" CAND_PRIO in the figure) describes the priority of the
	  address candidate being tested. The ECHO_REQUEST_SIGNED (denoted
	  ECHO_REQ_SIGN in the figure) includes a nonce that the recipient
	  must sign and echo back as it is.</t>
          <t>In step 2, the Initiator sends a connectivity check, using
          the same address pair candidate as in the previous step, and the
          message traverses successfully traverses the NAT boxes. The message
          includes the same parameters as in the previous step. It
          should be noted that the sequence identifier is locally
          assigned by the Initiator, so it can be different than in
          the previous step.</t>

	  <!-- XX FIXME: explain what happens to the SEQ ids of dropped packets and SEQ window -->
          <t>In step 3, the Responder has successfully received the previous
          connectivity check from the Initiator and starts to build a response
          message. Since the message from the Initiator included a SEQ, the
          Responder must acknowledge it using an ACK parameter. Also, the
          nonce contained in the echo request must be echoed back in an
          ECHO_RESPONSE_SIGNED (denoted ECHO_RESP_SIGN) parameter. The
          Responder includes also includes a MAPPED_ADDRESS parameter (denoted
          MAPPED_ADDR in the figure) that contains the transport address of
          the Initiator as observed by the Responder (i.e. peer reflexive (i.e., peer-reflexive
          candidate). This message is successfully delivered to the Initiator, and Initiator;
          upon reception reception, the Initiator marks the candidate pair as valid.
	  </t> valid.</t>
          <t>In step 4, the Responder retransmits the connectivity
          check sent in the first step, since it was not acknowledged
          yet.</t>
          <t>In step 5, the Initiator responds to the previous
          connectivity check message from the Responder. The Initiator
          acknowledges the SEQ parameter from the previous message
          using an ACK parameter and the ECHO_REQUEST_SIGNED parameter with
          ECHO_RESPONSE_SIGNED. In addition, it includes the MAPPED_ADDR
          parameter that includes the peer reflexive peer-reflexive candidate. This
          response message is successfully delivered to the
          Responder, and
          Responder; upon reception reception, the Initiator marks the candidate pair as valid.</t>
          <t>In step 6, despite the two hosts now having valid address
	  candidates, the hosts still test the remaining address candidates
	  in a similar way as in the previous steps. It should be noted that each
	  connectivity check has a unique sequence number in the SEQ
	  parameter.</t>
          <t>In step 7, the Initiator has completed testing all
          address candidates and nominates one address candidate to be
          used. It sends an UPDATE message using the selected address
          candidates that includes a number of parameters: SEQ,
          ECHO_REQUEST_SIGNED, CANDIDATE_PRIORITY CANDIDATE_PRIORITY, and the NOMINATE parameter.</t>
          <t>In step 8, the Responder receives the message with the NOMINATE
          parameter from the Initiator. It sends a response that includes the
          NOMINATE parameter in addition to a number of other parameters. The
          ACK and ECHO_RESPONSE_SIGNED parameters acknowledge the SEQ and
          ECHO_REQUEST_SIGNED parameters from the previous message from the
          Initiator. The Responder includes SEQ and ECHO_REQUEST_SIGNED
          parameters in order to receive an acknowledgment from the
          Responder.</t>
          <t>In step 9, the Initiator completes the candidate
          nomination process by confirming the message reception to
          the Responder. In the confirmation message, the ACK and
          ECHO_RESPONSE_SIGNED parameters correspond to the SEQ and
          ECHO_REQUEST_SIGNED parameters in the message sent by the
          Responder in the previous step.</t>
          <t>In step 10, the Initiator and Responder can start sending
          application payload over the successfully nominated address
          candidates.</t>
          <t>It is worth noting that if either host has registered a relayed
	  address candidate from a Data Relay Server, the host MUST
	  <bcp14>MUST</bcp14> activate the address before connectivity checks
	  by sending an UPDATE message containing the PEER_PERMISSION parameter as
	  described in <xref target="sec:forwarding" />. target="sec_forwarding"
	  format="default"/>. Otherwise, the Data Relay Server drops ESP
	  packets using the relayed address.
	  </t> address.</t>
          <t>It should be noted that in the case in which both the Initiator and
	  Responder both are advertising their own relayed address
	  candidates, it is possible that the two hosts choose the two
	  relayed addresses as a result of the ICE nomination
	  algorithm. While this is possible (and even could be
	  desirable for privacy reasons), it can be unlikely due to
	  low priority assigned for the relayed address candidates. In
	  such a an event, the nominated address pair is always
	  symmetric; the nomination algorithm prevents asymmetric
	  address pairs (i.e. (i.e., each side choosing different pair), pair) such
	  as a Data Relay Client using its own Data Relay Server to
	  send data directly to its peer while receiving data from the
	  Data Relay Server of its peer.
          </t>
        </section> <!-- "Connectivity Check Procedure" -->

<!--

seq: 385
ack: 449
echo_req_sign: 897
echo_resp_sign: 961
mapped_address: 4660
cand_prio: 4700
NOMINATE: 4710

-->

        <section title="Rules numbered="true" toc="default">
          <name>Rules for Connectivity Checks">

          <!-- XX FIXME: should we explicitly explain here the ordering of the ICE candidates? --> Checks</name>

	  <t>The HITs of the two communicating hosts MUST <bcp14>MUST</bcp14> be
	  used as credentials in this protocol (in contrast to ICE ICE, which
	  employs username-password fragments). A HIT pair uniquely identifies
	  the corresponding HIT association, and a SEQ number in an UPDATE
	  message identifies a particular connectivity check.</t>
          <t>All of the connectivity check messages MUST <bcp14>MUST</bcp14> be
          protected with HIP_HMAC and signatures (even though the
          illustrations in this specification omit them for simplicity)
          according to <xref target="RFC7401"/>. target="RFC7401" format="default"/>. Each
          connectivity check sent by a host MUST <bcp14>MUST</bcp14> include a SEQ
          parameter and ECHO_REQUEST_SIGNED
          parameter, and correspondingly parameter; correspondingly, the
          peer MUST <bcp14>MUST</bcp14> respond to these using ACK and
          ECHO_RESPONSE_SIGNED according to the rules specified in <xref
          target="RFC7401" />.
          </t>

	  <!-- format="default"/>.</t>

	  <t>The host sending a connectivity check should check <bcp14>MUST</bcp14> validate that
	  the response uses also the same pair of UDP ports. If ports, and drop the
	  UDP ports do
	  packet if this is not match, the connectivity checks for this
	  candidate pair MUST be considered to have failed.</t>

	  XX FIXME: vurnerable to replay attacks???
	  -->

	  <t>The host sending a connectivity check MUST validate that
	  the response uses the same pair of UDP ports, and drop the
	  packet if this is not the case.</t>

	  <t>A host may receive a case.</t>
          <t>A host may receive a connectivity check before it has received
	  the candidates from its peer. In such a case, the host MUST
	  <bcp14>MUST</bcp14> immediately queue a response by placing it in
	  the triggered-check queue, queue and then continue waiting for the
	  candidates. A host MUST NOT <bcp14>MUST NOT</bcp14> select a candidate pair
	  until it has verified the pair using a connectivity check as defined
	  in <xref
	  target="sec:conn_check_proc" />.</t> target="sec_conn_check_proc" format="default"/>.</t>
          <t><xref target="RFC7401"/> section 5.3.5 target="RFC7401" sectionFormat="of" section="5.3.5"/>
	  states that UPDATE packets have to include either a SEQ or ACK
	  parameter (but can include both). In the connectivity check
	  procedure specified in <xref target="sec:conn_check_proc" />, target="sec_conn_check_proc"
	  format="default"/>, each SEQ parameter should be acknowledged
	  separately. In the context of NATs, this means that some of the SEQ
	  parameters sent in connectivity checks will be lost or arrive out of
	  order. From the viewpoint of the recipient, this is not a problem
	  since the recipient will just "blindly" acknowledge the
	  SEQ. However, the sender needs to be prepared for lost sequence
	  identifiers and ACKs ACK parameters that arrive out of order.</t>
          <t>As specified in <xref target="RFC7401"/>, target="RFC7401" format="default"/>, an ACK
          parameter may acknowledge multiple sequence
          identifiers. While the examples in the previous sections do
          not illustrate such functionality, it is also permitted when
          employing ICE-HIP-UDP mode.</t>
          <t>In ICE-HIP-UDP mode, a retransmission of a connectivity check SHOULD
          <bcp14>SHOULD</bcp14> be sent with the same sequence identifier in
          the SEQ parameter. Some tested address candidates will never produce
          a working address pair, pair and thus may thus cause retransmissions. Upon
          successful nomination of an address pair, a host SHOULD
          <bcp14>SHOULD</bcp14> immediately stop sending such
          retransmissions.</t>

	  <!-- XX FIXME: no lite mode anymore in ICE -->

	  <t>Full ICE procedures for prioritizing candidates, eliminating
	  redundant candidates, forming check lists checklists (including
	  pruning) pruning), and triggered check-queues MUST
	  triggered-check queues <bcp14>MUST</bcp14> be followed as specified
	  in section 6.1 <xref
	  target="RFC8445"/>, target="RFC8445" sectionFormat="of" section="6.1"/>, with
	  the exception of being that the foundation, frozen candidates candidates, and
	  default candidates are not used. From the viewpoint of the ICE
	  specification <xref target="RFC8445"/>, target="RFC8445" format="default"/>, the
	  protocol specified in this document operates using Component a component ID of
	  1 on all candidates, and the foundation of all candidates is
	  unique. This specification defines only "full ICE" mode, and the
	  "lite ICE" is not supported. The reasoning behind the missing
	  features is described in <xref
	  target="sec:ice_diff" />.</t> target="sec_ice_diff"
	  format="default"/>.</t>
          <t> The connectivity check messages MUST <bcp14>MUST</bcp14> be paced by
	  the Ta value negotiated during the base exchange as described in
	  <xref
          target="sec:check_pacing_neg"/>. target="sec_check_pacing_neg" format="default"/>. If neither
	  one of the hosts announced a minimum pacing value, a value of 50 ms MUST
	  <bcp14>MUST</bcp14> be used. </t> used.</t>
          <t>Both hosts MUST <bcp14>MUST</bcp14> form a
          priority ordered checklist and begin to check transactions every Ta
          milliseconds as long as the checks are running and there are candidate
          pairs whose tests have not started. The retransmission timeout (RTO)
          for the connectivity check UPDATE packets SHOULD <bcp14>SHOULD</bcp14> be
	  calculated as follows:

          <list style="empty">
            <t>RTO follows:</t>
          <t indent="3">
            RTO = MAX (1000ms, (1000 ms, Ta * (Num-Waiting + Num-In-Progress))</t>
          </list> Num-In-Progress))
          </t>
          <t> In the RTO formula, Ta is the value used for the connectivity
	  check pacing, Num-Waiting is the number of pairs in the checklist in
	  the "Waiting" state, and Num-In-Progress is the number of pairs in
	  the "In-Progress" state. This is identical to the formula in <xref
          target="RFC8445"/>
	  target="RFC8445" format="default"/> when there is only one
	  checklist. A smaller value than 1000 ms for the RTO MUST NOT <bcp14>MUST
	  NOT</bcp14> be used.</t>
          <t> Each connectivity check request packet MUST <bcp14>MUST</bcp14> contain a
          CANDIDATE_PRIORITY parameter (see <xref target="sec:con-check"/>) target="sec_con-check" format="default"/>) with
          the priority value that would be assigned to a peer reflexive peer-reflexive candidate
          if one was learned from the corresponding check. An UPDATE packet that acknowledges
          a connectivity check request MUST <bcp14>MUST</bcp14> be sent from the same address that
          received the check and delivered to the same address where the check was received
          from. Each acknowledgment UPDATE packet MUST <bcp14>MUST</bcp14> contain a MAPPED_ADDRESS
          parameter with the port, protocol, and IP address of the address where
          the connectivity check request was received from.</t>

          <!-- XX FIXME: reference UDP-over-ESP -->

	  <t>Following the ICE guidelines <xref
	  target="RFC8445"/>, target="RFC8445"
	  format="default"/>, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to restrict the
	  total number of connectivity checks to 100 for each host
	  association. This can be achieved by limiting the connectivity
	  checks to the 100 candidate pairs with the highest priority.</t>
        </section> <!-- Rules for Connectivity Checks -->

        <section title="Rules numbered="true" toc="default">
          <name>Rules for Concluding Connectivity Checks"> Checks</name>
          <t>The controlling agent may find multiple working candidate
          pairs. To conclude the connectivity checks, it SHOULD <bcp14>SHOULD</bcp14>
          nominate the pair with the highest priority. The controlling agent MUST
          <bcp14>MUST</bcp14> nominate a candidate pair essentially by
          repeating a connectivity check using an UPDATE message that contains
          a SEQ parameter (with a new sequence number), a an ECHO_REQUEST_SIGNED
          parameter, the priority of the candidate in a CANDIDATE_PRIORITY parameter
          parameter, and a NOMINATE parameter to signify conclusion of the
          connectivity checks. Since the nominated address pair has already
          been tested for reachability, the controlled host should be able to
          receive the message. Upon reception, the controlled host SHOULD
          <bcp14>SHOULD</bcp14> select the nominated address pair. The
          response message MUST <bcp14>MUST</bcp14> include a SEQ parameter with a
          new sequence id, identifier, acknowledgment of the sequence from the controlling
          host in an ACK parameter, a new ECHO_REQUEST_SIGNED parameter,
          an ECHO_RESPONSE_SIGNED parameter corresponding to the
          ECHO_REQUEST_SIGNED parameter from the controlling host host, and the
          NOMINATE parameter. After sending this packet, the controlled host
          can create IPsec security associations using the nominated address
          candidate for delivering application payload to the controlling
          host. Since the message from the controlled host included a new
          sequence
	  id and identifier echo request for the signature, the controlling host MUST
          <bcp14>MUST</bcp14> acknowledge this with a new UPDATE message that
          includes an ACK and ECHO_RESPONSE_SIGNED parameters. After this
          final concluding message, the controlling host also can create IPsec
          security associations for delivering application payload to the
          controlled host.
	  </t> host.</t>
          <t>It is possible that packets are delayed by the network. Both
	  hosts MUST <bcp14>MUST</bcp14> continue to respond to any connectivity
	  checks despite an address pair having been nominated.</t>
          <t> If all the connectivity checks have failed, the hosts MUST NOT
	  <bcp14>MUST NOT</bcp14> send ESP traffic to each other but MAY
	  <bcp14>MAY</bcp14> continue communicating using HIP packets and the
	  locators used for the base exchange. Also, the hosts SHOULD
	  <bcp14>SHOULD</bcp14> notify each other about the failure with a
	  CONNECTIVITY_CHECKS_FAILED NOTIFY packet (see <xref target="sec:notify-types"/>).</t>
	  target="sec_notify-types" format="default"/>).</t>
        </section> <!-- Rules for Concluding Connectivity Checks -->

      </section> <!-- connectivity checks -->

      <section anchor="sec:alternatives" title="NAT anchor="sec_alternatives" numbered="true" toc="default">
        <name>NAT Traversal Optimizations"> Optimizations</name>
        <section title="Minimal anchor="sec_minimal" numbered="true" toc="default">
          <name>Minimal NAT Traversal Support" anchor="sec:minimal"> Support</name>
          <t>If the Responder has a fixed and publicly reachable IPv4
          address and does not employ a Control Relay Server, the explicit NAT
          traversal mode negotiation MAY <bcp14>MAY</bcp14> be omitted, and thus omitted; thus, even the
          UDP-ENCAPSULATION mode does not have to be negotiated. In
          such a scenario, the Initiator sends an I1 message over UDP
          and the Responder responds with an R1 message over UDP without
          including any NAT traversal mode parameter. The rest of the
          base exchange follows the procedures defined in <xref
          target="RFC7401"/>,
	  target="RFC7401" format="default"/>, except that the control and
	  data plane use UDP encapsulation. Here, the use of UDP for NAT
          traversal is agreed upon implicitly. This way of operation is still
	  subject to NAT timeouts, and the hosts MUST <bcp14>MUST</bcp14> employ
	  NAT keepalives as defined in <xref
          target="sec:nat-keepalives"/>.</t> target="sec_nat-keepalives"
	  format="default"/>.</t>

          <t>When UDP-ENCAPSULATION mode is chosen either explicitly or
	  implicitly, the connectivity checks as defined in this document MUST NOT
	  <bcp14>MUST NOT</bcp14> be used. When hosts lose connectivity, they MUST
	  <bcp14>MUST</bcp14> instead utilize <xref target="RFC8046" />
	  format="default"/> or <xref target="RFC8047" /> format="default"/>
	  procedures, but with the difference being that UDP-based tunneling MUST
	  <bcp14>MUST</bcp14> be employed for the entire lifetime of the
	  corresponding Host Association.</t> HIP association.</t>
        </section>

        <section anchor="sec:no_relay"
                 title="Base anchor="sec_no_relay" numbered="true" toc="default">
          <name>Base Exchange without Connectivity Checks"> Checks</name>
          <t>It is possible to run a base exchange without any connectivity
          checks as defined in Legacy ICE-HIP section 4.8 <xref (<xref target="RFC5770" />.
          sectionFormat="of" section="4.8"/>). The procedure is applicable also applicable
          in the context of this specification, so it is repeated here for
          completeness.</t>
          <t> In certain network environments, the connectivity checks can be
          omitted to reduce initial connection set-up setup latency because a base
          exchange acts as an implicit connectivity test itself. For this to
          work, the Initiator MUST <bcp14>MUST</bcp14> be able to reach the Responder by simply UDP
          encapsulating HIP and ESP packets sent to the Responder's address.
          Detecting and configuring this particular scenario is prone to failure
          unless carefully planned. </t>
          <t> In such a scenario, the Responder MAY <bcp14>MAY</bcp14> include
	  UDP-ENCAPSULATION NAT traversal mode as one of the supported modes
	  in the R1 packet. If the Responder has registered to a Control Relay
	  Server in order to discover its address candidates, it MUST
	  <bcp14>MUST</bcp14> also include a LOCATOR_SET parameter
	  encapsulated inside an ENCRYPTED parameter in an R1 message that
	  contains a preferred address where the Responder is able to receive
	  UDP-encapsulated ESP and HIP packets. This locator MUST
	  <bcp14>MUST</bcp14> be of type "Transport address", its Traffic type MUST
	  <bcp14>MUST</bcp14> be "both", and it MUST <bcp14>MUST</bcp14> have the
	  "Preferred bit" set (see <xref
          target="tbl:locator"/>). target="tbl_locator"
	  format="default"/>). If there is no such locator in R1, the
	  Initiator MUST <bcp14>MUST</bcp14> use the source address of the R1 as
	  the Responder's preferred address. </t>
          <t> The Initiator MAY <bcp14>MAY</bcp14> choose the UDP-ENCAPSULATION
	  mode if the Responder listed it in the supported modes and the
	  Initiator does not wish to use the connectivity checks defined in
	  this document for searching for a more optimal path. In this case,
	  the Initiator sends the I2 with UDP-ENCAPSULATION mode in the NAT
	  traversal mode parameter directly to the Responder's preferred
	  address (i.e., to the preferred locator in R1 or to the address
	  where R1 was received from if there was no preferred locator in
	  R1). The Initiator
          MAY <bcp14>MAY</bcp14> include locators in I2 but
	  they MUST NOT <bcp14>MUST NOT</bcp14> be taken as address candidates, since
	  connectivity checks defined in this document will not be used for
	  connections with UDP-ENCAPSULATION NAT traversal mode. Instead, if
	  R2 and I2 are received and processed successfully, a security
	  association can be created and UDP-encapsulated ESP can be exchanged
	  between the hosts after the base exchange completes according to the
	  rules in Section 4.4 in <xref target="RFC7401" />.
	  <!-- However, the Responder SHOULD NOT
          send any ESP to the Initiator's address before it has received data
          from the Initiator, as specified in Sections 4.4.3. and 6.9 of <xref
          target="RFC7401"/> and in Sections 3.3.1 and 5.4 of <xref
          target="RFC8046"/>. --> sectionFormat="of" section="4.4"/>.
 </t>
          <t>The Control Relay Server can be used for discovering address
	  candidates but it is not intended to be used for relaying end-host
	  packets using the UDP-ENCAPSULATION NAT mode. Since an I2 packet
	  with UDP-ENCAPSULATION NAT traversal mode selected MUST NOT <bcp14>MUST
	  NOT</bcp14> be sent via a Control Relay Server, the Responder SHOULD
	  <bcp14>SHOULD</bcp14> reject such I2 packets and reply with a
	  NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER NOTIFY packet (see <xref target="sec:notify-types"/>). </t>
	  target="sec_notify-types" format="default"/>).</t>
          <t> If there is no answer for the I2 packet sent directly to the
	  Responder's preferred address, the Initiator MAY <bcp14>MAY</bcp14> send
	  another I2 via the Control Relay Server, but it MUST NOT <bcp14>MUST
	  NOT</bcp14> choose UDP-ENCAPSULATION NAT traversal mode for that I2. </t>
	  I2.</t>
        </section> <!-- Base Exchange without ICE Connectivity Checks -->

        <section anchor="sec:no_udp"
                 title="Initiating anchor="sec_no_udp" numbered="true" toc="default">
          <name>Initiating a Base Exchange both Both with and without UDP Encapsulation"> Encapsulation</name>
          <t>It is possible to run a base exchange in parallel both with and
	  without UDP encapsulation as defined in Legacy ICE-HIP section 4.9 in <xref (<xref
	  target="RFC5770" />. sectionFormat="of" section="4.9"/>). The procedure
	  is applicable also applicable in the context of this specification, so it is
	  repeated here for completeness.</t>
          <t>The Initiator MAY <bcp14>MAY</bcp14> also try to simultaneously
          perform a base exchange with the Responder without UDP
          encapsulation. In such a case, the Initiator sends two I1 packets,
          one without and one with UDP encapsulation, to the Responder. The
          Initiator MAY <bcp14>MAY</bcp14> wait for a while before sending the
          other I1. How long to wait and in which order to send the I1 packets
          can be decided based on local policy.  For retransmissions, the
          procedure is repeated.</t>
          <t>The I1 packet without UDP encapsulation may arrive directly,
          without passing any a Control Relay Server, at the Responder. When
          this happens, the procedures in <xref target="RFC7401" />
          format="default"/> are followed for the rest of the base
          exchange. The Initiator may receive multiple R1 packets, with and
          without UDP encapsulation, from the Responder. However, after
          receiving a valid R1 and answering it with an I2, further R1 packets
          that are not retransmissions of the R1 message received first MUST
          <bcp14>MUST</bcp14> be ignored. </t>
          <t>The I1 packet without UDP encapsulation may also arrive at a
          HIP-capable middlebox. When the middlebox is a HIP rendezvous server Rendezvous Server
          and the Responder has successfully registered with the rendezvous
          service, the middlebox follows rendezvous procedures in <xref
	  target="RFC8004" />. </t> format="default"/>.</t>
          <t>If the Initiator receives a NAT traversal mode parameter in R1
	  without UDP encapsulation, the Initiator MAY <bcp14>MAY</bcp14> ignore
	  this parameter and send an I2 without UDP encapsulation and without
	  any selected NAT traversal mode. When the Responder receives the I2
	  without UDP encapsulation and without NAT traversal mode, it will
	  assume that no NAT traversal mechanism is needed. The packet
	  processing will be done as described in <xref target="RFC7401"/>. target="RFC7401"
	  format="default"/>. The Initiator MAY <bcp14>MAY</bcp14> store the NAT
	  traversal modes for future use, e.g., in case of a mobility or
	  multihoming event that causes NAT traversal to be used during the
	  lifetime of the HIP association. </t>
        </section> <!-- Base Exchange without UDP Encapsulation  -->

      </section> <!-- NAT Traversal Alternatives -->

      <section anchor="sec:control_no_relay"
        title="Sending anchor="sec_control_no_relay" numbered="true" toc="default">
        <name>Sending Control Packets after the Base Exchange"> Exchange</name>
        <t>The same considerations of with regard to sending control packets after the base
	exchange as described in legacy Legacy ICE-HIP section 5.10 in <xref
        target="RFC5770"/> apply (<xref target="RFC5770"
	sectionFormat="of" section="5.10"/>) also apply here, so they are
	repeated here for completeness.</t>
        <t>After the base exchange, the two end-hosts MAY end hosts <bcp14>MAY</bcp14> send
        HIP control packets directly to each other using the transport address
        pair established for a data channel without sending the control
        packets through any Control Relay
        Servers . Servers. When a host does not
        receive acknowledgments, e.g., to an UPDATE or CLOSE packet after a
        timeout based on local policies, a host SHOULD <bcp14>SHOULD</bcp14> resend
        the packet through the associated Data Relay Server of the peer (if
        the peer listed it in its LOCATOR_SET parameter in the base exchange
        according to the rules specified in section 4.4.2 in <xref
        target="RFC7401"/>.
	</t> target="RFC7401"
        sectionFormat="of" section="4.4.2"/>).</t>
        <t> If a Control Relay Client sends a packet through a Control Relay
	Server, the Control Relay Client
        MUST <bcp14>MUST</bcp14> always utilize
	the RELAY_TO parameter. The Control Relay Server SHOULD <bcp14>SHOULD</bcp14>
	forward HIP control packets originating from a Control Relay Client to
	the address denoted in the RELAY_TO parameter. In the other direction,
	the Control Relay Server SHOULD <bcp14>SHOULD</bcp14> forward HIP control
	packets to the Control Relay Clients, Clients and MUST <bcp14>MUST</bcp14> add a
	RELAY_FROM parameter to the control packets it relays to the Control
	Relay Clients.
	</t> Clients.</t>
        <t> If the Control Relay Server is not willing or able to relay a HIP
        packet, it MAY <bcp14>MAY</bcp14> notify the sender of the packet with a
        MESSAGE_NOT_RELAYED error notification (see <xref
        target="sec:notify-types"/>).
        target="sec_notify-types" format="default"/>). </t>
      </section> <!-- Sending Control Packets after the Base Exchange -->

      <section anchor="sec:mobility" title="Mobility anchor="sec_mobility" numbered="true" toc="default">
        <name>Mobility Handover Procedure"> Procedure</name>
        <t>A host may move after base exchange and connectivity
        checks. Mobility extensions for HIP <xref
        target="RFC8046"/> target="RFC8046"
	format="default"/> define handover procedures
        without NATs. In this section, we define how two hosts
        interact with handover procedures in scenarios involving
        NATs. The specified extensions define only simple mobility
        using a pair of security associations, and multihoming
        extensions are left to be defined in later specifications.
        The procedures in this section offer the same functionality as "ICE
	restart" specified in <xref
        target="RFC8445"/>. target="RFC8445" format="default"/>. The
        example described in this section shows only a Control Relay Server
        for the peer host for the sake of simplicity, but the
        mobile host may also have a Control Relay Server.</t>
        <t>The assumption here is that the two hosts have successfully negotiated
        and chosen the ICE-HIP-UDP mode during the base exchange as
        defined in <xref
        target="sec:nat_traversal_mode"/>. target="sec_nat_traversal_mode"
	format="default"/>. The Initiator of the base
        exchange MUST <bcp14>MUST</bcp14> store information that it was the controlling
        host during the base exchange. Similarly, the Responder MUST <bcp14>MUST</bcp14>
        store information that it was the controlled host during the
        base exchange.</t>

        <t>Prior to starting the handover procedures with all peer hosts, the
        mobile host SHOULD <bcp14>SHOULD</bcp14> first send its locators in UPDATE
        messages to its Control and Data Relay Servers if it has registered to
        such. It
	SHOULD <bcp14>SHOULD</bcp14> wait for all of them to respond for a
        configurable time, by default two minutes, and then continue with the
        handover procedure without information from the Relay Server that did
        not respond. As defined in <xref target="sec:registration" />, target="sec_registration"
        format="default"/>, a response message from a Control Relay Server
        includes a REG_FROM parameter that describes the server
	reflexive server-reflexive
        candidate of the mobile host to be used in the candidate exchange
        during the handover. Similarly, an UPDATE to a Data Relay Server is
        necessary to make sure the Data Relay Server can forward data to the
        correct IP address after a handoff.</t> handover.</t>
        <t>The mobility extensions for NAT traversal are illustrated
        in <xref target="fig:update"/>. target="fig_update" format="default"/>. The mobile host is the
        host that has changed its locators, and the peer host is the
        host it has a host association with. The mobile host may have
        multiple peers peers, and it repeats the process with all of its
        peers. In the figure, the Control Relay Server belongs to the peer host,
        i.e., the peer host is a Control Relay Client for the Control Relay Server.
        Note that the figure corresponds to figure 3 in <xref
        target="RFC8046"/>, target="RFC8046"
	format="default"/>, but the difference is that the main
        UPDATE procedure is carried over the relay and the
        connectivity is tested separately. Next, we describe the
        procedure in the of that figure in detail.</t>

        <?rfc needLines="21" ?>
        <figure anchor="fig:update" title="HIP anchor="fig_update">

          <name>HIP UPDATE procedure"> Procedure</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![CDATA[
Mobile Host               Control Relay Server              Peer Host
| 1. UDP(UPDATE(ESP_INFO,          |                                |
|          ENC(LOC_SET), SEQ))     |                                |
+--------------------------------->| 2. UDP(UPDATE(ESP_INFO,        |
|                                  |          ENC(LOC_SET), SEQ,    |
|                                  |          RELAY_FROM))          |
|                                  +------------------------------->|
|                                  |                                |
|                                  | 3. UDP(UPDATE(ESP_INFO, SEQ,   |
|                                  |          ACK, ECHO_REQ_SIGN,   |
|                                  |          RELAY_TO))            |
| 4. UDP(UPDATE(ESP_INFO, SEQ,     |<-------------------------------+
|          ACK, ECHO_REQ_SIGN,     |                                |
|          RELAY_TO))              |                                |
|<---------------------------------+                                |
|                                  |                                |
| 5. UDP(UPDATE(ACK,               |                                |
|          ECHO_RESP_SIGNED))      |                                |
+--------------------------------->| 6. UDP(UPDATE(ACK,             |
|                                  |          ECHO_RESP_SIGNED,     |
|                                  |          RELAY_FROM))          |
|                                  +------------------------------->|
|                                  |                                |
|                   7. connectivity checks over UDP                 |
+<----------------------------------------------------------------->+
|                                  |                                |
|                      8. ESP data over UDP                         |
+<----------------------------------------------------------------->+
|                                  |                                |
]]>
          </artwork>
]]></artwork>
        </figure>
        <t>In step 1, the mobile host has changed location and sends a
        location update to its peer through the Control Relay Server of the
        peer. It sends an UPDATE packet with the source HIT belonging to
        itself and destination HIT belonging to the peer host. In the packet,
        the source IP address belongs to the mobile host and the destination
        to the Control Relay Server. The packet contains an ESP_INFO parameter, parameter
        where, in this case, the OLD SPI and NEW SPI parameters both contain
        the pre-existing incoming SPI. The packet also contains the locators
        of the mobile host in a LOCATOR_SET parameter, encapsulated inside an
        ENCRYPTED parameter (see sections 5.2.18 and 6.5 Sections <xref target="RFC7401"
        section="5.2.18" sectionFormat="bare"/> and <xref target="RFC7401"
        section="6.5" sectionFormat="bare"/> in <xref target="RFC7401" />
        format="default"/> for details on the ENCRYPTED parameter). The packet contains
        also contains a SEQ number to be acknowledged by the peer. As
        specified in <xref
        target="RFC8046"/>, target="RFC8046" format="default"/>, the packet may
        also include a HOST_ID (for middlebox inspection) and DIFFIE_HELLMAN
        parameter for rekeying.</t>
        <t>In step 2, the Control Relay Server receives the UPDATE packet and forwards it
        to the peer host (i.e. (i.e., Control Relay Client). The Control Relay Server
        rewrites the destination IP address and appends a RELAY_FROM
        parameter to the message.</t>
        <t>In step 3, the peer host receives the UPDATE packet,
        processes it it, and responds with another UPDATE message. The
        message is destined to the HIT of the mobile host and to the IP
        address of the Control Relay Server. The message includes an ESP_INFO
        parameter where, in this case, the OLD SPI and NEW SPI
        parameters both contain the pre-existing incoming SPI. The
        peer includes a new SEQ and ECHO_REQUEST_SIGNED parameters parameter to be
        acknowledged by the mobile host.  The message acknowledges the
        SEQ parameter of the earlier message with an ACK parameter.
        The RELAY_TO parameter specifies the address of the mobile host where the
        Control Relay Server should forward the message.
        </t>
        <t>In step 4, the Control Relay Server receives the message, rewrites the
        destination IP address and UDP port according to the RELAY_TO parameter, and
        then forwards the modified message to the mobile host.
        </t>
        <t>In step 5, the mobile host receives the UPDATE packet and processes
        it. The mobile host concludes the handover procedure by acknowledging
        the received SEQ parameter with an ACK parameter and the
        ECHO_REQUEST_SIGNED parameter with an ECHO_RESPONSE_SIGNED
        parameter. The mobile host delivers sends the packet to the HIT of the peer and
        to the address of the HIP relay. The mobile host can start
        connectivity checks after this packet. </t>
        <t>In step 6, the HIP relay receives the UPDATE packet and
        forwards it to the peer host (i.e. (i.e., Relay Client). The HIP
        relay rewrites the destination IP address and port, and then appends a
        RELAY_FROM parameter to the message. When the peer host
        receives this concluding UPDATE packet, it can initiate the
        connectivity checks.
        </t>
        <t>In step 7, the two hosts test for connectivity across NATs
        according to procedures described in <xref
        target="sec:conn_checks"/>. target="sec_conn_checks"
	format="default"/>. The original Initiator of the
        communications is the controlling host and the original Responder is
        the controlled host.</t>
        <t>In step 8, the connectivity checks are successfully
        completed and the controlling host has nominated one address
        pair to be used. The hosts set up security associations to
        deliver the application payload.</t>
        <t>It is worth noting that the Control and Data Relay Client
        do not have to re-register reregister for the related services after a
        handoff.
        handover. However, if a Data Relay Client has registered a
        relayed address candidate from a Data Relay Server, the Data
        Relay Client MUST <bcp14>MUST</bcp14> reactivate the address before the
        connectivity checks by sending an UPDATE message containing
        the PEER_PERMISSION parameter as described in <xref
        target="sec:forwarding" />.
	target="sec_forwarding" format="default"/>. Otherwise, the Data Relay
	Server
        drops ESP packets sent to the relayed address.</t>
        <t>In so called the so-called "double jump" or simultaneous mobility
	scenario
	scenario, both peers change their location simultaneously. In
	such a case, both peers trigger the procedure described
	earlier in this section at the same time. In other words, both
	of the communicating hosts send an UPDATE packet carrying
	locators at the same time or with some delay. When the
	locators are exchanged almost simultaneously (reliably via
	Control Relay Servers), the two hosts can continue with
	connectivity checks after both have completed separately the
	steps in <xref target="fig:update" />. target="fig_update" format="default"/>. The problematic case
	occurs when one of the hosts (referred to here as host "M")
	moves later during the connectivity checks.  In such a case,
	host M sends a locator to the peer peer, which is in the middle of
	connectivity checks. Upon receiving the UPDATE message, the
	peer responds with an UPDATE with ECHO_REQ_SIGN as described
	in step 3 in <xref target="fig:update" />. target="fig_update" format="default"/>. Upon receiving the
	valid response from host M as described in step 6, the peer
	host MUST <bcp14>MUST</bcp14> restart the connectivity checks with host M. This
	way, both hosts start the connectivity checks roughly in a
	synchronized way. It is also important that the peer host does not
	restart the connectivity checks until the step 6 is
	successfully completed completed, because the UPDATE message
	carrying locators in step 1 could be replayed by an attacker.</t>
      </section>
      <section title="NAT Keepalives" anchor="sec:nat-keepalives"> anchor="sec_nat-keepalives" numbered="true" toc="default">
        <name>NAT Keepalives</name>
        <t>To prevent NAT states from expiring, communicating hosts
        MUST
        <bcp14>MUST</bcp14> send periodic keepalives to other hosts with which
        they have established a Host Association HIP association every 15 seconds (the so
        called
        so-called Tr value in ICE). Other values MAY <bcp14>MAY</bcp14> be used,
        but a Tr value smaller than 15 seconds MUST NOT <bcp14>MUST NOT</bcp14> be
        used.  Both a Control/Data Relay Client and Control/Data Relay Server,
        as well as two peers employing UDP-ENCAPSULATION or ICE-HIP-UDP mode, SHOULD
        <bcp14>SHOULD</bcp14> send HIP NOTIFY packets unless they have
        exchanged some other traffic over the used UDP ports.  However, the
        Data Relay Client and Data Relay Server MUST <bcp14>MUST</bcp14> employ
        only HIP NOTIFY packets in order to keep the server reflexive server-reflexive
        candidates alive.  The keepalive message encoding format is defined in
        <xref
        target="sec:keepalive" />.

        <!-- only NOTIFY works for the reflexive candidates because this address is not really a part of the Host Association of the Data Relay Server) -->

        <!-- Likewise, if a host has not sent any data to another
        host it has established a host association in the ICE-HIP_UDP
        mode within 15 seconds, it MUST send either a HIP NOTIFY packet or, alternatively, an ICMPv6
        echo request inside the related ESP tunnel. Control Relay Server
        servers MAY refrain from sending keepalives if it's known that
        they are not behind a middlebox that requires keepalives. --> target="sec_keepalive" format="default"/>.

        If the base exchange or mobility handover procedure occurs during an
	extremely slow path, a host (with a Host Association HIP association with the peer) MAY
	<bcp14>MAY</bcp14> also
        send HIP NOTIFY packets every 15 seconds to keep the path active with the recipient.
        </t>
      </section>
      <section anchor="sec:close" title="Closing Procedure"> anchor="sec_close" numbered="true" toc="default">
        <name>Closing Procedure</name>
        <t>The two-way procedure for closing a HIP association and the related
        security associations is defined in <xref
        target="RFC7401"/>. target="RFC7401"
        format="default"/>. One host initiates the procedure by sending a
        CLOSE message and the recipient confirms it with CLOSE_ACK. All
        packets are protected using HMACs and signatures, and the CLOSE
        messages includes a include an ECHO_REQUEST_SIGNED parameter to protect against
        replay attacks.</t>
        <t>The same procedure for closing HIP associations applies also applies here,
        but the messaging occurs using the UDP encapsulated UDP-encapsulated tunnel that the
        two hosts employ. A host sending the CLOSE message SHOULD
        <bcp14>SHOULD</bcp14> first send the message over a direct link. After
        a number of retransmissions, it MUST <bcp14>MUST</bcp14> send over a
        Control Relay Server of the recipient if one exists. The host
        receiving the CLOSE message directly without a Control Relay Server SHOULD
        <bcp14>SHOULD</bcp14> respond directly. If the CLOSE message came via a
        Control Relay Server, the host SHOULD <bcp14>SHOULD</bcp14> respond using the
        same Control Relay Server.</t>
      </section>
      <section title="Relaying Considerations"> numbered="true" toc="default">
        <name>Relaying Considerations</name>
        <section anchor="sec:forwarding" title="Forwarding anchor="sec_forwarding" numbered="true" toc="default">
          <name>Forwarding Rules and Permissions"> Permissions</name>
          <t> The Data Relay Server uses a similar permission model as a
          TURN server: before the Data Relay Server forwards any ESP data
          packets from a peer to a Data Relay Client (or the other direction),
          the client MUST <bcp14>MUST</bcp14> set a permission for the peer's address. The
          permissions also install a forwarding rule for each direction, similar to
          TURN's channels, based on the Security Parameter Index (SPI)
          values in the ESP packets.
          </t> packets.</t>
          <t>Permissions are not required for HIP control packets.
          However, if a relayed address (as conveyed in the RELAYED_ADDRESS
	  parameter from the Data Relay Server) is selected to be used for
          data, the Control Relay Client MUST <bcp14>MUST</bcp14> send an UPDATE message to the
          Data Relay Server containing a PEER_PERMISSION parameter (see <xref
          target="sec:peer_permission"/>)
	  target="sec_peer_permission" format="default"/>) with the following
	  information: the UDP port and address for the server reflexive server-reflexive
	  address, the UDP port and
          address of the peer, and the inbound and outbound SPIs used for ESP.
          The packet MUST <bcp14>MUST</bcp14> be sent to the same UDP tunnel
          the Client employed in the base exchange to contact the Server
	  (i.e., not to the port occupied by the server reflexive server-reflexive candidate).
          To avoid packet
          dropping of ESP packets, the Control Relay Client SHOULD <bcp14>SHOULD</bcp14> send the
          PEER_PERMISSION parameter before connectivity checks both in
          the case of base exchange and a mobility handover.  It is
          worth noting that the UPDATE message includes a SEQ
          parameter (as specified in <xref target="RFC7401"/>) target="RFC7401" format="default"/>) that
          the Data Relay Server must acknowledge, so that the Control Relay Client
          can resend the message with the PEER_PERMISSION parameter if it
          gets lost.</t>

	  <!-- should the message with PEER_PERMISSION include ECHO_SIGNED? NO (WOULD ACTUALLY REQUIRE 3-WAY MESSAGING) -->

          <!-- should the ESP data relay really do DPI or just use ports? Ari: relay can run out of ports. Miika: new SPI collision mechanism -->

          <t> When a Data Relay Server receives an UPDATE with a
          PEER_PERMISSION parameter, it MUST <bcp14>MUST</bcp14> check if the
          sender of the UPDATE is registered for data relaying data-relaying service, and
          drop the UPDATE if the host was not registered. If the host was
          registered, the Data Relay Server checks if there is a permission
          with matching information (protocol, addresses, ports ports, and SPI
          values). If there is no such permission, a new permission MUST
          <bcp14>MUST</bcp14> be created and its lifetime MUST <bcp14>MUST</bcp14>
          be set to 5 minutes. If an identical permission already existed, it MUST
          <bcp14>MUST</bcp14> be refreshed by setting the lifetime to 5
          minutes. A Data Relay Client SHOULD <bcp14>SHOULD</bcp14> refresh
          permissions 1 minute before the expiration when the permission is
          still needed. </t>
          <t>When a Data Relay Server receives an UPDATE from a registered
          client but without a PEER_PERMISSION parameter and with a new
          locator set, the Data Relay Server can assume that the mobile host
          has changed its location and, thus, and is thus not reachable in its previous
          location. In such an event, the Data Relay Server SHOULD
          <bcp14>SHOULD</bcp14> deactivate the permission and stop relaying
          data plane traffic to the client.</t>
          <t>The relayed address MUST <bcp14>MUST</bcp14> be activated with the
          PEER_PERMISSION parameter both after a base exchange and after a
          handover procedure with another ICE-HIP-UDP capable ICE-HIP-UDP-capable host. Unless
          activated, the Data Relay Server MUST <bcp14>MUST</bcp14> drop all ESP
          packets. It is worth noting that a Data Relay Client does not have
          to renew its registration upon a change of location UPDATE, but only
          when the lifetime of the registration is close to end.</t>
        </section> <!-- Forwarding Rules and Permissions -->

        <section title="HIP numbered="true" toc="default">
          <name>HIP Data Relay and Relaying of Control Packets"> Packets</name>
          <t>When a Data Relay Server accepts to relay UDP encapsulated UDP-encapsulated ESP
	  between a Data Relay Client and its peer, the Data Relay Server
	  opens a UDP port (relayed address) for this purpose as described in
	  <xref
          target="sec:registration"/>. target="sec_registration" format="default"/>. This port can be
	  used for delivering also delivering control packets because connectivity checks
	  also cover the path through the Data Relay Server. If the Data Relay
	  Server receives a UDP encapsulated UDP-encapsulated HIP control packet on that port,
	  it MUST <bcp14>MUST</bcp14> forward the packet to the Data Relay Client
	  and add a RELAY_FROM parameter to the packet as if the Data Relay
	  Server were acting as a Control Relay Server. When the Data Relay
	  Client replies to a control packet with a RELAY_FROM parameter via
	  its Data Relay Server, the Data Relay Client MUST <bcp14>MUST</bcp14> add
	  a RELAY_TO parameter containing the peer's address and use the
	  address of its Data Relay Server as the destination
	  address. Further, the Data Relay Server MUST <bcp14>MUST</bcp14> send
	  this packet to the peer's address from the relayed address.</t>
          <t> If the Data Relay Server receives a UDP packet that is not a
          HIP control packet to the relayed address, it MUST <bcp14>MUST</bcp14> check if
          it has a permission set for the peer the packet is arriving
          from (i.e., the sender's address and SPI value matches to an
          installed permission). If permissions are set, the Data Relay Server
          MUST
          <bcp14>MUST</bcp14> forward the packet to the Data Relay Client that
          created the permission. The Data Relay Server MUST <bcp14>MUST</bcp14> also implement
          the similar checks for the reverse direction (i.e. (i.e., ESP packets
          from the Data Relay Client to the peer). Packets without a
	  permission MUST <bcp14>MUST</bcp14> be dropped silently.</t>
        </section> <!-- HIP Data Relay and Relaying of Control Packets -->

        <section title="Handling anchor="sec_conflicting" numbered="true" toc="default">
          <name>Handling Conflicting SPI Values" anchor="sec:conflicting"> Values</name>
          <t>From the viewpoint of a host, its remote peers can have
          overlapping inbound SPI numbers because the IPsec uses also uses the
          destination IP address to index the remote peer host. However, a
          Data Relay Server can represent multiple remote peers, thus
          masquerading the actual destination. Since a Data Relay Server may
          have to deal with a multitude of Relay Clients and their peers, a
          Data Relay Server may experience collisions in the SPI namespace,
          thus being unable to forward datagrams to the correct
          destination. Since the SPI space is 32 bits and the SPI values
          should be random, the probability for a conflicting SPI value is
          fairly small, small but could occur on a busy Data Relay Server.  The two
          problematic cases are described in this section.</t>
          <t>In the first scenario, the SPI collision problems problem occurs
          if two hosts have registered to the same Data Relay Server
          and a third host initiates base exchange with both of
          them. Here, the two Responders (i.e. (i.e., Data Relay Clients)
          claim the same inbound SPI number with the same Initiator
          (peer). However, in this case, the Data Relay Server has
          allocated separate UDP ports for the two Data Relay Clients
          acting now as Responders (as recommended in <xref
          target="sec:reuse" />). target="sec_reuse"
	  format="default"/>). When the third host sends an ESP packet,
          the Data Relay Server is able to forward the packet to the
          correct Data Relay Client because the destination UDP port
          is different for each of the clients.</t>
          <t>In the second scenario, an SPI collision may occur when
	  two Initiators run a base exchange to the same Responder
	  (i.e.
	  (i.e., Data Relay Client), and both of the Initiators claim
	  the same inbound SPI at the Data Relay Server using
	  the PEER_PERMISSION Parameter. parameter. In this case, the Data Relay
	  Server cannot disambiguate the correct destination of an ESP
	  packet originating from the Data Relay Client because the
	  SPI could belong to either of the peers (and the destination IP
	  and UDP port belonging to the Data Relay Server are not
	  unique either). The recommended way and a contingency plan
	  to solve this issue are described below.</t>
          <t>The recommend way to mitigate the problem is as follows. For each
          new Host Association, A HIP association, a Data Relay Client acting as a Responder SHOULD
          <bcp14>SHOULD</bcp14> register a new server reflexive server-reflexive candidate as
          described in <xref
          target="sec:gathering" />. target="sec_gathering"
          format="default"/>. Similarly, the Data Relay Server
          SHOULD NOT re-use <bcp14>SHOULD
          NOT</bcp14> reuse the port numbers as described in <xref
          target="sec:reuse" />.
          target="sec_reuse" format="default"/>. This way, each server reflexive
          server-reflexive candidate for the Data Relay Client has a separate
          UDP port that the Data Relay Server can use to disambiguate packet
          destinations in case of SPI collisions.</t>
          <t>When the Data Relay Client is not registering or failed
	  to register a new relay candidate for a new peer, the Data
	  Relay Client MUST <bcp14>MUST</bcp14> follow a contingency plan as follows.
	  Upon receiving an I2 with a colliding SPI, the Data Relay
	  client
	  Client acting as the Responder MUST NOT <bcp14>MUST NOT</bcp14> include the relayed
	  address candidate in the R2 message because the Data Relay
	  Server would not be able to demultiplex the related ESP packet
	  to the correct Initiator.  The same applies also applies to the
	  handover procedures; the Data Relay Client MUST NOT <bcp14>MUST NOT</bcp14> include
	  the relayed address candidate when sending its new locator
	  set in an UPDATE to its peer if it would cause a an SPI
	  conflict with another peer.
	  <!--
	  However, a Data
	  Relay Client with many peers MAY proactively decrease the
	  odds of a conflict by registering to multiple Data Relay
	  Servers. Thus, the described collision scenario can be
	  avoided if the Responder delivers a new relayed address
	  candidate upon SPI collisions.  Each relayed address has a
	  separate UDP port reserved to it, so collision problem does
	  not occur. -->

          </t>

          <!--
          <t>The inbound SPI values of the registered
          clients should be unique so that a Control and Data Relay Server can properly demultiplex
          incoming packets from peer hosts to the correct registered clients. Likewise,
          the inbound SPIs of the peer hosts should be unique for the same reason. These two cases are
          discussed in this section separately.</t>
	  -->

          <!-- registeration using multiple local addresses does not work in the case of HIP? -->

          <!-- no sending of NOTIFYs upon SPI collisions -->

	  <!--
          <t>In first case, the SPI collision problem occurs when two
          Initiators run a base exchange to the same Responder
          (i.e. Data Relay Client), and both the Initiators claim the
          same inbound SPI. This is not a problem for the Responder since
          the two Initiators can be distinguished by their transport
          addresses. However, it is an issue for the Data Relay Server
          because it cannot demultiplex packets from the Initiator
          to the correct Responder.
	  -->

        </section> <!-- Handling Conflicting SPI Values -->

      </section> <!-- Relay Considerations -->

    </section>

    <!-- ***************************************************************** -->

    <section anchor="sec:format" title="Packet Formats"> anchor="sec_format" numbered="true" toc="default">
      <name>Packet Formats</name>
      <t> The following subsections define the parameter and packet encodings
      for the HIP and ESP packets. All values MUST <bcp14>MUST</bcp14> be in
      network byte order.</t>
      <t>It is worth noting that all of the parameters are shown for the sake
      of completeness even though they are specified already in Legacy ICE-HIP
      <xref target="RFC5770" />. format="default"/>. New parameters are explicitly
      described as new.</t>
      <section anchor="sec:udphip" title="HIP anchor="sec_udphip" numbered="true" toc="default">
        <name>HIP Control Packets"> Packets</name>
        <t><xref target="fig:udphip"/> target="fig_udphip" format="default"/> illustrates the packet
	format for UDP-encapsulated HIP. The format is identical to Legacy
	ICE-HIP <xref target="RFC5770"/>.</t> target="RFC5770" format="default"/>.</t>
        <figure anchor="fig:udphip"
          title="Format anchor="fig_udphip">
          <name>Format of UDP-Encapsulated HIP Control Packets"> Packets</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Source Port            |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Length              |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       32 bits of zeroes                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                    HIP Header and Parameters                  ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t> HIP control packets are encapsulated in UDP packets as defined in
        Section 2.2 of
	<xref target="RFC3948"/>, target="RFC3948" sectionFormat="of" section="2.2"/>, "IKE Header
	Format for Port 4500", except that a different port number is
	used. <xref
        target="fig:udphip"/> target="fig_udphip" format="default"/> illustrates the
	encapsulation.  The UDP header is followed by 32 zero bits that can be
	used to differentiate HIP control packets from ESP packets. The HIP
	header and parameters follow the conventions of <xref target="RFC7401"/> target="RFC7401"
	format="default"/> with the exception that the HIP header checksum MUST
	<bcp14>MUST</bcp14> be zero. The HIP header checksum is zero for two
	reasons. First, the UDP header already contains a checksum. Second,
	the checksum definition in <xref target="RFC7401"/> target="RFC7401" format="default"/>
	includes the IP addresses in the checksum calculation. The NATs that
	are unaware of HIP cannot recompute the HIP checksum after changing IP addresses. </t>
	addresses.</t>
        <t> A Control/Data Relay Server or a non-relay Responder SHOULD
	<bcp14>SHOULD</bcp14> listen at UDP port 10500 for incoming
	UDP-encapsulated HIP control packets. If some other port number is
	used, it needs to be known by potential Initiators. </t>

	<!--

	<t>It is worth noting that UDP encapsulation of HIP packets
	reduces the Maximum Transfer Unit (MTU) size of the control
	plane by 12 bytes.</t> -->

	<t>UDP encapsulation of HIP packets reduces the Maximum
	Transfer
	Transmission Unit (MTU) size of the control plane by 12 bytes
	(8-byte UDP header plus 4-byte zero SPI marker), and the data
	plane by 8 bytes.  Additional HIP relay parameters, such as
	RELAY_HMAC, RELAY_UDP_HIP, RELAY_UDP_ESP, etc., further
	increase the size of certain HIP packets. In regard to MTU,
	the following aspects need to be considered in an
	implementation:
        </t>

	<t><list style="symbols">

	<t>A

        <ul spacing="normal">
          <li>A HIP host SHOULD <bcp14>SHOULD</bcp14> implement ICMP message handling
	  to support path Path MTU discovery Discovery (PMTUD) discovery as described in
	  <xref target="RFC1063" /> target="RFC1191" format="default"/> and <xref target="RFC8201"
	/></t>

        <t>Reliance
	  format="default"/>.</li>
          <li>Reliance on IP fragmentation is unlikely to be a viable strategy
	  through NATs. If ICMP MTU discovery is not working,
        MTU related MTU-related path
	  black holes may occur.</t>

        <t>A occur.</li>

          <li>A mitigation strategy is to constrain the MTU, especially for
	  virtual interfaces, to expected safe MTU values, e.g., 1400 bytes
	  for the underlying interfaces that support 1500 bytes MTU.</t>

	<t>Further MTU.</li>
          <li>Further extensions to this specification may define a HIP-based
	  mechanism to find a working path MTU without unnecessary
	  constraining that size using Packetization Layer Path MTU Discovery
	  for Datagram Transports <xref target="I-D.ietf-tsvwg-datagram-plpmtud"/>.
	  target="RFC8899" format="default"/>. For
	  instance, such a mechanism could be implemented between a HIP Relay
	  Client and HIP Relay Server.
	</t>

	<t>It Server.</li>
          <li>It is worth noting that further HIP extensions can trim off 8
          bytes in the ESP header by negotiating implicit IV initialization
          vector (IV) support in the ESP_TRANSFORM parameter as described in
          <xref target="RFC8750" />.</t>

      </list></t> format="default"/>.</li>
        </ul>
      </section> <!-- HIP Control Packets -->

      <section anchor="sec:con_checks" title="Connectivity Checks"> anchor="sec_con_checks" numbered="true" toc="default">
        <name>Connectivity Checks</name>
        <t>HIP connectivity checks are HIP UPDATE packets. The format
        is specified in <xref target="RFC7401"/>.</t> target="RFC7401" format="default"/>.</t>
      </section>
      <section anchor="sec:keepalive" title="Keepalives"> anchor="sec_keepalive" numbered="true" toc="default">
        <name>Keepalives</name>
        <t>The RECOMMENDED <bcp14>RECOMMENDED</bcp14> encoding format for keepalives is
        HIP NOTIFY packets as specified in <xref target="RFC7401"/> target="RFC7401"
        format="default"/> with the Notify message type field set to
        NAT_KEEPALIVE [TBD by IANA:
        16385] (16385) and with an empty Notification data field. It is
        worth noting that the sending of such a HIP NOTIFY message SHOULD
        <bcp14>SHOULD</bcp14> be omitted if the host is actively (or passively) sending some other
        traffic (HIP or ESP) to the peer host over the related UDP tunnel
        during the Tr period. For instance, the host MAY <bcp14>MAY</bcp14>
        actively send ICMPv6 requests (or respond with an ICMPv6 response)
        inside the ESP tunnel to test the health of the associated IPsec
        security association. Alternatively, the host MAY <bcp14>MAY</bcp14> use
        UPDATE packets as a substitute. A minimal UPDATE packet would consist
        of a SEQ and a single ECHO_REQ_SIGN parameters, parameter, and a more complex one
        would involve rekeying procedures as specified in section 6.8 in <xref
        target="RFC7402" />. sectionFormat="of" section="6.8"/>. It is worth
        noting that a host actively sending periodic UPDATE packets to a busy
        server may increase the computational load of the server since it has
        to verify HMACs and signatures in UPDATE messages.</t>
      </section> <!-- keepalive -->

      <section anchor="sec:nat_tm-param" title="NAT anchor="sec_nat_tm-param" numbered="true" toc="default">
        <name>NAT Traversal Mode Parameter">

	<!-- XX FIXME: TRANSPORT_MODE MISSING --> Parameter</name>

        <t>The format of the NAT traversal mode parameter is defined in Legacy
        ICE-HIP <xref target="RFC5770"/> target="RFC5770" format="default"/> but repeated here
        for completeness.  The format of the NAT_TRAVERSAL_MODE parameter is
        similar to the format of the ESP_TRANSFORM parameter in <xref target="RFC7402"/>
        target="RFC7402" format="default"/> and is shown in <xref target="fig:nat_tfm" />.
        target="fig_nat_tfm" format="default"/>. The Native ICE-HIP extension
        specified in this document defines the new NAT traversal mode
        identifier for ICE-HIP-UDP and reuses the UDP-ENCAPSULATION mode from
        Legacy ICE-HIP <xref target="RFC5770"/>. target="RFC5770" format="default"/>. The
        identifier named RESERVED is reserved for future use. Future
        specifications may define more traversal modes. </t>
        <figure anchor="fig:nat_tfm"
          title="Format anchor="fig_nat_tfm">
          <name>Format of the NAT_TRAVERSAL_MODE Parameter"> Parameter</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Reserved            |            Mode ID #1         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Mode ID #2          |            Mode ID #3         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Mode ID #n          |             Padding           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type       608
Length     length
]]></artwork>
        </figure>

<dl newline="false" spacing="normal" indent="12">
  <dt>Type:</dt>
  <dd>608</dd>
  <dt>Length:</dt>
  <dd>Length in octets, excluding Type, Length, and padding
Reserved   zero Padding</dd>
  <dt>Reserved:</dt>
  <dd>Zero when sent, ignored when received
Mode ID    defines received</dd>
  <dt>Mode ID:</dt>
  <dd>Defines the proposed or selected NAT traversal mode(s)

The mode(s)</dd>
</dl>

<t>The following NAT traversal mode IDs are defined:

    ID name            Value
    RESERVED             0
    UDP-ENCAPSULATION    1
    ICE-STUN-UDP         2
    ICE-HIP-UDP          3
                ]]></artwork>
        </figure> defined:</t>
<table align="center">
<name>NAT Traversal Mode IDs
</name>
  <thead>
    <tr>
      <th>ID name</th>
      <th>Value</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>RESERVED</td>
      <td>0</td>
    </tr>
    <tr>
      <td>UDP-ENCAPSULATION</td>
      <td>1</td>
    </tr>
    <tr>
      <td>ICE-STUN-UDP</td>
      <td>2</td>
    </tr>
    <tr>
      <td>ICE-HIP-UDP</td>
      <td>3</td>
    </tr>
  </tbody>
</table>
        <t> The sender of a NAT_TRAVERSAL_MODE parameter MUST <bcp14>MUST</bcp14> make sure that
        there are no more than six (6) Mode IDs in one NAT_TRAVERSAL_MODE
        parameter. Conversely, a recipient MUST <bcp14>MUST</bcp14> be prepared to handle received
        NAT traversal mode parameters that contain more than six Mode IDs by
        accepting the first six Mode IDs and dropping the rest. The limited
        number of Mode IDs sets the maximum size of the NAT_TRAVERSAL_MODE
        parameter. The modes MUST <bcp14>MUST</bcp14> be in preference order, most preferred
        mode(s) first. </t>
        <t>Implementations conforming to this specification MUST
	<bcp14>MUST</bcp14> implement UDP-ENCAPSULATION and SHOULD
	<bcp14>SHOULD</bcp14> implement ICE-HIP-UDP modes.</t>
      </section> <!-- NAT Traversal Mode Parameter -->

      <section anchor="sec:check-pacing-param"
        title="Connectivity anchor="sec_check-pacing-param" numbered="true" toc="default">
        <name>Connectivity Check Transaction Pacing Parameter"> Parameter</name>
        <t> The TRANSACTION_PACING parameter is defined in <xref target="RFC5770"/>, target="RFC5770"
	format="default"/> but repeated in <xref target="fig:check_pacing"/> target="fig_check_pacing"
	format="default"/> for completeness. It contains only the connectivity
	check pacing value, expressed in milliseconds, as a 32-bit unsigned
	integer.</t>
        <figure anchor="fig:check_pacing"
          title="Format anchor="fig_check_pacing">
          <name>Format of the TRANSACTION_PACING Parameter"> Parameter</name>
          <artwork align="center"><![CDATA[ name="" type="" alt=""><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Min Ta                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type     610
Length   4
Min Ta   the
]]></artwork>
        </figure>

<dl newline="false" spacing="normal" indent="12">
  <dt>Type:</dt>
  <dd>610</dd>
  <dt>Length:</dt>
  <dd>4</dd>
  <dt>Min Ta:</dt>
  <dd>The minimum connectivity check transaction pacing value the host would
  use (in milliseconds)
                ]]></artwork>
        </figure> milliseconds)</dd>
</dl>
      </section>

      <section anchor="sec:rel-reg-params"
        title="Relay anchor="sec_rel-reg-params" numbered="true" toc="default">
        <name>Relay and Registration Parameters"> Parameters</name>
        <t> The format of the REG_FROM, RELAY_FROM, and RELAY_TO parameters is
	shown in <xref target="fig:reg_from" />. target="fig_reg_from" format="default"/>. All
	parameters are identical except for the type. Of the three, only
	REG_FROM is covered by the signature. </t>
        <figure anchor="fig:reg_from"
          title="Format anchor="fig_reg_from">
          <name>Format of the REG_FROM, RELAY_FROM, and RELAY_TO Parameters"> Parameters</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Port              |    Protocol   |     Reserved  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Address                            |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type       REG_FROM:   950
           RELAY_FROM: 63998
           RELAY_TO:   64002
Length     20
Port       transport
]]></artwork>
        </figure>

<dl newline="false" spacing="normal" indent="12">
  <dt>Type:</dt>
    <dd>
      <dl newline="false" spacing="compact">
	<dt>REG_FROM:</dt>
	<dd>950</dd>
        <dt>RELAY_FROM:</dt>
	<dd>63998</dd>
        <dt>RELAY_TO:</dt>
	<dd>64002</dd>
      </dl>
    </dd>
    <dt>Length:</dt>
    <dd>20 </dd>
    <dt>Port:</dt>
    <dd>Transport port number; zero when plain IP is used
Protocol   IANA assigned, used</dd>
    <dt>Protocol:</dt>
    <dd>IANA-assigned, Internet Protocol number. 17 for UDP, UDP; 0 for plain IP
Reserved   reserved
    IP</dd>
    <dt>Reserved:</dt>
    <dd>Reserved for future use; zero when sent, ignored when received
Address    an received</dd>
    <dt>Address:</dt>
    <dd>An IPv6 address or an IPv4 address in "IPv4-Mapped "IPv4-mapped IPv6 address" format
                ]]></artwork>
        </figure>
    format</dd>
</dl>

        <t> REG_FROM contains the transport address and protocol from which the Control
        Relay Server sees the registration coming. RELAY_FROM contains the
        address from which the relayed packet was received by the Control Relay Server
        and the protocol that was used. RELAY_TO contains the same information
        about the address to which a packet should be forwarded. </t>
      </section> <!-- Relay and Registration Parameters -->

      <section title="LOCATOR_SET Parameter" anchor="sec:locator_format"> anchor="sec_locator_format" numbered="true" toc="default">
        <name>LOCATOR_SET Parameter</name>
        <t>This specification reuses the format for UDP-based locators as
	specified in Legacy ICE-HIP <xref target="RFC5770"/> target="RFC5770" format="default"/>
	to be used for communicating the address candidates between two
	hosts. The generic and NAT-traversal-specific locator parameters are
	illustrated in <xref target="fig:locator"/>. target="fig_locator" format="default"/>. </t>
        <figure anchor="fig:locator" title="LOCATOR_SET Parameter"> anchor="fig_locator">
          <name>LOCATOR_SET Parameter</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type  |  Locator Type | Locator Length|  Reserved   |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Locator Lifetime                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Locator                            |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type  |  Loc Type = 2 | Locator Length|  Reserved   |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Locator Lifetime                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Transport Port            |  Transp. Proto|     Kind      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Priority                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SPI                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Address                            |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t> The individual fields in the LOCATOR_SET parameter are described in
        <xref target="tbl:locator"/>. target="tbl_locator" format="default"/>. </t>

        <texttable anchor="tbl:locator"
          title="Fields
        <table anchor="tbl_locator" align="center">
          <name>Fields of the LOCATOR_SET Parameter">
          <ttcol align="left">Field</ttcol>
          <ttcol align="left">Value(s)</ttcol>
          <ttcol align="left">Purpose</ttcol>
          <c>Type</c>
          <c>193</c>
          <c>Parameter type</c>
          <c>Length</c>
          <c>Variable</c>
          <c>Length Parameter</name>
          <thead>
            <tr>
              <th align="left">Field</th>
              <th align="left">Value(s)</th>
              <th align="left">Purpose</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Type</td>
              <td align="left">193</td>
              <td align="left">Parameter type</td>
            </tr>
            <tr>
              <td align="left">Length</td>
              <td align="left">Variable</td>
              <td align="left">Length in octets, excluding Type and Length fields and padding</c>
          <c>Traffic Type</c>
          <c>0-2</c>
          <c>Is the padding</td>
            </tr>
            <tr>
              <td align="left">Traffic Type</td>
              <td align="left">0-2</td>
              <td align="left">The locator for either HIP signaling (1), for (1) or ESP (2), or for
           both (0)</c>
          <c>Locator Type</c>
          <c>2</c>
          <c>"Transport (0)</td>
            </tr>
            <tr>
              <td align="left">Locator Type</td>
              <td align="left">2</td>
              <td align="left">"Transport address" locator type</c>
          <c>Locator Length</c>
          <c>7</c>
          <c>Length type</td>
            </tr>
            <tr>
              <td align="left">Locator Length</td>
              <td align="left">7</td>
              <td align="left">Length of the fields after Locator Lifetime in 4-octet units</c>
          <c>Reserved</c>
          <c>0</c>
          <c>Reserved units</td>
            </tr>
            <tr>
              <td align="left">Reserved</td>
              <td align="left">0</td>
              <td align="left">Reserved for future extensions</c>
          <c>Preferred extensions</td>
            </tr>
            <tr>
              <td align="left">Preferred (P) bit</c>
          <c>0 bit</td>
              <td align="left">0 or 1</c>
          <c>Set 1</td>
              <td align="left">Set to 1 for a Locator in R1 if the Responder can use it for the
          rest of the base exchange, otherwise set to zero</c>
          <c>Locator Lifetime</c>
          <c>Variable</c>
          <c>Locator zero</td>
            </tr>
            <tr>
              <td align="left">Locator Lifetime</td>
              <td align="left">Variable</td>
              <td align="left">Locator lifetime in seconds, see Section 4 in
	      <xref target="RFC8046" /></c>
          <c>Transport Port</c>
          <c>Variable</c>
          <c>Transport layer sectionFormat="of" section="4"/></td>
            </tr>
            <tr>
              <td align="left">Transport Port</td>
              <td align="left">Variable</td>
              <td align="left">Transport-layer port number</c>
          <c>Transport Protocol</c>
          <c>Variable</c>
          <c>IANA assigned, transport layer number</td>
            </tr>
            <tr>
              <td align="left">Transport Protocol</td>
              <td align="left">Variable</td>
              <td align="left">IANA-assigned, transport-layer Internet Protocol number.
           Currently
           Currently, only UDP (17) is supported.</c>
          <c>Kind</c>
          <c>Variable</c>
          <c>0 supported.</td>
            </tr>
            <tr>
              <td align="left">Kind</td>
              <td align="left">Variable</td>
              <td align="left">0 for host, 1 for server reflexive, 2 for peer
	      reflexive (currently unused) unused), or 3 for relayed address</c>
          <c>Priority</c>
          <c>Variable</c>
          <c>Locator's address</td>
            </tr>
            <tr>
              <td align="left">Priority</td>
              <td align="left">Variable</td>
              <td align="left">Locator's priority as described in <xref target="RFC8445"/>.
              target="RFC8445" format="default"/>. It is worth noting that
              while the priority of a single locator candidate is 32-bits, but 32 bits, an
              implementation should use a 64-bit integer to calculate the priority
              of a candidate pair for the ICE priority algorithm.</c>
          <c>SPI</c>
          <c>Variable</c>
          <c>Security algorithm.</td>

            </tr>
            <tr>
              <td align="left">SPI</td>
              <td align="left">Variable</td>
              <td align="left">Security Parameter Index (SPI) value that the
	      host expects to see in incoming ESP packets that use this locator</c>
          <c>Address</c>
          <c>Variable</c>
          <c>IPv6
	      locator</td>
            </tr>
            <tr>
              <td align="left">Address</td>
              <td align="left">Variable</td>
              <td align="left">IPv6 address or an "IPv4-Mapped "IPv4-mapped IPv6 address"
	      format IPv4 address <xref target="RFC4291"/></c>
        </texttable> target="RFC4291"
	      format="default"/></td>
            </tr>
          </tbody>
        </table>
        <t>The LOCATOR parameter MUST <bcp14>MUST</bcp14> be encapsulated inside an
	ENCRYPTED parameter.</t>
      </section> <!-- locator parameter format -->

      <section anchor="sec:relay-hmac" title="RELAY_HMAC Parameter"> anchor="sec_relay-hmac" numbered="true" toc="default">
        <name>RELAY_HMAC Parameter</name>
        <t>As specified in Legacy ICE-HIP <xref target="RFC5770"/>, target="RFC5770"
	format="default"/>, the RELAY_HMAC parameter value has the TLV type
	65520. It has the same semantics as RVS_HMAC as specified in section 4.2.1
        in <xref target="RFC8004"/>.  Similarly as with
	target="RFC8004" sectionFormat="of" section="4.2.1"/>.  Similar to
	RVS_HMAC, also RELAY_HMAC is also keyed with the HIP integrity key
	(HIP-lg or HIP-gl as specified in section 6.5 in <xref target="RFC7401"
        />), section="6.5"
	sectionFormat="of"/>), established during the relay registration
	procedure as described in <xref target="sec:registration" />.</t> target="sec_registration"
	format="default"/>.</t>
      </section> <!-- RELAY_HMAC -->

      <section anchor="sec:reg-types" title="Registration Types"> anchor="sec_reg-types" numbered="true" toc="default">
        <name>Registration Types</name>
        <t> The REG_INFO, REG_REQ, REG_RESP, and REG_FAILED parameters contain
	Registration Type <xref target="RFC8003"/> target="RFC8003" format="default"/> values for
	Control Relay Server registration. The value for RELAY_UDP_HIP is 2 as
	specified in Legacy ICE-HIP <xref target="RFC5770"/>. target="RFC5770"
	format="default"/>. The value for RELAY_UDP_ESP is (value [TBD by IANA: 3]).
	</t> 3.</t>
      </section> <!-- Registration Types -->

      <section anchor="sec:notify-types" title="Notify anchor="sec_notify-types" numbered="true" toc="default">
        <name>Notify Packet Types"> Types</name>
        <t>A Control/Data Relay Server and end-hosts end hosts can use NOTIFY packets to
	signal different error conditions. The NOTIFY packet types are the
	same as in Legacy ICE-HIP <xref target="RFC5770"/> target="RFC5770" format="default"/>
	except for the two last ones, which are new.</t>
        <t>The Notify Packet Types <xref
        target="RFC7401"/> target="RFC7401" format="default"/>
	are shown below. The Notification Data field for the error
	notifications SHOULD <bcp14>SHOULD</bcp14> contain the HIP header of the
	rejected packet and SHOULD <bcp14>SHOULD</bcp14> be empty for the
	CONNECTIVITY_CHECKS_FAILED type. </t>

        <figure> <artwork>
NOTIFICATION

<table anchor="notif-param-error-types">
<name>Notify Packet Types
</name>
  <thead>

    <tr>
      <th>NOTIFICATION PARAMETER - ERROR TYPES           Value
------------------------------------           -----

NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER          60
        </artwork> </figure>

        <t><list>
            <t> If TYPES</th>
       <th>Value</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><t>NO_VALID_NAT_TRAVERSAL_MODE_PARAMETER</t>
      <t>If a Control Relay Server does not forward a base exchange packet due
      to a missing NAT traversal mode parameter, or the Initiator selects a
      NAT traversal mode that the (non-relay) Responder did not expect, the
      Control Relay Server or the Responder may send back a NOTIFY error
      packet with this type. </t>
        </list></t>

        <figure> <artwork>
CONNECTIVITY_CHECKS_FAILED                    61
         </artwork> </figure>

        <t><list>
          <t> Used type.</t></td>
      <td>60</td>
    </tr>
    <tr>

      <td><t>CONNECTIVITY_CHECKS_FAILED</t>
       <t>Used by the end-hosts end hosts to signal that NAT traversal
      connectivity checks failed and did not produce a working path. </t>
        </list> </t>

        <figure> <artwork>
MESSAGE_NOT_RELAYED                           62
         </artwork> </figure>

        <t><list>
            <t> Used path.</t></td>
        <td>61</td>
    </tr>

    <tr>
      <td><t>MESSAGE_NOT_RELAYED</t>
       <t>Used by a Control Relay Server to signal that is it was not able or
      willing to relay a HIP packet. </t>
        </list> </t>

        <figure> <artwork>
SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED  63
         </artwork> </figure>

        <t><list>
            <t> Used packet.</t></td>
        <td>62</td>
    </tr>

    <tr>
      <td><t>SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED</t>
      <t>Used by a Data Relay Server to signal that is it was not able or
      willing to allocate a new server reflexive server-reflexive candidate for the Data
      Relay Client</t>
        </list> </t>

        <figure> <artwork>
RVS_HMAC_PROHIBITED_WITH_RELAY  64
         </artwork> </figure>

        <t><list>
          <t> In Client.</t></td>
       <td>63</td>
    </tr>
    <tr>

      <td><t>RVS_HMAC_PROHIBITED_WITH_RELAY</t>
      <t>In the unintended event that a Control Relay Server sends any HIP
      message with a an RVS_HMAC parameter, the Control Relay Client drops the
      received HIP message and sends a notify message back to the  Control
      Relay Server using this notify type</t>
        </list></t> type.</t></td>
      <td>64</td>
    </tr>
  </tbody>
</table>

      </section> <!-- Notify Packet Types -->

      <section anchor="sec:udpesp" title="ESP anchor="sec_udpesp" numbered="true" toc="default">
        <name>ESP Data Packets"> Packets</name>
        <t>The format for ESP data packets is identical to Legacy ICE-HIP
	<xref target="RFC5770"/>.</t> target="RFC5770" format="default"/>.</t>
        <t> <xref target="RFC3948"/> target="RFC3948" format="default"/> describes the UDP encapsulation of the
        IPsec ESP transport and tunnel mode. On the wire, the HIP ESP packets
        do not differ from the transport mode ESP, and thus ESP; thus, the encapsulation
        of the HIP ESP packets is same as the UDP encapsulation transport mode
        ESP. However, the (semantic) difference to Bound End-to-End Tunnel
        (BEET) mode ESP packets used by HIP is that the IP header is not used in
        BEET integrity protection calculation.</t>

        <t> During the HIP base exchange, the two peers exchange parameters
        that enable them to define a pair of IPsec ESP security associations
        (SAs) as described in <xref target="RFC7402"/>. target="RFC7402" format="default"/>. When two peers perform
        a UDP-encapsulated base exchange, they MUST <bcp14>MUST</bcp14> define a pair of IPsec SAs
        that produces UDP-encapsulated ESP data traffic. </t>
        <t> The management of encryption/authentication protocols and SPIs is
	defined in <xref target="RFC7402"/>. target="RFC7402" format="default"/>. The UDP
	encapsulation format and processing of HIP ESP traffic is described in Section 6.1 of
	<xref
        target="RFC7402"/>. </t>

	<!--
	<t>It is worth noting that UDP encapsulation of ESP reduces
	the MTU size of data plane by 8 bytes. target="RFC7402" sectionFormat="of" section="6.1"/>. </t>
	-->

      </section>
      <section anchor="sec:relayed_address"
        title="RELAYED_ADDRESS anchor="sec_relayed_address" numbered="true" toc="default">
        <name>RELAYED_ADDRESS and MAPPED_ADDRESS Parameters"> Parameters</name>
        <t>While the type values are new, the format of the RELAYED_ADDRESS
        and MAPPED_ADDRESS parameters (<xref target="fig:relayed_address"/>) target="fig_relayed_address"
        format="default"/>) is identical to REG_FROM,
        RELAY_FROM RELAY_FROM, and RELAY_TO
        parameters. This document specifies only the use of UDP relaying, and, relaying;
        thus, only protocol 17 is allowed. However, future documents may
        specify support for other protocols.</t>
        <figure anchor="fig:relayed_address"
          title="Format anchor="fig_relayed_address">
          <name>Format of the RELAYED_ADDRESS and MAPPED_ADDRESS Parameters"> Parameters</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Port              |    Protocol   |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            Address                            |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type      [TBD by IANA;
          RELAYED_ADDRESS: 4650
          MAPPED_ADDRESS:  4660]
Length    20
Port      the
]]></artwork>
        </figure>

<dl newline="false" spacing="normal" indent="12">
  <dt>Type:</dt>
    <dd>
        <dl newline="false" spacing="compact">
          <dt>RELAYED_ADDRESS:</dt>
          <dd>4650</dd>
          <dt>MAPPED_ADDRESS:</dt>
          <dd>4660</dd>
         </dl>
     </dd>
     <dt>Length:</dt>
     <dd>20</dd>
     <dt>Port:</dt>
     <dd>The UDP port number
Protocol  IANA assigned, number</dd>
     <dt>Protocol:</dt>
     <dd>IANA-assigned, Internet Protocol number (17 for UDP)
Reserved  reserved UDP)</dd>
     <dt>Reserved:</dt>
     <dd>Reserved for future use; zero when sent, ignored when received
Address   an received</dd>
     <dt>Address:</dt>
     <dd>An IPv6 address or an IPv4 address in "IPv4-Mapped "IPv4-mapped IPv6 address"
  format</dd>
</dl>

      </section>
      <section anchor="sec_peer_permission" numbered="true" toc="default">
        <name>PEER_PERMISSION Parameter</name>
        <t> The format
                ]]></artwork>
        </figure>

        <!-- These parameters are not in the RVS and relaying range
        since they should be signed by the Relay Server -->

      </section>

      <section anchor="sec:peer_permission"
        title="PEER_PERMISSION Parameter">

        <t> The format of of the new PEER_PERMISSION parameter is shown in <xref
        target="fig:peer_permission"/>.
	target="fig_peer_permission" format="default"/>. The parameter is used
	for setting up and refreshing forwarding rules and the permissions for
	data packets at the Data Relay Server. The parameter contains one or
	more sets of Port, Protocol, Address, Outbound SPI (OSPI), and Inbound
	SPI (ISPI) values. One set defines a rule for one peer address. </t>
        <figure anchor="fig:peer_permission"
          title="Format anchor="fig_peer_permission">
          <name>Format of the PEER_PERMISSION Parameter"> Parameter</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            RPort              |             PPort             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Protocol    |          Reserved                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            RAddress                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                            PAddress                           |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              OSPI                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ISPI                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type      [TBD by IANA; 4680]
Length    48
RPort     the transport layer
]]></artwork>
        </figure>

<dl newline="false" spacing="normal" indent="12">
  <dt>Type:</dt>
  <dd>4680</dd>
  <dt>Length:</dt>
  <dd>48</dd>
  <dt>RPort:</dt>
  <dd>The transport-layer (UDP) port at the Data Relay Server
          (i.e. (i.e., the port
  of the server reflexive candidate)
PPort     the transport layer server-reflexive candidate)</dd>
  <dt>PPort:</dt>
  <dd>The transport-layer (UDP) port number of the peer
Protocol  IANA assigned, peer</dd>
  <dt>Protocol:</dt>
  <dd>IANA-assigned, Internet Protocol number (17 for UDP)
Reserved  reserved UDP)</dd>
  <dt>Reserved:</dt>
  <dd>Reserved for future use; zero when sent, ignored when received
RAddress  an received</dd>
  <dt>RAddress:</dt>
  <dd>An IPv6 address, or an IPv4 address in "IPv4-Mapped "IPv4-mapped IPv6 address"
  format, of the server reflexive candidate
PAddress  an server-reflexive candidate</dd>
  <dt>PAddress:</dt>
  <dd>An IPv6 address, or an IPv4 address in "IPv4-Mapped "IPv4-mapped IPv6 address"
  format, of the peer
OSPI      the peer</dd>
  <dt>OSPI:</dt>
  <dd>The outbound SPI value the Data Relay Client is using for the peer
ISPI      the peer</dd>
  <dt>ISPI:</dt>
  <dd>The inbound SPI value the Data Relay Client is using for the peer
                ]]></artwork>
        </figure> peer</dd>
</dl>

      </section>
      <section anchor="sec:con-check" title="HIP anchor="sec_con-check" numbered="true" toc="default">
        <name>HIP Connectivity Check Packets"> Packets</name>
        <t>The connectivity request messages are HIP UPDATE packets containing
	a new CANDIDATE_PRIORITY parameter (<xref target="fig:candidate_priority"/>).
	target="fig_candidate_priority" format="default"/>). Response UPDATE
	packets contain a MAPPED_ADDRESS parameter (<xref
        target="fig:relayed_address"/>).
	target="fig_relayed_address" format="default"/>). </t>
        <figure anchor="fig:candidate_priority"
          title="Format anchor="fig_candidate_priority">
          <name>Format of the CANDIDATE_PRIORITY Parameter"> Parameter</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Priority                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type      [TBD by IANA; 4700]
Length    4
Priority  the
]]></artwork>
        </figure>

<dl newline="false" spacing="normal" indent="12">
  <dt>Type:</dt>
  <dd>4700</dd>
  <dt>Length:</dt>
  <dd>4</dd>
  <dt>Priority:</dt>
  <dd>The priority of a (potential) peer reflexive candidate
                ]]></artwork>
        </figure> peer-reflexive candidate</dd>
</dl>
      </section>

      <section anchor="sec:nominate" title="NOMINATE parameter"> anchor="sec_nominate" numbered="true" toc="default">
        <name>NOMINATE Parameter</name>
        <t><xref target="fig:nominate"/> target="fig_nominate" format="default"/> shows the NOMINATE
        parameter that is used to conclude the candidate nomination
	process.</t>
        <figure anchor="fig:nominate"
          title="Format anchor="fig_nominate">
          <name>Format of the NOMINATE Parameter"> Parameter</name>
          <artwork align="center"><![CDATA[ align="center" name="" type="" alt=""><![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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type      [TBD by IANA; 4710]
Length    4
Reserved  Reserved
]]></artwork>
        </figure>

<dl newline="false" spacing="normal" indent="12">
  <dt>Type:</dt>
  <dd>4710</dd>
  <dt>Length:</dt>
  <dd>4</dd>
  <dt>Reserved:</dt>
  <dd>Reserved for future extension purposes
                ]]></artwork>
        </figure> purposes</dd>
</dl>

      </section>
    </section>

    <!-- ***************************************************************** -->

<section>
<name>IAB Considerations
</name>

      <t>The ICE specification <xref target="RFC8445" format="default"/> discusses
      "Unilateral Self-Address Fixing" in Section <xref target="RFC8445"
      sectionFormat="bare" section="18"/>. This protocol is based on ICE; thus,
      the same considerations also apply here.
      </t>
</section>

    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>Since the control plane protocol and Control Relay Server are
      essentially the same (with some minor differences) in this document as
      in Legacy ICE-HIP <xref target="RFC5770"/>, target="RFC5770" format="default"/>, the same
      security considerations (in Sections <xref target="sec:privacy" />, target="sec_privacy"
      format="counter"/>, <xref target="sec:opportunistic" />, target="sec_opportunistic" format="counter"/>,
      <xref target="sec:bex_replay" /> target="sec_bex_replay" format="counter"/>, and <xref target="sec:demux" />,)
      target="sec_demux" format="counter"/>) are still valid, but are
      repeated here for the sake of completeness. New security considerations
      related to the new Data Relay Server are discussed in <xref target="sec:reuse"/>,
      target="sec_reuse" format="default"/>, and considerations related to the
      new connectivity check protocol are discussed in Sections <xref target="sec:amplification" />
      target="sec_amplification" format="counter"/> and  <xref target="sec:conn_attack" />.
      </t>
      target="sec_conn_attack" format="counter"/>.</t>
      <section anchor="sec:privacy" title="Privacy Considerations">

	<!--

        <t> The locators are in plain text format in favor of inspection at
        HIP-aware middleboxes in the future. The current document does not specify
        encrypted versions of LOCATOR_SETs, even though it could be beneficial for
        privacy reasons to avoid disclosing them to middleboxes. </t>
	--> anchor="sec_privacy" numbered="true" toc="default">
        <name>Privacy Considerations</name>

        <t> It is also possible that end-users end users may not want to reveal all
        locators to each other. For example, tracking the physical location of
        a multihoming end-host end host may become easier if it reveals all locators to
        its peer during a base exchange. Also, revealing host addresses exposes
        information about the local topology that may not be allowed in all
        corporate environments.
	For these two local policy reasons, it might be tempting to exclude
        certain host addresses from the LOCATOR_SET parameter of an end-host end host, but
	this is NOT RECOMMENDED.
	<!-- but this requires further experimentation. --> <bcp14>NOT RECOMMENDED</bcp14>.

	For instance, such
        behavior creates non-optimal paths when the hosts are located behind
        the same NAT. Especially, this could be problematic with a legacy NAT
        that does not support routing from the private address realm back to
        itself through the outer address of the NAT. This scenario is referred
        to as the hairpin problem <xref target="RFC5128"/>. target="RFC5128" format="default"/>. With such a legacy
        NAT, the only option left would be to use a relayed transport address
        from an a Data Relay Server.</t>
        <t> The use of Control and Data Relay Servers can be also be useful for
        privacy purposes. For example, a privacy concerned privacy-concerned Responder may reveal
        only its Control Relay Server and Relayed candidates to Initiators. This
        partially protects the Responder against Denial-of-Service (DoS)
        attacks by allowing the Responder to initiate new connections even if
        its relays would be unavailable due to a DoS attack. </t>
      </section> <!-- privacy -->

      <section anchor="sec:opportunistic" title="Opportunistic Mode"> anchor="sec_opportunistic" numbered="true" toc="default">
        <name>Opportunistic Mode</name>
        <t>In opportunistic HIP mode (cf. Section 4.1.8 in <xref (cf.&nbsp;<xref target="RFC7401" />),
        sectionFormat="of" section="4.1.8"/>), an Initiator sends an I1 with
        without setting the destination HIT of the Responder (i.e. (i.e., the
        Control Relay Client). A Control Relay Server SHOULD <bcp14>SHOULD</bcp14>
        have a unique IP address per the Control Relay Client when the Control
        Relay Server is serving more than one Control Relay Client and
        supports opportunistic mode. Otherwise, the Control Relay Server
        cannot guarantee to deliver the I1 packet to the intended recipient.
        Future extensions of this document may allow opportunistic mode to be
        used with non-unique IP addresses to be utilized either as a HIP-level
        anycast or multicast mechanism. Both of the mentioned cases would
        require a separate registration parameters that the Control Relay
        Server proposes and the Control Client Server accepts during
        registration.</t>
      </section> <!-- opportunistic -->

      <section anchor="sec:bex_replay" title="Base anchor="sec_bex_replay" numbered="true" toc="default">
        <name>Base Exchange Replay Protection for Control Relay Server"> Server</name>
        <t> In certain scenarios, it is possible that an attacker, or two
        attackers, can replay an earlier base exchange through a Control Relay Server
        by masquerading as the original Initiator and Responder. The
        attack does not require the attacker(s) to compromise the private
        key(s) of the attacked host(s). However, for this attack to succeed,
        the legitimate Responder has to be disconnected from the Control Relay Server. </t>
        <t> The Control Relay Server can protect itself against replay attacks by becoming
        involved in the base exchange by introducing nonces that the end-hosts end hosts
        (Initiator and Responder) are required to sign. One way to do this is
        to add ECHO_REQUEST_M parameters to the R1 and I2 packets as described
        in <xref target="I-D.heer-hip-middle-auth" /> format="default"/> and drop the I2 or R2
        packets if the corresponding ECHO_RESPONSE_M parameters are not
        present. </t>
      </section>
      <section anchor="sec:demux" title="Demultiplexing anchor="sec_demux" numbered="true" toc="default">
        <name>Demultiplexing Different HIP Associations">

        <t> Section 5.1 of <xref target="RFC3948"/> Associations</name>

        <t><xref target="RFC3948" sectionFormat="of" section="5.1"/> describes
	a security issue for the UDP encapsulation in the standard IP tunnel
	mode when two hosts behind different NATs have the same private IP
	address and initiate communication to the same Responder in the public
	Internet. The Responder cannot distinguish between two hosts, hosts because
	security associations are based on the same inner IP addresses. </t>
        <t> This issue does not exist with the UDP encapsulation of HIP ESP
        transport format because the Responder uses HITs to distinguish between
        different Initiators. </t>
      </section>
      <section anchor="sec:reuse" title="Reuse anchor="sec_reuse" numbered="true" toc="default">
        <name>Reuse of Ports at the Data Relay Server"> Server</name>
        <t> If the Data Relay Server uses the same relayed address and port
	(as conveyed in the RELAYED_ADDRESS parameter) for multiple Data Relay
	Clients, it appears to all the peers, and their firewalls, that all
	the Data Relay Clients are at the same address. Thus, a stateful
	firewall may allow packets to pass from hosts that would not normally be
	able to send packets to a peer behind the firewall. Therefore, a Data
	Relay Server SHOULD NOT re-use <bcp14>SHOULD NOT</bcp14> reuse the port numbers. If
	port numbers need to be re-used, reused, the Data Relay Server SHOULD
	<bcp14>SHOULD</bcp14> have a sufficiently large pool of port numbers
	and randomly select ports from the pool
        randomly to decrease the chances of a
	Data Relay Client obtaining the same address that a another host
	behind the same firewall is using. </t>
      </section> <!-- Reuse of Ports at the Data Relay -->

      <section anchor="sec:amplification" title="Amplification attacks"> anchor="sec_amplification" numbered="true" toc="default">
        <name>Amplification Attacks</name>
        <t>A malicious host may send an invalid list of candidates to
	its peer that are used for targeting a victim host by flooding
	it with connectivity checks. To mitigate the attack, this
	protocol adopts the ICE mechanism to cap the total amount of
	connectivity checks as defined in <xref
	target="sec:alternatives" />.</t> target="sec_alternatives"
	format="default"/>.</t>
      </section> <!-- Amplification attacks  -->

      <section anchor="sec:conn_attack" title="Attacks anchor="sec_conn_attack" numbered="true" toc="default">
        <name>Attacks against Connectivity Checks and Candidate Gathering">

	<t>Section 19.2 in <xref Gathering</name>
        <t><xref target="RFC8445" /> sectionFormat="of" section="19.2"/>
        describes attacks against ICE connectivity checks. HIP bases its
        control plane security on Diffie-Hellman key exchange, public keys keys,
        and Hashed Message Authentication codes, meaning that the mentioned
        security concerns do not apply to HIP either. The mentioned section discusses
        also of discusses man-in-the-middle replay attacks that are difficult to
        prevent. The connectivity checks in this protocol are effectively
        immune against replay attacks because a connectivity request includes
        a random nonce that the recipient must sign and send back as a
        response.
        </t>

	<t>Section 19.3 in <xref
        <t><xref target="RFC8445" /> sectionFormat="of" section="19.3"/>
	describes attacks on server reflexive server-reflexive address
	gathering. Similarly here, if the DNS, a Control Relay Server Server, or a Data Relay Server
	has been compromised, not much can be done. However,
	the case where attacker attackers can inject fake messages (located on a
	shared network segment like Wifi) Wi-Fi) does not apply here. HIP
	messages are integrity and replay protected, so it is not
	possible to inject fake server reflexive server-reflexive address candidates.
        </t>

	<t>Section 19.4 in <xref
        <t><xref target="RFC8445" /> sectionFormat="of" section="19.4"/>
	describes attacks on relayed candidate gathering. Similarly to
	ICE TURN servers, a Data Relay Server require requires an authenticated base
	exchange that protects relayed address gathering against fake
	requests and responses. Further, replay attacks are not
	possible because the HIP base exchange (and also UPDATE
	procedure) is protected against replay attacks.
        </t>
      </section>  <!-- Attacks against Connectivity Checks and Candidate Gathering  -->

      <section anchor="sec:cross_protocol" title="Cross-Protocol Attacks"> anchor="sec_cross_protocol" numbered="true" toc="default">
        <name>Cross-Protocol Attacks</name>
        <t><xref target="sec:registration"/> target="sec_registration" format="default"/> explains how a
        Control Relay Client registers for the RELAY_UDP_HIP service from a
        Control Relay Server. However, the same server may offer also offer
        Rendezvous functionality, and, functionality; thus, a client can register both to a
        RELAY_UDP_HIP and a RENDEZVOUS (see <xref
	target="RFC8004"/>) target="RFC8004"
        format="default"/>) service from the same server. Potentially, this
        introduces a cross-protocol attack (or actually a "cross-message"
        attack) because the key material is the same for the Control Relay
        Service and Rendezvous HMACs. While the problem could be avoided by
        deriving different keys for the Control Relay Service, a more simple
        measure was chosen because the exact attack scenario was
        unclear. Consequently, this section defines a mandatory mitigation
        mechanism against the cross-protocol attack that works by preventing
        the
	simultanous simultaneous use of Rendezvous and Control Relay Service in the
        context of a single HIP Association.</t>
        <t>The registration involves three parameters typically
	delivered sequentally sequentially in R1 (REG_INFO parameter), I2
	(REG_REQUEST)
	(REG_REQUEST), and R2 (REG_RESPONSE) messages but can also be
	delivered in UPDATE messages as described in <xref target="RFC8003" />.
	format="default"/>. The parameters and the
	modifications to their processing are described below:</t>

	<t><list style="numbers">
	  <t>REG_INFO: the
        <dl newline="false" spacing="normal">
          <dt>REG_INFO:</dt>
	  <dd>The Control Relay Server advertizes advertises its available services using
	  this parameter. RELAY_UDP_HIP and RENDEZVOUS services MAY
	  <bcp14>MAY</bcp14> be included in the first advertizement advertisement for the
	  HIP association association, but subsequent ones MUST <bcp14>MUST</bcp14> include only
	  one of them as agreed in earlier registrations (see steps 2 and 3).</t>
	  <t>REG_REQUEST: the
	  3).</dd>
          <dt>REG_REQUEST:</dt>
	  <dd>The Control Relay Client chooses the services it requires using
	  this parameter. If the Control Relay Server offered both RENDEZVOUS
	  or RELAY_UDP_HIP, the Control Relay Client MUST <bcp14>MUST</bcp14>
	  choose only one of them in the REG_REQUEST parameter. Upon choosing
	  one of of the two, it persists throughout the lifetime of the HIP
	  association, and the Control Relay Client MUST NOT <bcp14>MUST NOT</bcp14>
	  register the other remaining one in a subsequent UPDATE message.</t>
	  <t>REG_RESPONSE: the
	  message.</dd>
          <dt>REG_RESPONSE:</dt>
	  <dd>The Control Relay Server verifies the services requested by the
	  Control Relay Client using this parameter. If the Control Relay
	  Server offered both RENDEZVOUS and RELAY_UDP_HIP service, and the
	  Control Relay Client requested for both of them, the Control Relay
	  Client MUST <bcp14>MUST</bcp14> offer only RELAY_UDP_HIP service in the
	  REG_RESPONSE parameter and include a REG_FAILED parameter in the
	  same message, with RENDEZVOUS as the Registration Type and [TBD by IANA: 9]
	  9 as the Failure Type.</t>
	</list></t> Type.</dd>
        </dl>
        <t>As a further measure against cross-protocol attacks, the Control Relay
	Client MUST <bcp14>MUST</bcp14> drop any HIP message that includes an
	RVS_HMAC parameter when it originates from a successfully registered
	Control Relay Server. Upon such an (unintended) event, the Control
	Relay Client
	MUST <bcp14>MUST</bcp14> send a NOTIFY message with
	RVS_HMAC_PROHIBITED_WITH_RELAY as the Notify Message Type to the
	Control Relay Server.
	</t> Server.</t>
      </section>  <!-- Cross-Protocol Attacks  -->
    </section> <!-- security considerations -->

    <!-- ***************************************************************** -->

    <section title="IANA Considerations" anchor="sec:iana"> anchor="sec_iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t> This section is to be interpreted according to <xref
      target="RFC8126"/>.
      target="RFC8126" format="default"/>. </t>

      <!--
This document should also update the IANA port registry to add a
reference to this RFC-to-be to the existing entry for port 10500
(eventually even with note that this RFC-to-be discusses how to
distinguish the services using NAT_TRAVERSAL_MODE) -->

      <t>This document reuses the same default UDP port number 10500 as
      specified by Legacy ICE-HIP <xref target="RFC5770"/> target="RFC5770" format="default"/>
      for tunneling both HIP control plane and data plane traffic. The port was was
      registered separately for RFC5770 <xref target="RFC5770" format="default"/> to co-author Ari Keranen
      coauthor <contact fullname="Ari Keränen"/> originally, but should now be re-assigned it has been
      reassigned for IESG control. With the permission of Ari Keranen, <contact
      fullname="Ari Keränen"/>, the new assignee is the IESG and the contact "chair@ietf.org".
      is &lt;chair@ietf.org&gt;. In addition, IANA is requested to add has added a reference to
      this document in the entry for UDP port 10500 in the "Service Name and
      Transport Protocol Port Number Registry. Registry". The selection between Legacy
      ICE-HIP and Native ICE-HIP mode is negotiated using the
      NAT_TRAVERSAL_MODE parameter during the base exchange. By default, hosts
      listen to this port for incoming UDP datagrams and can also use it also for
      sending UDP datagrams. Other emphemeral ephemeral port numbers are negotiated and
      utilized dynamically.</t>

      <t> This document updates

      <t>IANA has assigned the IANA Registry for HIP Parameter Types <xref
      target="RFC7401"/> by assigning new HIP Parameter Type following values for in the new HIP Parameters: "Parameter Types" registry
      <xref target="RFC7401" format="default"/>:
      4650 for RELAYED_ADDRESS (length 20),
      4660 for MAPPED_ADDRESS (length 20, 20; defined in <xref target="sec:relayed_address"/>), target="sec_relayed_address"
      format="default"/>),
      4680 for PEER_PERMISSION (length 48, 48; defined in <xref target="sec:peer_permission"/>),
      target="sec_peer_permission" format="default"/>),
      4700 for CANDIDATE_PRIORITY
      (length 4, 4; defined in <xref target="sec:con-check"/>) target="sec_con-check" format="default"/>), and
      4710 for NOMINATE (length 4, 4; defined in <xref target="sec:nominate"/>).</t>

      <t> This document updates target="sec_nominate"
      format="default"/>).</t>

      <t>IANA has assigned the IANA Registry for HIP following value in the "HIP NAT
      traversal modes Traversal Modes"
      registry specified in Legacy ICE-HIP <xref target="RFC5770"/> by assigning value target="RFC5770" format="default"/>:
      3 for
      the NAT traversal mode ICE-HIP-UDP (defined in <xref
      target="sec:nat_tm-param"/>).</t>

      <t>This document updates
      target="sec_nat_tm-param" format="default"/>).</t>

      <t>IANA has assigned the following values in the IANA Registry for HIP Notify "Notify Message Types:
      type field Types" registry:
      16385 for NAT_KEEPALIVE in <xref target="sec:keepalive"/>, a new error type target="sec_keepalive"
      format="default"/>, 63 for
      SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED in <xref target="sec_notify-types"
      format="default"/>, and 64 for
      RVS_HMAC_PROHIBITED_WITH_RELAY in <xref target="sec:notify-types"/>.
      .</t> target="sec_notify-types"
      format="default"/>.</t>

      <t> This document defines additional registration types IANA has assigned the following values in the "Registration Types" registry for the HIP
      Registration Extension <xref target="RFC8003"/> that
      allow registering target="RFC8003" format="default"/>:
      3 for RELAY_UDP_ESP (defined in <xref target="sec_reg-types"
      format="default"/>) for allowing registration with a Data Relay Server for ESP relaying service:
      RELAY_UDP_ESP ESP-relaying service, and
      4 for CANDIDATE_DISCOVERY (defined in <xref target="sec:reg-types"/>, and target="sec_gathering"
      format="default"/>) for performing
      server reflexive server-reflexive candidate discovery: CANDIDATE_DISCOVERY (defined discovery.</t>

      <t>IANA has assigned one value in
      <xref target="sec:gathering"/>).</t>

      <t>This document defines an additional Registration the "Registration Failure
      Type Types" registry as
      defined in <xref target="sec:cross_protocol" />. target="sec_cross_protocol" format="default"/>. The
      value is [TBD by IANA: 9] 9, and the Registration Failure Type is
      "Simultaneous Rendezvous and Control Relay Service usage
      prohibited".</t>

      <t>ICE specification <xref target="RFC8445" /> discusses "Unilateral Self-Address Fixing"
      in section 18. This
      protocol is based on ICE, and thus the same considerations apply
      also here. <!-- with one exception: this protocol does not hide binary
      IP addresses from application-level gateways. (xx fix: assuming that we switch to encrypted addresses) --></t>

    </section> <!-- IANA -->

    <!-- ***************************************************************** -->

    <section title="Contributors">

      <!-- <t> This RFC is a product of a design team that also included Marcelo
      Bagnulo and Philip Matthews, who both have made major contributions to
      this document. </t> -->

      <t>
      Marcelo Bagnulo, Philip Matthews and Hannes Tschofenig have contributed
      to <xref target="RFC5770" />. This document leans heavily on the work in the RFC.
      </t>

    </section>

     <!-- contributors -->

      <!-- *************************************************************** -->

    <section title="Acknowledgments">

      <t>Thanks to Jonathan Rosenberg, Christer Holmberg and the rest of the MMUSIC WG folks for
      the excellent work on ICE. The authors would like to thank also
      Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert, Vivien
      Schmitt, and Abhinav Pathak for their contributions and Tobias Heer, Teemu
      Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Kristian Slavov, Janne
      Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha
      Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Tom Henderson, Alex Elsayed, Jani Hautakorpi, Tero Kauppinen and Timo Simanainen for
      their comments to <xref target="RFC5770" /> and this document.
      Thanks for Eric Vyncke, Alvaro Retana, Adam Roach, Ben Campbell, Eric Rescorla, Mirja Kuhlewind, Spencer Dawkins, Derek Fawcus,
      Tianran Zhou, Amanda Barber, Colin Perkins, Roni Even, Alissa Cooper, Carl Wallace, Martin Duke and Benjamin Kaduk for reviewing this document.
      </t>

      <t>This work has been partially funded by CyberTrust programme
      by Digile/Tekes in Finland.</t>

    </section>
    <!-- Acknowlegements -->

      <!-- *************************************************************** -->

  </middle>

  <back>

    <references title="Normative References">

      <?rfc include="reference.RFC.2119" ?>
      <?rfc include="reference.RFC.8174" ?>

      <?rfc include="reference.RFC.7401" ?>

      <?rfc include="reference.RFC.8003" ?>

      <?rfc include="reference.RFC.8004" ?>

      <?rfc include="reference.RFC.8046" ?>

      <?rfc include="reference.RFC.8047" ?>

<!--      <?rfc include="reference.I-D.ietf-mmusic-ice" ?> -->

<!-- XX FIXME: update these references when the individual RFCs are published -->

<!--      <?rfc include="reference.I-D.ietf-behave-turn" ?> -->

     <!-- XX FIXME: move RFC5770 to informative references? -->

       <?rfc include="reference.RFC.5389" ?>
      <?rfc include="reference.RFC.7402" ?>
      <?rfc include="reference.RFC.4291" ?>
      <?rfc include="reference.RFC.8126" ?>

      <?rfc include="reference.RFC.8445" ?> <!-- former reference.I-D.ietf-ice-rfc5245bis -->

      <?rfc include="reference.RFC.7050" ?>
      <?rfc include="reference.RFC.8005" ?>
      <?rfc include="reference.RFC.1063" ?>
      <?rfc include="reference.RFC.8201" ?>

      <?rfc include="reference.RFC.5770" ?>

      <?rfc include="reference.I-D.ietf-tcpm-rto-consider.xml" ?>

    </references>

    <references title="Informative References">

     <!--<?rfc include="reference.RFC.4423" ?> -->
     <?rfc include="reference.I-D.ietf-hip-rfc4423-bis.xml"?>

      <?rfc include="reference.RFC.2475" ?>

      <?rfc include="reference.RFC.5207" ?>
      <!-- <?rfc include="reference.RFC.6336" ?> -->

      <?rfc include="reference.I-D.rosenberg-mmusic-ice-nonsip" ?>

      <?rfc include="reference.RFC.6538" ?>

<!--

<reference anchor='MMUSIC-ICE'>
<front>
<title>Guidelines for Usage of Interactive Connectivity Establishment (ICE) by non Session Initiation Protocol (SIP) Protocols</title>

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

<date month='July' day='14' year='2008' />

<abstract><t>Interactive Connectivity Establishment (ICE) has been specified as a NAT traversal mechanism for protocols based on the offer/answer exchange model.  In practice, only the Session Initiation Protocol (SIP) has used ICE.  This document provides guidance on how other protocols can make use of ICE.</t></abstract>

</front>

<seriesInfo name='Work in' value='Progress' />

</reference>

-->

      <!-- <?rfc include="reference.RFC.4787" ?> -->
      <?rfc include="reference.RFC.5128" ?>

      <?rfc include="reference.I-D.heer-hip-middle-auth" ?>
<!--

      <reference anchor='HIP-MIDDLE'>
<front>
<title>End-Host Authentication for HIP Middleboxes</title>

<author initials='T' surname='Heer' fullname='Tobias Heer'>
    <organization />
</author>

<author initials='K' surname='Wehrle' fullname='Klaus Wehrle'>
    <organization

    </section>

  </middle>
  <back>
<displayreference target="I-D.rosenberg-mmusic-ice-nonsip" to="ICE-NONSIP"/>
<displayreference target="I-D.heer-hip-middle-auth" to="HIP-MIDDLEBOXES"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7401.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8003.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8004.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8046.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8047.xml"/>

       <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8489.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7402.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml"/>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7050.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8005.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5770.xml"/>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8961.xml"/>

      </references>
      <references>
        <name>Informative References</name>

<!-- reference.I-D.ietf-hip-rfc4423-bis.xml -->
   <reference anchor="RFC9068" target="https://www.rfc-editor.org/info/rfc9068">

     <front>
       <title>Host Identity Protocol Architecture</title>

       <author initials="R." surname="Moskowitz" fullname="Robert Moskowitz" role="editor">
         <organization />
       </author>
       <author initials='M' surname='Komu' fullname='Miika Komu'> initials="M." surname="Komu" fullname="Miika Komu">
         <organization />
       </author>

       <date month='February' day='27' year='2009' month="June" year="2021" />

<abstract><t>The Host Identity Protocol [RFC7401] is a signaling protocol for secure communication, mobility, and multihoming that introduces a cryptographic namespace.  This document specifies an extension for HIP that enables middleboxes to unambiguously verify the identities of hosts that communicate across them.  This extension allows middleboxes to verify the liveness and freshness of a HIP association and, thus, to secure access control in middleboxes.</t></abstract>
     </front>
     <seriesInfo name='Work in' value='Progress' name="RFC" value="9063" />
     <seriesInfo name="DOI" value="10.17487/RFC9068"/>

   </reference>
-->

      <?rfc include="reference.RFC.3948" ?>

      <?rfc include="reference.RFC.3264" ?>

      <?rfc include="reference.RFC.5245" ?>

      <?rfc include="reference.RFC.8750" ?>

      <?rfc include="reference.I-D.ietf-tsvwg-datagram-plpmtud.xml"?>

      <?rfc include="reference.RFC.5766" ?>

      <?rfc include="reference.RFC.6146" ?>

      <?rfc include="reference.RFC.6147" ?>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5207.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5245.xml"/>

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.rosenberg-mmusic-ice-nonsip.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6538.xml"/>

      <xi:include
	  href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5128.xml"/>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.heer-hip-middle-auth.xml"/>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3948.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3264.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8750.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"/>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8656.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/>
      </references>
    </references>

    <!-- ***************************************************************** -->

    <section anchor="sec:selecting_pacing_value"
      title="Selecting anchor="sec_selecting_pacing_value" numbered="true" toc="default">
      <name>Selecting a Value for Check Pacing"> Pacing</name>
      <t> Selecting a suitable value for the connectivity check transaction
      pacing is essential for the performance of connectivity check-based NAT
      traversal. The value should not be so small that the checks cause
      network congestion or overwhelm the NATs.  On the other hand, a pacing
      value that is too high makes the checks last for a long time, thus
      increasing the connection setup delay. </t>
      <t> The Ta value may be configured by the user in environments where the
      network characteristics are known beforehand. However, if the
      characteristics are not known, it is recommended that the value is
      adjusted dynamically. In this case, it is recommended that the hosts
      estimate the round-trip time (RTT) between them them, and SHOULD they
      <bcp14>SHOULD</bcp14> set the minimum Ta value so that at most a single
      connectivity check message is sent on every RTT. </t>
      <t> One way to estimate the RTT is to use the time that it takes for the
      Control Relay Server registration exchange to complete; this would give
      an estimate on the registering host's access link's RTT. Also, the I1/R1
      exchange could be used for estimating the RTT, but since the R1 can be
      cached in the network, or the relaying service can increase the delay
      notably, this is not recommended.
      In general, estimating RTT can be difficult and error prone, thus
      the guidelines for choosing a Ta value in <xref target="sec:check_pacing_neg" />
      MUST be followed.
      </t>
    </section>

    <!--

    <section title="Base Exchange through a Rendezvous Server">

      <t> When the Initiator looks up the information of the Responder from
      DNS, it is possible that it discovers a rendezvous server (RVS) record
      <xref target="RFC8004" />. In this case, if the Initiator uses NAT
      traversal methods described in this document, it MAY use its own HIP
      Relay Server to forward HIP traffic to the rendezvous server. The
      Initiator will send the I1 packet using its Control Relay Server server, which will
      then forward it to the RVS server of the Responder. In this case, the
      value of the protocol field in the RELAY_TO parameter MUST be IP RTT, but since
      RVS does not support UDP-encapsulated base exchange packets. The
      Responder will send the R1 packet directly to the Initiator's Control Relay Server
      server and can be
      cached in the following I2 and R2 packets are also sent directly using network, or the relay. </t>

      <t> In case relaying service can increase the Initiator delay
      notably, this is not able to distinguish which records are
      RVS address records recommended.  In general, estimating RTT can be
      difficult and which are Responder's address records (e.g., if
      the DNS server did not support HIP extensions), the Initiator SHOULD
      first try to contact error prone; thus, the Responder directly, without using guidelines for choosing a Control Relay Server
      server. If none of the addresses are reachable, it MAY try them out using
      its own Control Relay Server server as described above. Ta value
      in <xref target="sec_check_pacing_neg" format="default"/>
      <bcp14>MUST</bcp14> be followed. </t>
    </section> --> <!-- Base Exchange through a Rendezvous Server -->

    <section anchor="sec:ice_diff" title="Differences anchor="sec_ice_diff" numbered="true" toc="default">
      <name>Differences with respect Respect to ICE"> ICE</name>
      <t>Legacy ICE-HIP reuses the ICE/STUN/TURN protocol stack as it is. The
      benefits of such as an approach include the reuse of STUN/TURN
      infrastructure and possibly the reuse of existing software libraries,
      but there are also drawbacks with the approach. For example, ICE is
      meant for application-layer protocols, whereas HIP operates at layer 3.5
      between transport and network layers. This is particularly problematic
      because the implementations employ kernelspace kernel-space IPsec ESP as their data
      plane: demultiplexing of incoming ESP, HIP HIP, and TURN messages required
      the capturing of all UDP packets destined to port 10500 to the userspace
      (due to different, incompatible markers in ESP and STUN), thus causing
      additional software complexity and an unnecessary latency/throughput
      bottleneck for the dataplane performance. It is also worth noting that
      the demultiplexing of STUN packets in the kernel would incur an also incur a
      performance impact (albeit smaller than with userspace demultiplexing),
      and secure verification of STUN messages would require communication
      between the kernelspace kernel-space STUN detector and HIP daemon typically residing
      in the userspace (thus, (thus again increasing the performance overhead).
      </t> overhead).</t>
      <t>Legacy ICE-HIP involves also involves some other complexities when compared to
      the approach taken in this document.
      Relaying  The relaying of ESP packets via
      TURN relays was not considered that simple because TURN relays require
      adding and removing extra TURN framing for the relayed packets. Finally,
      the developers of the two Legacy ICE-HIP implementations concluded that "effort

effort needed for integrating an ICE library into a HIP implementation turned
out to be quite a bit higher that than initially estimated. Also, the amount of
extra code (some 10 kLoC) needed for all the new parsers, state machines,
etc., is was quite high and by re-using reusing the HIP code code, one should be able to do
with much less. This should result in smaller binary size, less bugs, and
easier debugging.". debugging.

     </t>
       <t> Consequently, the HIP working group decided to follow ICE
       methodology but reuse HIP messaging format to achieve the same
       functionality as ICE, and
      consequently ICE; the result of that is this document that document, which
       specifies the Native ICE-HIP protocol.
      </t>
      <t>The Native ICE-HIP protocol specified in this document follows the semantics
      of ICE as close as possible, and most of the differences are
      syntactical due to the use of a different protocol. In this
      section, we describe the differences to the ICE protocol.</t>

      <t><list style="symbols">

	<t>ICE
      <ul spacing="normal">
        <li>ICE operates at the application layer, whereas this
	protocol operates between transport and network layers, thus
	hiding the protocol details from the application.</t>

	<t>The application.</li>
        <li>The STUN protocol is not employed. Instead, native Native ICE-HIP
	reuses the HIP control plane format in order to simplify
	the demultiplexing of different protocols. For example, the STUN
	binding response is replaced with a HIP UPDATE message
	containing an ECHO_REQUEST_SIGNED parameter and the STUN
	binding response with a HIP UPDATE message containing an
	ECHO_RESPONSE_SIGNED parameter as defined in <xref
	target="sec:conn_checks" />.
	target="sec_conn_checks" format="default"/>.  It is worth noting that
	a
	drawback of not employing STUN is that discovery of the address
	candidates requires creating (using HIP base exchange) and
	maintaining (using HIP UPDATE procedures) state at the Control Relay Client and
	Control Relay Server. Future extensions to this document may define
	a stateless, HIP-specific mechanism for an end-host end host to discover its address candidates.
	</t>

	<t>The
	</li>
        <li>The TURN protocol is not utilized. Instead, native Native ICE-HIP reuses
	Control Relay Servers for the same purpose.</t>

	<t>ICMP purpose.</li>
        <li>ICMP errors may be used in ICE to signal failure. In the Native ICE-HIP
	protocol, HIP NOTIFY messages are used instead.</t>

	<t>Instead instead.</li>
        <li>Instead of the ICE username fragment and password mechanism for
        credentials, native Native ICE-HIP uses the HIT, derived from a public key,
        for the same purpose. The username fragments are "transient host
        identifiers, bound to a particular session established as part of the
        candidate exchange" <xref target="RFC8445" />.
        format="default"/>. Generally in HIP, a local public key and the
        derived HIT are considered long-term identifiers, identifiers and invariant across
        different host associations and different transport-layer flows.</t>

	<t>In flows.</li>
        <li>In ICE, the conflict when two communicating end-points endpoints take the
        same controlling role is solved using random values (so called (a so-called
        tie-breaker value). In the Native ICE-HIP protocol, the conflict is solved
        by the standard HIP base exchange procedure, where the host with the
        "larger" HIT switches to the Responder role, thus changing also changing to
        the controlled role.</t>

	<t>The role.</li>
        <li>The ICE-CONTROLLED and ICE-CONTROLLING attributes are not
	included in the connectivity checks.
	<!-- The attributes make it
	easier to build gateways between different protocols using
	ICE. -rosenberg-mmusic-ice-nonsip --></t>

	<t>The

        </li>
        <li>The foundation concept is unnecessary in native Native ICE-HIP
	because only a single UDP flow for the IPsec tunnel will be
	negotiated.</t>

	<t>Frozen
	negotiated.</li>
        <li>Frozen candidates are omitted for the same reason as the
	foundation concept is excluded.</t>

	<t>Components excluded.</li>
        <li>Components are omitted for the same reason as the
	foundation concept is excluded.</t>

	<!-- XX FIXME: no lite mode anymore in ICE -->

	<t>Native excluded.</li>

	<li>Native ICE-HIP supports only "full ICE" where the two
	communicating hosts participate actively to the connectivity checks,
	and the "lite" mode is not supported.  This design decision follows
	the guidelines of ICE ICE, which recommends full ICE implementations.
	However, it should be noted that a publicly reachable Responder may
	refuse to negotiate the ICE mode as described in <xref target="sec:no_relay" />.
	target="sec_no_relay" format="default"/>.  This would result in a <xref target="RFC7401" /> based HIP
	base exchange (as per <xref target="RFC7401" format="default"/>)
	tunneled over UDP UDP, followed by ESP traffic over the same tunnel, without
	the connectivity check procedures defined in this document (in some
	sense, this mode corresponds to the case where two ICE lite
	implementations connect since no connectivity checks are sent).</t>

	<t>As sent).</li>
        <li>As the "ICE lite" is not adopted here and both sides are
	capable of ICE-HIP-UDP mode (negotiated during the base
	exchange), default candidates are not employed in Native ICE-HIP.</t>

	<t> ICE-HIP.</li>
        <li> If the agent is using Diffserv Codepoint markings <xref
        target="RFC2475" /> format="default"/> in its media packets, it SHOULD
        <bcp14>SHOULD</bcp14> apply those same markings to its connectivity checks.</t>

	<!-- <t>Unlike
        checks.</li>

	<li>Unlike in ICE, the addresses are not XOR-ed XORed in Native ICE-HIP
	protocol in order to avoid middlebox tampering.</t> -->

	<t>Unlike in ICE, the addresses are not XOR-ed in Native ICE-HIP
	protocol but rather encrypted to avoid middlebox tampering.</t>

	<t>Native tampering.</li>

<li>ICE defines Related Address and Port attributes used for diagnostic/SIP
purposes, but the Native ICE-HIP protocol does not employ the ICE related address and
	related port attributes (that are used for diagnostic or SIP purposes).</t>

	<t>Minimum these attributes.
</li>

        <li>The minimum RTO is 500 ms in ICE but 1000 ms in the Native ICE-HIP
        protocol in favor of <xref target="I-D.ietf-tcpm-rto-consider"/></t>

      </list></t> target="RFC8961" format="default"/>.</li>
      </ul>
    </section> <!-- ice diff  -->

    <section anchor="sec:hip_diff" title="Differences anchor="sec_hip_diff" numbered="true" toc="default">
      <name>Differences to Base Exchange and UPDATE procedures"> Procedures</name>
      <t>This section gives some design guidance for implementers on how the
      extensions in this protocol extend and differ from <xref
      target="RFC7401" /> format="default"/> and <xref target="RFC8046" />.</t>

      <t><list style="symbols">

	<t>Both
      format="default"/>.</t>
      <ul spacing="normal">
        <li>Both the control and data plane are operated on top of UDP, not directly on IP.</t>

	<t>A IP.</li>
        <li>A minimal implementation would conform only to Sections <xref
	target="sec:minimal" />
        target="sec_minimal" format="counter"/> or <xref target="sec:no_relay" />, target="sec_no_relay"
        format="counter"/>, thus merely tunneling HIP control and data traffic
        over UDP. The drawback here is that it works only in the limited cases
        where the Responder has a public address.</t>

	<t>It address.</li>
        <li>It is worth noting that while a rendezvous server Rendezvous Server <xref
        target="RFC8004" /> format="default"/> has not been designed to be used
        in NATted NATed scenarios because it just relays the first I1 packet and does
        not employ UDP encapsulation, the Control Relay Server forwards all
        control traffic and, hence, is more suitable in
	NATted NATed
        environments. Further, the Data Relay Server guarantees forwarding of
        data plane traffic also in the cases
	when where the NAT traversal procedures fail.</t>

	<t>Registration
        fail.</li>

        <li>Registration procedures with a Control/Data Relay Server are
        similar as with rendezvous server. a Rendezvous Server. However, a Control/Data Relay
        Server has different registration parameters than rendezvous a Rendezvous Server
        because it offers a different service. Also, the Control/Data Relay
        Server includes also includes a REG_FROM parameter that informs the
        Control/Data Relay Client about its server reflexive server-reflexive address. A Data
        Relay Server includes also includes a RELAYED_ADDRESS containing the relayed
        address for the Data Relay Client.</t>

	<t>In Client.</li>
        <li>In <xref target="RFC7401" />, format="default"/>, the Initiator and Responder
	can start to exchange application payload immediately after
	the base exchange. While exchanging data immediately after a
	base exchange via a Data Control Relay would also be possible also here, we
	follow the ICE methodology to establish a direct path between
	two hosts using connectivity checks. This means that there
	will be some additional delay after the base exchange before
	application payload can be transmitted. The same applies for
	the UPDATE procedure as the connectivity checks introduce some
	additional delay.</t>

	<t>In delay.</li>
        <li>In HIP without any NAT traversal support, the base exchange
	acts as an implicit connectivity check, and the mobility and
	multihoming extensions support explicit connectivity
	checks. After a base exchange or UPDATE based UPDATE-based connectivity
	checks, a host can use the associated address pair for
	transmitting application payload. In this Native ICE-HIP extension, we follow
	the ICE methodology, methodology where one end-point endpoint acting in the
	controlled role chooses the used address pair also on behalf
	of the other end-point endpoint acting in the controlled role, which is
	different from HIP without NAT traversal support. Another
	difference is that the process of choosing an address pair is
	explicitly signaled using the nomination packets. The
	nomination process in this protocol supports only a single
	address pair, and multihoming extensions are left for further
	study.</t>

	<t>The
	study.</li>
        <li>The UPDATE procedure resembles the mobility extensions
	defined in <xref target="RFC8046" />. format="default"/>. The
	first UPDATE message from the mobile host is exactly the same
	as in the mobility extensions. The second UPDATE message from
	the peer host and third from the mobile host are different in
	the sense that they merely acknowledge and conclude the
	reception of the candidates through the Control Relay Server. In other words,
	they do not yet test for connectivity (besides reachability
	through the Control Relay Server) unlike in the mobility extensions. The
	idea is that the connectivity check procedure follows the ICE
	specification, which is somewhat different from the HIP
	mobility extensions.</t>

	<t>The extensions.</li>
        <li>The connectivity checks as defined in the mobility
	extensions <xref target="RFC8046" /> format="default"/> are
	triggered only by the peer of the mobile host. Since
	successful NAT traversal requires that both end-points endpoints test
	connectivity, both the mobile host and its peer host have to
	test for connectivity. In addition, this protocol
	validates
	also validates the UDP ports; the ports in the connectivity
	check must match with the response, as required by ICE.</t>

	<t>In ICE.</li>
        <li>In HIP mobility extensions <xref target="RFC8046" />,
        format="default"/>, an outbound locator has some associated state:
        UNVERIFIED mean means that the locator has not been tested for
        reachability, ACTIVE means that the address has been verified for
        reachability and is being used actively, and DEPRECATED means that the
        locator lifetime has expired. In the subset of ICE specifications used
        by this protocol, an individual address candidate has only two
        properties: type and priority. Instead, the actual state in ICE is
        associated with candidate pairs rather than individual addresses. The
        subset of ICE specifications utilized by this protocol require the
        following attributes for a candidate pair: valid bit, nominated bit, base
        base, and the state of the connectivity check. The connectivity checks
        have the following states: Waiting, In-progress, Succeeded Succeeded, and
        Failed. Handling of this state attribute requires some additional
        logic when compared to the mobility extensions extensions, since the state is
        associated with a local-remote address pair rather than just a remote address, and,
        address; thus, the mobility and ICE states do not have an unambiguous
        one-to-one mapping.
	</t>

	<t>Credit-based
	</li>
        <li>Credit-based authorization as defined in <xref target="RFC8046" /> format="default"/> could be used before
	candidate nomination has been concluded upon discovering
	working candidate pairs. However, this may result in the use
	of asymmetric paths for a short time period in the beginning
	of communications. Thus, support of credit-based authorization is left
	for further study.</t>

      </list></t> study.</li>
      </ul>
    </section> <!-- hip diff  -->

    <section anchor="sec:multihoming" title="Multihoming Considerations"> anchor="sec_multihoming" numbered="true" toc="default">
      <name>Multihoming Considerations</name>
      <t>This document allows a host to collect address candidates from
      multiple interfaces, interfaces but does not support activation and the simultaneous
      use of multiple address candidates.  While multihoming extensions to
      support functionality similar to that found in <xref target="RFC8047" /> like
      functionality
      format="default"/> are left for further study and experimentation, we
      envision here some potential compatibility improvements to support
      multihoming:</t>

      <t><list style="symbols">

	<t>Data

      <dl newline="false" spacing="normal">
        <dt>Data Relay Registration: a Registration:</dt>
	<dd>a Data Relay Client acting as an
	Initiator with another peer host should register a new
	server reflexive
	server-reflexive candidate for each local transport address candidate. A
	Data Relay Client acting as an a Responder should register a new
	server reflexive
	server-reflexive candidate for each { local {local transport address candidate,
	new peer host} pair for the reasons described in <xref
	target="sec:conflicting" />.
	target="sec_conflicting" format="default"/>. In both cases, the Data
	Relay Client should
	request the additional server reflexive server-reflexive candidates by sending UPDATE
	messages originating from each of the local address candidates as
	described in <xref target="sec:registration" />. target="sec_registration" format="default"/>. As the
        UPDATE messages are originating from an unknown location from the
	viewpoint of the Data Relay Server,
        it must include also a include an ECHO_REQUEST_SIGNED in the response in order to
	test for return routability.
	</t>

	<t>Data </dd>
        <dt>Data Relay unregistration: this unregistration:</dt>
	<dd>This follows the procedure in <xref target="sec:protocol" /> target="sec_protocol"
	format="default"/>, but the Data Relay Client should unregister using
	the particular transport address to be unregistered.  All transport
	address pair registrations can be unregistered when no RELAYED_ADDRESS
	parameter is
	included.</t>

	<t>PEER_PERMISSION parameter: this included.</dd>
        <dt>PEER_PERMISSION parameter:</dt>
	<dd>This needs to be extended or
	an additional parameter is needed to declare the specific local
	candidate of the Data Relay Client. Alternatively, the use of
	the PEER_PERMISSION could be used as a wild card to open permissions
	for a specific peer to all
	of the candidates of the Data Relay Client.</t>

	<t>Connectivity checks: the Client.</dd>
        <dt>Connectivity checks:</dt>
	<dd>The controlling host should be able to
	nominate multiple candidates (by repeating step 7 in <xref
	target="fig:cc1" />
	target="fig_cc1" format="default"/> in <xref target="sec:conn_checks" /> target="sec_conn_checks"
	format="default"/> using the additional candidate pairs).</t>

	<t>Keepalives pairs).</dd>
        <dt>Keepalives:</dt>
	<dd>These should be sent for all the nominated candidate
	pairs. Similarly, the Control/Data Relay Client should send keepalives
	from its local candidates to its Control/Data Relay Server transport addresses.</t>

      </list></t>
	addresses.</dd>
      </dl>
    </section>
    <section anchor="sec:dns" title="DNS Considerations"> anchor="sec_dns" numbered="true" toc="default">
      <name>DNS Considerations</name>
      <t>This section updates <xref target="RFC5770" /> Appendix B sectionFormat="of"
      section="B"/>, which will be replaced with the mechanism  described in
      this section.</t>
      <t><xref target="RFC5770" /> format="default"/> did not specify how an end-host
      end host can look up another end-host end host via DNS and initiate an a UDP-based
      HIP base exchange with it, so this section makes an attempt to fill this gap.
      </t>
      gap.</t>

      <t><xref target="RFC8005" /> format="default"/> specifies how a HIP end-host end
      host and its Rendezvous server Server is registered to DNS.  Essentially, the
      public key of the end-host end host is stored as a HI record and its Rendezvous
      Server as an A or AAAA record. This way, the Rendezvous Server can act
      as an intermediary for the end-host end host and forward packets to it based on
      the DNS configuration.  The Control Relay Server offers similar
      functionality as to the Rendezvous Server, with the difference being that the
      Control Relay Server forwards all control messages, not just the first I1 message.

      <!--
      The end-host has registered as a Rendezvous Client to the
      Rendezvous server, so they share a Host Association with each
      other and the end-host updates its locators to the Rendezvous
      Server when it moves. This way, a new HIP base exchange destined
      to the end-host is always delivered to the correct location
      since the Rendezvous Server has always the up-to-date location
      of the end-host.  As an alternative the Rendezvous Server, the
      DNS could be configured with actual IP addresses the end-host in
      A and AAAA records. This works with static hosts, and in Server forwards all control messages, not just the
      case of a mobile host, it can update its location using Dynamic
      DNS <xref target="I-D.ietf-hip-rfc4423-bis" />.
      --> first
      I1 message.

      </t>
      <t>
      Prior to this document, the A and AAAA records in the DNS
      refer either to the HIP end-host end host itself or a Rendezvous Server <xref target="RFC8005" />, format="default"/>,
      and control and data plane communication with the associated
      host has been assumed to occur directly over IPv4 or
      IPv6. However, this specification extends the records to be used for
      UDP-based communications.</t>
      <t>Let us consider the case of a HIP Initiator with the default policy
      to employ UDP encapsulation and the extensions defined in this document.
      The Initiator looks up the FQDN Fully Qualified Domain Name (FQDN) of a
      Responder, and retrieves its HI, A A, and AAAA records.  Since the default
      policy is to use UDP encapsulation, the Initiator MUST <bcp14>MUST</bcp14>
      send the I1 message over UDP to destination port 10500 (either over IPv4
      in the case of a an A record or over IPv6 in the case of
      a an AAAA
      record). It MAY <bcp14>MAY</bcp14> send an I1 message both with and without
      UDP encapsulation in parallel.
      <!-- but, when
      sending multiple I1 message, the Initiator SHOULD
      wait for a small amount of time (a reasonable time may be
      2 * expected RTT) after the first R1 reception to allow possibly
      multiple R1s to arrive as described in section 4.1.4 in <xref target="RFC7401" />. -->

      In the case in which the Initiator receives R1 messages both with and without UDP
      encapsulation from the Responder, the Initiator SHOULD <bcp14>SHOULD</bcp14>
      ignore the R1 messages without UDP encapsulation.
      <!--
      In the other case, the host sends the I1 directly over IPv4 in the case of a
      A-record or directly over IPv6 in the case of an AAAA-record as
      specified in <xref target="RFC8005" />.-->

      </t>

      <t>The UDP encapsulated UDP-encapsulated I1 packet could be received by three four different
      types of hosts:
      </t>

      <t><list style="numbers">
	<t>HIP
      <dl  newline="false" spacing="normal">
        <dt>HIP Control Relay Server: in Server:</dt>
	<dd>In this case case, the A/AAAA records refers refer to a Control Relay Server,
	and it
	which will forward the packet to the corresponding Control Relay
	Client based on the destination HIT in the I1 packet.</t>
	<t>HIP packet.</dd>
        <dt>HIP Responder supporting UDP encapsulation: in encapsulation:</dt>

	<dd>In this case, the A/AAAA records refers refer to the end-host. end host. Assuming
	the destination HIT belongs to the Responder, it the Responder receives
	and processes it the I1 packet according to the negotiated NAT traversal
	mechanism. The support for the protocol defined in this
      document vs document, as
	opposed to the support defined in <xref target="RFC5770" />
	format="default"/>, is dynamically negotiated during the base
	exchange. The details are specified in <xref target="sec:nat_traversal_mode"/>.</t>
	<t>HIP
	target="sec_nat_traversal_mode" format="default"/>.</dd>
        <dt>HIP Rendezvous Server: this Server:</dt>
	<dd>This entity is not listening to UDP port 10500, so it will drop
	the I1 message.</t>
	<t>HIP message.</dd>
        <dt>HIP Responder not supporting UDP encapsulation: the encapsulation:</dt>
	<dd>The targeted end-host end host is not listening to UDP port 10500, so it
	will drop the I1 message.</t>
      </list></t> message.</dd>
      </dl>
      <t>The A/AAAA-record MUST NOT A/AAAA record <bcp14>MUST NOT</bcp14> be configured to refer to a
      Data Relay Server unless the host in question supports also supports Control
      Relay Server functionality.
      </t>

            <!-- functionality.</t>

      <t>It is also worth mentioning that the Control Relay Server specification in this document and <xref target="RFC5770" />
      are compatible with each other.
      </t>-->

      <t>It also worth noting that SRV records are not employed in this
      specification. While they could be used for more flexible UDP
      port selection, they are not suitable for end-host discovery but
      rather would be more suitable for the discovery of HIP-specific infrastructure. Further
      extensions to this document may define SRV records for Control
      and Data Relay Server discovery within a DNS domain.
      </t>
    </section>

    <!-- ***************************************************************** -->

    <section numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>Thanks to <contact fullname="Jonathan Rosenberg"/>, <contact
      fullname="Christer Holmberg"/>, and the rest of the MMUSIC WG folks for
      the excellent work on ICE. The authors would also like to thank <contact
      fullname="Andrei Gurtov"/>, <contact fullname="Simon Schuetz"/>,
      <contact fullname="Martin Stiemerling"/>, <contact fullname="Lars
      Eggert"/>, <contact fullname="Vivien Schmitt"/>, and <contact
      fullname="Abhinav Pathak"/> for their contributions, and <contact
      fullname="Tobias Heer"/>, <contact fullname="Teemu Koponen"/>, <contact
      fullname="Juhana Mattila"/>, <contact fullname="Jeffrey M. Ahrenholz"/>,
      <contact fullname="Kristian Slavov"/>, <contact fullname="Janne
      Lindqvist"/>, <contact fullname="Pekka Nikander"/>, <contact
      fullname="Lauri Silvennoinen"/>, <contact fullname="Jukka Ylitalo"/>,
      <contact fullname="Juha Heinanen"/>, <contact fullname="Joakim
      Koskela"/>, <contact fullname="Samu Varjonen"/>, <contact fullname="Dan
      Wing"/>, <contact fullname="Tom Henderson"/>, <contact fullname="Alex
      Elsayed"/>, <contact fullname="Jani Hautakorpi"/>, <contact
      fullname="Tero Kauppinen"/>, and <contact fullname="Timo Simanainen"/>
      for their comments to <xref target="RFC5770" format="default"/> and this
      document.  Thanks to <contact fullname="Éric Vyncke"/>, <contact
      fullname="Alvaro Retana"/>, <contact fullname="Adam Roach"/>, <contact
      fullname="Ben Campbell"/>, <contact fullname="Eric Rescorla"/>, <contact
      fullname="Mirja Kühlewind"/>, <contact fullname="Spencer Dawkins"/>,
      <contact fullname="Derek Fawcus"/>, <contact fullname="Tianran Zhou"/>,
      <contact fullname="Amanda Barber"/>, <contact fullname="Colin
      Perkins"/>, <contact fullname="Roni Even"/>, <contact fullname="Alissa
      Cooper"/>, <contact fullname="Carl Wallace"/>, <contact fullname="Martin
      Duke"/>, and <contact fullname="Benjamin Kaduk"/> for reviewing this
      document.
      </t>

      <t>This work has been partially funded by the Cyber Trust Program
      by Digile/Tekes in Finland.</t>
    </section>

    <section numbered="false" toc="default">
      <name>Contributors</name>

      <t><contact fullname="Marcelo Bagnulo"/>, <contact fullname="Philip
      Matthews"/>, and <contact fullname="Hannes Tschofenig"/> have
      contributed to <xref target="RFC5770" format="default"/>. This document
      leans heavily on the work in that RFC.</t>
    </section>

  </back>
</rfc>

<!-- LocalWords: xref CDATA -->