HIP Working Group                                           M. Komu, Ed.
Internet-Draft                                                      HIIT
Intended status: Standards Track Experimental                                 S. Schuetz
Expires: September 6, 2007 January 7, 2008                                  M. Stiemerling
                                                                     NEC
                                                               L. Eggert
                                                                   Nokia
                                                               A. Pathak
                                                              IIT Kanpur
                                                           March 5,
                                                            July 6, 2007

    HIP Extensions for the Traversal of Network Address Translators
                    draft-ietf-hip-nat-traversal-01
                    draft-ietf-hip-nat-traversal-02

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 September 6, 2007. January 7, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document specifies extensions to

   The Host Identity Protocol (HIP) to
   support traversal of Network Address Translator (NAT) middleboxes.

   The traversal mechanism tunnels provides a new namespace that can be
   used for uniquely identifying hosts in public and also in private
   address realms.  Usually, HIP control and data traffic over UDP
   and enables cannot
   traverse Network Address Translators (NATs), that hinders general
   deployment.  This document specifies NAT traversal extensions for
   HIP.  As HIP initiators which MAY be behind NATs is located between network and transport layer, the
   extensions also provide general-purpose NAT traversal support for all
   high-layer networking applications that run over HIP.  The basic
   design concepts for these extensions have been adopted from the
   Interactive Connectivity Establishment (ICE) protocol to contact HIP
   responders which MAY be behind another NAT. HIP.  Using
   the specified extensions, two HIP-capable hosts are able to
   communicate with each other even when they are in different private
   address realms.

Table of Contents

   1.  Introduction  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Detecting NATs  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4 .  3
   3.  HIP Across NATs  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Packet Formats .  Port Number Selection  . . . . . . . . . . . . . . . . . .  6
     3.2.  Relay Registration and NAT Detection . . .  5
       3.1.1.  Control Traffic . . . . . . . .  6
     3.3.  Base Exchange via Relay  . . . . . . . . . . .  6
       3.1.2.  Control Channel Keep-Alives . . . . . .  8
     3.4.  Base Exchange without a Relay  . . . . . . .  6
       3.1.3.  Data Traffic . . . . . . . 10
     3.5.  Connectivity Tests . . . . . . . . . . . . . .  6
       3.1.4.  FROM_NAT Parameter . . . . . . 11
     3.6.  Selecting an Address Pair  . . . . . . . . . . . .  7
       3.1.5.  VIA_RVS_NAT Parameter . . . . 13
     3.7.  Mobility . . . . . . . . . . . .  8
     3.2.  UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . .  8
       3.2.1.  UDP Encapsulation of IPsec BEET-Mode ESP . . . . . . .  8
       3.2.2.  UDP Decapsulation of IPsec BEET-Mode ESP . . . . 14
     3.8.  NAT Keepalives . . . 10
     3.3.  Initiator Behind NAT . . . . . . . . . . . . . . . . . . . 10
       3.3.1.  NAT Traversal 15
     3.9.  Closing of HIP Control Traffic Associations  . . . . . . . . . 11
       3.3.2. . . . . . . 16
     3.10. Communication with HIP Hosts without NAT Traversal of HIP Data Traffic
           Support  . . . . . . . . . . 13
       3.3.3.  Use of the Rendezvous Service when only the
               Initiator is Behind NAT . . . . . . . . . . . . . . . 15
     3.4.  Responder Behind NAT 16
   4.  Packet Formats . . . . . . . . . . . . . . . . . . . . 17
       3.4.1.  Rendezvous Client Registration From Behind NAT . . . . 17
       3.4.2.  NAT Traversal of
     4.1.  HIP Control Traffic Packets  . . . . . . . . . 18
       3.4.3.  NAT Traversal of HIP Data Traffic . . . . . . . . . . 20
     3.5.  Both Hosts Behind NAT 17
     4.2.  Control Channel Keep-Alives  . . . . . . . . . . . . . . . 18
     4.3.  RELAY_FROM, RELAY_TO and RELAY_VIA Parameters  . . . 22
       3.5.1.  NAT Traversal of HIP Control Traffic . . . 18
     4.4.  LOCATOR Parameter  . . . . . . 22
       3.5.2.  NAT Traversal of HIP Data Traffic . . . . . . . . . . 25
     3.6.  NAT Keep-Alives . . . . 19
     4.5.  RELAY_HMAC . . . . . . . . . . . . . . . . . 26
     3.7.  HIP Mobility . . . . . . . 20
     4.6.  Registration Types . . . . . . . . . . . . . . . . . 27
     3.8.  HIP Multihoming . . . 20
     4.7.  ESP Data Packets . . . . . . . . . . . . . . . . . . . 29
     3.9. . . 21
     4.8.  UDP Encapsulation/Decapsulation of IPsec BEET-Mode ESP . . 21
   5.  Firewall Traversal . . . . . . . . . . . . . . . . . . . . 29
   4. . . 23
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 30
     4.1. 23
     6.1.  A Difference to RFC3948  . . . . . . . . . . . . . . . . . 30
     4.2.  Rendezvous and Responder 23
     6.2.  Privacy Considerations . . . . . . . . . . . . . 30
   5. . . . . . 24
     6.3.  Opportunistic Mode . . . . . . . . . . . . . . . . . . . . 24
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 30
   6.  Acknowledgements 25
   8.  Acknowlegements  . . . . . . . . . . . . . . . . . . . . . . . 30
   7. 25
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     7.1. 26
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 31
     7.2. 26
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 32 27
   Appendix A.  Differences to ICE  . . . . . . . . . . . . . . . . . 28
   Appendix B.  Document Revision History . . . . . . . . . . . . . . 33 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 35 31

1.  Terminology

   In general, this document borrows the terminology from
   [I-D.ietf-hip-base] and [RFC4423].  Additional terms are defined in
   the table below."  These draft e.g. define "Initiator" and
   "Responder"

   +---------------------+---------------------------------------------+
   | Term                | Explanation                                 |
   +---------------------+---------------------------------------------+
   | Rendezvous server   | A host that forwards I1 packets to the      |
   |                     | Responder                                   |
   | HIP Relay           | A host that forwards all HIP control        |
   |                     | packets between an Initiator and Responder  |
   | 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 a new
   namespace and protocol layer between the network and transport layers
   that decouples the identifier and locator roles to support e.g. mobility
   and multihoming in the Internet architecture.  HIP also secures
   application layer communications using IPsec ESP [I-D.ietf-hip-esp].

   The HIP protocol [I-D.ietf-hip-base] cannot operate across Network
   Address Translator (NAT) middleboxes, legacy NAT
   middleboxes as described in [I-D.irtf-hiprg-nat].  This document
   specifies how mechanisms that allow HIP can to traverse through legacy such NAT
   middleboxes that are not aware neither HIP-aware nor ESP-aware, without manual
   configuration of the NAT middleboxes.

   HIP or ESP.  The
   mechanisms defined in this document do not assume introduces a new namespace for hosts that decouples the NAT
   middleboxes identity
   of a host from its location [RFC4423].  The namespace consists of
   Host Identifiers which are reconfigured, as long as they allow UDP traffic. public keys.  The use hosts create the
   corresponding private keys by themselves which makes identity theft
   more difficult.

   The new namespace of HIP in NAT traversal has also some additional benefits
   provided by when the new namespace.
   extensions defined in this document are used.  First, it is possible
   to address hosts behind a single NAT middlebox in a relatively simple
   way.  The NAT middlebox translates the locators, but the Host
   Identifiers and
   ESP SPIs remain the same. same and can be used for uniquely identifying
   a host inside the private address realm.  Second, multiple services
   on different hosts can share the same transport layer port number
   behind a single legacy NAT.  There is no multiplexing issue as long
   as these services hosts have different Host
   Identifiers. Identifiers and UDP encapsulation
   is used for traversing the legacy NAT.

   Several different flavors types of NATs exist [RFC2663].  This document
   describes HIP extensions for the traversal of both Network Address
   Translator (NAT) and Network Address and Port Translator (NAPT)
   middleboxes.  It  The document generally uses the term NAT to refer to
   both types of middleboxes, unless it needs to distinguish between the
   two types.

   Three basic cases scenarios exist for NAT traversal.  In the first case,
   only the initiator Initiator of a HIP base exchange is located behind a NAT.
   In the second case, only the responder Responder of a HIP base exchange is
   located behind a NAT.  The respective peer host is assumed to be located
   at a publicly reachable address in both cases.  In the third case,
   both
   parties peers are located behind (different) (possible different) NATs.  This document describes
   extensions for  All of the first case
   use cases are addressed in Section 3.3, for the second case draft in
   Section 3.4 a unified method that has
   been adopted from Interactive Connectivity Establishment (ICE)
   protocol [I-D.ietf-mmusic-ice] and in Section 3.5 for adapted to HIP.

   Legacy NAT devices do not operate consistently although the third case. behavior
   for new NAT devices has been unified in [RFC4787].  The mechanisms described here also cover use HIP protocol
   extensions in this document make as little assumptions as possible of
   the behavior of rendezvous server
   from NATted environments.  The rendezvous server MUST be used when the responder is behind a NAT because otherwise successful devices so that NAT traversal cannot be guaranteed.  The rendezvous server MUST be
   located in a publicly addressable location.  Cascading of multiple will work even
   with legacy NAT enabled rendezvous servers is not possible, although there may be
   other kind of rendezvous servers on devices in the path. most general sense.  The NAT middleboxes
   MUST support address independent mapping in purpose of
   the case where extensions is to allow two HIP-enabled hosts to communicate with
   each other even if one or both communicating hosts are behind NAT devices.  Otherwise, in private
   address realms.  With some other external relaying
   mechanism MUST be used.  Endpoint independent filtering legacy NAT devices, connecting two hosts
   behind different address realms is not
   required in any impossible without relaying all
   traffic through a third party host [I-D.ietf-behave-p2p-state].  As a
   consequence, the relay host introduces additional hops between the
   hosts and can become a point of network congestion.  In the cases.  The NAT categories are defined in
   [I-D.srisuresh-behave-p2p-state].

   The mechanisms
   extensions described in this document are based on encapsulating
   both document, the control and data traffic in UDP in order to traverse NAT(s).
   The data traffic is assumed peers try to be ESP.  Other types avoid the use
   of a relay for data traffic
   are out and only make use of scope for it when necessary.

   Hosts that always get a public 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.  The responder listens at a fixed
   UDP port number for incoming  Both rendezvous and relay
   services forward HIP control packets.  The port number
   can be manually configured to packets, but the NAT to allow passing incoming
   traffic main difference is that
   the rendezvous service forwards only the initial I1 packet of the
   base exchange while all other HIP control packets are sent directly to
   between the host behind communicating hosts.  In contrast, the relay service
   relays all HIP control packets because p2p-unfriendly NAT (port forwarding). devices
   drop the packets otherwise [I-D.ietf-behave-p2p-state].  The
   benefit of such peers
   use the control channel to communicate their current locators to each
   other to find a configuration is that it does not require any
   rendezvous server direct path for carrying ESP encapsulated data
   traffic.  A direct path between the host behind the NAT.  Although this
   document does not prevent such configurations, it is out hosts enables efficient delivery
   of scope
   because data traffic without relaying of two drawbacks.  First, it allows only a single responder
   behind the NAT box.  Second, manual configuration ESP packets through several NAT
   devices may be difficult or administratively prohibited. an
   intermediary ESP relay.  The mobility and multihoming mechanisms of HIP [I-D.ietf-hip-mm],
   allow HIP direct path is searched using
   connectivity tests.

   The basis for the connectivity tests is ICE [I-D.ietf-mmusic-ice].
   Two hosts communicate their transport locator (a port and an IP
   address) to change network location during the lifetime of each other in a
   HIP association.  Consequently, hosts need base exchange.  The local locators are
   paired with peer locators and the pairs are prioritized according to start
   their proximity.  The locator pairs are tested sequentially in
   priority order using return routability tests [I-D.ietf-hip-mm].
   Both sides participate in the
   proposed NAT traversal mechanisms after connectivity tests.  The tests also
   determine whether transport layer encapsulation is required or not.
   As a mobility event relocates
   one result, the hosts either detect that no transport locator pairs
   are working, or both peers behind establish a NAT.  They may number of working locator pairs and
   select a single pair to be used for communication.

   The same connectivity tests are also stop using the
   proposed mechanisms if they both move used in situations when a mobile
   host moves to publicly addressable
   locations. a different network.  The mobile host communicates its
   new location to the corresponding node through the relay server of
   its peer and starts the connectivity tests.

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

