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

   The Host Identity Protocol (HIP) describes a new communication
   mechanism for Internet hosts [RFC4423].  It introduces a new
   namespace and protocol layer between  Terminology

   In general, this document borrows the network terminology from
   [I-D.ietf-hip-base] and transport layers
   that decouples [RFC4423].  Additional terms are defined in
   the identifier and locator roles to support table below."  These draft e.g.
   mobility define "Initiator" and multihoming in
   "Responder"

   +---------------------+---------------------------------------------+
   | Term                | Explanation                                 |
   +---------------------+---------------------------------------------+
   | Rendezvous server   | A host that forwards I1 packets to the Internet architecture.

   The HIP protocol [I-D.ietf-hip-base] cannot operate across Network
   Address Translator (NAT) middleboxes, as described in
   [I-D.irtf-hiprg-nat].  This document specifies how      |
   |                     | Responder                                   |
   | HIP can traverse
   through legacy NAT middleboxes Relay           | A host that are not aware of forwards all HIP or ESP.  The
   mechanisms defined in this document do not assume 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 NAT
   middleboxes are reconfigured, as long as they allow UDP traffic.

   The use of HIP in NAT traversal has also some additional benefits
   provided by the new namespace.  First, it is possible to corresponding  |
   |                     | IPv4/v6 address
   hosts behind                             |
   | Unreflexive locator | An IPv4 or IPv6 address of a single NAT middlebox in network        |
   |                     | interface of a relatively simple way.  The
   NAT middlebox translates the locators, but the Host Identifiers and
   ESP SPIs remain the same.  Second, multiple services can share the
   same host                         |
   | Relay reflexive     | A translated transport layer port number behind locator of a single NAT.  There is no
   multiplexing issue host as long |
   | transport locator   | observed by a relay                         |
   | Peer reflexive      | A translated transport locator of a host as these services have different Host
   Identifiers.

   Several different flavors |
   | transport locator   | observed by its peer                        |
   | Leased transport    | Transport locator of NATs exist [RFC2663].  This document an ESP relay           |
   | locator             |                                             |
   +---------------------+---------------------------------------------+

                           Table 1: Terminology

2.  Introduction

   The Host Identity Protocol (HIP) describes HIP extensions a new communication
   mechanism for the traversal of both Network Address
   Translator (NAT) Internet hosts [RFC4423].  It introduces a new
   namespace and Network Address protocol layer between the network and Port Translator (NAPT)
   middleboxes.  It generally uses transport layers
   that decouples the term NAT to refer identifier and locator roles to both types support 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 legacy NAT
   middleboxes as described in [I-D.irtf-hiprg-nat].  This document
   specifies mechanisms that allow HIP to traverse through such NAT
   middleboxes that are neither HIP-aware nor ESP-aware, without manual
   configuration of the NAT middleboxes.

   HIP introduces a new namespace for hosts that decouples the identity
   of a host from its location [RFC4423].  The namespace consists of
   Host Identifiers which are public keys.  The hosts create the
   corresponding private keys by themselves which makes identity theft
   more difficult.

   The new namespace of HIP has some additional benefits when the
   extensions defined in this document are used.  First, it is possible
   to address hosts behind a single NAT middlebox in a relatively simple
   way.  The NAT middlebox translates the locators, but the Host
   Identifiers remain the 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 hosts have different Host Identifiers and UDP encapsulation
   is used for traversing the legacy NAT.

   Several different 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.  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 in
   Section 3.4 and draft in Section 3.5 for the third case.

   The mechanisms described here also cover use of rendezvous server
   from NATted environments.  The rendezvous server MUST be used when
   the responder is behind a unified method that has
   been adopted from Interactive Connectivity Establishment (ICE)
   protocol [I-D.ietf-mmusic-ice] and adapted to HIP.

   Legacy NAT because otherwise successful devices do not operate consistently although the behavior
   for new NAT
   traversal cannot be guaranteed. devices has been unified in [RFC4787].  The rendezvous server MUST be
   located HIP protocol
   extensions in a publicly addressable location.  Cascading this document make as little assumptions as possible of multiple
   NAT enabled rendezvous servers is not possible, although there may be
   other kind
   the behavior of rendezvous servers on the path.  The NAT middleboxes
   MUST support address independent mapping devices so that NAT traversal will work even
   with legacy NAT devices in the case where most general sense.  The purpose of
   the 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 this document.  The responder listens at it when necessary.

   Hosts that always get a fixed
   UDP port number for incoming HIP control packets.  The port number public addresses can be manually configured to the NAT to allow passing incoming
   traffic directly to use the host behind the NAT (port forwarding).  The
   benefit of such a configuration is rendezvous
   services as described in [I-D.ietf-hip-rvs].  Hosts that it does not require any can be
   located in private-address realms may use a transport-layer based
   relay service as defined in this document.  Both rendezvous server for the host behind and relay
   services forward HIP control packets, but the NAT.  Although this
   document does not prevent such configurations, it main difference is out of scope
   because of two drawbacks.  First, it allows that
   the rendezvous service forwards only a single responder
   behind the NAT box.  Second, manual configuration through several NAT
   devices may be difficult or administratively prohibited.

   The mobility and multihoming mechanisms initial I1 packet of HIP [I-D.ietf-hip-mm],
   allow HIP hosts to change network location during the lifetime of a
   base exchange while all other HIP association.  Consequently, hosts need to start using control packets are sent directly
   between the communicating hosts.  In contrast, the
   proposed relay service
   relays all HIP control packets because p2p-unfriendly NAT traversal mechanisms after a mobility event relocates
   one or both peers behind a NAT.  They may also stop using devices
   drop the
   proposed mechanisms if they both move to publicly addressable
   locations. packets otherwise [I-D.ietf-behave-p2p-state].  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are peers
   use the control channel to be interpreted as described in [RFC2119].

2.  Detecting NATs

   In order communicate their current locators to know whether each
   other to use find a direct path for carrying ESP encapsulated data
   traffic.  A direct path between the NAT traversal mechanisms, HIP hosts need to detect the presence and type enables efficient delivery
   of NAT middleboxes along
   the data traffic without relaying of ESP packets through an
   intermediary ESP relay.  The direct path to their peer hosts.  This document does not describe any
   new NAT detection mechanism but rather assumes that the NAT is
   detected searched using some external mechanism.  Hence, no special HIP
   parameters are required in HIP control messages to detect NATs.
   connectivity tests.

   The
   NAT detection MUST occur prior 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 each other in a base exchange, after node
   movement exchange.  The local locators are
   paired with peer locators and prior the pairs are prioritized according to sending UPDATE messages.

   For example, STUN [RFC3489] offers a generic mechanism for detecting
   both
   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 presence and type of connectivity tests.  The tests also
   determine whether transport layer encapsulation is required or not.
   As a NAT.  In STUN, result, the host contacts a
   STUN server hosts either detect that is always located at no transport locator pairs
   are working, or establish a publicly reachable address.
   The STUN server replies back and provides information on the NAT
   presence and type.

   A limitation number of STUN is that it cannot detect whether the responder
   is behind the working locator pairs and
   select a single pair to be used for communication.

   The same NAT as the initiator.  This can lead connectivity tests are also used in situations when a mobile
   host moves to an
   unoptimal route a different network.  The mobile host communicates its
   new location to the corresponding node through the public address relay server of
   its peer and starts the NAT, especially in
   combination the rendezvous extensions that are described later connectivity tests.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document.  In the worst case, the NAT may not be able
   document are to forward
   the traffic unless it supports "hairpin translation" be interpreted 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 [RFC2119].

