HIP Working Group                                                M. Komu, Ed. Komu
Internet-Draft                                                      HIIT
Intended status: Experimental                                 S. Schuetz                               T. Henderson
Expires: January 7, August 28, 2008                              The Boeing Company
                                                             P. Matthews
                                                                   Avaya
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                             A. Keraenen
                                                                J. Melen
                                            Ericsson Research Nomadiclab
                                                              M. Stiemerling
                                                                     NEC
                                                            July 6, 2007 Bagnulo
                                                      Huawei Lab at UC3M
                                                       February 25, 2008

 Basic HIP Extensions for the Traversal of Network Address Translators
                    draft-ietf-hip-nat-traversal-02 and
                               Firewalls
                  draft-ietf-hip-nat-traversal-03.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 January 7, August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007). (2008).

Abstract

   The Host Identity Protocol (HIP) provides a new namespace that can be
   used for uniquely identifying hosts in public and also in private
   address realms.  Usually, hosts.  Existing HIP control and data traffic cannot
   traverse experimental
   specifications do not specify protocol operations across Network
   Address Translators (NATs), that hinders general
   deployment. (NATs).

   This document specifies NAT traversal extensions for HIP.  As  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 all
   high-layer higher-layer networking applications that run over HIP. applications.  The basic
   design concepts for these extensions have been adopted from are
   based on the use of the The Interactive Connectivity Establishment
   (ICE) protocol methodology to HIP. 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 they both nodes are in different private
   address realms. behind NATs or
   firewalls.

Table of Contents

   1.  Terminology  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   2.  Introduction  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3  5
   3.  HIP Across NATs  Protocol Description . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Relay Registration and NAT Detection . .  5
     3.1.  Port Number Selection . . . . . . . . .  7
     3.2.  Base Exchange via HIP Relay  . . . . . . . . .  6
     3.2.  Relay Registration and NAT Detection . . . . . .  9
   4.  Connectivity Tests . . . . .  6
     3.3.  Base Exchange via Relay . . . . . . . . . . . . . . . . .  8
     3.4.  Base Exchange without a Relay 11
     4.1.  NAT Transformation Negotiation . . . . . . . . . . . . . . 10
     3.5.  Connectivity Tests 11
     4.2.  ICE Procedure  . . . . . . . . . . . . . . . . . . . . 11
     3.6.  Selecting an Address Pair . . 12
     4.3.  NAT Keep-alives  . . . . . . . . . . . . . . 13
     3.7.  Mobility . . . . . . . 12
   5.  Packet Formats . . . . . . . . . . . . . . . . . . 14
     3.8.  NAT Keepalives . . . . . . 13
     5.1.  HIP Control Packets  . . . . . . . . . . . . . . . . 15
     3.9.  Closing of HIP Associations . . . 13
     5.2.  Keep-Alives  . . . . . . . . . . . . 16
     3.10. Communication with HIP Hosts without NAT Traversal
           Support . . . . . . . . . . . 13
     5.3.  Relay and Registration Parameters  . . . . . . . . . . . . 14
     5.4.  LOCATOR Parameter  . . 16
   4.  Packet Formats . . . . . . . . . . . . . . . . . . 14
     5.5.  RELAY_HMAC . . . . . . 17
     4.1.  HIP Control Packets . . . . . . . . . . . . . . . . . . 16
     5.6.  Registration Types . 17
     4.2.  Control Channel Keep-Alives . . . . . . . . . . . . . . . 18
     4.3.  RELAY_FROM, RELAY_TO and RELAY_VIA Parameters . . . . 16
     5.7.  HIP ESP Data Packet Formats  . . 18
     4.4.  LOCATOR Parameter . . . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . 19
     4.5.  RELAY_HMAC . . . . . . . . . . . . 17
     6.1.  Privacy Considerations . . . . . . . . . . . . 20
     4.6.  Registration Types . . . . . . 17
     6.2.  Opportunistic Mode . . . . . . . . . . . . . . 20
     4.7.  ESP Data Packets . . . . . . 18
   7.  IANA Considerations  . . . . . . . . . . . . . . . 21
     4.8.  UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 21
   5.  Firewall Traversal . . . . 18
   8.  Contributors . . . . . . . . . . . . . . . . . . 23
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
     6.1.  A Difference to RFC3948  . . . . . . . . . . . . . . . . . 23
     6.2.  Privacy Considerations . . . . . . . . . . . . . . 18
   9.  Acknowlegements  . . . . 24
     6.3.  Opportunistic Mode . . . . . . . . . . . . . . . . . . . 18
   10. References . 24
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
   8.  Acknowlegements . . . . 19
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 25
   9. 19
     10.2. Informative References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     9.1.  Normative References . . . 20
   Appendix A.  Firewall Traversal  . . . . . . . . . . . . . . . . 26
     9.2.  Informative References . 21
   Appendix B.  Base Exchange without ICE Connectivity Checks . . . . 22
   Appendix C.  IPv4-IPv6 Interoperability  . . . . . . . . . . . . . 27 22
   Appendix A.  Differences to ICE  . . . . . . . . . . . D.  Base Exchange through a Rendezvous Server . . . . . . 28 22
   Appendix B. E.  Document Revision History . . . . . . . . . . . . . . 29 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 31 26

1.  Terminology

   In general, this document borrows the terminology from  Introduction

   HIP [I-D.ietf-hip-base] and [RFC4423].  Additional terms are is defined in as a protocol that runs directly
   over IPv4 or IPv6.  This approach is known to have problems
   traversing NATs.  Several different types of NATs exist, see
   [RFC2663].  This document describes HIP extensions for the table below."  These draft e.g. define "Initiator" traversal
   of both Network Address Translator (NAT) and
   "Responder"

   +---------------------+---------------------------------------------+
   | Term                | Explanation                                 |
   +---------------------+---------------------------------------------+
   | Rendezvous server   | A host that forwards I1 packets 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      |
   |                     | Responder                                   |
   | HIP Relay           | term NAT to refer to these types of
   middleboxes.  A host that forwards all detailed description of HIP control        |
   |                     | packets between an Initiator and Responder  |
   | ESP Relay           | A host that forwards ESP traffic between    |
   |                     | two HIP-enabled hosts                       |
   | Locator             | A routable IPv4 or IPv6 address             |
   | Transport locator   | Transport layer port and the corresponding  |
   |                     | IPv4/v6 address                             |
   | Unreflexive locator | An IPv4 or IPv6 address of a network        |
   |                     | interface of a host                         |
   | Relay reflexive     | A translated transport locator of a host as |
   | transport locator   | observed by a relay                         |
   | Peer reflexive      | A translated transport locator of a host as |
   | transport locator   | observed by its peer                        |
   | Leased transport    | Transport locator of an ESP relay           |
   | locator             |                                             |
   +---------------------+---------------------------------------------+

                           Table 1: Terminology