2.  Detecting

3.  HIP Across NATs

   In order to know whether to use the

   This section describes NAT traversal mechanisms, between two HIP
   hosts need to detect the presence and type of NAT middleboxes along
   the path to their peer hosts.  This document does not describe any
   new end-hosts.  A
   successful NAT detection mechanism but rather assumes that traversal requires at least the NAT is
   detected using some external mechanism.  Hence, no special HIP
   parameters are required Responder located in HIP control messages to detect NATs.  The
   NAT detection MUST occur prior to a base exchange, after node
   movement and prior
   private address realm to register to sending UPDATE messages.

   For example, STUN [RFC3489] offers a generic mechanism for detecting
   both the presence and type relay server.  The use of a NAT.  In STUN, the host contacts a
   STUN server that
   relay is optional when the Responder is always located at in a publicly reachable address. public address
   realm without rendezvous server.

   The STUN server replies back and provides information on the NAT
   presence and type.

   A limitation of STUN is that it cannot detect whether the responder base exchange is behind the same NAT as the initiator.  This can lead to an
   unoptimal route relayed through the public address of the NAT, especially in
   combination relay server.  Next, the rendezvous extensions that are described later in
   this document.  In
   hosts test the worst case, reachability between the NAT may not be able different locators to forward
   the traffic unless it supports "hairpin translation" as described in
   [I-D.srisuresh-behave-p2p-state].

   To guarantee connectivity behind the same NAT, the initiator MUST
   detect the hairpin support of the NAT as described in
   [I-D.ietf-behave-nat-behavior-discovery].  If the NAT supports
   hairpinning, the initiator uses the UDP encapsulation procedures
   described in the following sections.  If the NAT does
   construct a direct route.  When a direct route is not support
   hairpinning, possible, the initiator SHOULD broadcast a single I1 packet
   without UDP encapsulation
   hosts resort to ESP relays.  When locators of a host change, the local network.  The responder MUST
   process
   hosts test reachability of locators again and select the I1 according to [I-D.ietf-hip-base].  However, "optimal"
   locator.  End-hosts can tear down HIP associations using the
   initiator MUST continue with CLOSE
   mechanism through the relay.

3.1.  Port Number Selection

   This document defines only UDP encapsulation mechanisms
   described in the following sections because the responder may
   actually be located in a different network.

   HIP-aware NATs are not in the scope of this document.  In the future,
   it for HIP and ESP packets.
   Further extensions may be possible to use some define bindings for other transport protocols.
   The RECOMMENDED transport protocol that is launched in
   parallel with e.g.  STUN to detect the presence of HIP aware NATs.
   When the path UDP.

   It is RECOMMENDED that an Initiator selects a random port number
   between the initiator and responder consists of HIP
   aware NATs, the extensions defined in this document SHOULD NOT be
   used.

3.  HIP Across NATs

   The HIP ephemeral port ranged 49152-65535 for initiating a base
   exchange as defined in [I-D.ietf-hip-base] works well in
   public networks. even for registration.  However, this does not work with some legacy NATs
   that the allocated port MUST be
   maintained until all of the corresponding Host Associations are not able to multiplex HIP
   closed.  Alternatively, a host MAY also use a single fixed port for
   initiating all outgoing connections.

   A relay or ESP traffic.  As a result, such
   NATs just drop HIP control traffic and/or ESP data traffic.  As Responder without a
   solution relay MUST listen at transport port
   HIPPORT for this, we propose UDP encapsulation of incoming UDP-encapsulated HIP control packets.

3.2.  Relay Registration and data
   traffic using a specific scheme described NAT Detection

   HIP rendezvous servers are used in this document.  The
   scheme also allows hosts behind NATs to act as servers.

   [RFC3948] describes UDP encapsulation of transport non-NATted environments and tunnel mode
   ESP packets.  This document describes a similar mechanism for BEET
   mode ESP packets [I-D.nikander-esp-beet-mode].

3.1.  Packet Formats its
   use is described in [I-D.ietf-hip-rvs].  This section defines the UDP-encapsulation packet format for
   another types middleboxes, called HIP base
   exchange and control traffic, IPsec ESP BEET-mode traffic and NAT
   keep-alive.

3.1.1.  Control Traffic

      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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     ~ Relays, which are used
   in NATted environments.

   A HIP Header and Parameters                  ~
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 1: Format for relay forwards UDP-encapsulated HIP control traffic, and in future
   extensions, a relay may also forward TCP-encapsulated traffic.

   Figure 1 shows how  A
   single relay may forward only HIP control packets are encapsulated within UDP. packets, ESP traffic or
   both.  A minimal UDP packet carries a complete HIP packet in its payload.
   Contents of the UDP source and destination ports are described below.
   The UDP length and checksum field MUST be computed host acting as described in
   [RFC0768].  The HIP header and parameter follow the conventions
   [I-D.ietf-hip-base] with the exception that the HIP header checksum
   MUST be zero.  The HIP headers checksum is zero for two reasons.
   First, the UDP header contains already a checksum.  Second, the
   checksum definition in [I-D.ietf-hip-base] includes the IP addresses Responder in the checksum calculation which is not applicable on a private address realm SHOULD
   use a HIP unaware
   NAT devices.

3.1.2.  Control Channel Keep-Alives

   The keep-alive relay for control channel are basically UDP encapsulated
   NOTIFY packets [I-D.ietf-hip-base].  The NOTIFY packets MAY contain
   HIP parameters.  The NAT traversal mechanisms encapsulate these
   NOTIFY packets within traversal.  It is RECOMMENDED that the payload of UDP packets.

3.1.3.  Data Traffic
      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 2: Format for UDP-encapsulated IPsec ESP BEET-mode traffic.

   Figure 2 shows how IPsec
   Responder uses also an ESP BEET-mode relay to guarantee successful NAT
   traversal with p2p-unfriendly NAT devices.

   A relay MUST NOT forward any packets are encapsulated
   within UDP.  Again, to a minimal UDP packet carries host that has not
   successfully registered to the ESP packet in
   its payload. relay.  The contents of registration process
   follows the UDP source and destination ports
   are described generic registration extensions defined in later sections.
   [I-D.ietf-hip-registration].  The UDP length and checksum field
   MUST be computed as described registration process is illustrated
   in [RFC0768].

3.1.4.  FROM_NAT Parameter

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Address                           |
     |                                                               |
     | Figure 1.

      Relay                                                    Relay
      Client                                                   Server
        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   1. I1                                                |         UDP Port
        +------------------------------------------------------->|
        |       Padding                                                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type        [ TBD by IANA (63998 = 2^16 - 2^11 + 2^9 - 2) ]
     Length      18
     Address     An IPv6 address or an IPv4 address in IPv4-in-IPv6
                 format.
     UDP Port    A UDP port number

                Figure 3: Format for the FROM_NAT Parameter

   Figure 3 shows FROM_NAT parameter.  The use of this parameter is
   described in the following sections.

3.1.5.  VIA_RVS_NAT Parameter

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             Type  2. R1(LOCATOR,REG_INFO(RELAY_UDP_HIP,RELAY_UDP_ESP))  |             Length
        |<-------------------------------------------------------+
        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                        |
        |   3. I2(LOCATOR,REG_REQ(RELAY_UDP_HIP,RELAY_UDP_ESP))  |                            Address
        +------------------------------------------------------->|
        |                                                        |
        |   4. R2(REG_RES(RELAY_UDP_HIP,RELAY_UDP_ESP),REG_FROM) |
        |<-------------------------------------------------------|
        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                        |          UDP Port
        |            Padding               5. Connectivity tests                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type        [ TBD by IANA (64002 = 2^16 - 2^11 + 2^9 + 2) ]
     Length      16
     Address     An IPv6 address or an IPv4-in-IPv6 format IPv4 address
     UDP Port    A UDP port
        |<------------------------------------------------------>|

                 Figure 4: Format for 1: Example registration to a relay

   In the VIA_RVS_NAT Parameter

   Figure 4 shows VIA_RVS_NAT parameter.  The parameter above figure, the end-host is used for
   diagnostic purposes, similarly referred to as VIA_RVS parameter in
   [I-D.ietf-hip-rvs]. a relay client
   and the relay middlebox as a relay server.  The exact use of this parameter registration is
   piggybacked to a base exchange, but it can be done also using HIP
   UPDATE control packets as described in
   later sections.

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

   [RFC3948] describes UDP encapsulation of [I-D.ietf-hip-registration].

   In step 1, the IPsec ESP transport and
   tunnel mode.  This section describes relay client starts the UDP encapsulation of registration procedure by
   sending an I1 packet over the
   BEET mode.

3.2.1.  UDP Encapsulation of IPsec BEET-Mode ESP

   During transport layer.  The port selection
   was explained in section Section 3.1.

   In step 2, the HIP base exchange, Responder lists 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 services that result it supports in UDP-encapsulated BEET-mode ESP data traffic. the
   R1 packet.  The management of encryption and 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 support for outgoing data HIP-over-UDP relaying is denoted by
   RELAY_UDP_HIP value and another one the support for incoming data.

   The BEET mode provides limited tunnel mode semantics without ESP-over-UDP relaying is
   denoted by a RELAY_UDP_ESP value in the
   regular tunnel mode overhead.  [I-D.nikander-esp-beet-mode] REG_INFO parameter.

   In step 3, the
   BEET mode, transport-layer checksums in the payload data are based on Initiator selects the HITs.  The packet MUST then undergo BEET-mode ESP cryptographic
   processing as defined services it registers to and
   lists them in Section 5.3 of [I-D.nikander-esp-beet-mode].

   Next, the resulting BEET-mode packet is UDP encapsulated.  For REG_REQ parameter.  In this
   purpose, a UDP header MUST be inserted between example, the IP Initiator
   registers both to HIP 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 relay services.

   In step 4, 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 5 illustrates relay server concludes the BEET-mode UDP encapsulation registration 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 5: UDP Encapsulation of
   an IPsec BEET-mode ESP packet
                         containing a TCP segment.

3.2.2.  UDP Decapsulation of IPsec BEET-Mode ESP

   An incoming UDP-encapsulated IPsec BEET-mode ESP R2 packet is
   decapsulated as follows.  First, if the UDP checksum is invalid, then and acknowledges the packet MUST be dropped.  Then, registered services in the packet MUST be verified as
   defined REG_RES
   parameter.  The relay may also denote unsuccessful registrations in [I-D.nikander-esp-beet-mode].  If verified,
   the ESP data
   contained REG_FAILED parameter in R2.  After the payload of registration, the UDP packet hosts
   MUST be decrypted send periodically NAT keepalive packets to each other as
   described defined
   later in [I-D.nikander-esp-beet-mode]. this document.

   In step 5, the client and server handle connectivity tests.  The NAT traversal methods
   procedure is described in this section are based on
   connection reversal and UDP hole punching similar to
   [I-D.ietf-behave-nat-udp].  However, a later section.

   When the methods in this section are
   adapted for HIP purposes, especially with ESP relay registration was successful, the rendezvous relay server in
   mind.