3.  HIP Across NATs

   This section describes NAT as described in
   [I-D.ietf-behave-nat-behavior-discovery].  If the traversal between two HIP end-hosts.  A
   successful NAT supports
   hairpinning, the initiator uses traversal requires at least the UDP encapsulation procedures
   described Responder located in the following sections.  If the NAT does not support
   hairpinning, the initiator SHOULD broadcast a single I1 packet
   without UDP encapsulation
   private address realm to the local network.  The responder MUST
   process the I1 according register to [I-D.ietf-hip-base].  However, the
   initiator MUST continue with the UDP encapsulation mechanisms
   described in a relay server.  The use of the following sections because
   relay is optional when the responder may
   actually be Responder is located in a different network.

   HIP-aware NATs are not in public address
   realm without rendezvous server.

   The base exchange is relayed through the scope of this document.  In relay server.  Next, the future,
   it may be possible
   hosts test the reachability between the different locators to use some other protocol that
   construct a direct route.  When a direct route is launched in
   parallel with e.g.  STUN to detect not possible, the presence of HIP aware NATs.
   hosts resort to ESP relays.  When locators of a host change, the path between the initiator and responder consists
   hosts test reachability of locators again and select the "optimal"
   locator.  End-hosts can tear down HIP
   aware NATs, associations using the extensions defined in this CLOSE
   mechanism through the relay.

3.1.  Port Number Selection

   This document SHOULD NOT be
   used.

3. defines only UDP encapsulation for HIP Across NATs and ESP packets.
   Further extensions may define bindings for other transport protocols.
   The HIP RECOMMENDED transport protocol is UDP.

   It is RECOMMENDED that an Initiator selects a random port number
   between the 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 or ESP traffic.  As
   closed.  Alternatively, a result, such
   NATs just drop HIP control traffic and/or ESP data traffic.  As host MAY also use a
   solution single fixed port for this, we propose UDP encapsulation of
   initiating all outgoing connections.

   A relay or a Responder without a relay MUST listen at transport port
   HIPPORT for 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 host acting as a complete HIP packet Responder in its payload.
   Contents of a private address realm SHOULD
   use a HIP relay for NAT traversal.  It is RECOMMENDED that the UDP source and destination ports are described below.
   The UDP length and checksum field MUST be computed as described in
   [RFC0768].  The HIP header and parameter follow the conventions
   [I-D.ietf-hip-base]
   Responder uses also an ESP relay to guarantee successful NAT
   traversal with the exception that the HIP header checksum p2p-unfriendly NAT devices.

   A relay MUST be zero.  The HIP headers checksum is zero for two reasons.
   First, the UDP header contains already NOT forward any packets to a checksum.  Second, host that has not
   successfully registered to the
   checksum definition in [I-D.ietf-hip-base] includes relay.  The registration process
   follows the IP addresses generic registration extensions defined in the checksum calculation which is not applicable on HIP unaware
   NAT devices.

3.1.2.  Control Channel Keep-Alives

   The keep-alive for control channel are basically UDP encapsulated
   NOTIFY packets [I-D.ietf-hip-base].
   [I-D.ietf-hip-registration].  The NOTIFY packets MAY contain
   HIP parameters.  The NAT traversal mechanisms encapsulate these
   NOTIFY packets within 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ registration process is illustrated
   in Figure 1.

      Relay                                                    Relay
      Client                                                   Server
        |         Source Port   1. I1                                                |       Destination Port
        +------------------------------------------------------->|
        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                                        |           Length
        |           Checksum  2. R1(LOCATOR,REG_INFO(RELAY_UDP_HIP,RELAY_UDP_ESP))  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |<-------------------------------------------------------+
        |                                                        |
     ~                          ESP Header                           ~
        |   3. I2(LOCATOR,REG_REQ(RELAY_UDP_HIP,RELAY_UDP_ESP))  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2: Format for UDP-encapsulated IPsec ESP BEET-mode traffic.
        +------------------------------------------------------->|
        |                                                        |
        |   4. R2(REG_RES(RELAY_UDP_HIP,RELAY_UDP_ESP),REG_FROM) |
        |<-------------------------------------------------------|
        |                                                        |
        |               5. Connectivity tests                    |
        |<------------------------------------------------------>|

                 Figure 2 shows how IPsec ESP BEET-mode packets are encapsulated
   within UDP.  Again, 1: Example registration to a minimal UDP packet carries relay

   In the ESP packet in
   its payload.  The contents of above figure, the UDP source end-host is referred to as a relay client
   and destination ports
   are described in later sections.  The UDP length and checksum field
   MUST be computed as described 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                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         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              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          UDP Port             |            Padding            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     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 the VIA_RVS_NAT Parameter

   Figure 4 shows VIA_RVS_NAT parameter.  The parameter is used for
   diagnostic purposes, similarly as VIA_RVS parameter in
   [I-D.ietf-hip-rvs].  The exact use of this parameter is described in
   later sections.

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

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

3.2.1.  UDP Encapsulation of IPsec BEET-Mode ESP

   During the HIP base exchange, the two peers exchange parameters that
   enable them to define a pair of IPsec ESP security associations
   (SAs), as described in [I-D.ietf-hip-esp].  When two peers perform a
   UDP-encapsulated base exchange, they MUST define a pair of IPsec SAs
   that result in UDP-encapsulated BEET-mode ESP data traffic.

   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 for outgoing data and another one
   for incoming data.

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

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

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

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

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

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

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

       Figure 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 packet is
   decapsulated as follows.  First, if the UDP checksum is invalid, then
   the packet MUST be dropped.  Then, the packet MUST be verified as
   defined in [I-D.nikander-esp-beet-mode].  If verified, the ESP data
   contained in the payload of the UDP packet MUST be decrypted as
   described in [I-D.nikander-esp-beet-mode].

   The NAT traversal methods described in this section are based on
   connection reversal and UDP hole punching similar to
   [I-D.ietf-behave-nat-udp].  However, the methods in this section are
   adapted for HIP purposes, especially with the rendezvous server in
   mind.

3.3.  Initiator Behind NAT

   This section discusses mechanisms to reach a HIP responder located in
   publicly addressable network by a HIP initiator that is located
   behind a NAT.  The section describes also the case where the
   responder is using a rendezvous service.

   Table 1 lists some short-hand notations used in this section.  For
   simplicity, the ports mangled by NAT are presented as example port
   numbers (11111, 22222, etc) instead of symbolic ones.  In the
   examples, we assume that the NAT(s) timeout after the I1-R1 exchange
   over UDP because of e.g large RTT or high puzzle difficulty.  In such
   a case, the NAT drops 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 the responder's rendezvous       |
   |                  | server                                         |
   | IP-NAT-I         | Public IP of the NAT of the initiator          |
   | IP-NAT-R         | Public IP of the NAT of the responder          |
   | UDP(50500,11111) | UDP packet with source port 50500 and          |
   |                  | destination port 11111                         |
   | UDP(11111,22222) | Example port numbers mangled by a NAT          |
   | UDP(44444,22222) | Port 44444 is used throughout the examples to  |
   |                  | denote the NAT mangled source port of I2 as    |
   |                  | received by the rendezvous server during the   |
   |                  | registration                                   |
   +------------------+------------------------------------------------+

                  Table 1: Notations Used in This Section

