HIP Working Group                                                M. Komu
Internet-Draft                                                      HIIT
Intended status: Experimental                               T. Henderson
Expires: August 28, 2008 January 16, 2009                             The Boeing Company
                                                             P. Matthews
                                                                   Avaya
                                                          (Unaffiliated)
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                        A. Keraenen
                                                                J. Melen Keraenen, Ed.
                                            Ericsson Research Nomadiclab
                                                              M. Bagnulo
                                                      Huawei Lab at UC3M
                                                       February 25,
                                                           July 15, 2008

   Basic HIP Extensions for Traversal of Network Address Translators and
                               Firewalls
                  draft-ietf-hip-nat-traversal-03.txt
                  draft-ietf-hip-nat-traversal-04.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008). January 16, 2009.

Abstract

   The Host Identity Protocol (HIP) provides a new namespace that can be
   used for uniquely identifying hosts.  Existing HIP experimental
   specifications do not specify protocol operations across Network
   Address Translators (NATs).

   This document specifies basic NAT traversal extensions for HIP.  The
   HIP shim layer is located between the network and transport layer,
   the extensions can also provide a more general-purpose NAT traversal
   support for higher-layer networking applications.  The extensions are
   based on the use of the The Interactive Connectivity Establishment
   (ICE) methodology to discover a working path between two end-hosts.
   Using the specified extensions, two HIP-capable hosts are able to
   communicate with each other even when both nodes are behind NATs or
   firewalls.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Protocol Description . . . . . . . . . . . . . . . . . . . . .  7  6
     3.1.  Relay Registration and NAT Detection . . . . . . . . . . .  7
     3.2.  Base Exchange via HIP Relay . . . . . . . . .  6
     3.2.  NAT Transformation Negotiation . . . . . . . . . .  9
   4.  Connectivity Tests . . . .  8
     3.3.  Base Exchange via HIP Relay  . . . . . . . . . . . . . . .  9
     3.4.  ICE Connectivity Checks  . . . 11
     4.1.  NAT Transformation Negotiation . . . . . . . . . . . . . . 11
     4.2.  ICE Procedure
     3.5.  NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 12
     4.3.  NAT Keep-alives
     3.6.  Base Exchange without ICE Connectivity Checks  . . . . . . 12
     3.7.  Base Exchange without UDP Encapsulation  . . . . . . . . . 13
     3.8.  Sending Control Messages using the Data Plane  . . . . . . 12
   5. 13
   4.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.1.
     4.1.  HIP Control Packets  . . . . . . . . . . . . . . . . . . . 13
     5.2.  Keep-Alives 14
     4.2.  Connectivity Checks  . . . . . . . . . . . . . . . . . . . 14
     4.3.  Keepalives . . . . . 13
     5.3. . . . . . . . . . . . . . . . . . . . 15
     4.4.  Relay and Registration Parameters  . . . . . . . . . . . . 14
     5.4. 16
     4.5.  LOCATOR Parameter  . . . . . . . . . . . . . . . . . . . . 14
     5.5. 17
     4.6.  RELAY_HMAC . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.6. 19
     4.7.  Registration Types . . . . . . . . . . . . . . . . . . . . 16
     5.7.  HIP 19
     4.8.  ESP Data Packet Formats Packets . . . . . . . . . . . . . . . 17
   6. . . . . . . 20
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
     6.1. 20
     5.1.  Privacy Considerations . . . . . . . . . . . . . . . . . . 17
     6.2. 20
     5.2.  Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 18
   7.  IANA Considerations  . . . . . 21
     5.3.  Base Exchange Replay Protection for HIP Relay Server . . . 21
     5.4.  Demuxing Different HIP Associations  . . . . . . . . . . . 21
   6.  IANA Considerations  . . 18
   8.  Contributors . . . . . . . . . . . . . . . . . . . 21
   7.  Contributors . . . . . . 18
   9.  Acknowlegements . . . . . . . . . . . . . . . . . . . 22
   8.  Acknowledgments  . . . . 18
   10. References . . . . . . . . . . . . . . . . . . . 22
   9.  References . . . . . . . 19
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     10.2. Informative 22
     9.1.  Normative References . . . . . . . . . . . . . . . . . . 20
   Appendix A.  Firewall Traversal  . . . 22
     9.2.  Informative References . . . . . . . . . . . . . . 21
   Appendix B.  Base Exchange without ICE Connectivity Checks . . . . 22 24
   Appendix C. A.  IPv4-IPv6 Interoperability  . . . . . . . . . . . . . 22 24
   Appendix D. B.  Base Exchange through a Rendezvous Server . . . . . . 22 24
   Appendix E. C.  Document Revision History . . . . . . . . . . . . . . 23 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 26 27

1.  Introduction

   HIP [I-D.ietf-hip-base] [RFC5201] is defined as a protocol that runs directly over IPv4
   or IPv6.  This approach is known to have problems traversing NATs.  Several different types  A
   detailed description of NATs exist, see
   [RFC2663]. HIP problems with traversing legacy
   middleboxes is documented in [I-D.irtf-hiprg-nat].  This document
   describes HIP extensions for the traversal of both Network Address
   Translator (NAT) and Network Address and Port Translator (NAPT)
   middleboxes.  Additionally, it covers firewalls to
   a certain extend (see Appendix A for a more detailed discussion).  The document generally uses the term NAT to refer to
   these types of middleboxes.  A detailed description of HIP problems with traversing
   legacy middleboxes is documented in [I-D.irtf-hiprg-nat].

   Currently deployed NAT devices do not operate consistently even
   though a recommended behavior is described in [RFC4787].  The HIP
   protocol extensions in this document make as few assumptions as
   possible about the behavior of the NAT devices so that NAT traversal
   will work even with legacy NAT devices.  The purpose of these
   extensions is to allow two HIP-
   enabled HIP-enabled hosts to communicate with each
   other even if one or both communicating hosts are in private address
   realms.

   Using the extensions defined in this draft, HIP end-hosts use the HIP
   control channel to communicate their current locators to each other
   to find a operational path for the ESP encapsulated data traffic.
   The hosts test connectivity between different locators and try to
   discover direct end-to-end path between the end-hosts.  However, With
   some legacy
   NAT devices, NATs, utilizing the shortest path between two end hosts
   located behind NATs is not possible without relaying the traffic
   through a relay, such as a TURN server [I-D.ietf-behave-p2p-state]. [RFC5128].  As a consequence,
   the TURN server increases the roundtrip delay and may become a point
   of network congestion.  With the extensions described in this
   document, hosts try to avoid the use of such a
   relay the TURN server when possible.

   This document defines new middlebox extensions to allow NAT traversal
   for HIP control plane.  The HIP Relay extensions define mechanisms to
   forward HIP control plane.  A distinction must be made here between a
   HIP rendezvous server (defined
   in [I-D.ietf-hip-rvs]) services [RFC5204]) and a HIP Relay, defined herein. Relay services.  HIP
   rendezvous servers solve initial contact and mobility related
   problems in networks without NATs.  HIP Relay servers solve the same
   problems, in addition to NAT traversal problems.  HIP Relay servers
   can be used both in NATted NATed and non-NATted non-NATed networks.

   Both rendezvous and relay services forward HIP control packets, but
   the main difference is that the rendezvous service forwards only the
   initial I1 packet of the base exchange while all other HIP control
   packets are sent directly between the communicating hosts.  In
   contrast, the relay service relays all HIP control packets because
   p2p-unfriendly NAT devices
   NATs can drop the packets otherwise
   [I-D.ietf-behave-p2p-state].  The peers use the control channel to
   communicate their current locators to each other to find a direct
   path for carrying ESP encapsulated data traffic.  A direct path
   between the hosts enables efficient delivery of data traffic without
   relaying of ESP packets through an intermediary TURN server.  The
   direct path is searched using connectivity tests. [RFC5128].

   The basis for the connectivity tests checks is ICE [I-D.ietf-mmusic-ice].

   [I-D.ietf-mmusic-ice] describes ICE as follows:

      "The Interactive Connectivity Establishment (ICE) methodology is a
      technique for NAT traversal for UDP-based media streams (though
      ICE can be extended to handle other transport protocols, such as
      TCP) established by the offer/answer model.  ICE is an extension
      to the offer/answer model, and works by including a multiplicity
      of IP addresses and ports in SDP offers and answers, which are
      then tested for connectivity by peer-to-peer connectivity checks.
      The IP addresses and ports included in the SDP and the
      connectivity checks are performed using the revised STUN
      specification [I-D.ietf-behave-rfc3489bis], now renamed to Session
      Traversal Utilities for NAT."

   ICE for SIP is specified in [I-D.ietf-mmusic-ice] and ICE for non-SIP
   protocols is specified in [I-D.rosenberg-mmusic-ice-nonsip].

   Two hosts communicate their peer address set (typically consisting of
   IP address and port number pairs) locators to each other in the HIP base
   exchange.  They are then paired with the locally operational address
   of the other end point endpoint and prioritized according to some policy. local and recommended
   policies.  These address sets are then tested sequentially based on
   the
   procedure procedures specified in ICE.  Both sides participate in the
   connectivity tests. checks.  The tests may also determine whether discover multiple
   operational address pairs and select the but determine a single preferred address
   pair to be used for subsequent communication.

   As

   In a summary, nutshell, the extensions in this document defines:

   o  illustrate how to encapsulate  encapsulatation of HIP packets in UDP

   o  refer to the  UDP encapsulation of IPsec ESP packets defined in
      Section 2.1 of RFC 3948 [RFC3948]

   o  define  registration extensions for HIP Relay services

   o  how a node interacts the "offer" and "answer" are carried in the base exchange

   o  interaction with ICE connectivity messages

   o  backwards compatibility issues with a HIP rendezvous server (defined
      in [I-D.ietf-hip-rvs]) when middleboxes are present servers

   o  describe  a methodology to determine operational address pairs
      between two end hosts based on ICE. number of optimizations (such when the ICE connectivity tests
      can be excluded)