3.3.  Initiator Behind NAT

   This section discusses mechanisms uses
   the source IP address and port of the R2 packet (HIPPORT) to reach a HIP responder located in
   publicly addressable network by a HIP initiator that is located
   behind a NAT.  The section describes also relay
   ESP traffic with the case where client.  This address-port pair of the
   responder relay is using
   referred to as a rendezvous service.

   Table 1 lists some short-hand notations used "leased transport locator" in this section.  For
   simplicity, document.  As the ports mangled by NAT are presented as example
   port
   numbers (11111, 22222, etc) instead of symbolic ones.  In the
   examples, we assume that number may be shared by multiple clients, the NAT(s) timeout after ESP relay MUST
   multiplex the I1-R1 exchange
   over UDP because of e.g large RTT or high puzzle difficulty.  In such
   a case, ESP traffic based on SPIs and not the NAT drops just the related UDP port state and port numbers
   change for the I2-R2 exchange.

   +------------------+------------------------------------------------+
   | Notation         | Explanation                                    |
   +------------------+------------------------------------------------+
   | HIT-I            | Initiator's HIT                                |
   | HIT-R            | Responder's HIT                                |
   | IP-I             | Initiator's IP address                         |
   | IP-R             | Responder's IP address                         |
   | IP-RVS           | IP address of
   number.

   The R2 packet also includes an REG_FROM parameter that indicates the responder's rendezvous       |
   |                  | server                                         |
   | IP-NAT-I         | Public IP
   transport locator of the NAT of client as observed by the initiator          |
   | IP-NAT-R         | Public IP server.  The
   transport locator may be translated by a number of the NAT of middleboxes
   between the responder          |
   | UDP(50500,11111) | UDP packet with source port 50500 client and          |
   |                  | destination port 11111                         |
   | UDP(11111,22222) | Example port numbers mangled by a NAT          |
   | UDP(44444,22222) | Port 44444 is used throughout the examples server.  This locator is referred to  |
   |                  | denote the NAT mangled source port of I2 as    |
   |                  | received by the rendezvous server during
   the   |
   |                  | registration                                   |
   +------------------+------------------------------------------------+

                  Table 1: Notations Used "relay reflexive transport locator" later in This Section

3.3.1.  NAT Traversal of this document.

   A single server can provide multiple HIP Control Traffic

   This section describes middlebox services or the details of enabling NAT traversal for
   services can be distributed among multiple servers.  The difference
   between a HIP
   control traffic for the base exchange [I-D.ietf-hip-base] through UDP
   encapsulation for rendezvous server [I-D.ietf-hip-rvs] and a HIP relay
   server depends on the case registration.  The rendezvous server processing
   rules apply when the initiator of the association is
   located behind Responder has registered to a NAT and middlebox with the responder is located in a publicly
   addressable network.  UDP-encapsulated HIP control traffic MUST use
   RVS registration type.  Correspondingly, the packet formats described middlebox applies the
   relay extensions defined in Section 3.1. this document when the Responder has
   registered using the relay registration types.  When sending UDP-
   encapsulated HIP control traffic, a HIP implementation MUST zero the
   HIP header checksum before calculating single server
   provides both rendezvous and relay services, they are multiplexed
   depending on the UDP checksum. absence or presence of transport layer
   encapsulation.

   The
   receiver Relay Client MUST only verify include a LOCATOR parameter in I2 which lists
   all of the correctness locators of the UDP checksum and Initiator.  The Relay Server MUST NOT verify include
   a LOCATOR parameter in R1, but it is RECOMMENDED that the checksum LOCATOR
   parameter includes only the source transport LOCATOR of R1 as the HIP header.
   only locator.  The initiator of a UDP-encapsulated HIP base exchange MUST use case when the Relay Server includes more locators
   may require IP header conversion between IPv4 and IPv6, insertion, or
   removal of, UDP destination port 50500 header and fragmentation handling.  Multiple locators
   in R1 is left for all control packets it sends. further experimentation.

3.3.  Base Exchange via Relay

   It is RECOMMENDED to use 50500 as that the source port as well, but Initiator sends an
   implementation MAY use a (randomly selected) unoccupied source port.
   If it uses a random source port, it MUST listen for and accept
   arriving HIP control/ESP Data packets on this port until I1 packet over the
   corresponding HIP association is torn down.  The random source port
   transport layer when it is RECOMMENDED destined to be in the range an IPv4 address of the dynamic and private ports
   (49152-65535).  Using a random source port, instead of a fixed one,
   enables
   Responder.  Respectively, the Responder MUST respond to have multiple clients behind a NAT middlebox that supports
   only address translation but no port translation.  This is referred
   to as port overloading in [I-D.ietf-behave-nat-udp]. such I1
   packet with an R1 packet over the transport layer and using the same
   transport protocol.  The responder rest of a UDP-encapsulated HIP the base exchange exchange, I2 and R2, MUST use 50500
   as
   also be sent over the source port for all UDP-encapsulated control packets it sends.
   The source address for all transport layer.  However, the packets that transport layer
   encapsulation can be unnecessary when there are no NATs between the responder sends MUST
   Initiator and Responder.  This will be detected in the same as connectivity
   tests described in the IP next section.

   When the Initiator has an IPv6 address on which responder receives packets
   from initiator.  The responder and it has discovered only an
   IPv6 address for the peer, it MUST respond to any arriving UDP-
   encapsulated control message using UDP encapsulation as well.  Hosts send it directly over IP.  In such
   a case, the Initiator MUST process UDP-encapsulated base exchange messages equivalently to
   non-encapsulated messages, i.e., according to follow the procedures described in
   [I-D.ietf-hip-base].

   The remainder of this section clarifies this process through an
   example which  Otherwise, it is illustrated in Figure 6.  It shows an initiator with
   the private address IP-I behind a NAT.  The NAT has RECOMMENDED that the public IP
   address Initiator
   proceeds as NAT.  The responder is shown in a publicly addressable location
   IP-R.

        +---+           +---+                                 +---+ Figure 2.

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

        1. IP(IP-I, IP-R)      UDP(50500, 50500)  I1(HIT-I, HIT-R)
        2. IP(IP-NAT-I, IP-R)  UDP(11111, 50500)  I1(HIT-I, HIT-R)
        3. IP(IP-R, IP-NAT-I)  UDP(50500, 11111)  R1(HIT-R, HIT-I)
        4. IP(IP-R, IP-I)      UDP(50500, 50500)  R1(HIT-R, HIT-I)
        5. IP(IP-I, IP-R)      UDP(50500, 50500)  I2(HIT-I, HIT-R)
        6. IP(IP-NAT-I, IP-R)  UDP(22222, 50500)  I2(HIT-I, HIT-R)            7. IP(IP-R, IP-NAT-I)  UDP(50500, 22222)  R2(HIT-R, HIT-I) R2(RELAY_TO) |
      |                8. IP(IP-R, IP-I)      UDP(50500, 50500)  R2(HIT-R, HIT-I) R2(RELAY_TO) |<---------------------------+
      |<-------------------------------+                            |
      |                                |                            |

                    Figure 6: Example of a UDP-encapsulated HIP base exchange (initiator
       behind a NAT, responder in 2: Base Exchange via a publicly addressable location).

   Before beginning the base exchange, relay

   In step 1 of the initiator detects that it is
   behind a NAT through some external mechanism, e.g.  STUN.  The
   initiator starts figure, the base exchange by sending a UDP-encapsulated I1
   packet to Initiator discovers the responder.  According to HIT of the rules specified above,
   Responder and the
   source IP IPv4 address of this the relay of the Responder.  The
   Initiator sends an I1 packet is IP-I and its source UDP port
   is 50500.  It is addressed over the transport layer to IP-R on port 50500.  The NAT in
   Figure 6 forwards the I1 but substitutes HIT of
   the Responder.  The port selection was explained in Section 3.1.  The
   source address IP-I with
   its own public address IP-NAT-I and is one of the source UDP port 50500 with
   11111.

   When routable addresses of the responder host is called
   "unreflexive locators" in Figure 6 this document.

   In step 2, the relay receives the UDP-encapsulated I1 packet on UDP at port 50500, it decapsulates HIPPORT.  If the packet and
   destination HIT belongs to a registered Responder, the relay
   processes the decapsulated packet according to [I-D.ietf-hip-base]. packet.  Otherwise, the relay MUST drop the packet.
   The
   responder replies back with relay MUST append a UDP-encapsulated R1 using the addresses
   and port information of I1.  Thus, RELAY_FROM parameter to the R1 I1 packet is destined to which
   preserves the transport source IP address and UDP port of the I1, i.e., IP address IP-NAT-I
   and port 11111. Initiator.
   The NAT receives relay protects the I1 and substitutes the
   destination of this packet with RELAY_HMAC as described in
   [I-D.ietf-hip-rvs], except that the initiator address (IP-I) and port
   information (50500). parameter type is different.  The initiator receives a UDP-encapsulated R1 packet from the
   responder, decapsulates and processes it according to
   [I-D.ietf-hip-base].  When it responds with a UDP-encapsulated I2
   packet, it uses
   relay MUST change the same IP source and destination addresses and UDP transport source to and destination ports that it of the
   packet to match the values the Responder used for sending when registering to the
   corresponding I1 packet,
   relay, i.e., the packet is addressed from IP-I port
   50500 to IP-R port 50500.  The NAT again substitutes reverse of the source
   information.  For illustration purposes, R2 used in the NAT state times out and
   it chooses a different source port (22222) for registration.  The
   relay MUST recalculate the I2 than for transport checksum and forwards the I1
   (11111).

   When a responder receives a UDP-encapsulated I2 packet destined
   to
   UDP port 50500, it MUST use the UDP source port contained in this
   packet for further HIP communications with Responder.

   In step 3, the initiator.  It then
   processes Responder receives the I2 I1 packet at the transport
   layer.  The Responder MUST process it according to the rules in
   [I-D.ietf-hip-base].  When it
   responds with an R2 message, it UDP-encapsulates  In addition, the message, using Responder MUST validate the UDP source port of
   RELAY_HMAC according to [I-D.ietf-hip-rvs] and drop the I2 packet as if the destination UDP port, and
   sends it to
   validation fails.  The Responder replies with an R1 packet that MUST
   contain a LOCATOR parameter that lists the source IP address locators of the I2 packet, i.e., it sends Responder.
   The locator list consists of unreflexive, reflexive and leased
   transport locators of the R2 Responder.  The R1 packet from IP-R port 50500 to IP-NAT-I port 22222. also contains a
   RELAY_TO parameter.  The NAT
   again replaces the destination RELAY_TO parameter contains same information in the R2 with IP-I port
   50500

   Usually,
   as the I1-R1 and I2-R2 exchanges occur fast enough for RELAY_FROM parameter, i.e., Initiator transport locator, but
   the NAT
   state to persist.  This means that type of the NAT uses parameter is different.  The RELAY_TO parameter is
   not integrity protected by the same port for signature of the
   I1-R1 exchange R1 to translate as the I2-R2 exchange.  However, allow pre-
   created R1 packets at the host
   MUST handle even Responder.

   In step 4, the case where relay receives the NAT state times out between R1 packet.  The relay MUST drop the
   two exchanges and
   packet if the I1 and I2 arrive from different UDP source
   ports and/or IP addresses, as illustrated in Figure 6.

3.3.2.  NAT Traversal of HIP Data Traffic

   This section describes the details of enabling NAT traversal of HIP
   data traffic.  As described in Section 3, HIP data traffic is carried
   in UDP-encapsulated IPsec BEET-mode ESP packets.