3.3.1.  NAT Traversal of HIP Control Traffic

   This section describes the details of enabling NAT traversal for HIP
   control traffic for the base exchange [I-D.ietf-hip-base] through UDP
   encapsulation for the case when the initiator of the association is
   located behind a NAT and the responder is located in a publicly
   addressable network.  UDP-encapsulated HIP control traffic MUST use
   the packet formats described in Section 3.1.  When sending UDP-
   encapsulated HIP control traffic, a HIP implementation MUST zero the
   HIP header checksum before calculating the UDP checksum.  The
   receiver MUST only verify the correctness of the UDP checksum and
   MUST NOT verify the checksum of the HIP header.

   The initiator of a UDP-encapsulated HIP base exchange MUST use the
   UDP destination port 50500 for all control packets it sends.  It is
   RECOMMENDED to use 50500 as the source port as well, but 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 the
   corresponding HIP association is torn down.  The random source port
   is RECOMMENDED to be in the range of the dynamic and private ports
   (49152-65535).  Using a random source port, instead of a fixed one,
   enables 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].

   The responder of a UDP-encapsulated HIP base exchange MUST use 50500
   as the source port for all UDP-encapsulated control packets it sends.
   The source address for all the packets that the responder sends MUST
   be the same as the IP address on which responder receives packets
   from initiator.  The responder MUST respond to any arriving UDP-
   encapsulated control message using UDP encapsulation as well.  Hosts
   MUST process UDP-encapsulated base exchange messages equivalently to
   non-encapsulated messages, i.e., according to [I-D.ietf-hip-base].

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

        +---+           +---+                                 +---+
        |   |----(1)--->|   |---------------(2)-------------->|   |
        |   |           | N |                                 |   |
        |   |<---(4)----| A |<--------------(3)---------------|   |
        | I |           | T |                                 | R |
        |   |----(5)--->| - |---------------(6)-------------->|   |
        |   |           | I |                                 |   |
        |   |<---(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)
        8. IP(IP-R, IP-I)      UDP(50500, 50500)  R2(HIT-R, HIT-I)

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

   Before beginning the base exchange, the initiator detects that it is
   behind a NAT through some external mechanism, e.g.  STUN.  The
   initiator starts the base exchange by sending a UDP-encapsulated I1
   packet to the responder.  According to the rules specified above, the
   source IP address of this I1 packet is IP-I and its source UDP port
   is 50500.  It is addressed to IP-R on port 50500.  The NAT in
   Figure 6 forwards the I1 but substitutes the source address IP-I with
   its own public address IP-NAT-I and the source UDP port 50500 with
   11111.

   When the responder in Figure 6 receives the UDP-encapsulated I1
   packet on UDP port 50500, it decapsulates the packet and processes
   the decapsulated packet according to [I-D.ietf-hip-base].  The
   responder replies back with a UDP-encapsulated R1 using the addresses
   and port information of I1.  Thus, the R1 packet is destined to the
   source IP address and UDP port of the I1, i.e., IP address IP-NAT-I
   and port 11111.  The NAT receives the I1 and substitutes the
   destination of this packet with the initiator address (IP-I) and port
   information (50500).

   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 relay middlebox as a UDP-encapsulated I2
   packet, it uses the same IP source and destination addresses and UDP
   source and destination ports that it used for sending the
   corresponding I1 packet, i.e., the packet is addressed from IP-I port
   50500 to IP-R port 50500. relay server.  The NAT again substitutes the source
   information.  For illustration purposes, the NAT state times out and
   it chooses a different source port (22222) for the I2 than for 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 the initiator.  It then
   processes the I2 packet according to [I-D.ietf-hip-base].  When it
   responds with an R2 message, registration is
   piggybacked to a base exchange, but it UDP-encapsulates the message, can be done also using HIP
   UPDATE control packets as described in [I-D.ietf-hip-registration].

   In step 1, the UDP source port of relay client starts the I2 registration procedure by
   sending an I1 packet as over the destination UDP port, and
   sends it to transport layer.  The port selection
   was explained in section Section 3.1.

   In step 2, the source IP address of Responder lists the I2 packet, i.e., services that it sends supports in the R2 packet from IP-R port 50500 to IP-NAT-I port 22222.
   R1 packet.  The NAT
   again replaces support for HIP-over-UDP relaying is denoted by
   RELAY_UDP_HIP value and the destination information support for ESP-over-UDP relaying is
   denoted by a RELAY_UDP_ESP value in the R2 with IP-I port
   50500

   Usually, REG_INFO parameter.

   In step 3, the I1-R1 and I2-R2 exchanges occur fast enough for Initiator selects the NAT
   state services it registers to persist.  This means that the NAT uses and
   lists them in the same port for REG_REQ parameter.  In this example, the
   I1-R1 exchange Initiator
   registers both to translate as the I2-R2 exchange.  However, the host
   MUST handle even the case where HIP and ESP relay services.

   In step 4, the NAT state times out between relay server concludes the
   two exchanges registration procedure with
   an R2 packet and acknowledges the I1 and I2 arrive from different UDP source
   ports and/or IP addresses, as illustrated registered services 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 REG_RES
   parameter.  The initiator MUST use UDP destination port 50500 for all UDP-
   encapsulated ESP packets it sends.  It MAY relay may also use port 50500 as
   source port or it MAY use a random source port.  If it uses a random
   source port, it denote unsuccessful registrations in
   the REG_FAILED parameter in R2.  After the registration, the hosts
   MUST listen for and accept arriving UDP-encapsulated
   ESP send periodically NAT keepalive packets on to each other as defined
   later in this port until document.

   In step 5, the corresponding HIP association is
   torn down. client and server handle connectivity tests.  The responder of
   procedure is described in a UDP-encapsulated IPsec BEET-mode later section.

   When the ESP exchange MUST
   use 50500 as relay registration was successful, the relay server uses
   the source IP address and port for all UDP-encapsulated of the R2 packet (HIPPORT) to relay
   ESP packets it
   sends.  The destination port traffic with the client.  This address-port pair of the relay is
   referred to as a "leased transport locator" in this document.  As the
   port from which number may be shared by multiple clients, the responder is
   receiving UDP encapsulated ESP data from the initiator.

   Both relay MUST
   multiplex the initiator ESP traffic based on SPIs and not the just the port
   number.

   The R2 packet also includes an REG_FROM parameter that indicates the responder
   transport locator of the client as observed by the server.  The
   transport locator may be translated by a HIP association MUST define
   BEET mode with UDP encapsulation number of NAT middleboxes
   between the client and the server.  This locator is referred to as
   the IPsec mode for "relay reflexive transport locator" later in this document.

   A single server can provide multiple HIP middlebox services or the SA after
   services can be distributed among multiple servers.  The difference
   between a
   successful base exchange. HIP rendezvous server [I-D.ietf-hip-rvs] and a HIP relay
   server depends on the registration.  The inner source address MUST be rendezvous server processing
   rules apply when the local
   HIT used during base exchange Responder has registered to a middlebox with the
   RVS registration type.  Correspondingly, the middlebox applies the
   relay extensions defined in this document when the Responder has
   registered using the relay registration types.  When a single server
   provides both rendezvous and relay services, they are multiplexed
   depending on the inner destination address absence or presence of transport layer
   encapsulation.

   The Relay Client MUST
   be the HIT include a LOCATOR parameter in I2 which lists
   all of the peer.  The other parts locators of the SA are described Initiator.  The Relay Server MUST include
   a LOCATOR parameter in
   individual sections.

3.3.2.1.1.  Security Associations at R1, but it is RECOMMENDED that the Initiator

   The initiator LOCATOR
   parameter includes only the source transport LOCATOR of a UDP-encapsulated base exchange defines its
   outbound SA R1 as shown in Table 2

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | The local IP address from which the base exchange  |
   | address      | packets were transmitted                           |
   | Outer dst    |
   only locator.  The peer case when the Relay Server includes more locators
   may require IP address to which base exchange packets |
   | address      | were transmitted                                   |
   | UDP src port | The port number as chosen for I2 packet in base    |
   |              | exchange                                           |
   | header conversion between IPv4 and IPv6, insertion, or
   removal of, UDP dst port | Port 50500                                         |
   +--------------+----------------------------------------------------+

                     Table 2: Outbound SA at initiator

   The initiator of a UDP-encapsulated base exchange defines its inbound
   SA as shown header and fragmentation handling.  Multiple locators
   in Table 3

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | The peer IP address to which base exchange packets |
   | address      | were transmitted                                   |
   | Outer dst    | The local IP address from which R1 is left for further experimentation.