2.  Terminology

   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 [RFC2119].

   This document borrows terminology from [I-D.ietf-hip-base],
   [I-D.ietf-hip-mm], [RFC5201], [RFC5206],
   [RFC4423], [I-D.ietf-mmusic-ice], and [I-D.ietf-behave-rfc3489bis].
   Additionally, the following terms are used:

    Rendezvous server:

      A host that forwards I1 packets to the Responder

   HIP Relay:

      A host that forwards all HIP control packets between an Initiator
      and Responder

   TURN server:

      A server that forwards data traffic between two end-hosts

   Locator:

      A

      As defined in [RFC5206]: "A name that controls how the packet is
      routed through the network and demultiplexed by the end host.  It
      may include a concatenation of traditional network addresses such
      as an IPv6 address and end-
      to-end end-to-end identifiers such as an ESP SPI.
      It may also include transport port numbers or IPv6 Flow Labels as
      demultiplexing context, or it may simply be a network address.  [I-D.ietf-hip-mm]
      "Address" address."
      It should noticed that "address" is used in this document as a
      synonym for locator.

   HIP Relay:

      LOCATOR (written in capital letters) denotes a HIP control message
      parameter that bundles multiple locators together

   ICE Offer:

      The Initiator's LOCATOR parameter in HIP I2 control message.

   ICE Answer:

      The Responder's LOCATOR parameter in HIP R2 control message

   Transport address:

      Transport layer port and the corresponding IPv4/v6 address

   Candidate:

      A transport address that has not been verified yet for
      reachability using ICE

   Host candidate:

      An IPv4 or IPv6 address of a network interface of a host

   Server reflexive transport candidate:

      A translated transport address of a host as observed by a HIP
      Relay or a STUN server

   Peer reflexive transport candidate:

      A translated transport address of a host as observed by its peer

   Relayed transport candidate:

      A transport address that exists on a TURN server.  If a permission
      exists, packets  Packets that
      arrive at this address are relayed towards the TURN client.

3.  Protocol Description

   This section describes the normative behavior of the protocol
   extension.  Examples of packet exchanges are provided for
   illustration purposes.

3.1.  Relay Registration and NAT Detection

   HIP rendezvous servers are used operate in non-NATted non-NATed environments and their
   use is described in [I-D.ietf-hip-rvs]. [RFC5204].  This section specifies a new
   role for these rendezvous servers to act as
   middlebox extension, called the HIP Relays. Relay, to perate in NATted
   environments.  HIP Relays Relay servers forward all HIP control packets
   between the Initiator and the Responder. Responder over UDP.

   End-hosts cannot use the HIP Relay service for forward ESP data
   plane.  Instead, they use TURN servers [I-D.ietf-behave-turn] are used for
   relaying the ESP traffic.  A host HIP end-host SHOULD register to a TURN
   server before registering to a HIP Relay to guarantee that the host
   can accept ESP traffic immediately after HIP Relay registration.

   A HIP relay forwards UDP-encapsulated HIP traffic, and in future
   extensions, a relay may also forward TCP-encapsulated traffic.  The
   HIP Relay forwards HIP control packets.  NAT traversal for HIP
   between two end-hosts may require the use of relays in certain
   scenarios.  A successful NAT traversal therefore requires at least
   the Responder located behind a NAT to register with a HIP Relay.

   A HIP Relay MUST silently drop packets to a HIP Relay Client that has
   not previously registered with the HIP Relay.  The registration
   process follows the generic registration extensions defined in
   [I-D.ietf-hip-registration]
   [RFC5203] and is illustrated in Figure 1.

      HIP                                                      HIP
      Relay                                                    Relay
      Client                                                   Server
        |   1. UDP(I1)                                           |
        +------------------------------------------------------->|
        |                                                        |
        |   2. UDP(R1(REG_INFO(RELAY_UDP_HIP)))                  |
        |<-------------------------------------------------------+
        |                                                        |
        |   3. UDP(I2(REG_REQ(RELAY_UDP_HIP)))                   |
        +------------------------------------------------------->|
        |                                                        |
        |   4. UDP(R2(REG_RES(RELAY_UDP_HIP), REG_FROM))         |
        |<-------------------------------------------------------+

               Figure 1: Example Registration to a HIP Relay

   In step 1, the Initiator Relay Client (Initiator) starts the registration
   procedure by sending an I1 packet over UDP.  It is RECOMMENDED that
   the Initiator selects a random port number from the ephemeral port
   range 49152-65535 for initiating a base exchange.  However, the
   allocated port MUST be maintained until all of the corresponding HIP
   Associations are closed.  Alternatively, a host MAY also use a single
   fixed port for initiating all outgoing connections.

   In step 2, the Responder Relay Server (Responder) lists the services that it
   supports in the R1 packet.  The support for HIP-over-UDP relaying is
   denoted by the RELAY_UDP_HIP value.  The R1 does SHOULD not contain any
   NAT transform
   parameter (see Section 4.1) as discussed in Appendix B. parameter.

   In step 3, the Initiator selects the services it registers for and
   lists them in the REG_REQ parameter.  In this example, the Initiator
   registers for HIP Relay service.

   In step 4, the Responder concludes the registration procedure with an
   R2 packet and acknowledges the registered services in the REG_RES
   parameter.  The Responder may also denote denotes unsuccessful registrations in the
   REG_FAILED parameter in R2.  The Responder also includes a REG_FROM
   parameter that contains the transport address of the client as
   observed by the Relay (Server Reflexive candidate).  After the
   registration, the Initiator needs to send sends periodically NAT keep-
   alives. keepalives.

   There are different ways for an Initiator to learn it's publically publicly
   visible IP address and port that are referred to as the "server
   reflexive transport candidate" in this document.  This document makes
   use  It is a local
   decision on how the end-host learnds the candidate, but either of two ways: the
   following methods is RECOMMENDED:

   o  The Relay client may use STUN servers to detect the server
      reflexive locator, as described in [I-D.ietf-behave-p2p-state]. [RFC5128].

   o  Alternatively, the Relay Client can learn it from the REG_FROM
      parameter when registering to a Relay.