3.3.2.1.  IPsec BEET-Mode Security Associations HIT belongs to an unregistered host.  The initiator MUST use UDP destination port 50500 for all UDP-
   encapsulated ESP packets it sends.  It MAY also use port 50500 as
   source port or it relay
   MAY use a random source port.  If it uses a random
   source port, it MUST listen for and accept arriving UDP-encapsulated
   ESP packets on this port until verify the corresponding HIP association is
   torn down.

   The responder signature of a UDP-encapsulated IPsec BEET-mode ESP exchange MUST
   use 50500 as the source port for all UDP-encapsulated ESP packets R1 packet and drop it
   sends.  The destination port is the port from which when the responder
   signature is
   receiving UDP encapsulated ESP data from invalid.  Otherwise, the initiator.

   Both relay changes the initiator destination
   transport header to match RELAY_TO information, recalculates
   transport checksum and forwards the responder of a HIP association MUST define
   BEET mode packet.

   In step 5, the Initiator receives the R1 packet and processes it
   accordingly to [I-D.ietf-hip-base].  It replies with UDP encapsulation as an I2 packet
   that has the IPsec mode for same transport locator as R1, but the SA after a
   successful base exchange.  The inner source address MUST be the local
   HIT used during base exchange and the inner
   destination address MUST
   be ports are swapped.  The I2 contains a LOCATOR parameter
   containing the HIT listing unreflexive, reflexive and leased transport
   locators of the peer.  The other parts of Initiator

   In step 6, the SA are described in
   individual sections.

3.3.2.1.1.  Security Associations at relay receives the Initiator I2 packet.  The initiator of relay appends a UDP-encapsulated base exchange defines its
   outbound SA
   RELAY_FROM and a RELAY_HMAC to the I2 packet as shown in Table 2

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | The local IP address from which the base exchange  |
   | address      | packets were transmitted                           |
   | Outer dst    | The peer IP address to which base exchange packets |
   | address      | were transmitted                                   |
   | UDP src port | The port number as chosen for second step.

   In step 7, the Responder receives the I2 packet and processes it
   according to [I-D.ietf-hip-base].  It replies with an R2 packet and
   includes a RELAY_TO parameter as in base    |
   |              | exchange                                           |
   | UDP dst port | Port 50500                                         |
   +--------------+----------------------------------------------------+

                     Table 2: Outbound SA at initiator step three.  The initiator of a UDP-encapsulated base exchange defines its inbound
   SA RELAY_TO
   parameter is protected by the HMAC.

   In step 8, the relay processes the R2 as shown described in Table 3

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | step four.  The peer IP address
   relay forwards the packet to which base exchange packets |
   | address      | were transmitted                                   |
   | Outer dst    | The local IP address from which the base exchange  |
   | Responder.

3.4.  Base Exchange without a Relay

   A host that has a publicly addressable, fixed IP address      | packets were transmitted                           |
   | UDP src port | Port 50500                                         |
   | UDP dst port | Initiator MUST use MAY exclude
   registration to a Relay.  As the UDP source port it uses in  |
   |              | Relay is not present, the outbound SA here                               |
   +--------------+----------------------------------------------------+

                     Table 3: Inbound SA at initiator

3.3.2.1.2.  Security Associations host MUST
   listen at the Responder

   The responder of a HIPPORT for transport-encapsulated HIP and ESP packets.  An
   UDP-encapsulated base exchange defines its
   outbound SA shown with such an host does not have the
   RELAY_TO and RELAY_FROM parameters present.  Connectivity tests MUST
   be handled as defined in Table 4.

   +-------------+-----------------------------------------------------+
   | Field       | Value                                               |
   +-------------+-----------------------------------------------------+
   | Outer src   | The local IP address from which the following section before any ESP traffic
   is allowed.

3.5.  Connectivity Tests

   The base exchange   |
   | address     | packets were transmitted                            |
   | Outer dst   | Peer IP address is completed with an R2 packet.  Then, the state of
   the I2 packet received during    |
   | address     | HIP associations at both peers is ESTABLISHED, but the base exchange                                   |
   | UDP src     | Port 50500                                          |
   | port        |                                                     |
   | UDP dst     | Source UDP port peers MUST
   NOT allow any ESP traffic until the connectivity tests described in
   the next section are performed successfully.  All of the I2 packet received from locators,
   except the  |
   | port        | initiator during base exchange                      |
   +-------------+-----------------------------------------------------+

                     Table 4: Outbound SA at Responder

   Similarly, relay address, are in UNVERIFIED state.  In the responder of
   connectivity tests, the hosts test connectivity between different
   locator pairs in order to find a UDP-encapsulated base exchange defines
   its inbound SA as shown working one.  The connectivity tests
   are illustrated in Table 5

   +-------------+-----------------------------------------------------+
   | Field       | Value                                               |
   +-------------+-----------------------------------------------------+ Figure 3.  In this example, both hosts are behind
   NATs.

     I                              Relay                            R
     | Outer src        2. R2(RELAY_TO)        | Source IP address of the I2 packet received from        1. R2(RELAY_TO)        |
     +<------------------------------+-------------------------------+
     | address                                                               | the initiator during base exchange
     |                3. UPDATE(ECHO_REQUEST,FROM_PEER)    NAT-R:DROP|
     +------------------------------------------------------------->X|
     | Outer dst                                                               | The local IP address from which the base exchange
     |                4. UPDATE(ECHO_REQUEST,FROM_PEER)              | address
     |<--------------------------------------------------------------+
     | packets were transmitted                                                               |
     | UDP src                5. UPDATE(ECHO_RESP,TO_PEER)                   | Source UDP port of the I2 packet received from the
     +-------------------------------------------------------------->+
     |                                                               | port
     | initiator during base exchange                6. UPDATE(ECHO_REQUEST,FROM_PEER)              |
     +-------------------------------------------------------------->|
     | UDP dst                                                               | Port 50500
     |                7. UPDATE(ECHO_RESP,TO_PEER)                   | port
     |<--------------------------------------------------------------+
     |                                                               |
   +-------------+-----------------------------------------------------+

                     Table 5: Inbound SA at responder

3.3.3.  Use of the Rendezvous Service when only the Initiator is Behind
        NAT

                       Figure 3: Connectivity tests

   The rendezvous connectivity tests are handled as the mobility extensions for HIP without NAT traversal have been defined
   in [I-D.ietf-hip-rvs].  This section addresses only the
   scenario where a NATted HIP node uses the rendezvous service [I-D.ietf-hip-mm] and are therefore subject to
   contact another HIP node in a publicly addressable network.  Figure 7
   illustrates the mechanism described same processing
   rules.  The packets include ESP_INFO, SEQ, ACK, HMAC, SIGNATURE
   parameters that are omitted in this section.

   A rendezvous server MUST listen on UDP port 50500 section for incoming UDP
   encapsulated I1 packets.  However, simplicity.  The
   differences to the mobility extensions are described in this specific case with only
   the initiator behind NAT, section.

   In steps 1 and 2, the rendezvous server MUST NOT relay R2 packet is relayed from the I1
   packets.  Instead, Responder through
   the rendezvous server replies Relay to the initiator
   with a NOTIFY message that includes Responder.  After this, both hosts start
   connectivity tests using the responder's locator return routability tests defined in a
   VIA_RVS parameter.
   [I-D.ietf-hip-mm].  The rendezvous server can differentiate this
   scenario return routability tests are used to probe
   for connectivity between each locator pair obtained from the others because the I1 arrives UDP encapsulated, but
   the responder has registered without UDP encapsulation.

   Upon receiving the NOTIFY with the local
   and peer locators of obtained during base exchange.  The return
   routability tests are also used as a UDP hole punching mechanism.
   The tests are carried in certain order which determined by the responder through
   priorization algorithm defined in the NAT, next section.

   As an example, let's consider the initiator MUST send case where hosts are testing each
   others outermost NAT addresses, i.e., relay reflexive transport
   locators.  In step 3, host I sends an I1 UPDATE message containing an
   ECHO_REQUEST to the responder.  However, it
   MUST continue retransmissions using the RVS location. R. This is
   mandatory because NOTIFY messages are not protected with signatures
   and can be forged by will punch a rogue host.

   When hole the initiator receives an R1 through NAT of I, but the NAT,
   NAT of R drops the responder
   verifies message because the integrity NAT of the packet and replies R has no state with an I2.  The
   responder should be aware that the I2 may arrive from a different
   port than the I1. I.

   In such a case, the responder should send the R2
   to step 4, R starts also reachability detection by sending an UPDATE
   with ECHO_REQUEST.  This traverses the source port NAT of I2.

     +---+           +---+                     +-------+   +---+
     |   |----(1)--->|   |---------------(2)-->|       |   |   |
     |   |           |   |                     | RVS R |   |   |
     |   |<---(4)----|   |<--------------(3)---|       |   |   |
     |   |           |   |                     +-------+   |   |
     |   |           | N |                                 |   |
     |   |----(5)--->| A |---------------(6)-------------->|   |
     | I |           | T |                                 | R |
     |   |<---(8)----| - |<--------------(7)---------------|   |
     |   |           | T |                                 |   |
     |   |----(9)--->|   |---------------(10)------------->|   |
     |   |           |   |                                 |   |
     |   |<---(11)---|   |<--------------(12)--------------|   |
     +---+           +---+                                 +---+

     1.  IP(IP-I, IP-RVS)      UDP(50500, 50500)   I1(HIT-I, HIT-R)
     2.  IP(IP-NAT-I, IP-RVS)  UDP(11111, 50500)   I1(HIT-I, HIT-R) successfully because
   Initiator had already punched an hole into its NAT in step 3.  IP(IP-RVS, IP-NAT-I)  UDP(50500, 11111)
                                   NOTIFY(HIT-R, HIT-I, VIA_RVS(IP-R))
     4.  IP(IP-RVS, IP-I)      UDP(50500, 50500)
                                   NOTIFY(HIT-R, HIT-I, VIA_RVS(IP-R))  The
   Responder replies using ECHO_RESPONSE in step 5.  IP(IP-I, IP-R)        UDP(50500, 50500)   I1(HIT-I, HIT-R)
     6.  IP(IP-NAT-I, IP-R)    UDP(22222, 50500)   I1(HIT-I, HIT-R)
     7.  IP(IP-R, IP-NAT-I)    UDP(50500, 22222)   R1(HIT-R, HIT-I)
     8.  IP(IP-R, IP-I)        UDP(50500, 50500)   R1(HIT-R, HIT-I)
     9.  IP(IP-I, IP-R)        UDP(50500, 50500)   I2(HIT-I, HIT-R)
     10. IP(IP-NAT-I, IP-R)    UDP(33333, 50500)   I2(HIT-I, HIT-R)
     11. IP(IP-R, IP-NAT-I)    UDP(50500, 33333)   R2(HIT-R, HIT-I)
     12. IP(IP-R, IP-I)        UDP(50500, 50500)   R2(HIT-R, HIT-I)

     Figure 7: Example of a UDP-encapsulated HIP base exchange via RVS
    (initiator behind a NAT, responder and RVS on  Upon receiving the
   ECHO_RESPONSE, the public Internet).

3.4. Responder Behind NAT

   This section discusses mechanisms transitions the address pair to reach VERIFIED
   state.

   In step 6, host I starts a HIP responder that is
   located behind new return routability test either due to
   a NAT.  This section assumes that retransmission timer or as a reaction to UPDATE with ECHO_REQUEST
   received from R. In step 7, host R receives and sends a response to
   I. Upon receiving the initiator is
   located on publicly addressable network.  The initiator contacts response, host R transitions the
   responder through an RVS server.