3.3.  Base Exchange via Relay

   It is RECOMMENDED that the base exchange  |
   | address      | packets were transmitted                           |
   | UDP src port | Port 50500                                         |
   | UDP dst port | Initiator MUST use sends an I1 packet over the UDP source port
   transport layer when it uses in  |
   |              | is destined to an IPv4 address of the outbound SA here                               |
   +--------------+----------------------------------------------------+

                     Table 3: Inbound SA at initiator

3.3.2.1.2.  Security Associations at
   Responder.  Respectively, the Responder MUST respond to a such I1
   packet with an R1 packet over the transport layer and using the same
   transport protocol.  The responder rest of a UDP-encapsulated the base exchange defines its
   outbound SA shown exchange, I2 and R2, MUST
   also be sent over the transport layer.  However, the transport layer
   encapsulation can be unnecessary when there are no NATs between the
   Initiator and Responder.  This will be detected in Table 4.

   +-------------+-----------------------------------------------------+
   | Field       | Value                                               |
   +-------------+-----------------------------------------------------+
   | Outer src   | The local IP address from which the base exchange   |
   | connectivity
   tests described in the next section.

   When the Initiator has an IPv6 address     | packets were transmitted                            |
   | Outer dst   | Peer IP and it has discovered only an
   IPv6 address of for the I2 packet received during    |
   | address     | peer, it MUST send it directly over IP.  In such
   a case, the base exchange                                   |
   | UDP src     | Port 50500                                          |
   | port        |                                                     |
   | UDP dst     | Source UDP port of Initiator MUST follow the I2 packet received from procedures described in
   [I-D.ietf-hip-base].  Otherwise, it is RECOMMENDED that the Initiator
   proceeds as shown in Figure 2.

      I                              Relay                          R
      | 1. I1                          | port                            | initiator during base exchange
      +------------------------------->| 2. I1(RELAY_FROM)          |
   +-------------+-----------------------------------------------------+

                     Table 4: Outbound SA at Responder

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

   +-------------+-----------------------------------------------------+
      | Field                                +--------------------------->|
      | Value                                |
   +-------------+-----------------------------------------------------+                            | Outer src
      | Source IP address of the I2 packet received from                                |    3. R1(LOCATOR,RELAY_TO) | address
      | the initiator during base exchange        4. R1(LOCATOR,RELAY_TO) |<---------------------------+
      |<-------------------------------+                            |
      | Outer dst                                | The local IP address from which the base exchange                            |
      | address 5. I2(LOCATOR)                 | packets were transmitted                            |
      +------------------------------->|                            | UDP src
      | Source UDP port of the I2 packet received from the                                | 6. I2(LOCATOR,RELAY_FROM)  |
      |                                +--------------------------->|
      | port                                | initiator during base exchange                            |
      | UDP dst                                | Port 50500            7. R2(RELAY_TO) |
      | port                8. R2(RELAY_TO) |<---------------------------+
      |<-------------------------------+                            |
      |
   +-------------+-----------------------------------------------------+

                     Table 5: Inbound SA at responder

3.3.3.  Use                                |                            |

                    Figure 2: Base Exchange via a relay

   In step 1 of the Rendezvous Service when only figure, the Initiator is Behind
        NAT discovers the HIT of the
   Responder and the IPv4 address of the relay of the Responder.  The rendezvous extensions for HIP without NAT traversal have been
   defined
   Initiator sends an I1 packet over the transport layer to the HIT of
   the Responder.  The port selection was explained in [I-D.ietf-hip-rvs].  This section Section 3.1.  The
   source address is one of the routable addresses only of the
   scenario where a NATted HIP node uses host is called
   "unreflexive locators" in this document.

   In step 2, the rendezvous service relay receives the I1 packet at port HIPPORT.  If the
   destination HIT belongs to
   contact another HIP node in a publicly addressable network.  Figure 7
   illustrates registered Responder, the mechanism described in this section.

   A rendezvous server relay
   processes the packet.  Otherwise, the relay MUST listen on UDP drop the packet.
   The relay MUST append a RELAY_FROM parameter to the I1 packet which
   preserves the transport source address and port 50500 for incoming UDP
   encapsulated of the Initiator.
   The relay protects the I1 packets.  However, in this specific case packet with only
   the initiator behind NAT, RELAY_HMAC as described in
   [I-D.ietf-hip-rvs], except that the rendezvous server parameter type is different.  The
   relay MUST NOT change the transport source to and destination of the
   packet to match the values the Responder used when registering to the
   relay, i.e., the reverse of the R2 used in the registration.  The
   relay MUST recalculate the transport checksum and forwards the packet
   to the Responder.

   In step 3, the Responder receives the I1
   packets.  Instead, packet at the transport
   layer.  The Responder MUST process it according to the rules in
   [I-D.ietf-hip-base].  In addition, the rendezvous server replies Responder MUST validate the
   RELAY_HMAC according to [I-D.ietf-hip-rvs] and drop the packet if the initiator
   validation fails.  The Responder replies with an R1 packet that MUST
   contain a NOTIFY message LOCATOR parameter that includes lists the responder's locators of the Responder.
   The locator in list consists of unreflexive, reflexive and leased
   transport locators of the Responder.  The R1 packet also contains a
   VIA_RVS
   RELAY_TO parameter.  The rendezvous server can differentiate this
   scenario from the others because RELAY_TO parameter contains same information
   as the I1 arrives UDP encapsulated, RELAY_FROM parameter, i.e., Initiator transport locator, but
   the responder has registered without UDP encapsulation.

   Upon receiving type of the NOTIFY with parameter is different.  The RELAY_TO parameter is
   not integrity protected by the locators signature of the responder through R1 to allow pre-
   created R1 packets at the NAT, Responder.

   In step 4, the relay receives the initiator R1 packet.  The relay MUST send an I1 drop the
   packet if the source HIT belongs to an unregistered host.  The relay
   MAY verify the responder.  However, signature of the R1 packet and drop it
   MUST continue retransmissions using when the RVS location.  This
   signature is
   mandatory because NOTIFY messages are not protected with signatures invalid.  Otherwise, the relay changes the destination
   transport header to match RELAY_TO information, recalculates
   transport checksum and can be forged by a rogue host.

   When forwards the packet.

   In step 5, the initiator Initiator receives an the R1 through packet and processes it
   accordingly to [I-D.ietf-hip-base].  It replies with an I2 packet
   that has the NAT, same transport locator as R1, but the responder
   verifies source and
   destination ports are swapped.  The I2 contains a LOCATOR parameter
   containing the integrity listing unreflexive, reflexive and leased transport
   locators of the Initiator

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

   In step 7, the Responder receives the I2 packet and processes it
   according to [I-D.ietf-hip-base].  It replies with an I2.  The
   responder should be aware that the I2 may arrive from R2 packet and
   includes a different
   port than RELAY_TO parameter as in step three.  The RELAY_TO
   parameter is protected by the I1. HMAC.

   In such a case, step 8, the responder should send relay processes the R2 as described in step four.  The
   relay forwards the packet to the source port of I2.

     +---+           +---+                     +-------+   +---+
     |   |----(1)--->|   |---------------(2)-->|       |   |   |
     |   |           |   |                     | RVS R |   |   |
     |   |<---(4)----|   |<--------------(3)---|       |   |   |
     |   |           |   |                     +-------+   |   |
     |   |           | N |                                 |   |
     |   |----(5)--->| Responder.