3.2.  Base Exchange via HIP Relay

   It is RECOMMENDED that  NAT Transformation Negotiation

   This section describes the Initiator sends an I1 packet encapsulated
   in UDP when it is destined to an IPv4 address usage of the Responder.
   Respectively, the Responder MUST respond to a such I1 packet with an
   R1 packet over the transport layer and using the same transport
   protocol. new non-critical transform
   parameter type.  The rest presence of the parameter in HIP base exchange, I2 and R2, MUST also use exchange
   means that the same transport layer.

     I end-host supports ICE connectivity checks.  As the
   parameter is non-critical, it can be ignored by an end-host which
   means that the host does not support or is not willing to use ICE
   connectivity checks.

   The NAT transform parameter applies to a base exchange between end-
   hosts, but currently does not apply to with a registration with a HIP
   Relay                          R server.  The NAT transform applies only to a base exchange with
   transport layer encapsulation and MUST not be included without
   transport layer encapsulation.  The NAT transform negotiation in base
   exchange is illustrated in Figure 2.

     Initiator                                                Responder
       | 1. UDP(I1)                                                   |                                |
     +----------------------------->| 2. UDP(I1(RELAY_FROM))
       +------------------------------------------------------------->|
       |                                                              |                              +------------------------------->|
       | 2. UDP(R1(.., NAT_TRANSFORM(list of transforms), ..))        |
       |<-------------------------------------------------------------+
       |                                                              |
       | 3. UDP(R1(RELAY_TO))           |
     | 4. UDP(R1(RELAY_TO))         |<-------------------------------+
     |<-----------------------------+                                | UDP(I2(.., NAT_TRANSFORM(selected transform), LOCATOR..)) |
       +------------------------------------------------------------->|
       |                                                              |
       | 5. UDP(I2(LOCATOR)) 4. UDP(R2(.., LOCATOR, ..))                                  |
       |<-------------------------------------------------------------+
       |
     +----------------------------->|                   ....                                       |

                  Figure 2: Negotiation of NAT Transforms

   In step 1, the Initiator sends an I1 to the Responder.  In step 2,
   the Responder responds with an R1.  The R1 contains a list of
   transforms the Responder supports in NAT_TRANSFORM parameter as shown
   in Table 1.

   +--------------+----------------------------------------------------+
   | Transform    | 6. UDP(I2(LOCATOR,RELAY_FROM)) Purpose                                            |
   |                              +------------------------------->| Type         |                                                    |
   +--------------+----------------------------------------------------+
   | RESERVED     | Reserved for future use                            | 7. UDP(R2(LOCATOR,RELAY_TO))
   | ICE-STUN-UDP | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+
     |<-----------------------------+ UDP encapsulated control and data traffic with     |
   |              | ICE-based connectivity checks using STUN messages  |

                  Figure 2: Base Exchange via a HIP Relay
   +--------------+----------------------------------------------------+

                     Table 1: Locator Transformations

   In step 1 of Figure 2, 3, the Initiator sends an I1 packet over I2 that includes a NAT_TRANSFORM
   parameter.  It contains the
   transport layer to transform type selected by the HIT Initiator
   from the list of transforms offered by the Responder.  The source address is
   one of I2 also
   includes the locators of the host. Initiator in a LOCATOR parameter.  The locators of the end-hosts are
   referred as "host candidates"
   locator parameter in this document. I2 is the "ICE offer".

   In step 2, the HIP Relay receives the I1 packet at port HIPPORT.  If
   the destination HIT belongs to a registered Responder, 4, the Relay
   processes Responder concludes the base exchange with an R2
   packet.  Otherwise, the Relay MUST drop the packet
   silently.  The Relay appends Responder includes a RELAY_FROM LOCATOR parameter to the I1 packet
   which constains the transport source address and port of the I1 as
   observed by the Relay.  The Relay protects the I1 packet with
   RELAY_HMAC as described in [I-D.ietf-hip-rvs], except that the R2 packet.
   The locators parameter type in R2 is different.  The Relay changes the source and
   destination ports "ICE answer".

3.3.  Base Exchange via HIP Relay

   This section describes how Initiator and IP addresses of the packet to match the values
   the Responder used when registering to the Relay, i.e., the reverse
   of the R2 used establish a base
   exchange through a HIP Relay.  The NAT transform negotiation (denoted
   as NAT_TFM in the registration.  The example) was described in previous section and
   shall not be repeated here.  When a Relay MUST recalculate receives an R1 or I2 packet
   without the
   transport checksum NAT transform packet, it drops it and forward the packet sends a NOTIFY
   error message to the Responder.

   In step 3, the Responder receives originator.

   It is RECOMMENDED that the Initiator sends an I1 packet.  The Responder
   processes packet encapsulated
   in UDP when it according is destined to an IPv4 address of the rules in [I-D.ietf-hip-base].  In
   addition, Responder.
   Respectively, the Responder validates the RELAY_HMAC according MUST respond to
   [I-D.ietf-hip-rvs] and silenty drops the such an I1 packet if the validation
   fails.  The Responder replies with an
   R1 packet to which it includes
   a RELAY_TO parameter.  The RELAY_TO parameter contains over the transport layer and using the same
   information as transport
   protocol.  The rest of the base exchange, I2 and R2, MUST also use
   the same transport layer.

     I                            HIP Relay                          R
     | 1. UDP(I1)                   |                                |
     +----------------------------->| 2. UDP(I1(RELAY_FROM))         |
     |                              +------------------------------->|
     |                              |                                |
     |                              | 3. UDP(R1(RELAY_TO, NAT_TFM))  |
     | 4. UDP(R1(RELAY_TO),NAT_TFM) |<-------------------------------+
     |<-----------------------------+                                |
     |                              |                                |
     | 5. UDP(I2(LOCATOR),NAT_TFM)  |                                |
     +----------------------------->|  6. UDP(I2(LOCATOR,RELAY_FROM),|
     |                              |       NAT_TFM)                 |
     |                              +------------------------------->|
     |                              |                                |
     |                              | 7. UDP(R2(LOCATOR,RELAY_TO))   |
     | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+
     |<-----------------------------+                                |
     |                              |                                |

                  Figure 3: Base Exchange via a HIP Relay

   In step 1 of Figure 3, the RELAY_FROM parameter, i.e., Initiator sends an I1 packet over the
   transport
   address, but layer to the type HIT of the parameter is different. Responder.  The RELAY_TO
   parameter source address is not integrity protected by
   one of the signature locators of the R1 host.  The locators belonging to
   allow pre-created R1 packets at the Responder. end-
   hosts are referred as "host candidates" in this document.

   In step 4, 2, the HIP Relay receives the R1 packet.  The Relay drops the I1 packet silently if at port HIPPORT.  If
   the source destination HIT belongs to an unregistered host.
   The a registered Responder, the Relay MAY verify
   processes the signature of packet.  Otherwise, the R1 packet and Relay MUST drop it if
   the signature is invalid.  Otherwise, the packet
   silently.  The Relay rewrites appends a RELAY_FROM parameter to source
   address and port, changes the destination I1 packet
   which contains the transport source address and port to match
   RELAY_TO information, recalculates transport checksum and forwards of the packet.

   In step 5, I1 as
   observed by the Initiator receives Relay.  The Relay protects the R1 I1 packet and processes it
   according to [I-D.ietf-hip-base].  It replies with an I2 packet that
   uses the destination transport address of R1
   RELAY_HMAC as described in [RFC5204], except that the source address
   and port.  The I2 contains a LOCATOR parameter that lists all type
   is different.  The Relay changes the ICE
   candidates (offer) source and destination ports and
   IP addresses of the Initiator.  The candidates are encoded
   using packet to match the format defined values the Responder used
   when registering to the Relay, i.e., the reverse of the R2 used in Section 5.4.

   In step 6,
   the registration.  The Relay receives MUST recalculate the I2 packet.  The relay appends a
   RELAY_FROM transport checksum
   and a RELAY_HMAC to forward the I2 packet as in to the second step. Responder.

   In step 7, 3, the Responder receives the I2 packet and I1 packet.  The Responder
   processes it according to [I-D.ietf-hip-base].  It the rules in [RFC5201].  In addition, the
   Responder validates the RELAY_HMAC according to [RFC5204] and
   silently drops the packet if the validation fails.  The Responder
   replies with a R2 an R1 packet and to which it includes a RELAY_TO parameter as in step three. parameter.
   The R2 packet
   includes a LOCATOR RELAY_TO parameter that lists all MUST contain same information as the ICE candidates
   (answer)
   RELAY_FROM parameter, i.e., the Initiator's transport address and the
   nonce, but the type of the Responder. parameter is different.  The RELAY_TO
   parameter is not integrity protected by the HMAC. signature of the R1 to
   allow pre-created R1 packets at the Responder.

   In step 8, 4, the Relay processes receives the R2 as described in step four. R1 packet.  The Relay forwards drops the
   packet to silently if the Responder.

4.  Connectivity Tests