3.4.1.  Rendezvous Client Registration From Behind NAT locator pair
   being tested to VERIFIED state.

   All locators in UNVERIFIED state MUST be retransmitted RTIME times.
   The rendezvous client registration [I-D.ietf-hip-rvs] describes the
   case when rendezvous client is present retransmission packets MUST be paced Ta ms apart as defined in publicly addressable
   network.  This section defines an extension to
   [I-D.ietf-mmusic-ice].  The retransmission are ordered in a sequence
   determined by the rendezvous client
   registration for priority of the case when transport locator pairs, as
   described in the rendezvous client has detected
   that it is behind a NAT. next section.

   The process in source address of the NAT case UPDATE messages containing ECHO_REQUEST
   parameter is identical to always an unreflexive IPv4 locator of the case without NAT, except that UDP encapsulation is used. host.  The
   registration
   destination locator is illustrated in Figure 8.

   A node behind a NAT MUST first register to the RVS when it peer's unreflexive, reflexive or leased
   transport locator, depending on which address is going
   to act as a responder being tested for some other nodes.  The node (i.e.
   rendezvous client) performs a base exchange with
   reachability.  Implementations may add RTT measurement information to
   the RVS over UDP as
   described in Section 3.3 by sending I1 UDP encapsulated and 50500 as
   destination port number.  RVS sends REG_INFO ECHO_REQUEST parameter in R1 to which
   rendezvous client replies with REG_REQ paramter in I2.  Both I1 and
   R1 are sent using UDP-encapsulation.  If RVS grants service addition to a nonce.

   The UPDATE messages carrying ECHO_REQUEST include a FROM_PEER
   parameter.  The sender of the
   rendezvous client, it UPDATE MUST store copy the source IP address and source
   port number of
   the I2 UDP packet that it had received from UPDATE to the
   rendezvous client during base exchange. FROM_PEER parameter.  When the peer receives the
   UPDATE, it responds with an UPDATE containing and a ECHO_REQUEST and
   TO_PEER parameters.  The TO_PEER parameter MUST contain the source IP
   address
   belongs to of the NAT UPDATE redundantly.  The reason from the FROM_PEER and
   TO_PEER parameters is that it is possible to learn new addresses
   using them.  When there is p2p-unfriendly NAT between the source peers, it
   may cause translate port number is of the NAT mangled
   port.  RVS then replies with REG_RESP in R2 over UDP.  If UPDATE packets to something
   that has not been communicated through the
   registration process results relay before.  Such an
   addresses are called "peer reflexive transport locators" in a successful REG_RESP, this
   document.  The FROM_PEER and TO_PEER parameters can be used for
   detecting peer reflexive locators.  The learned locators are added to
   the rendezvous
   client MUST send NAT keepalives (Section 3.1.2) connectivity tests.

   UPDATE packets destined to keep the mapping
   in 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 NAT with locator pairs in the RVS open.  The NAT keepalives sent from
   rendezvous client to order
   described in the RVS next section.  A host MUST have the same source port as transition the I2
   packet.

   When state of
   transport locator pairs verified by the RVS receives an I1 packet from a HIP node to be relayed return routability tests to
   the successfully registered rendezvous client behind NAT, RVS ACTIVE state.  Keepalive mechanisms described in later sections
   MUST
   relay the I1 over UDP with be applied to refresh the destination port as state in NAT devices for locators
   in the one stored
   during registration.  The RVS ACTIVE state.  A host MUST also zeroes set up the HIP header checksum Security
   Associations for the inbound ESP traffic for such locators.  The
   selection of a default outbound SA is defined in the I1. next section.

3.6.  Selecting an Address Pair

   This process is explained section describes priority ordering of connectivity tests 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 Section 3.4.2.

        +---+           +---+                                 +---+
        |   |----(1)--->|   |---------------(2)-------------->|   |
        |   |           | N |                                 | Table 2.

            +-----------------------------------+------------+
            | Locator Type                      |   |<---(4)----| A |<--------------(3)---------------| Preference |
            +-----------------------------------+------------+
            | I The preferred locator             | 127        | T
            | Unreflexive locator               | R 126        |
            |   |----(5)--->| - |---------------(6)-------------->|   | Peer reflexive transport locator  | 120        |
            | I Relay reflexive transport locator | 100        |
            | Leased transport locator          |   |<---(8)----|   |<--------------(7)---------------| 0          |
        +---+           +---+                                 +---+

        Initiator = Rendezvous client, Responder = Rendezvous server

        1. IP(IP-I, IP-R)     UDP(50500, 50500) I1(HIT-I, HIT-R)
        2. IP(IP-NAT-I, IP-R) UDP(33333, 50500) I1(HIT-I, HIT-R)
        3. IP(IP-R, IP-NAT-I) UDP(50500, 33333)
              R1(HIT-R, HIT-I, REG_INFO)
        4. IP(IP-R, IP-I)     UDP(50500, 50500)
              R1(HIT-R, HIT-I, REG_INFO)
        5. IP(IP-I, IP-R)     UDP(50500, 50500)
              I2(HIT-I, HIT-R, REG_REQ)
        6. IP(IP-NAT-I, IP-R) UDP(44444, 50500)
              I2(HIT-I, HIT-R, REG_REQ)
        7. IP(IP-R, IP-NAT-I) UDP(50500, 44444)
              R2(HIT-R, HIT-I, REG_RES)
        8. IP(IP-R, IP-I)     UDP(50500, 50500)
              R2(HIT-R, HIT-I, REG_RES)

               Figure 8: Rendezvous NAT Client Registration

3.4.2.  NAT Traversal
            +-----------------------------------+------------+

                     Table 2: Locator Type Preferences

   In addition to the "type" priority, the priority of HIP Control Traffic

   This section describes a locator is also
   affected by the details "local" priority.  A (multihoming) host may have
   multiple locators of enabling NAT traversal same type and SHOULD assign a unique local
   priority for base
   exchange packets [I-D.ietf-hip-base] through UDP encapsulation, 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 case when the HIP initiator is local priority.  A host SHOULD calculate locator priority based
   on publicly addressable network
   and the HIP responder is behind NAT.  The process is illustrated local and type priorities as shown in Figure 9.

   Before the HIP base exchange starts, the responder of the HIP base
   exchange 4.  The locator
   priority MUST have completed a successful rendezvous client
   registration using always be included in the scheme defined type 3 locator fields in
   LOCATOR parameters as described in section Section 3.4.1.

   The initiator of the HIP base exchange sends 4.4.

              Locator priority = (2^24) * (type preference) +
                                 (2^8) * (local preference)

                        Figure 4: Locator priority

   A host SHOULD calculate a plain I1 packet
   (without UDP encapsulation) to the RVS priority for each locator pair as described shown in
   [I-D.ietf-hip-rvs].  In this case, the rendezvous server detects that
   Figure 5.  I and R denote the I1 is not UDP encapsulated, but priorities of locators of Initiator and
   Responder.  The use of the rendezvous client has
   registered using UDP encapsulation.

   To relay same formula at both ends gives more
   guarantees that the I1 packet, RVS MUST zero peers prefer shortest paths between them.  It
   also converges the HIP header checksum from selection of the I1 packet.  RVS MUST add locator pair towards a FROM parameter, as described in
   [I-D.ietf-hip-rvs], which contains the IP address symmetric
   pair instead of HIP initiator. an asymmetric pair even though it is not completely
   guaranteed.  The FROM parameter reasoning for the formula is integrity protected by a RVS_HMAC parameter as described in [I-D.ietf-hip-rvs].  RVS replaces
   [I-D.ietf-mmusic-ice].

      Pair priority = 2^32 * MIN(I,R) + 2 * MAX(I,R) + (I > R ? 1 : 0)

                          Figure 5: Pair priority

   After reachability tests, both hosts SHOULD assign the destination IP transport
   address in pair with the IP header highest pair priority as their default outgoing
   SA for ESP.

3.7.  Mobility

   When one of the packet with IP that hosts changes its locators, it had stored
   during the rendezvous client registration (which is the IP address has to notify its
   peers of the outermost NAT behind which rendezvous client address change.  This is located).  It
   MUST then encapsulate the I1 packet within UDP.  The source port handled as described in the UDP header MUST be 50500 and
   connectivity tests in Section 3.5 with the destination port MUST be exception that the
   same UPDATE
   with parameter LOCATOR is used as the source port number (44444) trigger to start connectivity
   tests instead of the I2 R2.  The UPDATE packet which it had
   stored during the registration process.  RVS then recomputes the IP
   header checksum contains a LOCATOR
   parameter listing unreflexive, reflexive and sends leased transport
   locators of the packet.

                        +-------+
                        |       |
                 +----->|  RVS  +-----+           +----+
   +---+         |      |       |     | Initiator.  This is illustrated in Figure 6.

     Mobile                         Relay                Corresponding
     Node                            |                            Node
     |          +---+                               |   |---(1)---+      +-------+     +----(2)--->|    |---(3)--->|                               |
     |     1. UPDATE(LOCATOR)        |  2. UPDATE(LOCATOR,RELAY_TO)  | N
     +-------------------------------+------------------------------>|
     |                                                               |
     |                3. UPDATE(ECHO_REQUEST,FROM_PEER)     NAT: DROP|
     +------------------------------------------------------------->X|
     |   |<------------------(5)--------------------| A  |<--(4)----|                                                               |
     | I                4. UPDATE(ECHO_REQUEST,FROM_PEER)              |
     |<--------------------------------------------------------------+
     | T                                                               |
     | R                5. UPDATE(ECHO_RESP,TO_PEER)                   |
     |-------------------------------------------------------------->|
     |   |-------------------(6)------------------->| -  |---(7)--->|                                                               |
     |                6. UPDATE(ECHO_REQUEST,FROM_PEER)              |
     |<--------------------------------------------------------------|
     | R                                                               |
     |                7. UPDATE(ECHO_RESP,TO_PEER)                   |
     |-------------------------------------------------------------->|
     |   |<------------------(9)--------------------|    |<--(8)----|                                                               |
   +---+                                          +----+          +---+

   1. IP(IP-I, IP-RVS)     I1(HIT-I, HIT-R)
   2. IP(IP-RVS, IP-NAT-R) UDP(50500, 44444)
         I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC)
   3. IP(IP-RVS, IP-R)     UDP(50500, 50500)
         I1(HIT-I, HIT-R, FROM:IP-I, RVS_HMAC)
   4. IP(IP-R, IP-I)
         UDP(50500, 50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
   5. IP(IP-NAT-R, IP-I)
         UDP(44444,   50500) R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500)
   6. IP(IP-I, IP-NAT-R)   UDP(50500, 44444)   I2(HIT-I, HIT-R)
   7. IP(IP-I, IP-R)       UDP(50500, 50500) I2(HIT-I, HIT-R)
   8. IP(IP-R, IP-I)       UDP(50500, 50500) R2(HIT-R, HIT-I)
   9. IP(IP-NAT-R, IP-I)   UDP(44444, 50500) R2(HIT-R, HIT-I)

                            Figure 9: UDP-encapsulated HIP base exchange (initiator on public
                    Internet, responder behind 6: Handover

   When a NAT).

   The relayed I1 packet travels mobile host moves from RVS a private address realm to another, it
   can obtain the NAT.  The NAT changes same locator on both networks.  To denote that the destination IP address of new
   locator requires reachability detection, the UDP encapsulated I1 packet, mobile host MUST use a
   new SPI for the new locator.

   A host can also use the UPDATE mechanism can also be used 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
   destination port number in result of
   the UDP header.  The responder accepts RTT measurements may indicate that another locator pair is more
   optimal than the
   packet locator pair resulting from the RVS connectivity and processes it according to [I-D.ietf-hip-rvs].
   The resulting R1 must be encapsulated within UDP.  The responder MAY
   append
   priority tests.  In such a VIA_RVS_NAT parameter to case, the message, which contains host MAY send UPDATE with
   LOCATOR parameter with the IP
   address of optimal locator with the rendezvous and preferred bit on.
   This gives the port highest priority for the rendezvous server most optimal locator and will
   be used for
   relaying if the I1.  The RECOMMENDED source port connectivity tests succeed.