2.  Introduction

   The Host Identity Protocol (HIP) describes a new communication
   mechanism for Internet hosts [RFC4423].  It introduces problems with traversing
   legacy middleboxes is documented in [I-D.irtf-hiprg-nat].

   NAT devices do not operate consistently even though a new
   namespace and protocol layer between the network and transport layers
   that decouples the identifier and locator roles to support mobility
   and multihoming recommended
   behavior is described in the Internet architecture.  HIP also secures
   application layer communications using IPsec ESP [I-D.ietf-hip-esp]. [RFC4787].  The HIP protocol [I-D.ietf-hip-base] cannot operate across legacy NAT
   middleboxes as described extensions in [I-D.irtf-hiprg-nat].  This
   this document
   specifies mechanisms that allow HIP to traverse through such NAT
   middleboxes that are neither HIP-aware nor ESP-aware, without manual
   configuration make as few assumptions as possible about the behavior
   of the NAT middleboxes.

   HIP introduces a new namespace for hosts devices so that decouples the identity
   of a host from its location [RFC4423]. NAT traversal will work even with legacy
   NAT devices.  The namespace consists purpose of
   Host Identifiers which are public keys.  The these extensions is to allow two HIP-
   enabled hosts create the
   corresponding private keys by themselves which makes identity theft
   more difficult.

   The new namespace of HIP has some additional benefits when the
   extensions defined in this document are used.  First, it is possible to communicate with each other even if one or both
   communicating hosts are in private address realms.  With some legacy
   NAT devices, utilizing the shortest path between two end hosts
   located behind NATs is not possible without relaying the traffic
   through a single NAT middlebox in relay, such as a relatively simple
   way.  The NAT middlebox translates the locators, but TURN server [I-D.ietf-behave-p2p-state].
   As a consequence, the Host
   Identifiers remain TURN server increases the same roundtrip delay and can be used for uniquely identifying
   may become a host inside point of network congestion.  With the private address realm.  Second, multiple services
   on different extensions
   described in this document, hosts can share try to avoid the same transport layer port number
   behind use of such a single legacy NAT.  There is no multiplexing issue as long
   as these hosts have different Host Identifiers
   relay when possible.

   A distinction must be made between a HIP rendezvous server (defined
   in [I-D.ietf-hip-rvs]) and UDP encapsulation
   is used for traversing the legacy NAT.

   Several different types of NATs exist [RFC2663].  This document
   describes a HIP extensions for Relay, defined herein.  HIP
   rendezvous servers solve initial contact and mobility related
   problems in networks without NATs.  HIP Relay solve the same
   problems, in addition to NAT traversal of problems.  HIP Relay servers
   can be used both Network Address
   Translator (NAT) in NATted and Network Address non-NATted networks.

   Both rendezvous and Port Translator (NAPT)
   middleboxes.  The document generally uses the term NAT to refer to
   both types of middleboxes, unless it needs to distinguish between relay services forward HIP control packets, but
   the
   two types.

   Three basic scenarios exist for NAT traversal.  In main difference is that the first case, rendezvous service forwards only the Initiator
   initial I1 packet of a HIP the base exchange is located behind a NAT.
   In the second case, only the Responder of a while all other HIP base exchange is
   located behind a NAT.  The respective peer is assumed to be located
   at a publicly reachable address in both cases.  In the third case,
   both peers are located behind (possible different) NATs.  All of the
   use cases control
   packets are addressed in sent directly between the draft in a unified method that has
   been adopted from Interactive Connectivity Establishment (ICE)
   protocol [I-D.ietf-mmusic-ice] and adapted to HIP.

   Legacy NAT devices do not operate consistently although communicating hosts.  In
   contrast, the behavior
   for new NAT devices has been unified in [RFC4787].  The relay service relays all HIP protocol
   extensions in this document make as little assumptions as possible of
   the behavior of the NAT devices so that NAT traversal will work even
   with legacy control packets because
   p2p-unfriendly NAT devices in drop the most general sense. packets otherwise
   [I-D.ietf-behave-p2p-state].  The purpose of peers use the extensions is to allow two HIP-enabled hosts control channel to
   communicate with their current locators to each other even if one or both communicating hosts are in private
   address realms.  With some legacy NAT devices, connecting two to find a direct
   path for carrying ESP encapsulated data traffic.  A direct path
   between the hosts
   behind different address realms is impossible enables efficient delivery of data traffic without
   relaying all
   traffic of ESP packets through an intermediary TURN server.  The
   direct path is searched using connectivity tests.

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

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

      "The Interactive Connectivity Establishment (ICE) methodology is a third party host [I-D.ietf-behave-p2p-state].  As a
   consequence,
      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 relay host introduces additional hops between offer/answer model.  ICE is an extension
      to the
   hosts offer/answer model, and can become works by including a point multiplicity
      of network congestion.  In the
   extensions described IP addresses and ports in this document, the peers try to avoid the use
   of a relay for data traffic SDP offers and only make use of it when necessary.

   Hosts that always get a public answers, which are
      then tested for connectivity by peer-to-peer connectivity checks.
      The IP addresses can use the rendezvous
   services as described in [I-D.ietf-hip-rvs].  Hosts that can be
   located in private-address realms may use a transport-layer based
   relay service as defined in this document.  Both rendezvous and relay
   services forward HIP control packets, but the main difference is that
   the rendezvous service forwards only ports included in the initial I1 packet of SDP and the
   base exchange while all other HIP control packets
      connectivity checks are sent directly
   between the communicating hosts.  In contrast, the relay service
   relays all HIP control packets because p2p-unfriendly NAT devices
   drop the packets otherwise [I-D.ietf-behave-p2p-state].  The peers
   use performed using the control channel to communicate their current locators to each
   other revised STUN
      specification [I-D.ietf-behave-rfc3489bis], now renamed to find a direct path Session
      Traversal Utilities 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 ESP relay.  The direct path is searched using
   connectivity tests.

   The basis NAT."

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

   Two hosts communicate their transport locator (a port and an peer address set (typically consisting of
   IP
   address) address and port number pairs) to each other in a the HIP base
   exchange.  The local locators  They are then paired with peer locators and the pairs are locally operational address
   of the other end point and prioritized according to
   their proximity.  The locator pairs some policy.
   These address sets are then tested sequentially based on the
   procedure specified in
   priority order using return routability tests [I-D.ietf-hip-mm]. ICE.  Both sides participate in the
   connectivity tests.  The tests also determine whether transport layer encapsulation is required or not.
   As a result, the hosts either detect that no transport locator pairs
   are working, or establish a number of working locator operational
   address pairs and select a single the preferred address pair to be used for
   subsequent communication.

   The same connectivity tests are also used in situations when

   As a mobile
   host moves summary, the extensions in this document

   o  illustrate how to a different network.  The mobile host communicates its
   new location encapsulate HIP packets in UDP

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

   o  define how a node through the relay interacts with a HIP rendezvous server of
   its peer and starts the connectivity tests. (defined
      in [I-D.ietf-hip-rvs]) when middleboxes are present

   o  describe a methodology to determine operational address pairs
      between two end hosts based on ICE.

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

3.  HIP Across NATs

   This section describes NAT traversal between two HIP end-hosts.  A
   successful NAT traversal requires at least document borrows terminology from [I-D.ietf-hip-base],
   [I-D.ietf-hip-mm], [RFC4423], [I-D.ietf-mmusic-ice], and
   [I-D.ietf-behave-rfc3489bis].  Additionally, the Responder located in a
   private address realm to register following terms are
   used:

    Rendezvous server:

      A host that forwards I1 packets to a relay server.  The use of the
   relay is optional when the Responder is located in a public address
   realm without rendezvous server.

   The base exchange is relayed through the relay server.  Next, the
   hosts test the reachability

   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 name that controls how the different locators to
   construct a direct route.  When a direct route packet is not possible, routed through the
   hosts resort to ESP relays.  When locators of a host change, network
      and demultiplexed by the
   hosts test reachability end host.  It may include a concatenation
      of locators again and select the "optimal"
   locator.  End-hosts can tear down HIP associations using the CLOSE
   mechanism through the relay.

3.1.  Port Number Selection

   This document defines only UDP encapsulation for HIP traditional network addresses such as an IPv6 address and end-
      to-end identifiers such as an ESP packets.
   Further extensions SPI.  It may define bindings for other transport protocols.
   The RECOMMENDED also include
      transport protocol is UDP.

   It is RECOMMENDED that an Initiator selects a random port number
   between the ephemeral port ranged 49152-65535 for initiating numbers or IPv6 Flow Labels as demultiplexing
      context, or it may simply be a base
   exchange even network address.  [I-D.ietf-hip-mm]
      "Address" is used in this document as a synonym for registration.  However, the allocated locator.

   Transport address:

      Transport layer port MUST be
   maintained until all of and the corresponding IPv4/v6 address

   Candidate:

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

   Host Associations are
   closed.  Alternatively, candidate:

      An IPv4 or IPv6 address of a host MAY also use network interface of a single fixed port for
   initiating all outgoing connections. host
   Server reflexive transport candidate:

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

   Peer reflexive transport candidate:

      A translated transport address of a relay MUST listen at host as observed by its peer

   Relayed transport port
   HIPPORT candidate:

      A transport address that exists on a TURN server.  If a permission
      exists, 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 incoming UDP-encapsulated HIP control packets.

3.2.
   illustration purposes.

3.1.  Relay Registration and NAT Detection

   HIP rendezvous servers are used in non-NATted environments and its their
   use is described in [I-D.ietf-hip-rvs].  This section defines the
   another types middleboxes, called specifies a new
   role for these rendezvous servers to act as HIP Relays.  HIP Relays
   forward HIP control packets between the Initiator and ESP Relays, which the Responder.
   TURN servers [I-D.ietf-behave-turn] are used
   in NATted environments.

   A HIP relay forwards UDP-encapsulated traffic, and in future
   extensions, a relay may also forward TCP-encapsulated for relaying ESP
   traffic.  A
   single relay may forward only host SHOULD register to a TURN server before registering
   to a HIP control packets, Relay to guarantee that the host can accept ESP traffic or
   both.
   immediately after HIP Relay registration.

   A host acting as a Responder HIP relay forwards UDP-encapsulated HIP traffic, and in future
   extensions, a private address realm SHOULD
   use a HIP relay for may also forward TCP-encapsulated traffic.  The
   HIP Relay forwards HIP control packets.  NAT traversal.  It is RECOMMENDED that traversal for HIP
   between two end-hosts may require the
   Responder uses also an ESP relay to guarantee use of relays in certain
   scenarios.  A successful NAT traversal with p2p-unfriendly therefore requires at least
   the Responder located behind a NAT devices. to register with a HIP Relay.

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

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

               Figure 1: Example registration to a relay

   In the above figure, the end-host is referred to as a relay client
   and the relay middlebox as a relay server.  The registration is
   piggybacked Registration to a base exchange, but it can be done also using HIP
   UPDATE control packets as described in [I-D.ietf-hip-registration]. Relay

   In step 1, the relay client Initiator starts the registration procedure by sending
   an I1 packet over UDP.  It is RECOMMENDED that the transport layer.  The Initiator selects
   a random port selection
   was explained in section Section 3.1. 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 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 and the support for ESP-over-UDP relaying is
   denoted by a RELAY_UDP_ESP value in the REG_INFO parameter.

   In step 3, value.  The R1 does not contain any NAT transform
   parameter (see Section 4.1) as discussed in Appendix B.

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

   In step 4, the relay server Responder concludes the registration procedure with an
   R2 packet and acknowledges the registered services in the REG_RES
   parameter.  The relay Responder may also denote 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 hosts
   MUST Initiator needs to send periodically NAT keepalive packets keep-
   alives.

   There are different ways for an Initiator to each other as defined
   later in this document.

   In step 5, the client and server handle connectivity tests.  The
   procedure is described in a later section.

   When the ESP relay registration was successful, the relay server uses
   the source learn it's publically
   visible IP address and port of the R2 packet (HIPPORT) to relay
   ESP traffic with the client.  This address-port pair of the relay is that are referred to as a "leased the "server
   reflexive transport locator" candidate" in this document.  As the
   port number  This document makes
   use of two ways:

   o  The Relay client may be shared by multiple clients, the ESP relay MUST
   multiplex use STUN servers to detect the ESP traffic based on SPIs and not server
      reflexive locator, as described in [I-D.ietf-behave-p2p-state].

   o  Alternatively, the just Relay Client can learn it from the port
   number.

   The R2 packet also includes an REG_FROM
      parameter when registering to a Relay.