4.1.  NAT Transformation Negotiation

   This section describes usage of a new optional transform parameter
   type. source HIT belongs to an unregistered host.
   The presence Relay MAY verify the signature of the parameter in HIP base exchange means that R1 packet and drop it if
   the host supports all of signature is invalid.  Otherwise, the extensions defined in this document.  If Relay rewrites the transform parameter is used, hosts MUST use a password for STUN
   HMACs that is drawn from source
   address and port, and changes the DH keying material.

   The transform parameter applies both destination address and port to
   match RELAY_TO information.  Finally, the registration Relay recalculates
   transport checksum and forwards the packet.

   In step 5, the Initiator receives the R1 packet and processes it
   according to [RFC5201].  It replies with an I2 packet that uses the HIP
   Relay as well
   destination transport address of R1 as to the source address and port.
   The I2 contains a base exchange between end-hosts. LOCATOR parameter that lists all the ICE candidates
   (ICE offer) of the Initiator.  The transform
   negotiation in base exchange is illustrated candidates are encoded using the
   format defined in Figure 3.

     Initiator                                                Responder
       | 1. UDP(I1)                                                   |
       +------------------------------------------------------------->|
       |                                                              |
       | 2. UDP(R1(.., NAT_TRANSFORM(list of transforms), ..))        |
       |<-------------------------------------------------------------+
       |                                                              |
       | 3. UDP(I2(.., NAT_TRANSFORM(selected transform), LOCATOR..)) |
       +------------------------------------------------------------->|
       |                                                              |
       | 4. UDP(R2(.., LOCATOR, ..))                                  |
       |<-------------------------------------------------------------+
       |                   ....                                       |

                  Figure 3: Negotiation of Section 4.5.  The I2 packet MUST also contain the
   NAT Transforms transform parameter with ICE-STUN-UDP or some other transform
   selected because otherwise the Relay may drop the I2 packet.

   In step 1, 6, the Initiator sends an I1 Relay receives the I2 packet.  The relay appends a
   RELAY_FROM and a RELAY_HMAC to the Responder. I2 packet as explained in the
   second step.

   In step 2, 7, the Responder responds receives the I2 packet and processes it
   according to [RFC5201].  It replies with an R1.  The R1 contains a list of
   transforms the Responder supports in NAT_TRANSFORM R2 packet and includes a
   RELAY_TO parameter as shown explained in Table 1.

   +--------------+----------------------------------------------------+
   | Transform    | Purpose                                            |
   | Type         |                                                    |
   +--------------+----------------------------------------------------+
   | RESERVED     | Reserved for future use                            |
   | ICE-STUN-UDP | UDP encapsulated control and data traffic with     |
   |              | ICE-based connectivity tests using STUN messages   |
   +--------------+----------------------------------------------------+

                     Table 1: Locator Transformations

   In step 3, the Initiator sends an I2 that three.  The R2 packet
   includes a NAT_TRANSFORM
   parameter.  It contains the transform type selected by the Initiator
   from LOCATOR parameter that lists all the list ICE candidates (ICE
   answer) of transforms offered by the Responder.  The I2 also
   includes RELAY_TO parameter is protected by the locators of
   HMAC.

   In step 8, the Initiator Relay processes the R2 as described in a LOCATOR parameter.

   In step 4, four.  The
   Relay forwards the packet to the Responder.

3.4.  ICE Connectivity Checks

   The Responder concludes completes the base exchange with an R2
   packet.  The Responder includes a LOCATOR parameter in the R2 packet.

4.2.  ICE Procedure

   Hosts exchange HIP control packets packet through
   the HIP Relay.
   Connectivity tests are, however, directly exchanged between  When Initiator successfully receives and processes the
   address pairs
   R2, both hosts have transitioned to determine operational address pairs.  If a working
   direct path between ESTABLISHED state.  However, the hosts is found, also
   destination address the HIP control traffic
   MAY start using it.

   The Initiator and Responder used for delivering
   base exchange is completed with an R2 packet.  Then, packets belonged to the state of Relay as indicated by the HIP associations at both peers is ESTABLISHED, but
   RELAY_FROM and RELAY_TO parameters.  Therefore, the peers address of the
   Relay MUST
   NOT allow any not be used for sending ESP traffic until unless it was listed
   as a TURN server in the offer/answer.  Instead, the Initiator and
   Responder MUST start ICE connectivity tests are performed
   successfully.  All of after they have
   transitioned to ESTABLISHED state after the locators, except base exchange when they
   do not have valid locator pair for ESP traffic and the HIP Relay address, NAT transform
   parameter was negotiated successfully.

   The ICE connectivity checks are defined in UNVERIFIED state.  In [I-D.ietf-mmusic-ice].
   Section Section 4.2 defines the connectivity tests, details of the hosts test STUN control packets.
   As a result of the ICE connectivity between different locator pairs in order to find checks, ICE nominates a
   working one. single
   transport address pair to be used if an operational address could be
   found.  The connectivity tests are illustrated in Figure 4.  In end-hosts MUST use this example, both hosts are behind NATs.

     I                            HIP Relay                          R
     | 2. UDP(R2(LOCATOR,RELAY_TO))  | 1. UDP(R2(LOCATOR,RELAY_TO))  |
     |<------------------------------+-------------------------------|
     |                                                               |
     |           3. Connectivity tests for address pairs             |
     |<------------------------------------------------------------->|
     |                                                               |
     |           4. HIP UPDATE for preferred address pair            |
     |<------------------------------------------------------------->|
     |                                                               |

                       Figure 4: Connectivity tests

   In steps 1 and 2, for the R2 packet is relayed ESP traffic.

3.5.  NAT Keepalives

   To prevent NAT state from the Responder through
   the Relay expiring, communicating end-hosts hosts
   send periodically keepalives to the Initiator.

   Afterwards, connectivity tests are started based on the procedure
   described in [I-D.rosenberg-mmusic-ice-nonsip] by using the candiates
   previously exchanged in the HIP base exchange.

4.3. each other.  NAT Keep-alives

   Data channel keepalives are STUN Binding Indications.  Keepalives Relays MUST be sent not send
   any keepalives.  An end-host MUST send keepalives every 20 15 seconds to
   refresh the UDP port mapping at the minimum NAT(s) when the control or data
   channel is idle.  To implement failure tolerance, a host an end-host SHOULD
   have smaller shorter keepalive period.  When data traffic is exchanged between the end
   points then no further

   The keepalives are STUN Binding Indications if the hosts have agreed
   on NAT_TRANSFORM during the base exchange, or HIP NOTIFY messages
   otherwise.  A HIP Relay MUST not forward NOTIFY messages.

   The communicating hosts MUST send keepalives need to be exchanged.

5.  Packet Formats

   The following subsections define each other using the parameter and packet encodings.
   All values MUST be
   transport locators exchanged in network byte order.

5.1.  HIP Control Packets

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

         Figure 5: Format for UDP-encapsulated HIP Control Packets

   HIP control packets the base exchange when they are encapsulated in UDP packets like in Section
   2.2 of [RFC3948], "rules for encapsulating IKE messages", except that
   ESTABLISHED state.  Also, the Initiator MUST send a different port number is used.  Figure 5 shows NOTIFY message to
   the encapsulation:
   UDP header is followed by 32 zero bits that can be used Relay to
   differentiate HIP control packets from ESP packets.  The HIP header
   and parameters follow refresh the conventions of [I-D.ietf-hip-base] with NAT state alive on the
   exception that path between the HIP header checksum
   Initiator and Relay when the Initiator has not received any response
   to its I1 or I2 from the Responder in 15 seconds.  The Relay MUST not
   forward the NOTIFY messages.

3.6.  Base Exchange without ICE Connectivity Checks

   In certain network environments, the ICE connectivity checks can be zero.  The HIP header
   checksum is zero for two reasons.
   omitted to reduce initial connection set up latency because base
   exchange acts an implicit connectivity test itself.  There are three
   assumptions about such as environments.  First, the UDP header contains
   already Responder should
   have a checksum.  Second, the checksum definition long-term, fixed locator in
   [I-D.ietf-hip-base] includes the IP addresses in network.  Second, the checksum
   calculation.  The NATs unaware of HIP cannot recompute the HIP
   checksum after changing IP addresses.

   A HIP Relay or a
   Responder without should not have a relay MUST listen at transport
   port HIPPORT for incoming UDP-encapsulated HIP control packets.

5.2.  Keep-Alives

   Control and data channel keep-alives are STUN Binding Indications, as
   defined in [I-D.ietf-behave-rfc3489bis].  They use Relay configured for itself.  Third,
   the same UDP
   header as Initiator can reach the Responder by simply UDP encapsulating HIP control
   and ESP packets but there to the host.  Detecting and configuring this
   particular scenario is no non-ESP-marker
   between prone to administrative failure unless
   carefully planned.

   In such a scenario, the Initiator sends an I1 packet over UDP header to the
   Responder.  The Responder replies with a R1 packet that does not
   contain the NAT transform parameter.  The Initiator receives the R1
   packet and determines from the STUN header.  STUN messages are
   demultiplexed absence of the NAT transform and
   RELAY_TO parameters that ICE connectivity checks can be omitted.
   Finally, the hosts can start to use the locators from ESP the concluding
   I2 and HIP control messages using R2 packets of the STUN
   markers, base exchange for ESP without ICE
   connectivity checks.