3.8.  NAT Keepalives

   A NAT can delete the mapping state after a timeout when there is 50500 and no
   traffic refreshing the
   destination port number state.  For this reason, both hosts MUST be 50500.  The destination address send
   keep-alives to each other for all locators pairs that are in the IP header
   ACTIVE state.  Keepalives MUST be the same sent every 20 seconds for UDP.  The
   keepalive is a NOTIFY packet without parameters.

   The keep-alives MAY also be used to implement failure detection
   between end-hosts as the one specified in the FROM
   parameter of the relayed I1 packet. [I-D.oliva-hiprg-reap4hip] (XX FIXME: this
   needs still more details).  The initiator MUST listen on port 50500 and it receives the UDP
   encapsulated R1.  After verifying the basic idea is to keep track of HIP packet, it concludes that
   the responder
   control and ESP packets received over a transport port.  When there
   is behind no HIP or ESP traffic (not even keep-alives) arriving during a NAT because
   certain time period, the packet was UDP
   encapsulated. host switches to an alternative locator
   pair.  The initiator processes host transitions the R1 control packet
   according default locator pair to [I-D.ietf-hip-base] and replies using I2 that is UDP
   encapsulated.  The addresses and ports are derived from the received
   R1.

   The NAT translates
   UNVERIFIED state and forwards replaces the UDP encapsulated I2 packet currently default SA to correspond
   to the
   responder. ACTIVE locator pair with the highest priority.  The resulting R2 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 UDP encapsulated using used the address keep-alives to detect loss of connectivity
   with relay server.  When this occurs, the end-host can register to a
   new relay and port information from replace the received I2 packet.

3.4.3.  NAT Traversal IP address of HIP Data Traffic

   After the old relay server with a successful base exchange, both
   new one in DNS or DHT.

3.9.  Closing of the HIP nodes have
   communicated all the necessary information to establish UDP-
   encapsulated BEET mode Security Associations.  The following section
   describes inbound and outbound security associations at initiator and
   responder.

3.4.3.1.  Security Associations at the Initiator

   The initiator of

   A host closes a base exchange defines its outbound SA HIP association as shown described in
   Table 6

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | The local IP address from which [I-D.ietf-hip-base]
   except that the base exchange  |
   | address      | CLOSE and CLOSE_ACK packets were transmitted                           |
   | Outer dst    | The peer IP address from which R2 packet was       |
   | address      | received during base exchange                      |
   | UDP src port | Port 50500                                         |
   | UDP dst port | Source port of incoming R2 packet during base      |
   |              | exchange                                           |
   +--------------+----------------------------------------------------+

                     Table 6: Outbound SA at initiator

   The initiator of a base exchange defines its inbound SA are sent over transport
   layer and through the relay as shown illustrated in
   Table 7
   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | Figure 7.  Hosts MUST
   transition the corresponding locator pairs to the DEPRECATED state
   after a successful CLOSE-CLOSE_ACK exchange.  The peer IP address from which R2 packet was       |
   | address      | received during base exchange corresponding
   inbound and outbound SAs must be deleted on such occasion.

     I                            Relay                              R
     | 1. CLOSE                    | Outer dst                                 | The local IP address from which the base exchange
     +---------------------------->| 2. CLOSE                        |
     | address                             +-------------------------------->|
     | packets were transmitted                             |                                 | UDP src port
     | Source port of incoming R2 packet during base                             |                    3. CLOSE_ACK |
     | exchange                4. CLOSE_ACK |<--------------------------------+
     |<----------------------------+                                 |
     | UDP dst port                             | Port 50500                                 |
   +--------------+----------------------------------------------------+

                     Table

                  Figure 7: Inbound SA at initiator

3.4.3.2.  Security Associations at the Responder

   The responder Closing of a UDP-encapsulated base exchange defines its
   outbound SA shown in Table 8.

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | HIP association

   The local IP address hosts may also use the CLOSE mechanism to remove redundant SAs
   remaining from which the base exchange  |
   | address      | packets were transmitted                           |
   | Outer dst    | The peer IP as that used during base exchange      |
   | address      |                                                    |
   | UDP src port | The as source port chosen during base exchange     |
   | UDP dst port | Port 50500                                         |
   +--------------+----------------------------------------------------+

                     Table 8: Outbound SA at Responder

   Similarly, connectivity tests.  However, the responder of a UDP-encapsulated base exchange defines
   its inbound SA as shown in Table 9

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | Source peer IP address as used removal can
   prolong the recovery in base exchange    |
   | address      |                                                    |
   | Outer dst    | The local IP address from which the base exchange  |
   | address      | packets were transmitted                           |
   | UDP src port | Port 50500                                         |
   | UDP dst port | The as source port chosen during base exchange     |
   +--------------+----------------------------------------------------+

                     Table 9: Inbound SA at responder

3.5.  Both event of connectivity failures.

3.10.  Communication with HIP Hosts Behind without NAT

   This section describes the details Traversal Support

   The UDP encapsulation of enabling NAT traversal for HIP
   control and ESP data traffic, such as the base exchange
   [I-D.ietf-hip-base], through control packets has not been
   defined in any other IETF document and legacy hosts drop all UDP encapsulation, for the case when the
   encapsulated HIP initiator and the HIP responder are both behind two separate
   NATs.  The limitation ESP traffic.  Processing of this approach is that unknown locator
   types terminates the NAT middlebox MUST
   support endpoint independent mapping
   [I-D.srisuresh-behave-p2p-state].

   The registration and rendezvous relay are handled similarly as
   described in Section 3.3.3 and Section 3.4.1.  Now that both hosts
   are behind NATs, both base exchange or UPDATE.  As such, the initiator (Section 3.3) and responder
   (Section 3.4) mechanisms
   extensions defined in this document are combined here.  There is one exception
   though; the initiator does not retransmit an I1 but rather completely backwards
   compatible and require a NOTIFY
   message.

3.5.1.  NAT Traversal minimal support in implementations.

   A minimal implementation MUST provide UDP encapsulation of HIP Control Traffic

   Before an initiator can start the base exchange, and
   ESP packets.  In such a case, the responder minimal NAT traversal
   implementation MUST
   have completed a successful rendezvous client registration with its
   RVS using silently discard the mechanism described in Section 3.4.1.  The initiator processing of
   the HIP base exchange starts the base exchange by sending a UDP
   encapsulated I1 packet type 3
   locators to RVS. allow communication with implementations supporting NAT
   traversal defined in this document.  The UDP packet MUST have destination
   port number 50500 and the initiator is RECOMMENDED to use 50500 as
   source port number.  RVS minimal implementation MUST listen on
   support UDP port 50500.  RVS MUST
   accept the packet as described in Section 3.3.3.  As there has been a
   successful rendezvous client registration between the responder and
   the RVS as described in Section 3.4.1, the RVS knows keepalives to refresh state of the port number NAT(s).

   Hosts that conform to be used [I-D.ietf-hip-mm] respond to communicate UPDATE messages
   containing an ECHO_REQUEST with an UPDATE message containing an
   ECHO_RESPONSE.  This completes the responder through connectivity tests for the NAT.  RVS
   MUST add a FROM_NAT parameter to host
   supporting the I1 packet.  The FROM_NAT
   parameter contains extensions defined in this document.  As long as the source address
   implementation supports UDP encapsulation of the I1 packet, which HIP control packets,
   this requires no changes.

   The Relay extensions defined in this document do not work with
   minimalistic implementations.  When there is
   effectively a Relay between the address of
   hosts, both the outermost NAT of Initiator and Responder MUST support the initiator. extensions
   defined in this document.  The
   RVS copies the source port presence of RELAY_TO and RELAY_FROM
   parameters denotes the UDP encapsulated I1 packet into the
   port number field precence of the FROM_NAT parameter.  The FROM_NAT parameter
   is integrity protected by a relay.

4.  Packet Formats

   This section defines an RVS_HMAC as described in
   [I-D.ietf-hip-rvs].  It MUST replace the destination IP address of
   the I1 UDP-encapsulation packet by the one it had stored earlier during rendezvous
   client registration.  It MUST replace source IP address of I1 format for 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 are encapsulated within UDP.
   A minimal UDP packet
   with carries a complete HIP packet in its own address.  UDP source port payload.

   Contents of the relayed I1 packet MUST
   be 50500 UDP source and destination port ports are described below.
   The UDP length and checksum field MUST be the same computed as one it had stored
   during the client rendezvous registration.  It MUST recompute the IP described in
   [RFC0768].  The HIP header checksum.

   Upon receiving and parameter follow the VIA_RVS_NAT parameter, conventions
   [I-D.ietf-hip-base] with the initiator sends NOTIFY
   message without any contents to exception that the responder, which responder HIP header checksum
   MUST
   ignore.  This punches a hole to the NAT of the initiator.

   The responder receives the I1 relayed by the RVS.  The responder acts
   as described in Section 3.4.2 by replying with an R1. be zero.  The R1 punches
   a hole to the responder's NAT HIP header checksum is zero for two reasons.
   First, the initiator.  The R1 makes it to
   the initiator because the initiator UDP header contains already punched a hole checksum.  Second, the
   checksum definition in its own
   NAT with [I-D.ietf-hip-base] includes the empty NOTIFY message for IP addresses
   in the responder. checksum calculation.  The initiator and responder complete the rest NATs unaware of HIP cannot
   recompute the base exchange
   with I2 and R2. HIP checksum after changing IP addresses.