3.4.  Base Exchange without a Relay

   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)
     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))
     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 host that has a UDP-encapsulated publicly addressable, fixed IP address MAY exclude
   registration to a Relay.  As the Relay is not present, the host MUST
   listen at HIPPORT for transport-encapsulated HIP and ESP packets.  An
   UDP-encapsulated base exchange via RVS
    (initiator behind a NAT, responder with such an host does not have the
   RELAY_TO and RVS on RELAY_FROM parameters present.  Connectivity tests MUST
   be handled as defined in the public Internet).

3.4.  Responder Behind NAT

   This section discusses mechanisms to reach a HIP responder that is
   located behind a NAT.  This following section assumes that the initiator before any ESP traffic
   is
   located on publicly addressable network. allowed.

3.5.  Connectivity Tests

   The initiator contacts the
   responder through base exchange is completed with an RVS server.

3.4.1.  Rendezvous Client Registration From Behind NAT

   The rendezvous client registration [I-D.ietf-hip-rvs] describes R2 packet.  Then, the
   case when rendezvous client state of
   the HIP associations at both peers is present ESTABLISHED, but the peers MUST
   NOT allow any ESP traffic until the connectivity tests described in publicly addressable
   network.  This section defines an extension to
   the rendezvous client
   registration for next section are performed successfully.  All of the case when locators,
   except the rendezvous client has detected
   that it is behind a NAT.  The process relay address, are in UNVERIFIED state.  In the NAT case is identical to
   connectivity tests, the case without NAT, except that UDP encapsulation is used. hosts test connectivity between different
   locator pairs in order to find a working one.  The
   registration is connectivity tests
   are illustrated in Figure 8.

   A node 3.  In this example, both hosts are behind a NAT MUST first register to
   NATs.

     I                              Relay                            R
     |        2. R2(RELAY_TO)        |        1. R2(RELAY_TO)        |
     +<------------------------------+-------------------------------+
     |                                                               |
     |                3. UPDATE(ECHO_REQUEST,FROM_PEER)    NAT-R:DROP|
     +------------------------------------------------------------->X|
     |                                                               |
     |                4. UPDATE(ECHO_REQUEST,FROM_PEER)              |
     |<--------------------------------------------------------------+
     |                                                               |
     |                5. UPDATE(ECHO_RESP,TO_PEER)                   |
     +-------------------------------------------------------------->+
     |                                                               |
     |                6. UPDATE(ECHO_REQUEST,FROM_PEER)              |
     +-------------------------------------------------------------->|
     |                                                               |
     |                7. UPDATE(ECHO_RESP,TO_PEER)                   |
     |<--------------------------------------------------------------+
     |                                                               |

                       Figure 3: Connectivity tests

   The connectivity tests are handled as the RVS when it is going mobility extensions defined
   in [I-D.ietf-hip-mm] and are therefore subject to act as a responder the same processing
   rules.  The packets include ESP_INFO, SEQ, ACK, HMAC, SIGNATURE
   parameters that are omitted in this section for some other nodes. simplicity.  The node (i.e.
   rendezvous client) performs a base exchange with
   differences to the RVS over UDP as mobility extensions are described in Section 3.3 by sending I1 UDP encapsulated this section.

   In steps 1 and 50500 as
   destination port number.  RVS sends REG_INFO parameter in R1 2, the R2 packet is relayed from the Responder through
   the Relay to which
   rendezvous client replies with REG_REQ paramter the Responder.  After this, both hosts start
   connectivity tests using the return routability tests defined in I2.  Both I1 and
   R1
   [I-D.ietf-hip-mm].  The return routability tests are sent using UDP-encapsulation.  If RVS grants service used to the
   rendezvous client, it MUST store the source IP address and source
   port number of the I2 UDP packet that it had received probe
   for connectivity between each locator pair obtained from the
   rendezvous client local
   and peer locators obtained during base exchange.  The source IP address
   belongs to the NAT and the source port number is the NAT mangled
   port.  RVS then replies with REG_RESP return
   routability tests are also used as a UDP hole punching mechanism.
   The tests are carried in R2 over UDP.  If certain order which determined by the
   registration process results
   priorization algorithm defined in a successful REG_RESP, the rendezvous
   client MUST send next section.

   As an example, let's consider the case where hosts are testing each
   others outermost NAT keepalives (Section 3.1.2) addresses, i.e., relay reflexive transport
   locators.  In step 3, host I sends an UPDATE message containing an
   ECHO_REQUEST to keep the mapping
   in R. This will punch a hole the NAT with of I, but the RVS open.  The
   NAT keepalives sent from
   rendezvous client to the RVS MUST have the same source port as the I2
   packet.

   When the RVS receives an I1 packet from a HIP node to be relayed to of R drops the successfully registered rendezvous client behind NAT, RVS MUST
   relay message because the I1 over UDP NAT of R has no state with the destination port as the one stored
   during registration.  The RVS I.

   In step 4, R starts also zeroes reachability detection by sending an UPDATE
   with ECHO_REQUEST.  This traverses the HIP header checksum NAT of
   the I1.  This process is explained in Section 3.4.2.

        +---+           +---+                                 +---+
        |   |----(1)--->|   |---------------(2)-------------->|   |
        |   |           | N |                                 |   |
        |   |<---(4)----| A |<--------------(3)---------------|   |
        | I |           | T |                                 | R |
        |   |----(5)--->| - |---------------(6)-------------->|   |
        |   |           | I |                                 |   |
        |   |<---(8)----|   |<--------------(7)---------------|   |
        +---+           +---+                                 +---+ successfully because
   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) had already punched an hole into its NAT in step 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)  The
   Responder replies using ECHO_RESPONSE in step 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 of HIP Control Traffic

   This section describes  Upon receiving the
   ECHO_RESPONSE, the Responder transitions the address pair to VERIFIED
   state.

   In step 6, host I starts a new return routability test either due to
   a retransmission timer or as a reaction to UPDATE with ECHO_REQUEST
   received from R. In step 7, host R receives and sends a response to
   I. Upon receiving the details of enabling NAT traversal for base
   exchange response, host R transitions the locator pair
   being tested to VERIFIED state.

   All locators in UNVERIFIED state MUST be retransmitted RTIME times.
   The retransmission packets [I-D.ietf-hip-base] through UDP encapsulation, for MUST be paced Ta ms apart as defined in
   [I-D.ietf-mmusic-ice].  The retransmission are ordered in a sequence
   determined by the case when priority of the HIP initiator is on publicly addressable network
   and transport locator pairs, as
   described in the HIP responder next section.

   The source address of the UPDATE messages containing ECHO_REQUEST
   parameter is behind NAT. always an unreflexive IPv4 locator of the host.  The process
   destination locator is illustrated in
   Figure 9.

   Before the HIP base exchange starts, peer's unreflexive, reflexive or leased
   transport locator, depending on which address is being tested for
   reachability.  Implementations may add RTT measurement information to
   the responder ECHO_REQUEST parameter in addition to a nonce.

   The UPDATE messages carrying ECHO_REQUEST include a FROM_PEER
   parameter.  The sender of the HIP base
   exchange UPDATE MUST have completed a successful rendezvous client
   registration using copy the scheme defined in Section 3.4.1.

   The initiator source address of
   the HIP base exchange sends a plain I1 packet
   (without UDP encapsulation) UPDATE to the RVS as described in
   [I-D.ietf-hip-rvs].  In this case, FROM_PEER parameter.  When the rendezvous server detects that peer receives the I1
   UPDATE, it responds with an UPDATE containing and a ECHO_REQUEST and
   TO_PEER parameters.  The TO_PEER parameter MUST contain the source
   address of the UPDATE redundantly.  The reason from the FROM_PEER and
   TO_PEER parameters is not UDP encapsulated, but that it is possible to learn new addresses
   using them.  When there is p2p-unfriendly NAT between the rendezvous client peers, it
   may cause translate port number of the UPDATE packets to something
   that has
   registered using UDP encapsulation.

   To not been communicated through the relay before.  Such an
   addresses are called "peer reflexive transport locators" in this
   document.  The FROM_PEER and TO_PEER parameters can be used for
   detecting peer reflexive locators.  The learned locators are added to
   the I1 packet, RVS MUST zero connectivity tests.

   UPDATE packets destined to the HIP header checksum from 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 I1 packet.  RVS MUST add a FROM parameter, as described locator pairs in
   [I-D.ietf-hip-rvs], which contains the IP address of HIP initiator.
   The FROM parameter is integrity protected by a RVS_HMAC parameter as order
   described in [I-D.ietf-hip-rvs].  RVS replaces the destination IP
   address in the IP header of the packet with IP that it had stored
   during the rendezvous client registration (which is next section.  A host MUST transition the IP address state of
   transport locator pairs verified by the outermost NAT behind which rendezvous client is located).  It
   MUST then encapsulate return routability tests to
   the I1 packet within UDP.  The source port ACTIVE state.  Keepalive mechanisms described in
   the UDP header later sections
   MUST be 50500 and applied to refresh the destination port state in NAT devices for locators
   in the ACTIVE state.  A host MUST be also set up the
   same as Security
   Associations for the source port number (44444) inbound ESP traffic for such locators.  The
   selection of a default outbound SA is defined in the I2 packet which it had
   stored during the registration process.  RVS then recomputes the IP
   header checksum next section.