3.7.  Base Exchange without UDP Encapsulation

   The Initiator MAY also try to establish a base exchange with the
   Responder without UDP encapsulation.  In such as a case, the magic cookie value.

5.3.  Relay and Registration Parameters

      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Port              |           Transport           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type        [ TBD by IANA:
                   RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2)
                   RELAY_TO:   (64002 = 2^16 - 2^11 + 2^9 + 2)
                   REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10) ]

     Length      20
     Address     An IPv6 address or Initiator
   sends first an IPv4 address in "IPv4-compatible
                 IPv6 address" format
     Port        Transport port number; zero when plain IP is used
     Transport   Transport protocol type; zero for I1 packet without UDP

        Figure 6: Format for encapsulation to the RELAY_FROM,  RELAY_TO and REG_FROM
                                parameters

   Format of Responder.
   After 100 ms, the RELAY_FROM, RELAY_TO and REG_FROM parameters Initiator MUST then send an UDP-encapsulated I1
   packet.  For retransmissions, the procedure is shown repeated.

   The I1 packet may arrive directly at the Responder.  When the
   recipient is the Responder, the proceduces in Figure 6.  Parameters [RFC5201] are identical except followed
   for the type field.

5.4.  LOCATOR Parameter rest of the base exchange.  The generic LOCATOR parameter format is Initiator may receive
   multiple R1 messages from the same as in
   [I-D.ietf-hip-mm].  However, presenting ICE candidates requires Responder, but upon receiving a new
   locator type. valid
   R1 without UDP encapsulation, the Initiator MUST ignore further R1
   messages with UDP encapsulation encapsulation.  The generic end-hosts do not
   trigger ICE connectivity checks after the base exchange since the UDP
   encapsulation was excluded.

   The packet may also arrive at a HIP-capable middlebox.  When the
   middlebox is a HIP rendezvous server and NAT traversal specific locator
   parameters are illustrated the Responder has
   successfully registered to the rendezvous service, the middlebox
   follows rendezvous procedures in Figure 7.

      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 [RFC5204].  If the middlebox is a
   HIP Relay server, it drops the I1 packet silently.

3.8.  Sending Control Messages using the Data Plane

   The end-hosts MAY send control messages directly to each other using
   the transport address pair established for data channel without
   sending the control packets through the Relay.  When a host does not
   get acknowledgements e.g. to an UPDATE or CLOSE message after a
   timeout based on local policies, the host SHOULD resend the packet
   through the Relay.  This optimization requires further
   experimentation.

4.  Packet Formats

   The following subsections define the parameter and packet encodings.
   All values MUST be in network byte order.

4.1.  HIP Control Packets

      0                   1                   2                   3
      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                        | 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Transport        Source Port            |  Transp. Proto|     Kind      Destination Port         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Priority                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           Length              |                              SPI           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Locator                       32 bits of zeroes                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                    HIP Header and Parameters                  ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 7: LOCATOR parameter

   The individual fields in the LOCATOR parameter 4: Format for UDP-encapsulated HIP Control Packets

   HIP control packets are described encapsulated in
   Table 2.

   +-----------+----------+--------------------------------------------+
   | Field     | Value(s) | Purpose                                    |
   +-----------+----------+--------------------------------------------+
   | Type      | 193      | Parameter type                             |
   | Length    | Variable | Length UDP packets as defined in octets, excluding Type and       |
   |           |          | Length fields and padding                  |
   | Traffic   | 0-2      | Is the locator
   Section 2.2 of [RFC3948], "rules for HIP signaling (1), encapsulating IKE messages"
   except for  |
   | Type      |          | a different port number.  Figure 4 illustrates the
   encapsulation.  The UDP header is followed by 32 zero bits that can
   be used to differentiate HIP control packets from ESP (2), or for both (0)                   |
   | Locator   | 2        | "Transport address" locator type           |
   | Type      |          |                                            |
   | Locator   | 7        | Length packets.  The
   HIP header and parameters follow the conventions of [RFC5201] with
   the Locator field in 4-octet     |
   | Length    |          | units                                      |
   | Reserved  | 0        | Reserved for future extensions             |
   | Preferred | 0        | Not used for transport address locators;   |
   | (P) bit   |          | exception that the HIP header checksum MUST be ignored by the receiver.           |
   | Locator   | Variable | Locator lifetime in seconds                |
   | Lifetime  |          |                                            |
   | Transport | Variable | Transport layer port number                |
   | Port      |          |                                            |
   | Transport | 0        | 0 zero.  The HIP
   header checksum is zero for two reasons.  First, the UDP                                  |
   | Protocol  |          |                                            |
   | Kind      | Variable | 0 for host, 1 for server reflexive, 2 for  |
   |           |          | peer reflexive or 3 for relayed address    |
   | Priority  | Variable | Locator's priority as described header
   contains already a checksum.  Second, the checksum definition in         |
   |           |          | [I-D.ietf-mmusic-ice]                      |
   | SPI       | Variable | SPI value which
   [RFC5201] includes the host expects to see IP addresses in |
   |           |          | incoming ESP packets that use this locator |
   | Locator   | Variable | IPv6 address or an "IPv4-compatible IPv6   |
   |           |          | address" format IPv4 address [RFC3513],    |
   |           |          | obfuscated by XORring it with the owner's  |
   |           |          | HIT                                        |
   +-----------+----------+--------------------------------------------+

                 Table 2: Fields checksum calculation.  The
   NATs unaware of HIP cannot recompute the LOCATOR parameter

5.5.  RELAY_HMAC HIP checksum after changing
   IP addresses.

   A HIP Relay or a Responder without a relay MUST listen at transport
   port HIPPORT for incoming UDP-encapsulated HIP control packets.

4.2.  Connectivity Checks

   The RELAY_HMAC parameter value has connectivity checks are performed using STUN Binding Requests.
   This section describes the TLV type 65520 (2^16 - 2^5 +
   2^4).  It has details of the same semantics parameters in the STUN
   messages.

   The username is formed from the username fragments as RVS_HMAC [I-D.ietf-hip-rvs].

5.6.  Registration Types defined in
   section 7.1.1.3 of [I-D.ietf-mmusic-ice].  The REG_INFO, REQ_REQ, REG_RESP requests MUST use STUN
   short term credentials with HITs of the Initiator and REG_FAILED parameters Responder
   concatenated as a username fragment.  The HITs are concatenated
   according to the Sort(HIT-I, HIT-R) algorithm defined in [RFC5201]
   section 6.5.  The HIT username fragment MUST contain
   values for HIP Relay registration. a UTF-8
   [RFC3629] encoded sequence and MUST have been processed using
   SASLPrep [RFC4013] as defined section 15.3 of
   [I-D.ietf-behave-rfc3489bis].  The value for RELAY_UDP_HIP concatenated HIT pair MUST have a
   fixed size that is 2.
   The value accomplished by including the leading zeroes for RELAY_UDP_ESP is 3.

5.7.
   the HITs.

   Drawing of HIP ESP Data Packet Formats

   [RFC3948] describes UDP encapsulation keys is defined in [RFC5201] section 6.5 and drawing
   of the IPsec ESP transport and
   tunnel mode.  On keys in [RFC5202] section 7.  Correspondingly, the wire hosts MUST
   draw symmetric keys for STUN according to [RFC5201] section 6.5.  The
   hosts draw the STUN keys after HIP keys, or after ESP packets do not differ from the
   transport mode keys if ESP and thus
   transform was successfully negotiated in the encapsulation of base exchange.  The
   hosts draw two keys which they MUST use to generate the HIP ESP packets STUN
   password.  As the STUN password is the same as at both ends, the UDP encapsulation transport mode ESP.

   During two
   drawn keys MUST be concatenated with the HIP base exchange, key for the two peers exchange parameters that
   enable them to define a pair greater HIT
   first.  Section 15.4 of IPsec ESP security associations
   (SAs), as described in [I-D.ietf-hip-esp].  When two peers perform a
   UDP-encapsulated base exchange, they MUST define a pair [I-D.ietf-behave-rfc3489bis] describes how
   hosts use the password for message integrity of IPsec SAs
   that produces UDP-encapsulated ESP data traffic. STUN messages.

   The management of encryption/authentication protocols and security
   parameter indices (SPIs) is connectivity checks MUST contain PRIORITY attribute.  They MAY
   contain USE-CANDIDATE attributes as defined in [I-D.ietf-hip-esp].  The UDP
   encapsulation format and processing section 7.1.1.1 of HIP ESP traffic
   [I-D.ietf-mmusic-ice].

   The Initiator is described always in Section 6.1 of [I-D.ietf-hip-esp].

   Section 5.1 of [RFC3948] describes a security issue for the UDP
   encapsulation in controller role during a base
   exchange.  Hence, the standard IP tunnel mode when ICE-CONTROLLED and ICE-CONTROLLING attributes
   are not needed and SHOULD NOT be used.  When two hosts behind
   different NATs have the same private IP address and initiate
   communication are initiating
   to each other simultaneously, HIP state machine detects it and
   assigns the host with the larger HIT as the same Responder as explained in the public Internet.
   sections 4.4.2 and and 6.7 in [RFC5201].