4.2.  Control Channel Keep-Alives

   The keep-alive for control channel are UDP encapsulated NOTIFY
   packets [I-D.ietf-hip-base].  The NOTIFY packets MAY contain HIP
   parameters.  The NAT state may timeout in case the R1 cookie was
   relatively large or in case the RTT is large.  For this reason, the
   initiator MUST refresh traversal mechanisms encapsulate these NOTIFY
   packets within the state payload of the NATs by resending empty
   NOTIFY messages until it receives an R2.

    +---+        +----+         +-------+            +----+        +---+
    |   +--(1)-->|    +---(2)-->+       |            |    |        |   | 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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               | RVS-R
     |                             Address                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Port              |    |<--(3a)--+       +---(3b)---->|             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 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 address in IPv4-in-IPv6
                 format.
     Port        Transport port number

       Figure 9: Format for the RELAY_FROM,  RELAY_TO and RELAY_VIA
                                parameters

   Figure 9 shows the format of 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                            |   |<-(4a)--+ N
     |                                                               | N  +--(4b)->|
     |                                                               |
     |                                                               | A
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Traffic Type   | A Loc Type = 2 | Locator Length | Reserved   |P|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Locator Lifetime                        | I +--(5a)->| T
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Transport Port            | T  |<-(5b)--+ R  Transp. Proto |    Kind      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Priority                            | -  |<-(6b)------------------(6a)->| -
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              SPI                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Locator                            |   |<-(7b)--+ I
     |                                                               | R  +--(7a)->|
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 10: Locator parameter

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

   +------------+----------+-------------------------------------------+
   | Field      | Value(s) | Purpose                                   |
   +------------+----------+-------------------------------------------+
   | Type       | 193      | Parameter type                            |   +--(8)-->|    +--------------(9)------------>|    +--(10)->|
   | Length     | Variable | Length in octets, excluding Type and      |
   |            |          | Length fields, and excluding padding.     |
   | Traffic    |   |<-(13)--+    |<-------------(12)------------+    |<-(11)--+ 0-2      |
    +---+        +----+                              +----+        +---+

    1.   IP(IP-I, IP-RVS)       UDP(50500, 50500)  I1(HIT-I, HIT-R)
    2.   IP(IP-NAT-I, IP-RVS)   UDP(11111, 50500)  I1(HIT-I, HIT-R)

    3a.  IP(IP-RVS, IP-NAT-I)   UDP(50500, 11111)
            NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
    3b.  IP(IP-RVS, IP-NAT-R)   UDP(50500, 44444)
            I1(HIT-I, HIT-R, FROM_NAT:[IP-NAT-I,11111], RVS_HMAC)

    4a.  IP(IP-RVS-R, IP-I)     UDP(50500, 50500)
            NOTIFY(HIT-R, HIT-I, VIA_RVS_NAT(IP-NAT-R, 44444)
    4b.  IP(IP-RVS, IP-R)       UDP(50500, 50500)
            I1(HIT-I, HIT-R, FROM_NAT:[NAT-I,11111], RVS_HMAC)

    5a.  IP(IP-I, IP-NAT-R)     UDP(50500, 44444) NOTIFY(HIT-I, HIT-R)
    5b.  IP(IP-R, IP-NAT-I)     UDP(50500, 11111)
            R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))

    6a.  IP(IP-NAT-I, IP-NAT-R) UDP(11111, 44444) NOTIFY(HIT-I, HIT-R)
    6b.  IP(IP-NAT-R, IP-NAT-I) UDP(44444, 11111)
            R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
    7a.  IP(IP-NAT-I, IP-NAT-R) UDP(11111, 50500) NOTIFY(HIT-I, HIT-R)
    7b.  IP(IP-NAT-R, IP-NAT-I) UDP(44444, 50500)
            R1(HIT-R, HIT-I, VIA_RVS_NAT(IP-FVS, 50500))
    8-10. I2(HIT-I, HIT-R), details similarly as in the cases before
    11-13 R2(HIT-R, HIT-I), details similarly as in the cases before

       Figure 10: UDP-encapsulated HIP base exchange (initiator and
                responder behind a NAT, RVS on public IP).

   The UDP hole punching is applicable only in the case when the NAT
   devices on the path support address independent mapping
   [I-D.srisuresh-behave-p2p-state].  After the initiator has received a
   VIA_RVS_NAT parameter 2 for unreflexive and has been in I1_SENT state leased, 1 for a policy
   specific period, the initiator MAY transition to E-FAILED state.
   Alternatively, it is RECOMMENED to switch to an external relay based
   protocol mechanism.

3.5.2.  NAT Traversal of HIP Data Traffic

   After a successful base exchange, both the HIP nodes have all the
   parameters with them to establish UDP BEET mode Security Association.
   The following section describes inbound and outbound security
   associations at initiator and responder.

3.5.2.1.  Security Associations at the Initiator

   The initiator of a base exchange defines its outbound SA as shown in
   Table 10

   +--------------+----------------------------------------------------+ | Field
   | Value Type       |
   +--------------+----------------------------------------------------+          | Outer src    | The local IP address from which the base exchange reflexive                                 |
   | address Locator    | packets were transmitted 3        | Transport locator                         | Outer dst
   | The peer IP address from which R2 packet was Type       |          | address                                           | received during base exchange
   | Locator    | UDP src port 19       | The as Length of the port number chosen to send I2 during    |
   |              | base exchange Locator field in 4-octet    |
   | UDP dst port | Source port of incoming R2 packet during base      | Length     |          | exchange units                                     |
   +--------------+----------------------------------------------------+

                    Table 10: Outbound SA at initiator

   The initiator of a base exchange defines its inbound SA as shown in
   Table 11

   +--------------+----------------------------------------------------+
   | Field Reserved   | Value 0        |
   +--------------+----------------------------------------------------+ Reserved for future extensions            | Outer src
   | The peer IP address from which R2 packet was Preferred  | 0        | address Usually zero for type 3 locators          | received during base exchange
   | (P) bit    | Outer dst          | The local IP address from which the base exchange                                           |
   | address Locator    | packets were transmitted Variable | Locator lifetime in seconds               | UDP src port
   | Source port of incoming R2 packet during base Lifetime   |          |                                           | exchange
   | Transport  | UDP dst port Variable | The as the port number chosen to send I2 during Zero for unreflexive and greater than     |
   | Port       | base exchange          |
   +--------------+----------------------------------------------------+
                     Table 11: Inbound SA at initiator

3.5.2.2.  Security Associations at the Responder

   The responder of a UDP-encapsulated base exchange defines its
   outbound SA shown in Table 12.

   +--------------+----------------------------------------------------+ zero otherwise                            | Field
   | Value Transport  |
   +--------------+----------------------------------------------------+ 0        | Outer src Zero for UDP                              | The local IP address from which the base exchange
   | Protocol   | address          | packets were transmitted                                           |
   | Outer dst Kind       | The peer IP as that used during base exchange Variable | 0 for unreflexive, 1 for relay reflexive, | address
   |            |          | UDP src port 2 for leased                              | The as source port chosen send R2 during base
   | Priority   | Variable | exchange Locator preference, see Section 3.6       |
   | UDP dst port SPI        | The as source port number of I2 packet during base Variable | 0 for relay reflexive, otherwise greater  |
   | exchange            |
   +--------------+----------------------------------------------------+

                    Table 12: Outbound SA at Responder

   Similarly, the responder of a UDP-encapsulated base exchange defines
   its inbound SA as shown in Table 13

   +--------------+----------------------------------------------------+          | Field than zero                                 | Value
   |
   +--------------+----------------------------------------------------+ Locator    | Outer src Variable | Source peer IP An IPv6 address as used in base exchange    | or an IPv4-in-IPv6 format | address
   |            |          | Outer dst IPv4 address[RFC2373]                     |
   +------------+----------+-------------------------------------------+

                 Table 3: Fields of the locator parameter

4.5.  RELAY_HMAC

   The local IP address from which RELAY_HMAC parameter value has the base exchange  | 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | address         Source Port           | packets were transmitted       Destination Port        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | UDP src port           Length              | The as source Port received from I2 during base           Checksum            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               | exchange
     ~                          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 dst port | packet carries the ESP packet in
   its payload.  The as contents of the UDP source port used to send R2 during base     |
   |              | exchange                                           |
   +--------------+----------------------------------------------------+

                     Table 13: Inbound SA at responder

3.6.  NAT Keep-Alives

   Typically, NATs cache an established binding and time it out if they
   have not used it to relay traffic for a given period 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 time. IPsec BEET-Mode ESP

   [RFC3948] describes UDP encapsulation of the IPsec ESP transport and
   tunnel mode.  This
   timeout is different for different NAT implementations.  The BEHAVE
   working group is discussing recommendations for standardized timeout
   values.  To prevent NAT bindings that support section describes the traversal UDP encapsulation of UDP-
   encapsulated HIP traffic from timing out during times when there is
   no control or data traffic, HIP hosts SHOULD send periodic keep-alive
   messages.

   Typically, only outgoing traffic refreshes the NAT port state for
   security reasons.  Consequently, both hosts SHOULD send periodic
   keep-alives for the
   BEET mode.

4.8.1.  UDP channel Encapsulation of all their established IPsec BEET-Mode ESP

   During the HIP
   associations if base exchange, the channel has been idle for two peers exchange parameters that
   enable them to define a specific period pair of
   time.

   For the 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 channel, keep-alives ports, MUST be UDP-encapsulated
   defined according to this section.  Two SAs MUST be defined on each
   host for one HIP NOTIFY
   packets 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 3.1.2.  The packets 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 use be inserted between the same IP and ESP header.
   The source and destination ports and IP addresses as the corresponding
   UDP tunnel. are filled in.  The default keep-alive interval for control channels
   SHOULD UDP checksum
   MUST be 20 seconds. calculated based on the outer addresses (locators) of the
   IPsec security association.  The peer host other fields of the HIP association UDP header are
   computed as described in [RFC0768].

   The resulting UDP packet MUST
   discard the keep-alives.

3.7.  HIP Mobility

   After a successful base exchange, a mobile node can change its
   network location using the mechanisms then undergo BEET IP header processing
   as defined in [I-D.ietf-hip-mm].
   This section describes such mobility mechanisms in the presence Section 5.4 of
   NATs.  However, [I-D.nikander-esp-beet-mode].

   Figure 12 illustrates the double jump scenario, where both peers move
   simultaneously, is excluded.

   The mobile node can change its location as described in Table 14.

   +----+---------------------------+----------------------------------+
   | No | From network              | To network                       |
   +----+---------------------------+----------------------------------+
   | 1  | Behind NAT                | Publicly Addressable Network     |
   | 2 BEET-mode UDP encapsulation procedure for a
   TCP packet.

     ORIGINAL TCP PACKET:
        +------------------------------------------+
        | Publicly Addressable inner IPv6 hdr | Behind NAT  ext hdrs  |     |      | Network
        |   with HITs    | if present | 3 TCP | Behind NAT-A Data | Stays behind NAT-A, but
        +------------------------------------------+

     PACKET AFTER BEET-MODE ESP PROCESSING:
        +----------------------------------------------------------+
        | inner IPv6 hdr | ESP | dest | different IP     |      | 4  ESP    | Behind NAT-A ESP | Behind NAT-B
        |   with HITs    | 5 hdr | Publicly Addressable opts.| TCP | Publicly Addressable Network Data | Trailer | ICV | Network
        +----------------------------------------------------------+
                               |<------- encryption -------->|
                         |<----------- integrity ----------->|

     FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING:
        +------------------------------------------------------------+
        | outer IPv4 |
   +----+---------------------------+----------------------------------+

                   Table 14: End host mobility scenarios

   The corresponding peer node can be located as follows Table 15
             +----+------------------------------------------+ UDP | No ESP | Peer Node network dest |
             +----+------------------------------------------+     | A      | Publicly Addressable Network With RVS  ESP    | ESP | B
        | Publicly Addressable Network Without RVS    hdr     | hdr | C hdr | Behind NAT With RVS opts.| TCP | Data | D Trailer | Behind NAT Without RVS ICV |
             +----+------------------------------------------+

                   Table 15: Peer host Network Scenarios

   The NAT traversal mechanisms may not work when the corresponding node
   is behind a NAT without RVS (case D), except when the mobile node
   stays behind the same cone NAT (case 3D).

   When a mobile node changes its location, it SHOULD detect the
   presence
        +------------------------------------------------------------+
                                 |<------- encryption -------->|
                           |<----------- integrity ----------->|

      Figure 12: UDP encapsulation of NATs along the new paths to its corresponding nodes using
   some external mechanism before sending any UPDATE messages.  If no
   NAT was detected in such a case, it SHOULD send an UPDATE to its
   corresponding nodes without IPsec  BEET-mode ESP packet
                         containing a TCP segment