3.2.  Base Exchange via HIP Relay

   It is RECOMMENDED that indicates the
   transport locator Initiator sends an I1 packet encapsulated
   in UDP when it is destined to an IPv4 address of the client as observed by Responder.
   Respectively, the server.  The
   transport locator may be translated by Responder MUST respond to a number of NAT middleboxes
   between such I1 packet with an
   R1 packet over the client transport layer and using the server.  This locator is referred to as
   the "relay reflexive same transport locator" later in this document.

   A single server can provide multiple HIP middlebox services or the
   services can be distributed among multiple servers.
   protocol.  The difference
   between a HIP rendezvous server [I-D.ietf-hip-rvs] 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))           |
     | 4. UDP(R1(RELAY_TO))         |<-------------------------------+
     |<-----------------------------+                                |
     |                              |                                |
     | 5. UDP(I2(LOCATOR))          |                                |
     +----------------------------->|                                |
     |                              | 6. UDP(I2(LOCATOR,RELAY_FROM)) |
     |                              +------------------------------->|
     |                              |                                |
     |                              | 7. UDP(R2(LOCATOR,RELAY_TO))   |
     | 8. UDP(R2(LOCATOR,RELAY_TO)) |<-------------------------------+
     |<-----------------------------+                                |
     |                              |                                |

                  Figure 2: Base Exchange via a HIP relay
   server depends on Relay

   In step 1 of Figure 2, the registration.  The rendezvous server processing
   rules apply when Initiator sends an I1 packet over the Responder has registered
   transport layer to a middlebox with the
   RVS registration type.  Correspondingly, HIT of the middlebox applies Responder.  The source address is
   one of the
   relay extensions defined locators of the host.  The locators of the end-hosts are
   referred as "host candidates" in this document when document.

   In step 2, the Responder has
   registered using HIP Relay receives the relay registration types.  When I1 packet at port HIPPORT.  If
   the destination HIT belongs to a single server
   provides both rendezvous and relay services, they are multiplexed
   depending on registered Responder, the absence or presence of transport layer
   encapsulation.

   The Relay Client MUST include a LOCATOR parameter in I2 which lists
   all of
   processes the locators of packet.  Otherwise, the Initiator.  The Relay Server MUST include drop the packet
   silently.  The Relay appends a LOCATOR RELAY_FROM parameter in R1, but it is RECOMMENDED that to the LOCATOR
   parameter includes only I1 packet
   which constains the source transport LOCATOR source address and port of R1 the I1 as
   observed by the
   only locator. Relay.  The case when the Relay Server includes more locators
   may require IP header conversion between IPv4 and IPv6, insertion, or
   removal of, UDP header and fragmentation handling.  Multiple locators
   in R1 is left for further experimentation.

3.3.  Base Exchange via Relay

   It is RECOMMENDED that protects the Initiator sends an I1 packet over with
   RELAY_HMAC as described in [I-D.ietf-hip-rvs], except that the
   transport layer when it
   parameter type is destined to an IPv4 address different.  The Relay changes the source and
   destination ports and IP addresses of the
   Responder.  Respectively, packet to match the values
   the Responder MUST respond used when registering to a such I1
   packet with an R1 packet over the transport layer and using Relay, i.e., the same
   transport protocol.  The rest reverse
   of the base exchange, I2 and R2, R2 used in the registration.  The Relay MUST
   also be sent over recalculate the
   transport layer.  However, checksum and forward the transport layer
   encapsulation can be unnecessary when there are no NATs between packet to the
   Initiator and Responder.  This will be detected in

   In step 3, the connectivity
   tests described Responder receives the I1 packet.  The Responder
   processes it according to the rules in [I-D.ietf-hip-base].  In
   addition, the next section.

   When Responder validates the Initiator has an IPv6 address RELAY_HMAC according to
   [I-D.ietf-hip-rvs] and it has discovered only an
   IPv6 address for silenty drops the peer, it MUST send packet if the validation
   fails.  The Responder replies with an R1 packet to which it directly over IP.  In such includes
   a case, RELAY_TO parameter.  The RELAY_TO parameter contains same
   information as the RELAY_FROM parameter, i.e., Initiator MUST follow transport
   address, but the procedures described in
   [I-D.ietf-hip-base].  Otherwise, it type of the parameter is RECOMMENDED that different.  The RELAY_TO
   parameter is not integrity protected by the Initiator
   proceeds as shown in Figure 2.

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

                    Figure 2: Base Exchange via a relay signature of the R1 to
   allow pre-created R1 packets at the Responder.

   In step 1 of 4, the figure, Relay receives the Initiator discovers R1 packet.  The Relay drops the
   packet silently if the source HIT belongs to an unregistered host.
   The Relay MAY verify the signature of the
   Responder R1 packet and drop it if
   the IPv4 signature is invalid.  Otherwise, the Relay rewrites to source
   address of and port, changes the relay of destination address and port to match
   RELAY_TO information, recalculates transport checksum and forwards
   the packet.

   In step 5, the Responder.  The Initiator sends receives the R1 packet and processes it
   according to [I-D.ietf-hip-base].  It replies with an I1 I2 packet over that
   uses the destination transport layer to the HIT address of R1 as the Responder.  The port selection was explained in Section 3.1.  The source address is one of
   and port.  The I2 contains a LOCATOR parameter that lists all the routable addresses ICE
   candidates (offer) of the host is called
   "unreflexive locators" Initiator.  The candidates are encoded
   using the format defined in this document. Section 5.4.

   In step 2, 6, the relay Relay receives the I1 packet at port HIPPORT.  If the
   destination HIT belongs to a registered Responder, the relay
   processes the packet.  Otherwise, the relay MUST drop the I2 packet.  The relay MUST append appends a
   RELAY_FROM parameter and a RELAY_HMAC to the I1 I2 packet which
   preserves as in the transport source address and port of second step.

   In step 7, the Initiator.
   The relay protects Responder receives the I1 I2 packet with RELAY_HMAC as described in
   [I-D.ietf-hip-rvs], except that the parameter type is different.  The
   relay MUST change the transport source to and destination of the
   packet to match the values the Responder used when registering to the
   relay, i.e., the reverse of the R2 used in the registration.  The
   relay MUST recalculate the transport checksum and forwards the packet
   to the Responder.

   In step 3, the Responder receives the I1 packet at the transport
   layer.  The Responder MUST process processes it
   according to the rules in [I-D.ietf-hip-base].  In addition, the Responder MUST validate the
   RELAY_HMAC according to [I-D.ietf-hip-rvs] and drop the packet if the
   validation fails.  The Responder  It replies with an R1 a R2 packet that MUST
   contain and
   includes a LOCATOR RELAY_TO parameter that lists the locators of the Responder.
   The locator list consists of unreflexive, reflexive and leased
   transport locators of the Responder. as in step three.  The R1 R2 packet also contains
   includes a
   RELAY_TO parameter.  The RELAY_TO LOCATOR parameter contains same information
   as the RELAY_FROM parameter, i.e., Initiator transport locator, but that lists all the type ICE candidates
   (answer) of the parameter is different. Responder.  The RELAY_TO parameter is
   not integrity protected by
   the signature of the R1 to allow pre-
   created R1 packets at the Responder. HMAC.

   In step 4, 8, the relay receives Relay processes the R1 packet. R2 as described in step four.  The relay MUST drop
   Relay forwards the packet if the source HIT belongs to an unregistered host.  The relay
   MAY verify the signature Responder.

4.  Connectivity Tests