4.3.  Keepalives

   The
   Responder cannot distinguish between two hosts, because security keepalives for HIP associations agreed that are NAT_TRANSFORM
   capable are STUN Binding Indications, as defined in
   [I-D.ietf-behave-rfc3489bis].  The source and destination ports are
   in the UDP header are based on the same inner IP addresses.

   This issue does not exist with as used for HIP (50500).  However, in
   contrast to the UDP encapsulation of encapsulated HIP ESP
   transport format because header, there non-ESP-marker
   between the Responder use HITs to distinguish
   between different communication instances.

6.  Security Considerations

6.1.  Privacy Considerations

   The LOCATORs are sent XORed format in plain text in favour of
   inspection at HIP-aware middleboxes in UDP header and the future.  The current draft
   does not specify encrypted versions of LOCATORs even though it could
   be beneficial for privacy reasons.

   It STUN header is possible that an Initiator or Responder may not want to reveal
   all of its locators to its peer.  For example, a host may not want to
   reveal the internal topology of excluded.  Keepalives
   MUST contain the private address realm FINGERPRINT STUN attribute but SHOULD NOT contain
   any other STUN attributes and it
   discards host addresses.  Such behavior creates non-optimal paths
   when the hosts SHOULD NOT utilize any authentication
   mechanism.  STUN messages are located behind the same NAT.  Especially, this
   could be a problem with a legacy NAT that does not support routing demultiplexed from ESP and HIP control
   messages using the private address realm back to itself through the outer
   address of the NAT.  This scenario is referred to as the hairpin
   problem [I-D.ietf-behave-p2p-state].  With STUN markers, such a legacy NAT, the
   only option left would be to use a relayed transport address from a
   TURN server.  As a consequence, a host may support locator-based
   privacy by leaving out as the reflexive candidates.  Using only host
   candidates can produce suboptimal paths possibly causing congestion.

   The use of HIP Relays or TURN Relays can be useful for protection
   against Denial-of-Service attacks.  If a Responder reveals only its
   HIP magic cookie value and ESP relay candidates to malign Initiators, the Initiators can
   only attack
   the relays FINGERPRINT attribute.

   Keepalives for aHIP associations that does are not prevent the Responder from
   initiating new outgoing connections if a path around the relay
   exists.

6.2.  Opportunistic Mode

   A HIP Relay should have one address per Relay Client when a NAT_TRANSFORM capable
   are HIP Relay
   is serving more than one Relay Clients and is willing to support
   opportunistic mode.  Otherwise, it cannot be guaranteed control messages that have NOTIFY as the
   Relay can deliver the I1 packet to the intended recipient.

7.  IANA Considerations

   This section is to be interpreted according to [RFC2434].

   This draft currently uses a UDP port in the "Dynamic and/or Private
   Port" type.  The
   NOTIFY messages do not contain any parameters.

4.4.  Relay and HIPPORT.  Upon publication of this document, IANA is
   requested to register a UDP Registration Parameters

      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Port              |           Transport           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type        [ TBD by IANA:
                   REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10) ]

     Length      20
     Address     An IPv6 address or an IPv4 address in "IPv4-compatible
                 IPv6 address" format
     Port        Transport port and the RFC editor number; zero when plain IP is requested to
   change all occurrences of port HIPPORT to the port IANA has
   registered.  The HIPPORT number 50500 should be used
     Transport   Transport protocol type; zero for initial
   experimentation.

   This document updates the IANA Registry UDP

                  Figure 5: Format for HIP Parameter Types by
   assigning new HIP Parameter Type values REG_FROM parameter
      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Port              |           Transport           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Nonce                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type        [ TBD by IANA:
                   Critical parameters:
                   RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2)
                   RELAY_TO:   (64002 = 2^16 - 2^11 + 2^9 + 2)

     Length      24
     Address     An IPv6 address or an IPv4 address in "IPv4-compatible
                 IPv6 address" format
     Port        Transport port number; zero when plain IP is used
     Transport   Transport protocol type; zero for UDP
     Nonce       A nonce assigned by the new HIP Parameters:
   RELAY_FROM, RELAY_TO Relay server.

        Figure 6: Format for the RELAY_FROM and RELAY_TO parameters

   Format for the REG_FROM (defined parameter is shown in Section 5.3) Figure 5, and
   RELAY_HMAC (defined in Section 5.5).

8.  Contributors

   Marcelo Bagnulo, Jan Melen, Simon Schuetz, Martin Stiemerling, Lars
   Eggert, Vivien Schmitt, Abhinav Pathak
   RELAY_FROM and Andrei Gurtov have
   contributed to the initial versions of this draft.

9.  Acknowlegements

   Thanks RELAY_TO in Figure 6.  Parameters are identical except
   for Jonathan Rosenberg the type and nonce fields.

   The nonce field is an experimental field for the rest of RELAY_FROM and
   RELAY_TO parameters.  It allows the MMUSIC WG folks for Relay to have constant state
   towards the excellent work on ICE.  In addition, Initiators without allowing the authors would like Responder to
   thank Andrei Gurtov, Tobias Heer, Teemu Koponen, Juhana Mattila,
   Jeffrey M. Ahrenholz, Thomas Henderson, Kristian Slavov, Janne
   Lindqvist, Pekka Nikander, Lauri Silvennoinen, Jukka Ylitalo, Juha
   Heinanen, Joakim Koskela, Samu Varjonen, Dan Wing, Hannes Tschofenig,
   Jan Melen, Jani Hautakorpi and Ari Keraenen For their comments on
   this document.

   Miika Komu is working in send R1 or
   R2 packets to arbitrary hosts through the Networking Research group at Helsinki
   Institute for Information Technology (HIIT). Relay.

4.5.  LOCATOR Parameter

   The InfraHIP project
   was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence
   Forces, and Ericsson and Birdstep.

10.  References