4.8.2.  UDP encapsulation.

   The mobile node MUST send the UPDATE Decapsulation of IPsec BEET-Mode ESP

   An incoming UDP-encapsulated IPsec BEET-mode ESP packet through the corresponding
   node's RVS is
   decapsulated as follows.  First, if it uses one, in addition to sending it to the
   corresponding node directly.  The mobile node encapsulates the UPDATE
   packet within UDP only when it checksum is behind a NAT.  The corresponding
   node MUST reply using UDP when invalid, then
   the packet was encapsulated within
   UDP, or without UDP when the UDP header was not present in the UPDATE
   packet.

   The rendezvous server relays the UPDATE similarly to I1.  The
   rendezvous server MUST add FROM parameter when it gets an UPDATE
   packet without UDP encapsulation, or a FROM_NAT parameter when be dropped.  Then, the
   UPDATE packet it receives is UDP encapsulated and MUST be verified as
   defined in both cases
   protect the packet with a HMAC parameter.  Upon replying to the
   UPDATE, the corresponding node MUST add a VIA_RVS (or VIA_RVS_NAT)
   parameter to the reply.

   The mobile node MUST leave out the NATted locators from [I-D.nikander-esp-beet-mode].  If verified, the LOCATOR
   parameter.  This MUST be done before applying HMAC and SIGNATURE to
   an R1, I2 or UPDATE packet.  Thus, ESP data
   contained in the LOCATOR parameter consists
   only payload of the type and length fields when the mobile node has only
   NATted addresses.  When the mobile node has e.g. a single IPv6
   address and one NATted address, the LOCATOR parameter consists of
   single locator.  The UDP header along with its port number conveys
   the NATted locator to the peer.

3.8.  HIP Multihoming

   Multiple security associations can exists between the same hosts.
   They may be connected through several paths, some of which may
   include a NAT and others may not.  Implementations that support
   multihoming packet MUST support concurrent HIP associations between the same
   host pair be decrypted as
   described in a way that allows some of them to use UDP encapsulation
   while others are not UDP encapsulated.

3.9. [I-D.nikander-esp-beet-mode].

5.  Firewall Traversal

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

   When the initiator is behind a firewall, the

   The NAT traversal mechanisms described in Section 3 depend on require that the ability to initiate
   communication via
   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 destination port 50500 from arbitrary source
   ports and to receive UDP response traffic from 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
   chosen source port. firewall.

   Most firewall implementations support "UDP connection tracking",
   i.e., after a host behind a firewall has initiated a 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 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 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 50500 HIPPORT
   and destined to arbitrary source IP addresses and UDP ports.

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

   The NAT traversal mechanisms described in Section 3 require that the
   firewall - stateful or not - allow inbound UDP traffic to port 50500
   and allow outbound UDP traffic to arbitrary UDP ports.  If necessary
   for firewall traversal,
   ports reserved for IKE MAY be used for
   initiating new connections, but the implementation MUST be able to
   listen for UDP packets from port 50500.

4. are required.

6.  Security Considerations

4.1.

6.1.  A Difference to RFC3948

   Section 5.1 of [RFC3948] describes a security issue for the UDP
   encapsulation of 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 Responder in the public Internet.  The
   responder
   Responder cannot distinguish between the 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 Responder use the HITs to
   distinguish between different communication instances.

4.2.  Rendezvous and Responder

6.2.  Privacy Considerations

   The rendezvous usage LOCATORs are sent in this draft has been designed plain text.  Alternatively, they could be
   encrypted.  This option was not chosen to follow the
   RVS specification [I-D.ietf-hip-rvs] when allow packet inspection by
   middleboxes.  Plain text locators may be useful for HIP-aware
   middleboxes in the NAT supports end-point
   independent filtering.  However, as NAT networking presents some
   additional challenges, it future.

   It is not possible that an Initiator or Responder may not want to follow reveal
   all of its locators to its peer.  For example, a host may not want to
   reveal the RVS design
   exactly.  Particularly, internal topology of the mechanisms described in Figure 7 private address realm and
   Section 3.5.1 require that it
   discards unreflexive locators.  Such behavior creates non-optimal
   paths when the rendezvous server replies back to hosts are located behind the
   initiator same NAT.  Especially,
   this could be a problem with a message which includes legacy NAT that does not support
   routing from the private address realm back to itself through the
   outer address and port of the
   responder NAT.  Another design choice would have been  This scenario is referred to relay also as the R1 (and I2 in case of both hosts behind NAT) through
   hairpin problem [I-D.ietf-behave-p2p-state].  With such a legacy NAT,
   the
   rendezvous server only option left would be to delay use a leased transport locator from
   a relay.  As a consequence, a host may support locator-based privacy
   by leaving out the exposure 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 responder NAT address 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 port related information for additional DoS protection.  However, its use is not
   defined in this choice was document.  In opportunistic HIP, the Initiator sends
   the I1 message with null destination HIT.  Private address realms do
   not selected have unique addresses by definition.  Therefore, opportunistic
   mode is subject to reduce round trip time.  As failure even when there are no attackers present.
   In a
   consequence, the rendezvous client must accept normal HIP base exchange, a well-behaving Responder drops the risk of lowered
   privacy protection I1
   packet when it registers the destination HIT does not belong to it.  An attacker
   could respond to the RVS over UDP I1, but the base exchange would eventually fail
   as defined
   in Figure 8.

5. 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" range, i.e., 50500. 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 50500 HIPPORT to the port IANA has
   registered.

6.  Acknowledgements  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 (defined in Section
   4.3) o RELAY_HMAC (defined in Section 4.5)

8.  Acknowlegements

   The authors would like to thank Lars Eggert, Vivien Schmitt Schmitt, Abhinav
   Pathak and Andrei Gurtov for his their contributions to previous versions
   of this draft.  Thanks for Philip Matthews on introducing ICE
   concepts to the authors and for proposing the initial design.  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
   Tobias Heer, Teemu Koponen, Juhana Mattila, Jeffrey M. Ahrenholz,
   Thomas Henderson, Kristian Slavov, Janne Lindqvist, Pekka Nikander,
   Lauri Silvennoinen, Jukka Ylitalo, Andrei Gurtov and Juha
   Heinanen Heinanen, Joakim Koskela,
   Samu Varjonen, Dan Wing, Hannes Tschofenig and Jani Hautakorpi 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 describes
   significantly takes a
   different mechanisms that, among other differences, use
   external NAT discovery and do not require encapsulation servers. 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 for InfraHIP research in the Networking Research group at Helsinki
   Institute for Information Technology (HIIT).  The InfraHIP project is
   was funded by Tekes, Telia-Sonera, Elisa, Nokia, The the Finnish Defence
   Forces and Ericsson.

7.  Miika Komu wrote draft-ietf-hip-nat-02 version
   from scratch based on ICE-related comments from Philip Matthews.

9.  References

7.1.

9.1.  Normative References

   [I-D.ietf-hip-base]
              Moskowitz, R., "Host Identity Protocol",
              draft-ietf-hip-base-06
              draft-ietf-hip-base-08 (work in progress), June 2006. 2007.

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

   [I-D.ietf-hip-mm]
              Nikander, P.,
              Henderson, T., "End-Host Mobility and Multihoming with the
              Host Identity Protocol", draft-ietf-hip-mm-04 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 (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-16 (work in progress), June 2007.

   [I-D.nikander-esp-beet-mode]
              Melen, J. and P. Nikander, "A Bound End-to-End Tunnel
              (BEET) mode for ESP", draft-nikander-esp-beet-mode-06 draft-nikander-esp-beet-mode-07
              (work in progress), August 2006. February 2007.

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

   [RFC2119]  Bradner, S., "Key words for use 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 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.

7.2.

9.2.  Informative References

   [I-D.ietf-behave-nat-behavior-discovery]
              MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
              Using STUN", draft-ietf-behave-nat-behavior-discovery-00

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

   [I-D.ietf-behave-nat-udp]
              Audet, F. and C. Jennings, "NAT Behavioral Requirements
              for Unicast UDP", draft-ietf-behave-nat-udp-08 (work in
              progress), October 2006.

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

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

   [I-D.srisuresh-behave-p2p-state]
              Srisuresh, P., "State of Peer-to-Peer(P2P) Communication
              Across Network Address  Translators(NATs)",
              draft-srisuresh-behave-p2p-state-04

   [I-D.oliva-hiprg-reap4hip]
              Oliva, A. and M. Bagnulo, "Fault tolerance configurations
              for HIP multihoming", draft-oliva-hiprg-reap4hip-00 (work
              in progress),
              September 2006. July 2007.

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

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [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 Unicast UDP", BCP 127,
              RFC 4787, January 2007.

Appendix A.  Differences to ICE

   The protocol extensions defined in this draft are based on ICE.  The
   extensions are a rough translation of ICE concepts to HIP protocol.
   The translation preserved certain concepts as they are, but there are
   subtle differences.  This section tries to explain how ICE concepts
   were mapped to HIP protocol and what are the differences.

   The terminology for this draft is a hybrid of ICE and HIP
   terminology.  "Agent" was translated to "host" in favour of HIP
   terminology.  Transport address was changed to transport locator.
   Similarly, address pair 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 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 to peer reflexive locator and relayed
   candidate became leased transport locator.

   The component, base and foundation terms are not used in the document
   as there is only a single "media stream" for all (ESP) traffic
   between two hosts.

   There is no "lite" version ICE in this document, just full, as the
   full version is the preferred one also for ICE.  One specific
   scenario defined in this document has some resemblance to the lite
   ICE.  When a Responder is a publicly accessible server with fixed
   address, it may exclude the use of the relay.  In that case, it does
   not have to handle the RELAY parameters but still has to respond to
   the connectivity checks.

   A connectivity check is not a STUN Binding Request.  Instead, it is
   return routability check as defined in [I-D.ietf-hip-mm].  "Triggered
   check" occurs when a host receives a UPDATE with ECHO_REQUEST and it
   responds using a ECHO_RESPONSE and sends 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 to
   locator pairs that have been verified successfully by the return
   routability tests.

   The peers trigger the connectivity checks after the base exchange or
   after a base exchange.  The conclusion of the connectivity checks,
   i.e., selection of the final address pair, differs the most as a
   result of fitting the ICE nomination algorithm to HIP mobility
   mechanisms.  There is no "controlling agent" and the end-hosts make a
   local decision on which locator pair to choose.  This could lead to
   asymmetric address pairs, but the priority algorithm guarantees that
   the address pairs converge.  Also, there is are no aggressive and
   regular nomination modes as a consequence of the lack of controlling
   agent.

   ICE uses TLS, usernames and passwords as security mechanisms.  HIP
   has built-in security mechanisms that preferred over the ones that
   are used in ICE.

Appendix B.  Document Revision History

   To be removed upon publication

   +------------+------------------------------------------------------+
   | Revision   | Comments                                             |
   +------------+------------------------------------------------------+
   | schmitt-00 | Initial version.                                     |
   | ietf-00    | Officially adopted as WG item. Solved issues         |
   |            | 1-9,11,12                                            |
   | ietf-01    | Solved remaining issues except that relaying ESP and |
   |            | mobility were still incomplete.                      |
   | ietf-02    | Miika rewrote almost from scratch based on ICE.      |
   |            | Editorial corrections from Simon and Andrei.         |
   +------------+------------------------------------------------------+

Authors' Addresses

   Miika Komu (editor)
   Helsinki Institute for Information Technology
   Tammasaarenkatu 3
   Helsinki
   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

   Phone: +49 6221 4342 165
   Fax:   +49 6221 4342 155
   Email: simon.schuetz@netlab.nec.de
   URI:   http://www.netlab.nec.de/

   Martin Stiemerling
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 4342 113
   Fax:   +49 6221 4342 155
   Email: stiemerling@netlab.nec.de
   URI:   http://www.netlab.nec.de/

   Lars Eggert
   Nokia Research Center
   P.O. Box 407
   Nokia Group  00045
   Finland

   Phone: +358 50 48 24461
   Email: lars.eggert@nokia.com
   URI:   http://research.nokia.com/people/lars_eggert/

   Abhinav Pathak
   IIT Kanpur
   B204, Hall - 1, IIT Kanpur
   Kanpur  208016
   India

   Phone: +91 9336 20 1002
   Email: abhinav.pathak@hiit.fi
   URI:   http://www.iitk.ac.in/

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

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