4.1.  NAT Transformation Negotiation

   This section describes usage of a new optional transform parameter
   type.  The presence of the R1 packet and drop it when parameter in HIP base exchange means that
   the
   signature is invalid.  Otherwise, host supports all of the relay changes extensions defined in this document.  If
   the destination
   transport header transform parameter is used, hosts MUST use a password for STUN
   HMACs that is drawn from the DH keying material.

   The transform parameter applies both to match RELAY_TO information, recalculates
   transport checksum and forwards the packet. registration to the HIP
   Relay as well as to a base exchange between end-hosts.  The transform
   negotiation in base exchange is illustrated 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 NAT Transforms

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

   +--------------+----------------------------------------------------+
   | Transform    | Purpose                                            |
   | Type         |                                                    |
   +--------------+----------------------------------------------------+
   | RESERVED     | Reserved for future use                            |
   | ICE-STUN-UDP | UDP encapsulated control and processes it
   accordingly to [I-D.ietf-hip-base].  It replies data traffic with     |
   |              | ICE-based connectivity tests using STUN messages   |
   +--------------+----------------------------------------------------+

                     Table 1: Locator Transformations

   In step 3, the Initiator sends an I2 packet that has includes a NAT_TRANSFORM
   parameter.  It contains the same transport locator as R1, but transform type selected by the source and
   destination ports are swapped. Initiator
   from the list of transforms offered by the Responder.  The I2 contains a LOCATOR parameter
   containing also
   includes the listing unreflexive, reflexive and leased transport locators of the Initiator

   In step 6, the relay receives the I2 packet.  The relay appends a
   RELAY_FROM and a RELAY_HMAC to the I2 packet as in the second step. a LOCATOR parameter.

   In step 7, 4, the Responder receives concludes the I2 packet and processes it
   according to [I-D.ietf-hip-base].  It replies base exchange with an R2 packet and
   packet.  The Responder includes a RELAY_TO LOCATOR parameter as in step three.  The RELAY_TO
   parameter is protected by the HMAC.

   In step 8, the relay processes the R2 as described in step four.  The
   relay forwards packet.

4.2.  ICE Procedure

   Hosts exchange HIP control packets through the packet to HIP Relay.
   Connectivity tests are, however, directly exchanged between the Responder.

3.4.  Base Exchange without a Relay

   A host that has a publicly addressable, fixed IP
   address MAY exclude
   registration pairs to determine operational address pairs.  If a Relay.  As working
   direct path between the Relay hosts is not present, found, also the host MUST
   listen at HIPPORT for transport-encapsulated HIP and ESP packets.  An
   UDP-encapsulated base exchange with such an host does not have the
   RELAY_TO and RELAY_FROM parameters present.  Connectivity tests MUST
   be handled as defined in the following section before any ESP control traffic
   is allowed.

3.5.  Connectivity Tests
   MAY start using it.

   The base exchange is completed with an R2 packet.  Then, the state of
   the HIP associations at both peers is ESTABLISHED, but the peers MUST
   NOT allow any ESP traffic until the connectivity tests described in
   the next section are performed
   successfully.  All of the locators, except the relay HIP Relay address, are
   in UNVERIFIED state.  In the connectivity tests, the hosts test
   connectivity between different locator pairs in order to find a
   working one.  The connectivity tests are illustrated in Figure 3. 4.  In
   this example, both hosts are behind NATs.

     I                            HIP Relay                          R
     | 2. R2(RELAY_TO) UDP(R2(LOCATOR,RELAY_TO))  | 1. R2(RELAY_TO) UDP(R2(LOCATOR,RELAY_TO))  |
     +<------------------------------+-------------------------------+
     |<------------------------------+-------------------------------|
     |                                                               |
     |           3. UPDATE(ECHO_REQUEST,FROM_PEER)    NAT-R:DROP|
     +------------------------------------------------------------->X|
     |                                                               |
     |                4. UPDATE(ECHO_REQUEST,FROM_PEER)              |
     |<--------------------------------------------------------------+
     |                                                               |
     |                5. UPDATE(ECHO_RESP,TO_PEER)                   |
     +-------------------------------------------------------------->+
     |                                                               |
     |                6. UPDATE(ECHO_REQUEST,FROM_PEER) Connectivity tests for address pairs             |
     +-------------------------------------------------------------->|
     |<------------------------------------------------------------->|
     |                                                               |
     |                7. UPDATE(ECHO_RESP,TO_PEER)           4. HIP UPDATE for preferred address pair            |
     |<--------------------------------------------------------------+
     |<------------------------------------------------------------->|
     |                                                               |

                       Figure 3: 4: Connectivity tests

   The connectivity tests are handled as the mobility extensions defined
   in [I-D.ietf-hip-mm] and are therefore subject to the same processing
   rules.  The packets include ESP_INFO, SEQ, ACK, HMAC, SIGNATURE
   parameters that are omitted in this section for simplicity.  The
   differences to the mobility extensions are described in this section.

   In steps 1 and 2, the R2 packet is relayed from the Responder through
   the Relay to the Responder.  After this, both hosts start Initiator.

   Afterwards, connectivity tests are started based on the procedure
   described in [I-D.rosenberg-mmusic-ice-nonsip] by using the return routability tests defined candiates
   previously exchanged in
   [I-D.ietf-hip-mm].  The return routability tests are used to probe
   for connectivity between each locator pair obtained from the local
   and peer locators obtained during HIP base exchange.  The return
   routability tests are also used as a UDP hole punching mechanism.
   The tests

4.3.  NAT Keep-alives

   Data channel keepalives are carried in certain order which determined by STUN Binding Indications.  Keepalives
   MUST be sent every 20 seconds at the
   priorization algorithm defined in minimum when the next section.

   As an example, let's consider the case where hosts are testing each
   others outermost NAT addresses, i.e., relay reflexive transport
   locators.  In step 3, host I sends an UPDATE message containing an
   ECHO_REQUEST to the R. This will punch channel is
   idle.  To implement failure tolerance, a hole the NAT of I, but the
   NAT of R drops the message because host SHOULD have smaller
   keepalive period.  When data traffic is exchanged between the NAT of R has end
   points then no state with I.

   In step 4, R starts also reachability detection by sending an UPDATE
   with ECHO_REQUEST.  This traverses the NAT of I successfully because
   Initiator had already punched an hole into its NAT in step 3.  The
   Responder replies using ECHO_RESPONSE in step further STUN keepalives need to be exchanged.

5.  Upon receiving the
   ECHO_RESPONSE, the Responder transitions  Packet Formats

   The following subsections define the address pair to VERIFIED
   state.

   In step 6, host I starts a new return routability test either due to
   a retransmission timer or as a reaction to UPDATE with ECHO_REQUEST
   received from R. In step 7, host R receives parameter and sends a response to
   I. Upon receiving the response, host R transitions the locator pair
   being tested to VERIFIED state. packet encodings.
   All locators in UNVERIFIED state MUST be retransmitted RTIME times.
   The retransmission packets values MUST be paced Ta ms apart as defined in
   [I-D.ietf-mmusic-ice].  The retransmission 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 are ordered encapsulated in a sequence
   determined by the priority UDP packets like in Section
   2.2 of [RFC3948], "rules for encapsulating IKE messages", except that
   a different port number is used.  Figure 5 shows the transport locator pairs, as
   described in the next section. encapsulation:
   UDP header is followed by 32 zero bits that can be used to
   differentiate HIP control packets from ESP packets.  The source address of HIP header
   and parameters follow the UPDATE messages containing ECHO_REQUEST
   parameter is always an unreflexive IPv4 locator conventions of [I-D.ietf-hip-base] with the host.  The
   destination locator is
   exception that the peer's unreflexive, reflexive or leased
   transport locator, depending on which address HIP header checksum MUST be zero.  The HIP header
   checksum is being tested zero for
   reachability.  Implementations may add RTT measurement information to two reasons.  First, the ECHO_REQUEST parameter in addition to a nonce.

   The UPDATE messages carrying ECHO_REQUEST include UDP header contains
   already a FROM_PEER
   parameter.  The sender of the UPDATE MUST copy the source address of checksum.  Second, the UPDATE to checksum definition in
   [I-D.ietf-hip-base] includes the FROM_PEER parameter.  When IP addresses in the peer receives checksum
   calculation.  The NATs unaware of HIP cannot recompute the
   UPDATE, it responds with an UPDATE containing and HIP
   checksum after changing IP addresses.

   A HIP Relay or a ECHO_REQUEST and
   TO_PEER parameters.  The TO_PEER parameter Responder without a relay MUST contain the source
   address of 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 the UPDATE redundantly.  The reason from same UDP
   header as the FROM_PEER and
   TO_PEER parameters is that it is possible to learn new addresses
   using them.  When HIP control packets but there is p2p-unfriendly NAT no non-ESP-marker
   between the peers, it
   may cause translate port number of the UPDATE packets to something
   that has not been communicated through UDP header and the relay before.  Such an
   addresses STUN header.  STUN messages are called "peer reflexive transport locators" in this
   document.  The FROM_PEER
   demultiplexed from ESP and TO_PEER parameters can be used for
   detecting peer reflexive locators.  The learned locators are added to
   the connectivity tests.

   UPDATE packets destined to the unreflexive locators are sent directly
   over IP.  UPDATE packets destined for reflexive peer, relay and
   leased locators are sent transport layer encapsulated.

   Hosts proceed sequentially through the locator pairs in the order
   described in the next section.  A host MUST transition the state of
   transport locator pairs verified by the return routability tests to
   the ACTIVE state.  Keepalive mechanisms described in later sections
   MUST be applied to refresh the port state in NAT devices for locators
   in the ACTIVE state.  A host MUST also set up the Security
   Associations for HIP control messages using the inbound ESP traffic for STUN
   markers, such locators.  The
   selection of a default outbound SA is defined in as the next section.

3.6.  Selecting an Address Pair

   This section describes priority ordering of connectivity tests magic cookie value.