10.1.  Normative References

   [I-D.ietf-behave-rfc3489bis]
              Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for (NAT) (STUN)",
              draft-ietf-behave-rfc3489bis-15 (work in progress),
              February 2008.

   [I-D.ietf-behave-turn]
              Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)",
              draft-ietf-behave-turn-06 (work in progress),
              January 2008.

   [I-D.ietf-hip-base]
              Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", draft-ietf-hip-base-10 (work in
              progress), October 2007.

   [I-D.ietf-hip-esp]
              Jokela, P., "Using ESP transport generic LOCATOR parameter format with HIP",
              draft-ietf-hip-esp-06 (work in progress), June 2007.

   [I-D.ietf-hip-mm]
              Henderson, T., "End-Host Mobility and Multihoming with is the
              Host Identity Protocol", draft-ietf-hip-mm-05 (work in
              progress), March 2007.

   [I-D.ietf-hip-registration]
              Laganier, J., "Host Identity Protocol (HIP) Registration
              Extension", draft-ietf-hip-registration-02 (work same as in
              progress), June 2006.

   [I-D.ietf-hip-rvs]
              Laganier, J. [RFC5206].
   However, presenting ICE candidates requires a new locator type.  The
   generic and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", draft-ietf-hip-rvs-05 (work in
              progress), June 2006.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

   [I-D.rosenberg-mmusic-ice-nonsip]
              Rosenberg, J., "NICE: Non Session Initiation Protocol
              (SIP) usage of Interactive  Connectivity Establishment
              (ICE)", draft-rosenberg-mmusic-ice-nonsip-00 (work in
              progress), February 2008.

   [RFC2119]  Bradner, S., "Key words for use NAT traversal specific locator parameters are illustrated
   in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. Figure 7.

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

                        Figure 7: LOCATOR parameter

   The individual fields in the LOCATOR parameter are described in
   Table 2.

   +-----------+----------+--------------------------------------------+
   | Field     | Value(s) | Purpose                                    |
   +-----------+----------+--------------------------------------------+
   | Type      | 193      | Parameter type                             |
   | Length    | Variable | Length in octets, excluding Type and       |
   |           |          | Length fields and padding                  |
   | Traffic   | 0-2      | Is the locator for HIP signaling (1), for  |
   | Type      |          | ESP (2), or for both (0)                   |
   | Locator   | 2        | "Transport address" locator type           |
   | Type      |          |                                            |
   | Locator   | 7        | Length of the Locator field in 4-octet     |
   | Length    |          | units                                      |
   | Reserved  | 0        | Reserved for future extensions             |
   | Preferred | 0        | Not used for transport address locators;   |
   | (P) bit   |          | MUST be ignored by the receiver.           |
   | Locator   | Variable | Locator lifetime in seconds                |
   | Lifetime  |          |                                            |
   | Transport | Variable | Transport layer port number                |
   | Port      |          |                                            |
   | Transport | 0        | 0 for UDP                                  |
   | Protocol  |          |                                            |
   | Kind      | Variable | 0 for host, 1 for server reflexive, 2 for  |
   |           |          | peer reflexive or 3 for relayed address    |
   | Priority  | Variable | Locator's priority as described in         |
   |           |          | [I-D.ietf-mmusic-ice]                      |
   | SPI       | Variable | SPI value which the host expects to see in |
   |           |          | incoming ESP packets that use this locator |
   | Locator   | Variable | IPv6 address or an "IPv4-compatible IPv6   |
   |           |          | address" format IPv4 address [RFC3513],    |
   |           |          | obfuscated by XORing it with the owner's   |
   |           |          | HIT                                        |
   +-----------+----------+--------------------------------------------+

                 Table 2: Fields of the LOCATOR parameter

4.6.  RELAY_HMAC

   The RELAY_HMAC parameter value has the TLV type 65520 (2^16 - 2^5 +
   2^4).  It has the same semantics as RVS_HMAC [RFC5204].

4.7.  Registration Types

   The REG_INFO, REQ_REQ, REG_RESP and H. Alvestrand, "Guidelines REG_FAILED parameters contain
   values for HIP Relay registration.  The value for RELAY_UDP_HIP is 2.
   The value for RELAY_UDP_ESP is 3.

4.8.  ESP Data Packets

   [RFC3948] describes 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 the encapsulation of the HIP ESP packets
   is same as the UDP encapsulation transport mode ESP.  However, the
   (semantic) difference to BEET mode ESP packets used by HIP is that IP
   header is not used in BEET integrity protection calculation.

   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 [RFC5202].  When two peers perform a UDP-encapsulated
   base exchange, they MUST define a pair of IPsec SAs that produces
   UDP-encapsulated ESP data traffic.

   The management of encryption/authentication protocols and SPIs is
   defined in [RFC5202].  The UDP encapsulation format and processing of
   HIP ESP traffic is described in Section 6.1 of [RFC5202].

5.  Security Considerations

5.1.  Privacy Considerations

   The locators are in XORed format in plain text in favor of inspection
   at HIP-aware middleboxes in the future.  The current draft does not
   specify encrypted versions of LOCATORs even though it could be
   beneficial for Writing privacy reasons.

   It is possible that an
              IANA Considerations Section Initiator or Responder may not want to reveal
   all of its locators to its peer.  For example, a host may not want to
   reveal the internal topology of the private address realm and it
   discards host addresses.  Such behavior creates non-optimal paths
   when the hosts are located behind the same NAT.  Especially, this
   could be a problem 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 [RFC5128].  With such a legacy NAT, the only option left
   would be to use a relayed transport address from a TURN server.

   As a consequence, a host may support locator-based privacy by leaving
   out the reflexive candidates.  However, the trade-off in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3513]  Hinden, R. using only
   host candidates can produce suboptimal paths that can congest the
   TURN server.  The use of HIP Relays or TURN Relays can be useful for
   protection against Denial-of-Service attacks.  If a Responder reveals
   only its HIP Relay addresses and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC4423]  Moskowitz, R. Relayed transport candidates to
   Initiators, the Initiators can only attack the relays that does not
   prevent the Responder from initiating new outgoing connections if a
   path around the relay exists.

5.2.  Opportunistic Mode

   A HIP Relay server should have one address per Relay Client when a
   HIP Relay is serving more than one Relay Clients and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

10.2.  Informative References

   [I-D.ietf-behave-p2p-state]
              Srisuresh, P., Ford, B., supports
   opportunistic mode.  Otherwise, it cannot be guaranteed that the
   Relay can deliver the I1 packet to the intended recipient.

5.3.  Base Exchange Replay Protection for HIP Relay Server

   On certain scenarios, it is possible that an attacker, or two
   attackers, can replay an earlier base exchange through a Relay server
   by masquerading as the original Initiator and D. Kegel, "State Responder.  The attack
   does not require the attacker(s) to compromise the private key(s) of Peer-to-
              Peer(P2P) Communication Across Network Address
              Translators(NATs)", draft-ietf-behave-p2p-state-06 (work
   the attacked host(s).  However, Responder has to be disconnected from
   the Relay in progress), November 2007.

   [I-D.irtf-hiprg-nat]
              Stiemerling, M., "NAT and Firewall Traversal Issues of
              Host Identity Protocol (HIP)  Communication",
              draft-irtf-hiprg-nat-04 (work order to masquarade successfully as the Responder.

   The Relay can protect itself against Replay attacks by involving in progress), March 2007.

   [RFC2663]  Srisuresh, P.
   the base exchange by introducing nonces that the end-hosts (Initiator
   and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology Responder) have to sign.  The Relay MAY add ECHO_REQUEST_M
   parameters to the R1 and Considerations",
              RFC 2663, August 1999.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., I2 messages as described in
   [I-D.heer-hip-middle-auth] and M.

              Stenberg, "UDP Encapsulation drops the I2 or R2 messages if the
   corresponding ECHO_RESPONSE_M parameters are not present.

5.4.  Demuxing Different HIP Associations

   Section 5.1 of IPsec ESP Packets",
              RFC 3948, January 2005.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

Appendix A.  Firewall Traversal

   This section [RFC3948] describes firewall traversal issues separately from NAT
   issues.  When 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 Initiator or same Responder in the public Internet.  The
   Responder cannot distinguish between two hosts, because security
   associations are based on the same inner IP addresses.

   This issue does not exist with the UDP encapsulation of a HIP association ESP
   transport format because the Responder use HITs to distinguish
   between different Initiators.

6.  IANA Considerations

   This section is
   behind a firewall, additional issues arise.  The firewall discussion
   applies both to IPv4 and IPv6 addressing.

   The NAT traversal mechanisms described in this document require that
   the firewall - stateful or not - allows be interpreted according to [RFC2434].

   This draft currently uses a UDP traffic.  At the minimum,
   successful firewall control packet traversal requires that the host
   behind port in the firewall "Dynamic and/or Private
   Port" and HIPPORT.  Upon publication of this document, IANA is allowed
   requested to communicate packets with a HIP
   Relay (or register a Responder without HIP Relay) that is listening on UDP port HIPPORT.  Successful ESP data packet traversal requires the same
   for the TURN server.  For unrelayed traffic, and the destination RFC editor is requested to
   change all occurrences of port HIPPORT should be open at the firewall to all hosts behind the
   firewall.

   Most firewall implementations support "UDP connection tracking",
   i.e., after a host behind a firewall port IANA has initiated UDP communication
   to
   registered.  The HIPPORT number 50500 should be used for initial
   experimentation.

   This document updates the public Internet, IANA Registry for HIP Parameter Types by
   assigning new HIP Parameter Type values for the firewall accepts UDP response traffic new HIP Parameters:
   RELAY_FROM, RELAY_TO and REG_FROM (defined in
   the return direction.  If no such return traffic arrives for Section 4.4) and
   RELAY_HMAC (defined in Section 4.6).  NAT_TRANSFORM is also a
   specific period new
   parameter.

7.  Contributors

   This draft is a product of time, the firewall stops accepting the given IP
   address a design team which also included Marcelo
   Bagnulo and port pair.  The mechanisms described in Jan Melen who both have made major contributions to this document
   already enable traversal of such firewalls, if the keep-alive
   interval used is less than
   document.