3.6.  Selecting an Address Pair

   This section describes priority ordering of connectivity tests and sends
   locators pair selection based on ICE [I-D.ietf-mmusic-ice].  As part
   of the packet.

                        +-------+
                        |       |
                 +----->|  RVS  +-----+           +----+
   +---+         |      |       |     |           |    |          +---+
   |   |---(1)---+      +-------+     +----(2)--->|    |---(3)--->|   |
   |   |                                          | N  |          |   |
   |   |<------------------(5)--------------------| A  |<--(4)----|   |
   | I |                                          | T priority calculation, each locator has a preference based on
   its type.  The values for these preferences are shown in Table 2.

            +-----------------------------------+------------+
            | Locator Type                      | R Preference |
            +-----------------------------------+------------+
            |   |-------------------(6)------------------->| -  |---(7)--->| The preferred locator             | 127        |
            | Unreflexive locator               | R 126        |
            | Peer reflexive transport locator  | 120        |   |<------------------(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 a NAT).

   The relayed I1 packet travels from RVS Relay reflexive transport locator | 100        |
            | Leased transport locator          | 0          |
            +-----------------------------------+------------+

                     Table 2: Locator Type Preferences

   In addition to the NAT.  The NAT changes "type" priority, the destination IP address priority of a locator is also
   affected by the UDP encapsulated I1 packet, and the
   destination port number in the UDP header.  The responder accepts the
   packet from the RVS "local" priority.  A (multihoming) host may have
   multiple locators of same type and processes it according to [I-D.ietf-hip-rvs].
   The resulting R1 must be encapsulated within UDP.  The responder MAY
   append SHOULD assign a VIA_RVS_NAT parameter unique local
   priority for each locator.  Hosts preferring IPv6 communication can
   assign higher local preferences for IPv6 locators than for
   unreflexive IPv4 locators.  ECHO_REQUEST parameters may include RTT
   calculation information that an implementation may use to increase
   the message, which contains the IP
   address of local priority.  A host SHOULD calculate locator priority based
   on the rendezvous local and the port the rendezvous server used for
   relaying the I1. type priorities as shown in Figure 4.  The RECOMMENDED source port is 50500 and the
   destination port number locator
   priority MUST always be 50500.  The destination address included in the IP header MUST be type 3 locator fields in
   LOCATOR parameters as described in section Section 4.4.

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

                        Figure 4: Locator priority
   A host SHOULD calculate a priority for each locator pair as shown in
   Figure 5.  I and R denote the priorities of locators of Initiator and
   Responder.  The use of the same as formula at both ends gives more
   guarantees that the one specified in peers prefer shortest paths between them.  It
   also converges the FROM
   parameter selection of the relayed I1 packet.

   The initiator MUST listen on port 50500 and locator pair towards a symmetric
   pair instead of an asymmetric pair even though it receives is not completely
   guaranteed.  The reasoning for the UDP
   encapsulated R1. formula is described in
   [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 verifying reachability tests, both hosts SHOULD assign the transport
   address pair with the highest pair priority as their default outgoing
   SA for ESP.

3.7.  Mobility

   When one of the HIP packet, hosts changes its locators, it concludes that has to notify its
   peers of the responder address change.  This is behind a NAT because handled as described in the packet was UDP
   encapsulated.  The initiator processes
   connectivity tests in Section 3.5 with the R1 control packet
   according to [I-D.ietf-hip-base] and replies using I2 exception that is UDP
   encapsulated.  The addresses and ports are derived from the received
   R1.

   The NAT translates and forwards UPDATE
   with parameter LOCATOR is used as the UDP encapsulated I2 packet trigger to start connectivity
   tests instead of the
   responder. R2.  The resulting R2 UPDATE packet is also UDP encapsulated using
   the address and port information from the received I2 packet.

3.4.3.  NAT Traversal of HIP Data Traffic

   After contains a successful base exchange, both 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 LOCATOR
   parameter listing unreflexive, reflexive and
   responder.

3.4.3.1.  Security Associations at the Initiator

   The initiator leased transport
   locators of a base exchange defines its outbound SA as shown in
   Table 6

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | The local IP address from which the base exchange  |
   | address      | 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 Initiator.  This is illustrated in Figure 6.

     Mobile                         Relay                Corresponding
     Node                            |                            Node
     |                               | exchange                               |
   +--------------+----------------------------------------------------+

                     Table 6: Outbound SA at initiator

   The initiator of a base exchange defines its inbound SA as shown in
   Table 7
   +--------------+----------------------------------------------------+
     | Field     1. UPDATE(LOCATOR)        | Value  2. UPDATE(LOCATOR,RELAY_TO)  |
   +--------------+----------------------------------------------------+
     +-------------------------------+------------------------------>|
     | Outer src                                                               | The peer IP address from which R2 packet was
     |                3. UPDATE(ECHO_REQUEST,FROM_PEER)     NAT: DROP|
     +------------------------------------------------------------->X|
     | address                                                               | received during base exchange
     |                4. UPDATE(ECHO_REQUEST,FROM_PEER)              | Outer dst
     |<--------------------------------------------------------------+
     | The local IP address from which the base exchange                                                               |
     | address                5. UPDATE(ECHO_RESP,TO_PEER)                   | packets were transmitted
     |-------------------------------------------------------------->|
     |                                                               | UDP src port
     | Source port of incoming R2 packet during base                6. UPDATE(ECHO_REQUEST,FROM_PEER)              |
     |<--------------------------------------------------------------|
     |                                                               | exchange
     |                7. UPDATE(ECHO_RESP,TO_PEER)                   | UDP dst port
     |-------------------------------------------------------------->|
     | Port 50500                                                               |
   +--------------+----------------------------------------------------+

                     Table 7: Inbound

                            Figure 6: Handover

   When a mobile host moves from a private address realm to another, it
   can obtain the same locator on both networks.  To denote that the new
   locator requires reachability detection, the mobile host MUST use a
   new SPI for the new locator.

   A host can also use the UPDATE mechanism can also be used for
   switching to a more optimal path after connectivity tests.  In the
   connectivity tests, the host may implement RTT measurements within
   ECHO_REQUEST and ECHO_RESPONSE messages.  In some cases the result of
   the RTT measurements may indicate that another locator pair is more
   optimal than the locator pair resulting from the connectivity and
   priority tests.  In such a case, the host MAY send UPDATE with
   LOCATOR parameter with the optimal locator with the preferred bit on.
   This gives the highest priority for the most optimal locator and will
   be used if the connectivity tests succeed.

3.8.  NAT Keepalives

   A NAT can delete the mapping state after a timeout when there is no
   traffic refreshing the state.  For this reason, both hosts MUST send
   keep-alives to each other for all locators pairs that are in the
   ACTIVE state.  Keepalives MUST be 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 in [I-D.oliva-hiprg-reap4hip] (XX FIXME: this
   needs still more details).  The basic idea is to keep track of HIP
   control and ESP packets received over a transport port.  When there
   is no HIP or ESP traffic (not even keep-alives) arriving during a
   certain time period, the host switches to an alternative locator
   pair.  The host transitions the default locator pair to the
   UNVERIFIED state and replaces the currently default SA at initiator

3.4.3.2.  Security Associations at to correspond
   to the Responder ACTIVE locator pair with the highest priority.  The responder host may
   also try to send an UPDATE packet with the LOCATOR parameter after a
   certain time period if connectivity is still broken.

   End-host may also used the keep-alives to detect loss of connectivity
   with relay server.  When this occurs, the end-host can register to a UDP-encapsulated base exchange defines its
   outbound SA shown in Table 8.

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | The local IP address from which
   new relay and replace 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, of the responder old relay server with a
   new one in DNS or DHT.

3.9.  Closing of HIP Associations

   A host closes a UDP-encapsulated base exchange defines
   its inbound SA HIP association as shown described in Table 9

   +--------------+----------------------------------------------------+
   | Field        | Value                                              |
   +--------------+----------------------------------------------------+
   | Outer src    | Source peer IP address [I-D.ietf-hip-base]
   except that the CLOSE and CLOSE_ACK packets are sent over transport
   layer and through the relay as used illustrated in base exchange    |
   | address Figure 7.  Hosts MUST
   transition the corresponding locator pairs to the DEPRECATED state
   after a successful CLOSE-CLOSE_ACK exchange.  The corresponding
   inbound and outbound SAs must be deleted on such occasion.

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

                     Table 9: Inbound SA at responder

3.5.  Both Hosts Behind NAT

   This section describes the details                             |                                 |

                  Figure 7: Closing of enabling NAT traversal for a HIP
   control and ESP data traffic, such as association

   The hosts may also use the base exchange
   [I-D.ietf-hip-base], through UDP encapsulation, for CLOSE mechanism to remove redundant SAs
   remaining from the case when connectivity tests.  However, the
   HIP initiator and removal can
   prolong the HIP responder are both behind two separate
   NATs.  The limitation of this approach is that recovery in the event of connectivity failures.

3.10.  Communication with HIP Hosts without NAT middlebox MUST
   support endpoint independent mapping
   [I-D.srisuresh-behave-p2p-state]. Traversal Support

   The registration UDP encapsulation of HIP and rendezvous relay are handled similarly as
   described ESP control packets has not been
   defined in Section 3.3.3 any other IETF document and Section 3.4.1.  Now that both legacy hosts
   are behind NATs, both the initiator (Section 3.3) and responder
   (Section 3.4) mechanisms are combined here.  There is one exception
   though; the initiator does not retransmit an I1 but rather a NOTIFY
   message.

3.5.1.  NAT Traversal of drop all UDP
   encapsulated HIP Control Traffic

   Before an initiator can start the base exchange, the responder MUST
   have completed a successful rendezvous client registration with its
   RVS using the mechanism described in Section 3.4.1.  The initiator and ESP traffic.  Processing of unknown locator
   types terminates the HIP base exchange starts or UPDATE.  As such, the base exchange by sending a UDP
   encapsulated I1 packet to RVS.  The UDP packet MUST have destination
   port number 50500
   extensions defined in this document are not completely backwards
   compatible and the initiator is RECOMMENDED to use 50500 as
   source port number.  RVS require a minimal support in implementations.

   A minimal implementation MUST listen on provide UDP port 50500.  RVS MUST
   accept the packet as described in Section 3.3.3.  As there has been encapsulation of HIP and
   ESP packets.  In such a
   successful rendezvous client registration between case, the responder and minimal NAT traversal
   implementation MUST silently discard the RVS as described processing of type 3
   locators to allow communication with implementations supporting NAT
   traversal defined in Section 3.4.1, the RVS knows this document.  The minimal implementation MUST
   support UDP 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 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 by the one it had stored earlier during rendezvous
   client registration.  It MUST replace source IP address of I1 carries a complete HIP packet
   with 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 in its own
   NAT with the empty NOTIFY message for the responder.

   The initiator and responder complete the rest of checksum.  Second, the base exchange
   with I2 and R2.  The NAT state may timeout
   checksum definition in case [I-D.ietf-hip-base] includes the R1 cookie was
   relatively large or IP addresses
   in case the RTT is large.  For this reason, the
   initiator MUST refresh the state checksum calculation.  The NATs unaware of HIP cannot
   recompute the NATs by resending empty
   NOTIFY messages until it receives an R2.

    +---+        +----+         +-------+            +----+        +---+
    |   +--(1)-->|    +---(2)-->+       |            |    |        |   |
    |   |        |    |         | RVS-R |            |    |        |   |
    |   |        |    |<--(3a)--+       +---(3b)---->|    |        |   |
    |   |        | 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 traversal mechanisms encapsulate these NOTIFY
   packets within the payload of UDP packets.

4.3.  RELAY_FROM, RELAY_TO and RELAY_VIA Parameters

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         +-------+             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |   |<-(4a)--+ N                             Address                           |
     | N  +--(4b)->|                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | A             Port              |             Padding           | A
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | I +--(5a)->| T Traffic Type   | Locator Type | T  |<-(5b)--+ R Locator Length | Reserved   |P|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Locator Lifetime                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | -  |<-(6b)------------------(6a)->| -                            Locator                            |
     |                                                               |
     |   |<-(7b)--+ I                                                               |
     | R  +--(7a)->|                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Traffic Type   | Loc Type = 2 | Locator Length | Reserved   |P|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Locator Lifetime                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Transport Port            |  Transp. Proto |   +--(8)-->|    +--------------(9)------------>|    +--(10)->|    Kind      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Priority                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              SPI                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Locator                            |
     |                                                               |
     |   |<-(13)--+    |<-------------(12)------------+    |<-(11)--+                                                               |
    +---+        +----+                              +----+        +---+

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

   The UDP hole punching is applicable only individual fields 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 LOCATOR parameter and has been in I1_SENT state 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 are described in
   Table 10

   +--------------+----------------------------------------------------+ 3.

   +------------+----------+-------------------------------------------+
   | Field      | Value Value(s) |
   +--------------+----------------------------------------------------+ Purpose                                   | Outer src
   +------------+----------+-------------------------------------------+
   | The local IP address from which the base exchange Type       | 193      | address Parameter type                            | packets were transmitted
   | Length     | Outer dst Variable | The peer IP address from which R2 packet was Length in octets, excluding Type and      |
   | address            | received during base exchange          | Length fields, and excluding padding.     | UDP src port
   | The as the port number chosen to send I2 during Traffic    | 0-2      | 2 for unreflexive and leased, 1 for relay | base exchange
   | Type       | UDP dst port          | Source port of incoming R2 packet during base reflexive                                 |
   | Locator    | exchange 3        |
   +--------------+----------------------------------------------------+

                    Table 10: Outbound SA at initiator

   The initiator Transport locator                         |
   | Type       |          |                                           |
   | Locator    | 19       | Length of a base exchange defines its inbound SA as shown the Locator field in
   Table 11

   +--------------+----------------------------------------------------+ 4-octet    | Field
   | Value Length     |
   +--------------+----------------------------------------------------+          | Outer src units                                     | The peer IP address from which R2 packet was
   | Reserved   | address 0        | received during base exchange Reserved for future extensions            |
   | Preferred  | 0        | Usually zero for type 3 locators          | Outer dst
   | The local IP address from which the base exchange (P) bit    |          | address                                           | packets were transmitted
   | Locator    | UDP src port Variable | Source port of incoming R2 packet during base Locator lifetime in seconds               |
   | Lifetime   | exchange          |                                           | UDP dst port
   | The as the port number chosen to send I2 during Transport  | Variable | Zero for unreflexive and greater than     | 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.

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

                    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            | Value          |
   +--------------+----------------------------------------------------+ than zero                                 | Outer src
   | Source peer IP address as used in base exchange Locator    | Variable | An IPv6 address or an IPv4-in-IPv6 format |
   |            | 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 and destination ports
   are described in later sections.  The UDP length and checksum field
   MUST be computed as described in [RFC0768].

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

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

4.8.1.  UDP Encapsulation of IPsec BEET-Mode ESP

   During the HIP base     |
   |              | exchange, the two peers exchange                                           |
   +--------------+----------------------------------------------------+

                     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 parameters that
   enable them to relay traffic for define a given period pair of time.  This
   timeout is different for different NAT implementations.  The BEHAVE
   working group is discussing recommendations for standardized timeout
   values.  To prevent NAT bindings 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 support the traversal produces UDP-encapsulated BEET-mode ESP data traffic.

   The management of UDP-
   encapsulated HIP traffic from timing out during times when there encryption/authentication protocols and security
   parameter indices (SPIs) is
   no control or data traffic, 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 hosts SHOULD send periodic keep-alive
   messages.

   Typically, only outgoing traffic refreshes the NAT port state association; one for
   security reasons.  Consequently, both hosts SHOULD send periodic
   keep-alives outgoing data and another one
   for incoming data.

   The BEET mode provides limited tunnel mode semantics without the UDP channel of all their established HIP
   associations if
   regular tunnel mode overhead [I-D.nikander-esp-beet-mode].  In the channel has been idle for a specific period of
   time.

   For
   BEET mode, transport-layer checksums in the UDP channel, keep-alives payload data are based on
   the HITs.  The packet MUST be UDP-encapsulated HIP NOTIFY
   packets 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.  The default keep-alive interval for control channels
   SHOULD be 20 seconds. are filled in.  The peer host of the HIP association UDP checksum
   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 defined in [I-D.ietf-hip-mm].
   This section describes such mobility mechanisms in be calculated based on the presence outer addresses (locators) of
   NATs.  However, the double jump scenario, where both peers move
   simultaneously, is excluded.
   IPsec security association.  The mobile node can change its location other fields of the UDP header are
   computed as described in Table 14.

   +----+---------------------------+----------------------------------+
   | No | From network              | To network                       |
   +----+---------------------------+----------------------------------+
   | 1  | Behind NAT                | Publicly Addressable Network     |
   | 2  | Publicly Addressable      | Behind NAT                       | [RFC0768].

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

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

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

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

                   Table 14: End host mobility scenarios

   The corresponding peer node can be located as follows Table 15
             +----+------------------------------------------+ ICV | No
        +----------------------------------------------------------+
                               |<------- encryption -------->|
                         |<----------- integrity ----------->|

     FINAL PACKET AFTER BEET_MODE IP HEADER PROCESSING:
        +------------------------------------------------------------+
        | Peer Node network outer IPv4 |
             +----+------------------------------------------+ UDP | A ESP | Publicly Addressable Network With RVS dest |     | B      | Publicly Addressable Network Without RVS  ESP    | ESP | C
        | Behind NAT With RVS    hdr     | hdr | D hdr | Behind NAT Without RVS opts.| TCP |
             +----+------------------------------------------+

                   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 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 UDP encapsulation.

   The mobile node MUST send the UPDATE packet through the corresponding
   node's RVS 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 is behind a NAT.  The corresponding
   node MUST reply using UDP when the packet was encapsulated within
   UDP, or without UDP when the Data | Trailer | ICV |
        +------------------------------------------------------------+
                                 |<------- encryption -------->|
                           |<----------- integrity ----------->|

      Figure 12: 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 encapsulation of an UPDATE IPsec  BEET-mode ESP packet without UDP encapsulation, or
                         containing a FROM_NAT parameter when the
   UPDATE TCP segment

4.8.2.  UDP Decapsulation of IPsec BEET-Mode ESP

   An incoming UDP-encapsulated IPsec BEET-mode ESP packet it receives is
   decapsulated as follows.  First, if the UDP encapsulated and MUST in both cases
   protect checksum is invalid, then
   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 be dropped.  Then, the LOCATOR
   parameter.  This packet MUST be done before applying HMAC and SIGNATURE to
   an R1, I2 or UPDATE packet.  Thus, the LOCATOR parameter consists
   only of the type and length fields when the mobile node has only
   NATted addresses.  When verified as
   defined in [I-D.nikander-esp-beet-mode].  If verified, the mobile node has e.g. a single IPv6
   address and one NATted address, ESP data
   contained in the LOCATOR parameter consists payload 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 UDP 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 plain text.  Alternatively, they could be
   encrypted.  This option was not chosen to allow packet inspection by
   middleboxes.  Plain text locators may be useful for HIP-aware
   middleboxes in this draft has been designed to follow the
   RVS specification [I-D.ietf-hip-rvs] when 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, normal HIP base exchange, a well-behaving Responder drops the I1
   packet when the destination HIT does not belong to it.  An attacker
   could respond to the I1, but the rendezvous client must accept base exchange would eventually fail
   as the risk of lowered
   privacy protection when it registers attacker would fail to prove its ownership of the RVS over UDP as defined
   in Figure 8.

5. 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,

   [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),
              July 2007.

   [I-D.irtf-hiprg-nat]
              Stiemerling, M., "NAT Behavior Discovery
              Using STUN", draft-ietf-behave-nat-behavior-discovery-00 and Firewall Traversal Issues of
              Host Identity Protocol (HIP)  Communication",
              draft-irtf-hiprg-nat-04 (work in progress), March 2007.

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

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

   [I-D.ietf-behave-nat-udp]

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

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, January 2005.

   [RFC4787]  Audet, F. and C. Jennings, "NAT "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", draft-ietf-behave-nat-udp-08 (work BCP 127,
              RFC 4787, January 2007.

Appendix A.  Differences to ICE

   The protocol extensions defined in
              progress), October 2006.

   [I-D.irtf-hiprg-nat]
              Stiemerling, M., "NAT 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 Firewall Traversal Issues of
              Host Identity Protocol (HIP)  Communication",
              draft-irtf-hiprg-nat-03 (work it
   responds using a ECHO_RESPONSE and sends its own ECHO_REQUEST.  A
   "check list" is effectively a LOCATOR parameter as defined in progress), June 2006.

   [I-D.nikander-hip-path]
              Nikander, P., "Preferred Alternatives for Tunnelling
   [I-D.ietf-hip-mm].  The term "ordinary check" is not really used in
   this document as it HIP
              (PATH)", draft-nikander-hip-path-01 (work packets are retransmitted periodically when
   the LOCATORs are in progress),
              March 2006.

   [I-D.srisuresh-behave-p2p-state]
              Srisuresh, P., "State 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 Peer-to-Peer(P2P) Communication
              Across Network Address  Translators(NATs)",
              draft-srisuresh-behave-p2p-state-04 (work in progress),
              September 2006.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology 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 Considerations",
              RFC 2663, August 1999.

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., 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 R. Mahy,
              "STUN - Simple Traversal
   regular nomination modes as a consequence 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 the lack of IPsec ESP Packets",
              RFC 3948, January 2005. 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 A. 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).