5.3.  Relay and
   locators pair selection based on ICE [I-D.ietf-mmusic-ice].  As part
   of the priority calculation, each locator has a preference based on
   its type.  The values for these preferences are shown in Table 2.

            +-----------------------------------+------------+ 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Locator             Type              | Preference |
            +-----------------------------------+------------+
            | The preferred locator             | 127        |             Length            | Unreflexive locator
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 126                                                               |
     | Peer reflexive transport locator                            Address                            | 120
     |                                                               | Relay reflexive transport locator
     | 100                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Leased transport locator             Port              | 0           Transport           |
            +-----------------------------------+------------+

                     Table 2: Locator
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type Preferences

   In addition to the "type" priority, the priority of a locator is also
   affected        [ TBD by the "local" priority.  A (multihoming) host may have
   multiple locators of same type and SHOULD assign a unique local
   priority for each locator.  Hosts preferring IPv6 communication can
   assign higher local preferences for IPv6 locators than for
   unreflexive IPv4 locators.  ECHO_REQUEST parameters may include RTT
   calculation information that an implementation may use to increase
   the local priority.  A host SHOULD calculate locator priority based
   on the local and type priorities as shown in Figure 4.  The locator
   priority MUST always be included in the type 3 locator fields in
   LOCATOR parameters as described in section Section 4.4.

              Locator priority IANA:
                   RELAY_FROM: (63998 = (2^24) * (type preference) 2^16 - 2^11 +
                                 (2^8) * (local preference)

                        Figure 4: Locator priority
   A host SHOULD calculate a priority for each locator pair as shown in
   Figure 5.  I and R denote the priorities of locators of Initiator and
   Responder.  The use of the same formula at both ends gives more
   guarantees that the peers prefer shortest paths between them.  It
   also converges the selection of the locator pair towards a symmetric
   pair instead of an asymmetric pair even though it is not completely
   guaranteed.  The reasoning for the formula is described in
   [I-D.ietf-mmusic-ice].

      Pair priority 2^9 - 2)
                   RELAY_TO:   (64002 = 2^32 * MIN(I,R) 2^16 - 2^11 + 2 * MAX(I,R) 2^9 + (I > R ? 1 : 0)

                          Figure 5: Pair priority

   After reachability tests, both hosts SHOULD assign the transport 2)
                   REG_FROM: (64010 = 2^16 - 2^11 + 2^9 + 10) ]

     Length      20
     Address     An IPv6 address pair with the highest pair priority as their default outgoing
   SA for ESP.

3.7.  Mobility

   When one of the hosts changes its locators, it has to notify its
   peers of the or an IPv4 address change.  This is handled as described in the
   connectivity tests in Section 3.5 with the exception that the UPDATE
   with parameter LOCATOR "IPv4-compatible
                 IPv6 address" format
     Port        Transport port number; zero when plain IP is used as the trigger to start connectivity
   tests instead of
     Transport   Transport protocol type; zero for UDP

        Figure 6: Format for the R2.  The UPDATE packet contains a LOCATOR
   parameter listing unreflexive, reflexive RELAY_FROM,  RELAY_TO and leased transport
   locators REG_FROM
                                parameters

   Format of the Initiator.  This RELAY_FROM, RELAY_TO and REG_FROM parameters is illustrated shown
   in Figure 6.

     Mobile                         Relay                Corresponding
     Node                            |                            Node
     |                               |                               |
     |     1. UPDATE(LOCATOR)  Parameters are identical except for the type field.

5.4.  LOCATOR Parameter

   The generic LOCATOR parameter format is the same as in
   [I-D.ietf-hip-mm].  However, presenting ICE candidates requires a new
   locator type.  The generic and NAT traversal specific locator
   parameters are illustrated 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 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  2. UPDATE(LOCATOR,RELAY_TO)             Type              |
     +-------------------------------+------------------------------>|            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Traffic Type  |                3. UPDATE(ECHO_REQUEST,FROM_PEER)     NAT: DROP|
     +------------------------------------------------------------->X|  Locator Type | Locator Length|  Reserved   |P|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Locator Lifetime                        |                4. UPDATE(ECHO_REQUEST,FROM_PEER)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
     |<--------------------------------------------------------------+                            Locator                            |
     |                                                               |                5. UPDATE(ECHO_RESP,TO_PEER)
     |
     |-------------------------------------------------------------->|                                                               |
     |                                                               |                6. UPDATE(ECHO_REQUEST,FROM_PEER)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Traffic Type  |  Loc Type = 2 | Locator Length|  Reserved   |P|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Locator Lifetime                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |
     |<--------------------------------------------------------------|     Transport Port            |  Transp. Proto|     Kind      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                7. UPDATE(ECHO_RESP,TO_PEER)                           Priority                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              SPI                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Locator                            |
     |-------------------------------------------------------------->|
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 6: Handover

   When a mobile host moves from a private address realm to another, it
   can obtain 7: LOCATOR parameter

   The individual fields in the same locator on both networks.  To denote that 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 new locator requires reachability detection, the mobile host MUST use a
   new SPI for the new locator.

   A host can also use the UPDATE mechanism can also be used HIP signaling (1), for
   switching to a more optimal path after connectivity tests.  In the
   connectivity tests, the host may implement RTT measurements within
   ECHO_REQUEST and ECHO_RESPONSE messages.  In some cases the result of
   the RTT measurements may indicate that another locator pair is more
   optimal than the locator pair resulting from the connectivity and
   priority tests.  In such a case, the host MAY send UPDATE with
   LOCATOR parameter with the optimal  |
   | Type      |          | ESP (2), or for both (0)                   |
   | Locator   | 2        | "Transport address" locator with the preferred bit on.
   This gives type           |
   | Type      |          |                                            |
   | Locator   | 7        | Length of the highest priority Locator field in 4-octet     |
   | Length    |          | units                                      |
   | Reserved  | 0        | Reserved for the most optimal locator and will
   be future extensions             |
   | Preferred | 0        | Not used if the connectivity tests succeed.

3.8.  NAT Keepalives

   A NAT can delete the mapping state after a timeout when there is no
   traffic refreshing the state.  For this reason, both hosts MUST send
   keep-alives to each other for all locators pairs that are in the
   ACTIVE state.  Keepalives transport address locators;   |
   | (P) bit   |          | MUST be sent every 20 ignored by the receiver.           |
   | Locator   | Variable | Locator lifetime in seconds                |
   | Lifetime  |          |                                            |
   | Transport | Variable | Transport layer port number                |
   | Port      |          |                                            |
   | Transport | 0        | 0 for UDP.  The
   keepalive is a NOTIFY packet without parameters.

   The keep-alives MAY also be used to implement failure detection
   between end-hosts 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.oliva-hiprg-reap4hip] (XX FIXME: this
   needs still more details).  The basic idea is to keep track of HIP
   control and ESP packets received over a transport port.  When there
   is no HIP or ESP traffic (not even keep-alives) arriving during a
   certain time period, the host switches to an alternative locator
   pair.  The host transitions the default locator pair to the
   UNVERIFIED state and replaces the currently default SA to correspond
   to the ACTIVE locator pair with         |
   |           |          | [I-D.ietf-mmusic-ice]                      |
   | SPI       | Variable | SPI value which the highest priority.  The host may
   also try to send an UPDATE packet with the LOCATOR parameter after a
   certain time period if connectivity is still broken.

   End-host may also used the keep-alives expects to detect loss of connectivity
   with relay server.  When this occurs, the end-host can register to a
   new relay and replace the IP address of the old relay server with a
   new one in DNS or DHT.

3.9.  Closing of HIP Associations

   A host closes a HIP association as described see in [I-D.ietf-hip-base]
   except that the CLOSE and CLOSE_ACK |
   |           |          | incoming ESP packets are sent over transport
   layer and through the relay as illustrated in Figure 7.  Hosts MUST
   transition the corresponding that use this locator pairs to the DEPRECATED state
   after a successful CLOSE-CLOSE_ACK exchange.  The corresponding
   inbound and outbound SAs must be deleted on such occasion.

     I                            Relay                              R | 1. CLOSE
   | Locator   |
     +---------------------------->| 2. CLOSE Variable | IPv6 address or an "IPv4-compatible IPv6   |                             +-------------------------------->|
   |           |          | address" format IPv4 address [RFC3513],    |
   |                    3. CLOSE_ACK           |          |                4. CLOSE_ACK |<--------------------------------+
     |<----------------------------+ obfuscated by XORring it with the owner's  |
   |           |          |

                  Figure 7: Closing HIT                                        |
   +-----------+----------+--------------------------------------------+

                 Table 2: Fields of a HIP association

   The hosts may also use the CLOSE mechanism to remove redundant SAs
   remaining from the connectivity tests.  However, the removal can
   prolong LOCATOR parameter

5.5.  RELAY_HMAC

   The RELAY_HMAC parameter value has the recovery in TLV type 65520 (2^16 - 2^5 +
   2^4).  It has the event of connectivity failures.

3.10.  Communication with HIP Hosts without NAT Traversal Support same semantics as RVS_HMAC [I-D.ietf-hip-rvs].

5.6.  Registration Types

   The UDP encapsulation of HIP and ESP control packets has not been
   defined in any other IETF document REG_INFO, REQ_REQ, REG_RESP and legacy hosts drop all UDP
   encapsulated 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.