8.  Acknowledgments

   Thanks for Jonathan Rosenberg and the refresh interval rest of the firewall.

   When the Initiator is behind a firewall, MMUSIC WG folks for
   the NAT traversal mechanisms
   described in this document depend excellent work on ICE.  In addition, the ability to initiate
   communication via UDP authors would like to the destination port HIPPORT from arbitrary
   source ports
   thank Andrei Gurtov, Simon Schuetz, Martin Stiemerling, Lars Eggert,
   Vivien Schmitt, Abhinav Pathak for their contributions and to receive UDP response traffic from that port to
   the chosen source port.  If the Initiator Tobias
   Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz, Thomas
   Henderson, Kristian Slavov, Janne Lindqvist, Pekka Nikander, Lauri
   Silvennoinen, Jukka Ylitalo, Juha Heinanen, Joakim Koskela, Samu
   Varjonen, Dan Wing and Jani Hautakorpi for their comments on this
   document.

   Miika Komu is behind a firewall that
   does not support "UDP connection tracking", the NAT traversal
   mechanisms described working in this document can still be supported, if the
   firewall allows permanently inbound UDP traffic from Networking Research group at Helsinki
   Institute for Information Technology (HIIT).  The InfraHIP project
   was funded by Tekes, Telia-Sonera, Elisa, Nokia, the port HIPPORT Finnish Defence
   Forces, and destined to arbitrary source IP addresses Ericsson and UDP ports.

   When the Responder is behind a firewall, the Birdstep.

9.  References

9.1.  Normative References

   [I-D.ietf-behave-rfc3489bis]
              Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for (NAT) (STUN)",
              draft-ietf-behave-rfc3489bis-16 (work in progress),
              July 2008.

   [I-D.ietf-behave-turn]
              Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
              Relays around NAT traversal mechanisms
   described (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)",
              draft-ietf-behave-turn-08 (work in progress), June 2008.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in this document depend on the ability to send and receive
   UDP traffic originating from HIPPORT progress), October 2007.

   [I-D.rosenberg-mmusic-ice-nonsip]
              Rosenberg, J., "NICE: Non Session Initiation Protocol
              (SIP) usage of the HIP Relays and TURN
   servers.  When end-to-end traffic is preferred, arbitrary source IP
   addresses and ports are required.

Appendix B.  Base Exchange without ICE Interactive  Connectivity Checks

   In certain network environments, the ICE connectivity tests can be
   omitted Establishment
              (ICE)", draft-rosenberg-mmusic-ice-nonsip-00 (work in
              progress), February 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to reduce initial connection set up latency because base
   exchange acts Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an implicit connectivity test itself.  There are three
   assumptions about such as environments.  First, the Responder should
   have a long-term, fixed locator
              IANA Considerations Section in the network.  Second, the
   Responder should not have RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a HIP Relay configured transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for itself.  Third, User Names
              and Passwords", RFC 4013, February 2005.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008.

   [RFC5202]  Jokela, P., Moskowitz, R., and P. Nikander, "Using the Initiator can reach
              Encapsulating Security Payload (ESP) Transport Format with
              the Responder by simply UDP encapsulating HIP Host Identity Protocol (HIP)", RFC 5202, April 2008.

   [RFC5203]  Laganier, J., Koponen, T., and L. Eggert, "Host Identity
              Protocol (HIP) Registration Extension", RFC 5203,
              April 2008.

   [RFC5204]  Laganier, J. and ESP packets to the host.  Detecting L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", RFC 5204, April 2008.

   [RFC5206]  Nikander, P., Henderson, T., Vogt, C., and configuring this
   particular scenario is prone administrative failure unless carefully
   planned.

   In such a scenario, the Initiator sends an I1 packet over UDP to the
   Responder.  The Responder replies J. Arkko, "End-
              Host Mobility and Multihoming with a R1 packet that does not
   contain the transform parameter as explained Host Identity
              Protocol", RFC 5206, April 2008.

9.2.  Informative References

   [I-D.heer-hip-middle-auth]
              Heer, T., Wehrle, K., and M. Komu, "End-Host
              Authentication for HIP Middleboxes",
              draft-heer-hip-middle-auth-01 (work in Section 4.1.  The
   Initiator receives the R1 packet progress),
              July 2008.

   [I-D.irtf-hiprg-nat]
              Stiemerling, M., "NAT and determines from the absence Firewall Traversal Issues of
   the transform
              Host Identity Protocol (HIP)  Communication",
              draft-irtf-hiprg-nat-04 (work in progress), March 2007.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and RELAY_TO parameters that ICE connectivity tests can
   be omitted with the Responder.  Finally, the hosts set up M.
              Stenberg, "UDP Encapsulation of IPsec
   security associations using the locators observed from the concluding
   I2 ESP Packets",
              RFC 3948, January 2005.

   [RFC4787]  Audet, F. and R2 packets C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5128]  Srisuresh, P., Ford, B., and D. Kegel, "State of the base exchange without ICE connectivity
   tests. Peer-to-
              Peer (P2P) Communication across Network Address
              Translators (NATs)", RFC 5128, March 2008.

Appendix C. A.  IPv4-IPv6 Interoperability

   Currently Relay Client and Server do not have to run any ICE
   connectivity tests as described in Appendix B. Section 3.6.  However, it could be
   useful for IPv4-IPv6 interoperability when the Relay Server actually
   includes both the NAT transform parameter and multiple locators in
   R2.  The interoperability benefit is that the Relay could support
   IPv4-based Initiators and IPv6-based Responders by converting the
   network headers and recalculating UDP checksums.

   Such an approach is underspecified in this document currently.  It is
   not yet recommended because it may consume resources at the Relay and
   requires also similar conversion support at the TURN relay for data
   packets.

Appendix D. B.  Base Exchange through a Rendezvous Server

   This section describes handling for a scenario where Initiator looks
   up the information of the Responder from DNS and discovers a RVS
   record [I-D.ietf-hip-rvs]. [RFC5204].  In such a case, the Initiator uses its own HIP
   Relay to forward HIP traffic to the Rendezvous server.  The Initiator
   will send the I1 message using the its HIP Relay server which will
   then forward it to the RVS server of the responder.  The responder
   will send the R1 packet directly to the Initiator's HIP Relay server
   and the following I2 and R2 packets are also sent directly using the
   Relay.

   In case the Initiator is not able to distinguish which records are
   RVS address records and which are Responders address records, then
   the Initiator SHOULD first try to contact the Responder directly and
   if none of the addresses is reachable it MAY try out them using its
   own HIP Relay as described in the above.

Appendix E. C.  Document Revision History

   To be removed upon publication

   +-----------------------------+-------------------------------------+
   | Revision                    | Comments                            |
   +-----------------------------+-------------------------------------+
   | draft-ietf-nat-traversal-00 | Initial version.                    |
   | draft-ietf-nat-traversal-01 | Draft based on RVS.                 |
   | draft-ietf-nat-traversal-02 | Draft based on Relay proxies and    |
   |                             | ICE concepts.                       |
   | draft-ietf-nat-traversal-03 | Draft based on STUN/ICE formats.    |
   | draft-ietf-nat-traversal-04 | Issues 25-27,29-36                  |
   +-----------------------------+-------------------------------------+

Authors' Addresses

   Miika Komu
   Helsinki Institute for Information Technology
   Metsanneidonkuja 4
   Espoo
   Finland

   Phone: +358503841531
   Fax:   +35896949768
   Email: miika@iki.fi
   URI:   http://www.hiit.fi/
   Thomas Henderson
   The Boeing Company
   P.O. Box 3707
   Seattle, WA
   USA

   Email: thomas.r.henderson@boeing.com

   Philip Matthews
   Avaya
   100 Innovation Drive
   Ottawa, Ontario  K2K 3G7
   Canada

   Phone: +1 613 592 4343 224
   (Unaffiliated)

   Email: philip_matthews@magma.ca

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.com

   Ari Keraenen (editor)
   Ericsson Research Nomadiclab
   Hirsalantie 11
   02420 Jorvas
   Finland

   Phone: +358 9 2991
   Email: ari.keranen@ericsson.com
   Jan Melen
   Ericsson Research Nomadiclab
   Hirsalantie 11
   02420 Jorvas
   Finland

   Phone: +358 9 2991
   Email: jan.melen@ericsson.com

   Marcelo Bagnulo
   Huawei Lab at UC3M
   Av. Universidad 30
   Leganes, Madrid  28911
   Spain

   Phone: 34 91 6249500
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es/

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).