5.7.  HIP and ESP traffic.  Processing Data Packet Formats

   [RFC3948] describes UDP encapsulation of unknown locator
   types terminates the base exchange or UPDATE.  As such, IPsec ESP transport and
   tunnel mode.  On the
   extensions defined in this document are wire the HIP ESP packets do not completely backwards
   compatible differ from the
   transport mode ESP and require a minimal support in implementations.

   A minimal implementation MUST provide UDP thus the encapsulation of the HIP and ESP packets.  In such a case, packets
   is same as the minimal NAT traversal
   implementation MUST silently discard UDP encapsulation transport mode ESP.

   During the processing of type 3
   locators HIP base exchange, the two peers exchange parameters that
   enable them to allow communication with implementations supporting NAT
   traversal defined define a pair of IPsec ESP security associations
   (SAs), as described in this document.  The minimal implementation [I-D.ietf-hip-esp].  When two peers perform a
   UDP-encapsulated base exchange, they MUST
   support UDP keepalives to refresh state define a pair of the NAT(s).

   Hosts IPsec SAs
   that conform to [I-D.ietf-hip-mm] respond to UPDATE messages
   containing an ECHO_REQUEST with an UPDATE message containing an
   ECHO_RESPONSE.  This completes the connectivity tests for the host
   supporting the extensions produces UDP-encapsulated ESP data traffic.

   The management of encryption/authentication protocols and security
   parameter indices (SPIs) is defined in this document.  As long as the
   implementation supports [I-D.ietf-hip-esp].  The UDP
   encapsulation format and processing of HIP control packets,
   this requires no changes.

   The Relay extensions defined in this document do not work with
   minimalistic implementations.  When there ESP traffic is described
   in Section 6.1 of [I-D.ietf-hip-esp].

   Section 5.1 of [RFC3948] describes a Relay between security issue for the
   hosts, both UDP
   encapsulation in the Initiator standard IP tunnel mode when two hosts behind
   different NATs have the same private IP address and Responder MUST support initiate
   communication to the extensions
   defined same Responder in this document. the public Internet.  The presence of RELAY_TO and RELAY_FROM
   parameters denotes
   Responder cannot distinguish between two hosts, because security
   associations are based on the precence of a relay.

4.  Packet Formats same inner IP addresses.

   This section defines an UDP-encapsulation packet format for issue does not exist with the UDP encapsulation of HIP base
   exchange and control traffic, IPsec ESP BEET-mode traffic and NAT
   keep-alive packets.

4.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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                    HIP Header and Parameters                  ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 8: Format for UDP-encapsulated HIP control packets

   Figure 8 shows how HIP control packets
   transport format because the Responder use HITs to distinguish
   between different communication instances.

6.  Security Considerations

6.1.  Privacy Considerations

   The LOCATORs are encapsulated within UDP.
   A minimal UDP packet carries a complete HIP packet sent XORed format in its payload.

   Contents plain text in favour of
   inspection at HIP-aware middleboxes in the UDP source and destination ports are described below. future.  The UDP length and checksum field MUST current draft
   does not specify encrypted versions of LOCATORs even though it could
   be computed as described in
   [RFC0768].  The HIP header and parameter follow the conventions
   [I-D.ietf-hip-base] with the exception beneficial for privacy reasons.

   It is possible that the HIP header checksum
   MUST 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 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 zero.  The HIP header checksum 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 zero for two reasons.
   First, referred to as the UDP header contains already hairpin
   problem [I-D.ietf-behave-p2p-state].  With such a checksum.  Second, the
   checksum definition in [I-D.ietf-hip-base] includes legacy NAT, the IP addresses
   in
   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 checksum calculation. reflexive candidates.  Using only host
   candidates can produce suboptimal paths possibly causing congestion.

   The NATs unaware use of HIP cannot
   recompute the HIP checksum after changing IP addresses.

4.2.  Control Channel Keep-Alives

   The keep-alive Relays or TURN Relays can be useful for control channel are UDP encapsulated NOTIFY
   packets [I-D.ietf-hip-base].  The NOTIFY packets MAY contain protection
   against Denial-of-Service attacks.  If a Responder reveals only its
   HIP
   parameters.  The NAT traversal mechanisms encapsulate these NOTIFY
   packets within the payload of UDP packets.

4.3.  RELAY_FROM, RELAY_TO and RELAY_VIA 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              |             Padding           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type        [ TBD by IANA:
                   RELAY_FROM: (63998 = 2^16 - 2^11 + 2^9 - 2)
                   RELAY_TO:   (64002 = 2^16 - 2^11 + 2^9 + 2)
                   RELAY_VIA:  (64006 = 2^16 - 2^11 + 2^9 + 6) ]
     <!-- AG: those are ESP relay candidates to malign Initiators, the Initiators can
   only attack the relays that does not described?
                   TO_PEER:    (64010 = 2^16 - 2^11 + 2^9 + 10)
                   REG_FROM:   (64010 = 2^16 - 2^11 + 2^9 + 12) ]
     -->
     Length      18
     Address     An IPv6 address or an IPv4 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 HIP Relay
   is serving more than one Relay Clients and is willing to support
   opportunistic mode.  Otherwise, it cannot be guaranteed that 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 IPv4-in-IPv6
                 format.
     Port        Transport the "Dynamic and/or Private
   Port" and HIPPORT.  Upon publication of this document, IANA is
   requested to register a UDP port and the RFC editor is requested to
   change all occurrences of port HIPPORT to the port IANA has
   registered.  The HIPPORT number

       Figure 9: Format 50500 should be used for initial
   experimentation.

   This document updates the RELAY_FROM,  RELAY_TO and RELAY_VIA
                                parameters
   Figure 9 shows IANA Registry for HIP Parameter Types by
   assigning new HIP Parameter Type values for the format of new HIP Parameters:
   RELAY_FROM, RELAY_TO and RELAY_VIA
   parameters.

4.4.  LOCATOR Parameter

   The generic LOCATOR parameter format is the same as in
   [I-D.ietf-hip-mm].  However, presenting transport locators requires a
   new locator type.  The generic and NAT specific locator parameters
   are illustrated in Figure 10.

      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 10: Locator parameter

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

   +------------+----------+-------------------------------------------+
   | Field      | Value(s) | Purpose                                   |
   +------------+----------+-------------------------------------------+
   | Type       | 193      | Parameter type                            |
   | Length     | Variable | Length in octets, excluding Type and      |
   |            |          | Length fields, and excluding padding.     |
   | Traffic    | 0-2      | 2 for unreflexive and leased, 1 for relay |
   | Type       |          | reflexive                                 |
   | Locator    | 3        | Transport locator                         |
   | Type       |          |                                           |
   | Locator    | 19       | Length of the Locator field in 4-octet    |
   | Length     |          | units                                     |
   | Reserved   | 0        | Reserved for future extensions            |
   | Preferred  | 0        | Usually zero for type 3 locators          |
   | (P) bit    |          |                                           |
   | Locator    | Variable | Locator lifetime in seconds               |
   | Lifetime   |          |                                           |
   | Transport  | Variable | Zero for unreflexive and greater than     |
   | Port       |          | zero otherwise                            |
   | Transport  | 0        | Zero for UDP                              |
   | Protocol   |          |                                           |
   | Kind       | Variable | 0 for unreflexive, 1 for relay reflexive, |
   |            |          | 2 for leased                              |
   | Priority   | Variable | Locator preference, see Section 3.6       |
   | SPI        | Variable | 0 for relay reflexive, otherwise greater  |
   |            |          | than zero                                 |
   | Locator    | Variable | An IPv6 address or an IPv4-in-IPv6 format |
   |            |          | IPv4 address[RFC2373]                     |
   +------------+----------+-------------------------------------------+

                 Table 3: Fields of the locator parameter

4.5.  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 [I-D.ietf-hip-rvs].

4.6.  Registration Types

   The REG_INFO, REQ_REQ, REG_RESP and REG_FAILED parameters contains
   values for relay registration.  The value for RELAY_UDP_HIP is 2.
   The value for RELAY_UDP_ESP is 3.

4.7.  ESP Data 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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~                          ESP Header                           ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 11: Format for UDP-encapsulated IPsec ESP BEET-mode traffic

   Figure 11 shows how IPsec ESP BEET-mode packets are encapsulated
   within UDP.  Again, a minimal UDP packet carries the ESP packet in
   its payload.  The contents of the UDP source and destination ports
   are described in later sections.  The UDP length and checksum field
   MUST be computed as described in [RFC0768].

4.8.  UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP

   [RFC3948] describes UDP encapsulation of the IPsec ESP transport and
   tunnel mode.  This section describes the UDP encapsulation of the
   BEET mode.

4.8.1.  UDP Encapsulation of IPsec BEET-Mode ESP

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

   The management of encryption/authentication protocols and security
   parameter indices (SPIs) is defined in [I-D.ietf-hip-esp].
   Additional SA parameters, such as IP addresses and UDP ports, MUST be
   defined according to this section.  Two SAs MUST be defined on each
   host for one HIP association; one for outgoing data and another one
   for incoming data.

   The BEET mode provides limited tunnel mode semantics without the
   regular tunnel mode overhead [I-D.nikander-esp-beet-mode].  In the
   BEET mode, transport-layer checksums in the payload data are based on
   the HITs.  The packet MUST then undergo BEET-mode ESP cryptographic
   processing as defined in Section 5.3 of [I-D.nikander-esp-beet-mode].

   Next, the resulting BEET-mode packet is UDP encapsulated.  For this
   purpose, a UDP header MUST be inserted between the IP and ESP header.
   The source and destination ports are filled in.  The UDP checksum
   MUST be calculated based on the outer addresses (locators) of the
   IPsec security association.  The other fields of the UDP header are
   computed as described in [RFC0768].

   The resulting UDP packet MUST then undergo BEET IP header processing
   as defined in Section 5.4 of [I-D.nikander-esp-beet-mode].

   Figure 12 illustrates the BEET-mode UDP encapsulation procedure for a
   TCP packet.

     ORIGINAL TCP PACKET:
        +------------------------------------------+
        | inner IPv6 hdr |  ext hdrs  |     |      |
        |   with HITs    | if present | TCP | Data |
        +------------------------------------------+

     PACKET AFTER BEET-MODE ESP PROCESSING:
        +----------------------------------------------------------+
        | inner IPv6 hdr | ESP | dest |     |      |  ESP    | ESP |
        |   with HITs    | hdr | opts.| TCP | Data | Trailer | ICV |
        +----------------------------------------------------------+
                               |<------- encryption -------->|
                         |<----------- integrity ----------->|

     FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING:
        +------------------------------------------------------------+
        | outer IPv4 | UDP | ESP | dest |     |      |  ESP    | ESP |
        |    hdr     | hdr | hdr | opts.| TCP | Data | Trailer | ICV |
        +------------------------------------------------------------+
                                 |<------- encryption -------->|
                           |<----------- integrity ----------->|

      Figure 12: UDP encapsulation of an IPsec  BEET-mode ESP packet
                         containing a TCP segment

4.8.2.  UDP Decapsulation of IPsec BEET-Mode ESP

   An incoming UDP-encapsulated IPsec BEET-mode ESP packet is
   decapsulated as follows.  First, if the UDP checksum is invalid, then
   the packet MUST be dropped.  Then, the packet MUST be verified as
   defined in [I-D.nikander-esp-beet-mode].  If verified, the ESP data
   contained in the payload of the UDP packet MUST be decrypted as
   described in [I-D.nikander-esp-beet-mode].

5.  Firewall Traversal

   This section describes firewall traversal issues separately from NAT
   issues.  When the Initiator or the Responder of a HIP association is
   behind a firewall, additional issues arise.

   The NAT traversal mechanisms described in Section 3 require that the
   firewall - stateful or not - allows UDP traffic.  At the minimum,
   successful firewall control packet traversal requires that the host
   behind the firewall is allowed to communicate packets with a HIP
   relay (or a Responder without Relay) that is listening on UDP port
   HIPPORT.  Successful ESP data packet traversal requires the same for
   the ESP relay.  For unrelayed traffic, the destination 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 has initiated UDP communication
   to the public Internet, the firewall relays UDP response traffic in
   the return direction.  If no such return traffic arrives for a
   specific period of time, the firewall stops relaying the given IP
   address and port pair.  The mechanisms described in Section 3 already
   enable traversal of such firewalls, if the keep-alive interval used
   is less than the refresh interval of the firewall.

   When the Initiator is behind a firewall, the NAT traversal mechanisms
   described in Section 3 depend on the ability to initiate
   communication via UDP to the destination port HIPPORT from arbitrary
   source ports and to receive UDP response traffic from that port to
   the chosen source port.  If the Initiator is behind a firewall that
   does not support "UDP connection tracking", the NAT traversal
   mechanisms described in Section 3 can still be supported, if the
   firewall allows permanently inbound UDP traffic from the port HIPPORT
   and destined to arbitrary source IP addresses and UDP ports.

   When the Responder is behind a firewall, the NAT traversal mechanisms
   described in Section 3 depend on the ability to send and receive UDP
   traffic originating from HIPPORT of the HIP and ESP relays.  When
   unrelayed traffic is preferred, arbitrary source IP addresses and
   ports are required.

6.  Security Considerations

6.1.  A Difference to RFC3948

   Section 5.1 of [RFC3948] 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, because security
   associations are based on the same inner IP addresses.

   This issue does not exist with the UDP encapsulation of IPsec BEET
   mode as described in Section 3, because the Responder use HITs to
   distinguish between different communication instances.

6.2.  Privacy Considerations

   The LOCATORs are sent in plain text.  Alternatively, they could be
   encrypted.  This option was not chosen to allow packet inspection by
   middleboxes.  Plain text locators may be useful for HIP-aware
   middleboxes in the future.

   It 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 the private address realm and it
   discards unreflexive locators.  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 [I-D.ietf-behave-p2p-state].  With such a legacy NAT,
   the only option left would be to use a leased transport locator from
   a relay.  As a consequence, a host may support locator-based privacy
   by leaving out the reflexive locators.  Using only unreflexive
   locators can produce suboptimal paths possibly causing congestion.

   The use of relays can be useful for protection against Denial-of-
   Service attacks.  If a Responder reveals only its HIP and ESP relay
   addresses to malign 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.

6.3.  Opportunistic Mode

   The use of opportunistic HIP is NOT RECOMMENDED and its use is not
   defined in this document.  In opportunistic HIP, the Initiator sends
   the I1 message with null destination HIT.  Private address realms do
   not have unique addresses by definition.  Therefore, opportunistic
   mode is subject to failure even when there are no attackers present.
   In a normal HIP base exchange, a well-behaving Responder drops the I1
   packet when the destination HIT does not belong to it.  An attacker
   could respond to the I1, but the base exchange would eventually fail
   as the attacker would fail to prove its ownership of the destination
   HIT of the I1.

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" and HIPPORT.  Upon publication of this document, IANA is
   requested to register a UDP port and the RFC editor is requested to
   change all occurrences of port HIPPORT to the port IANA has
   registered.  The HIPPORT number 50500 should be used for initial
   experimentation.

   This document updates the IANA Registry for HIP Parameters Types by
   assigning new HIP Parameter Types values for the new HIP Parameters
   defined in Section 4: o RELAY_FROM (defined in Section 4.3) o
   RELAY_TO (defined in Section 4.3) o RELAY_VIA REG_FROM (defined in Section
   4.3) o 5.3) and
   RELAY_HMAC (defined in Section 4.5) 5.5).

8.  Acknowlegements

   The authors would like to thank  Contributors

   Marcelo Bagnulo, Jan Melen, Simon Schuetz, Martin Stiemerling, Lars
   Eggert, Vivien Schmitt, Abhinav Pathak and Andrei Gurtov for their contributions have
   contributed to previous the initial versions of this draft.  Thanks for Philip Matthews on introducing ICE
   concepts to the authors and for proposing the initial design.

9.  Acknowlegements

   Thanks for Jonathan Rosenberg and the rest of the MMUSIC WG folks for
   the excellent work on ICE.  In addition, the authors would like 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 and Tschofenig,
   Jan Melen, Jani Hautakorpi for and Ari Keraenen For their comments on
   this document.

   [I-D.nikander-hip-path] presented some initial ideas for NAT
   traversal of HIP communication.  The idea was based on NAT detection
   using extra parameters in the base exchange.  This document takes a
   different approach based on ICE.

   Simon Schuetz and Martin Stiemerling are partly funded by Ambient
   Networks, a research project supported by the European Commission
   under its Sixth Framework Program.  The views and conclusions
   contained herein are those of the authors and should not be
   interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the Ambient Networks
   project or the European Commission.

   Miika Komu is working in the Networking Research group at Helsinki
   Institute for Information Technology (HIIT).  The InfraHIP project
   was funded by Tekes, Telia-Sonera, Elisa, Nokia, the Finnish Defence
   Forces
   Forces, and Ericsson.  Miika Komu wrote draft-ietf-hip-nat-02 version
   from scratch based on ICE-related comments from Philip Matthews.

9. Ericsson and Birdstep.

10.  References

9.1.

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-08 draft-ietf-hip-base-10 (work in
              progress), June October 2007.

   [I-D.ietf-hip-esp]
              Jokela, P., "Using ESP transport 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 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 in
              progress), June 2006.

   [I-D.ietf-hip-rvs]
              Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
              Rendezvous Extension", draft-ietf-hip-rvs-05
              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 in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

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

   [RFC4423]  Moskowitz, R. 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., and D. Kegel, "State of Peer-to-
              Peer(P2P) Communication Across Network Address
              Translators(NATs)", draft-ietf-behave-p2p-state-06 (work
              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 in progress), June 2006.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for March 2007.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT)
              Traversal Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.

              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, January 2005.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-16 (work in progress), June Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [I-D.nikander-esp-beet-mode]
              Melen, J.

Appendix A.  Firewall Traversal

   This section describes firewall traversal issues separately from NAT
   issues.  When the Initiator or the Responder of a HIP association is
   behind a firewall, additional issues arise.  The firewall discussion
   applies both to IPv4 and P. Nikander, "A Bound End-to-End Tunnel
              (BEET) mode for ESP", draft-nikander-esp-beet-mode-07
              (work IPv6 addressing.

   The NAT traversal mechanisms described in progress), February 2007.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC2119]  Bradner, S., "Key words this document require that
   the firewall - stateful or not - allows UDP traffic.  At the minimum,
   successful firewall control packet traversal requires that the host
   behind the firewall is allowed to communicate packets with a HIP
   Relay (or a Responder without HIP Relay) that is listening on UDP
   port HIPPORT.  Successful ESP data packet traversal requires the same
   for use the TURN server.  For unrelayed traffic, the destination 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 has initiated UDP communication
   to the public Internet, the firewall accepts UDP response traffic in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2373]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 2373, July 1998.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines
   the return direction.  If no such return traffic arrives for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

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

9.2.  Informative References

   [I-D.ietf-behave-p2p-state]
              Srisuresh, P., "State a
   specific period of Peer-to-Peer(P2P) Communication
              Across Network Address  Translators(NATs)",
              draft-ietf-behave-p2p-state-03 (work in progress),
              July 2007.

   [I-D.irtf-hiprg-nat]
              Stiemerling, M., "NAT time, the firewall stops accepting the given IP
   address and Firewall Traversal Issues of
              Host Identity Protocol (HIP)  Communication",
              draft-irtf-hiprg-nat-04 (work in progress), March 2007.

   [I-D.nikander-hip-path]
              Nikander, P., "Preferred Alternatives for Tunnelling HIP
              (PATH)", draft-nikander-hip-path-01 (work port pair.  The mechanisms described in progress),
              March 2006.

   [I-D.oliva-hiprg-reap4hip]
              Oliva, A. and M. Bagnulo, "Fault tolerance configurations
              for HIP multihoming", draft-oliva-hiprg-reap4hip-00 (work this document
   already enable traversal of such firewalls, if the keep-alive
   interval used is less than the refresh interval of the firewall.

   When the Initiator is behind a firewall, the NAT traversal mechanisms
   described in progress), July 2007.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., this document depend on the ability to initiate
   communication via UDP to the destination port HIPPORT from arbitrary
   source ports and M.
              Stenberg, to receive UDP response traffic from that port to
   the chosen source port.  If the Initiator is behind a firewall that
   does not support "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, January 2005.

   [RFC4787]  Audet, F. connection tracking", the NAT traversal
   mechanisms described in this document can still be supported, if the
   firewall allows permanently inbound UDP traffic from the port HIPPORT
   and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

Appendix A.  Differences destined to ICE

   The protocol extensions defined arbitrary source IP addresses and UDP ports.

   When the Responder is behind a firewall, the NAT traversal mechanisms
   described in this draft are based document depend on ICE.  The
   extensions are a rough translation of ICE concepts the ability to send and receive
   UDP traffic originating from HIPPORT of the HIP protocol.
   The translation preserved certain concepts as they are, but there Relays and TURN
   servers.  When end-to-end traffic is preferred, arbitrary source IP
   addresses and ports are
   subtle differences.  This section tries to explain how required.

Appendix B.  Base Exchange without ICE Connectivity Checks

   In certain network environments, the ICE concepts
   were mapped connectivity tests can be
   omitted to HIP protocol and what 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 differences.

   The terminology for this draft is Responder should
   have a hybrid of ICE and HIP
   terminology.  "Agent" was translated to "host" long-term, fixed locator in favour of the network.  Second, the
   Responder should not have a HIP
   terminology.  Transport address was changed Relay configured for itself.  Third,
   the Initiator can reach the Responder by simply UDP encapsulating HIP
   and ESP packets to transport locator.
   Similarly, address pair the host.  Detecting and configuring this
   particular scenario is denoted as locator pair.  This document
   does not really talk about "candidate addresses", but just "locators"
   which may or may not be verified using prone administrative failure unless carefully
   planned.

   In such a scenario, the return routability tests,
   in favour of mobility terminology in [I-D.ietf-hip-mm].  Host
   candidate of ICE became unreflexive locator, server reflexive
   candidate was mapped to relay reflexive transport locator, peer
   reflexive candidate was mapped Initiator sends an I1 packet over UDP to peer reflexive locator and relayed
   candidate became leased transport locator. the
   Responder.  The component, base and foundation terms are Responder replies with a R1 packet that does not used in
   contain the document transform parameter as there is only a single "media stream" for all (ESP) traffic
   between two hosts.

   There is no "lite" version ICE explained in this document, just full, as Section 4.1.  The
   Initiator receives the
   full version is R1 packet and determines from the preferred one also for ICE.  One specific
   scenario defined in this document has some resemblance to absence of
   the lite
   ICE.  When a Responder is a publicly accessible server transform and RELAY_TO parameters that ICE connectivity tests can
   be omitted with fixed
   address, it may exclude the use Responder.  Finally, the hosts set up IPsec
   security associations using the locators observed from the concluding
   I2 and R2 packets of the relay.  In that case, it does base exchange without ICE connectivity
   tests.

Appendix C.  IPv4-IPv6 Interoperability

   Currently Relay Client and Server do not have to handle run any ICE
   connectivity tests as described in Appendix B.  However, it could be
   useful for IPv4-IPv6 interoperability when the RELAY parameters but still has to respond to Relay Server actually
   includes both the connectivity checks.

   A connectivity check NAT transform parameter and multiple locators in
   R2.  The interoperability benefit is not a STUN Binding Request.  Instead, it 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
   return routability check as defined underspecified in [I-D.ietf-hip-mm].  "Triggered
   check" occurs when 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.  Base Exchange through a host receives Rendezvous Server

   This section describes handling for a UPDATE with ECHO_REQUEST scenario where Initiator looks
   up the information of the Responder from DNS and it
   responds using discovers a RVS
   record [I-D.ietf-hip-rvs].  In such a ECHO_RESPONSE and sends case, the Initiator uses its
   own ECHO_REQUEST.  A
   "check list" is effectively a LOCATOR parameter as defined in
   [I-D.ietf-hip-mm].  The term "ordinary check" is not really used in
   this document as it HIP packets are retransmitted periodically when
   the LOCATORs are in UNVERIFIED state.  "Valid list" corresponds Relay to forward HIP traffic to
   locator pairs that have been verified successfully by the return
   routability tests. Rendezvous server.  The peers trigger
   Initiator will send the connectivity checks after I1 message using the base exchange or
   after a base exchange.  The conclusion of its HIP Relay server
   which will then forward it to the connectivity checks,
   i.e., selection RVS server of the final address pair, differs the most as a
   result of fitting responder.  The
   responder will send the ICE nomination algorithm R1 packet directly to the Initiator's HIP mobility
   mechanisms.  There is no "controlling agent"
   Relay server and the end-hosts make a
   local decision on which locator pair to choose.  This could lead to
   asymmetric address pairs, but following I2 and R2 packets are also sent
   directly using the priority algorithm guarantees that Relay.

   In case the address pairs converge.  Also, there Initiator is not able to distinguish which records are no aggressive
   RVS address records and
   regular nomination modes as a consequence of which are Responders address records, then
   the lack of controlling
   agent.

   ICE uses TLS, usernames Initiator SHOULD first try to contact the Responder directly and passwords as security mechanisms.  HIP
   has built-in security mechanisms that preferred over
   if none of the ones that
   are used addresses is reachable it MAY try out them using its
   own HIP Relay as described in ICE. the above.

Appendix B. E.  Document Revision History

   To be removed upon publication

   +------------+------------------------------------------------------+

   +-----------------------------+-------------------------------------+
   | Revision                    | Comments                            |
   +------------+------------------------------------------------------+
   +-----------------------------+-------------------------------------+
   | schmitt-00 draft-ietf-nat-traversal-00 | Initial version.                    |
   | ietf-00    | Officially adopted as WG item. Solved issues         |
   | draft-ietf-nat-traversal-01 | 1-9,11,12 Draft based on RVS.                 |
   | ietf-01 draft-ietf-nat-traversal-02 | Solved remaining issues except that relaying ESP Draft based on Relay proxies and    |
   |                             | mobility were still incomplete. ICE concepts.                       |
   | ietf-02 draft-ietf-nat-traversal-03 | Miika rewrote almost from scratch Draft based on ICE.      |
   |            | Editorial corrections from Simon and Andrei. STUN/ICE formats.    |
   +------------+------------------------------------------------------+
   +-----------------------------+-------------------------------------+

Authors' Addresses

   Miika Komu (editor)
   Helsinki Institute for Information Technology
   Metsanneidonkuja 4
   Espoo
   Finland

   Phone: +358503841531
   Fax:   +35896949768
   Email: miika@iki.fi
   URI:   http://www.hiit.fi/
   Simon Schuetz
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany
   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: +49 6221 4342 165
   Fax:   +49 6221 4342 155 +1 613 592 4343 224
   Email: philip_matthews@magma.ca

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: simon.schuetz@netlab.nec.de Hannes.Tschofenig@gmx.net
   URI:   http://www.netlab.nec.de/

   Martin Stiemerling
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany   http://www.tschofenig.com

   Ari Keraenen
   Ericsson Research Nomadiclab
   Hirsalantie 11
   02420 Jorvas
   Finland

   Phone: +49 6221 4342 113
   Fax:   +49 6221 4342 155 +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: stiemerling@netlab.nec.de marcelo@it.uc3m.es
   URI:   http://www.netlab.nec.de/   http://www.it.uc3m.es/

Full Copyright Statement

   Copyright (C) The IETF Trust (2007). (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).