[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
Network Working Group                                          L. Eggert
Internet-Draft                                                       NEC
Expires: August 5, 2004                                 February 5, 2004


           Host Identity Protocol (HIP) Rendezvous Mechanisms
                      draft-eggert-hip-rendezvous

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

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

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

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

   This Internet-Draft will expire on August 5, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document discusses rendezvous mechanisms for the Host Identity
   Protocol (HIP). Rendezvous mechanisms, such as HIP Rendezvous
   Servers, improve operation when HIP nodes are multi-homed or mobile.
   They can also facilitate communication between HIP and non-HIP nodes.
   Possible rendezvous mechanisms differ in performance, compatibility,
   and impact on the HIP and Internet architectures.










Eggert                   Expires August 5, 2004                 [Page 1]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Communication Between HIP Nodes  . . . . . . . . . . . . . .  5
   3.    Communication Between Mobile or Multi-Homed HIP Nodes  . . .  7
   3.1   Mobility and Multi-Homing with DNS Updates . . . . . . . . .  7
   3.2   Mobility and Multi-Homing with Rendezvous Servers  . . . . .  8
   4.    Communication Between HIP and Non-HIP Nodes  . . . . . . . . 11
   4.1   Non-HIP Initiator to HIP Responder . . . . . . . . . . . . . 11
   4.2   HIP Initiator to Non-HIP Responder . . . . . . . . . . . . . 12
   4.3   Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.3.1 Relaying Overhead  . . . . . . . . . . . . . . . . . . . . . 14
   4.3.2 Return Traffic . . . . . . . . . . . . . . . . . . . . . . . 14
   4.3.3 Node Identification  . . . . . . . . . . . . . . . . . . . . 14
   4.3.4 Network Address Translation  . . . . . . . . . . . . . . . . 15
   5.    Rendezvous Broker  . . . . . . . . . . . . . . . . . . . . . 16
   5.1   Comparison to Rendezvous Servers . . . . . . . . . . . . . . 17
   5.2   Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   5.3   Tunneling  . . . . . . . . . . . . . . . . . . . . . . . . . 18
   6.    Security Considerations  . . . . . . . . . . . . . . . . . . 20
   7.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 21
         Normative References . . . . . . . . . . . . . . . . . . . . 22
         Informative References . . . . . . . . . . . . . . . . . . . 23
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 24
   A.    Document Revision History  . . . . . . . . . . . . . . . . . 25
         Intellectual Property and Copyright Statements . . . . . . . 26

























Eggert                   Expires August 5, 2004                 [Page 2]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


1. Introduction

   The current Internet uses two global namespaces: domain names and IP
   addresses. The Domain Name System (DNS) provides a two-way lookup
   service between the two [1]. Domain names are symbolic identifiers
   for sets of IP addresses.

   IP addresses have two uses. First, they are topological locators for
   network attachment points. Second, they act as names for the attached
   network interfaces. Saltzer [13] discusses these naming concepts in
   detail.

   Routing and other network-layer mechanisms are based on the locator
   aspects of IP addresses. Transport-layer protocols and mechanisms
   typically use IP addresses in their role as names for communication
   endpoints.

   This dual use of IP addresses limits the flexibility of the Internet
   architecture. The need to avoid readdressing in order to maintain
   existing transport-layer connections complicates advanced
   functionality, such as mobility, multi-homing, or network
   composition. Sunshine summarizes the consequences of addressing on
   advanced network functions [14].

   The Host Identity Protocol (HIP) architecture [2] defines a new third
   namespace. The Host Identity namespace decouples the name and locator
   roles currently filled by IP addresses. Instead of mapping domain
   names directly into IP addresses, HIP maps domain names into Host
   Identities, and Host Identities into IP addresses. Transport-layer
   mechanisms operate on Host Identities instead of using IP addresses
   as endpoint names. Network-layer mechanisms continue to use IP
   addresses as pure locators.

   Without HIP, nodes establish transport-layer connections by first
   looking up the fully-qualified domain name (FQDN) of a peer in the
   DNS. A successful DNS lookup returns the peer's IP addresses. A node
   uses one of the returned IP addresses to initiate transport-layer
   communication with a peer node.

   HIP nodes will also look up the domain name of desired peers in the
   DNS. When a successful lookup includes a peer's Host Identities, HIP
   nodes perform a HIP Base Exchange before establishing transport-layer
   connections. The HIP Base Exchange authenticates the end hosts and
   can bootstrap encryption of the subsequent communication with IPsec
   [15]. The HIP specification [3] discusses the details of the Base
   Exchange and the related protocol exchanges.

   After the Base Exchange, HIP nodes use Host Identities instead of IP



Eggert                   Expires August 5, 2004                 [Page 3]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   addresses for transport-layer connections with a peer. The HIP layer
   in the network stack internally translates Host Identities (HI) into
   network-layer IP addresses. This additional mapping between Host
   Identities and IP addresses (HI->IP) is logically separate from the
   first mapping between fully-qualified domain names and Host
   Identities (FQDN->HI).

   For application and transport-layer compatibility, the FQDN->HI
   mapping must remain in the DNS. However, the HI->IP mapping is
   internal to the HIP layer and may be performed in a number of ways.
   Different lookup mechanism may support communication between two
   mobile or multi-homed HIP nodes better [4].

   Transparent communication between HIP and non-HIP nodes places
   additional restrictions on the lookup mechanisms. For example,
   non-HIP nodes expect DNS lookups to return IP addresses, requiring
   the HI->IP mapping (or a representation thereof) to remain in the
   DNS. Section 4 discusses communication between HIP and non-HIP nodes
   and describes different alternatives that support it.
































Eggert                   Expires August 5, 2004                 [Page 4]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


2. Communication Between HIP Nodes

   In the current Internet, the DNS provides a FQDN->IP mapping. With
   HIP, it must continue to provide a mapping based on domain names.
   This allows transport-layer connections to bind to Host Identities
   instead of IP addresses transparently.

   Instead of mapping domain names directly into IP addresses
   (FQDN->IP), with HIP the DNS maps them to Host Identities (FQDN->HI).
   In a second step, another lookup that is internal to the HIP-layer
   translates the Host Identities into IP addresses for network-layer
   delivery (HI->IP).

   Several alternative approaches are possible for maintaining the
   HI->IP information. The DNS can maintain this mapping along with the
   FQDN->HI mapping. Alternatively, a database separate from the DNS can
   manage this information. This section discusses the different
   approaches and their implications on communication between two HIP
   nodes. Section 4 will discuss the compatibility aspects of the
   alternatives described here when HIP and non-HIP nodes communicate.

   The HIP architecture and protocol specifications suggest storing Host
   Identities along with a node's IP addresses in the DNS [2][3]. The
   index for both tables will be domain names. Logically, the DNS will
   thus contain two separate mappings: FQDN->HI and FQDN->IP.

                       #1 FQDN(R)      +----------+
                 +-------------------->|   DNS    |
                 | +-------------------|          |
                 | |  #2 HI(R), IP(R)  | FQDN->HI |
                 | |                   | FQDN->IP |
                 | |                   +----------+
                 | V
               +-----+       #3 HIP Base Exchange      +-----+
               |     |-------------------------------->|     |
               |  I  |<--------------------------------|  R  |
               |     |-------------------------------->|     |
               |     |<--------------------------------|     |
               +-----+                                 +-----+

                 Figure 1: HIP Lookup and Base Exchange

   Figure 1 shows the lookup steps and HIP Base Exchange when a node's
   Host Identities are stored alongside its IP addresses. In step #1,
   the initiator I performs a DNS lookup on R's domain name FQDN(R). The
   DNS server responds with both R's Host Identities HI(R) and its IP
   addresses IP(R) in step #2.




Eggert                   Expires August 5, 2004                 [Page 5]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   The initiator I uses both pieces of information to perform the HIP
   Base Exchange with R in step #3. (The details of the Base Exchange,
   specified in [3], are not relevant to this discussion and will thus
   be omitted.)

   Note that the DNS does not currently store the HI->IP mapping
   directly. Instead, a DNS lookup on a domain name returns both its
   FQDN->HI and FQDN->IP entries. The HIP stack then implicitly
   constructs the HI->IP mapping based on the HI and IP information
   returned by the DNS lookup. In the example in Figure 1, the FQDN(R)
   lookup in step #1 returns both HI(R) and IP(R) in step #2. HIP
   implicitly constructs the HI(R)->IP(R) mapping based on the
   assumption that HI(R) is reachable at IP(R).

   One disadvantage of this approach is that a node's domain name is
   required to obtain both its Host Identities and its IP addresses.
   Even if a HIP node already knows the Host Identity of a HIP peer
   through other means, it cannot currently obtain the peer's IP
   addresses through the DNS. The DNS does not maintain an explicit
   HI->IP table, but instead indexes Host Identities only by domain
   names.

   A reverse HIP->FQDN DNS mapping could address this limitation. HIP
   nodes would then look up a HIP peer's domain name through its Host
   Identity. They would then use the returned domain name to find the
   peer's IP addresses in a second lookup. However, the DNS may not be
   structurally suited to maintain the reverse HIP->FQDN mapping. As the
   main Internet-wide database, the DNS is already being overloaded with
   functionality that might be better handled with new mechanisms [16].
   Finally, the additional reverse lookup would increase the latency of
   the HIP Base Exchange.




















Eggert                   Expires August 5, 2004                 [Page 6]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


3. Communication Between Mobile or Multi-Homed HIP Nodes

   HIP decouples domain names from IP addresses. Because transport
   protocols bind to Host Identities, they remain unaware if the set of
   IP addresses associated with a Host Identity changes. This change can
   have various reasons, including, but not limited to, mobility and
   multi-homing.

   Proposed extensions for mobility and multi-homing [4] allow a HIP
   node to notify its peers about changes in its set of IP addresses.
   These extensions require an established HIP association between two
   nodes, i.e., a completed HIP Base Exchange.

   In addition to notifying its current peers about changes in its IP
   addresses, a HIP node must also update its HI->IP mapping in response
   to IP address changes. Otherwise, HIP Base Exchanges from new peers
   could fail because they try to contact the node at an IP address it
   is no longer reachable at.

3.1 Mobility and Multi-Homing with DNS Updates

   If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP
   table, nodes can dynamically update their DNS entry in a secure
   fashion [5][6]. The DNS server maintaining the information will then
   sign and distribute the updated zone.

              #2 FQDN(R)     +----------+
       +-------------------->|   DNS    |
       | +-------------------|          |<------+
       | |  #3 HI(R), IP(R)  | FQDN->HI |       | #1 Update
       | |                   | FQDN->IP |       |    FQDN(R)->IP(R)
       | |                   +----------+       |    whenever IP(R)
       | V                                      |    changes.
     +-----+       #4 HIP Base Exchange      +-----+
     |     |-------------------------------->|     |
     |  I  |<--------------------------------|  R  |
     |     |-------------------------------->|     |
     |     |<--------------------------------|     |
     +-----+                                 +-----+

        Figure 2: HIP Lookup and Base Exchange with DNS Updates

   Figure 2 shows an example of this scenario. In step #1, R registers
   its FQDN(R)->IP(R) entry in the DNS. It will dynamically update the
   DNS entry whenever its IP addresses IP(R) change. Because the DNS
   always contains R's current IP addresses, node I can perform a HIP
   Base Exchange with R at its new IP address (steps #2-4).




Eggert                   Expires August 5, 2004                 [Page 7]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   One drawback of using dynamic DNS updates in this way is the cost of
   updating secure zones. Re-signing an entire zone whenever the IP
   addresses of one entry change places a high cost on the DNS server.
   Using dynamic DNS to update HI->IP mappings may thus not be
   appropriate when changes of IP addresses are frequent.

   A simple, operational change could help limit the costs of frequent
   DNS updates. Instead of recomputing a zone after each dynamic update,
   a DNS server could aggregate the modifications and only perform zone
   updates periodically. The disadvantage of this approach is that HIP
   nodes may be unreachable until the DNS server distributes the updated
   zone.

   Another concern with using the DNS to support HIP node mobility is
   the propagation time of updated DNS entries. DNS servers frequently
   cache DNS responses to reduce the load on the primary servers. During
   the time-to-live associated with a DNS response, DNS servers may
   answer additional requests for the same DNS entry from their local
   caches instead of contacting the primary servers. Thus, even after a
   HIP node updates its DNS entry, the DNS can still serve the old entry
   until the cached responses expire. This can lead to communication
   problems, because peers may try to contact a HIP node at an IP
   address it is no longer reachable at.

3.2 Mobility and Multi-Homing with Rendezvous Servers

   The HIP architecture tries to greatly reduce the frequency of Dynamic
   DNS updates by introducing Rendezvous Servers [2]. Instead of
   registering its current set of IP addresses in its HI->IP entry in
   the DNS, a HIP node may instead register the IP addresses of its
   Rendezvous Servers. Because the IP addresses of Rendezvous Servers
   are assumed to change only infrequently, this approach can
   significantly reduce the load on DNS servers.

   Rendezvous Servers maintain a mapping between the Host Identities of
   HIP nodes for which they provide service and the node's current IP
   addresses. HIP nodes must notify their Rendezvous Servers about any
   changes in their IP addresses. This approach effectively relocates
   the HI->IP information - and the burden of keeping it current - from
   the DNS to the Rendezvous Servers. This can reduce update costs under
   the assumption that Rendezvous Servers provide more efficient ways of
   maintaining HI->IP tables.

   When a packet destined for one of its HIP nodes arrives at a
   Rendezvous Server, it relays the packet to one of the HIP node's
   current IP addresses. Due to the specifics of the HIP, only the first
   packet of a HIP Base Exchange will require such relaying [2].
   Subsequent packet of the HIP Base Exchange and all further data



Eggert                   Expires August 5, 2004                 [Page 8]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   packets will directly flow between the HIP nodes, bypassing the
   Rendezvous Server.

               #3 FQDN(R)      +----------+ #2 Register IP(RVS) in
        +--------------------->|   DNS    |    FQDN(R)->IP(RVS).
        | +--------------------|          |<------------------+
        | |  #4 HI(R), IP(RVS) | FQDN->HI |                   |
        | |                    | FQDN->IP |                   |
        | |                    +----------+                   |
        | |                                                   |
        | |                   #1 Update IP(R) in HI(R)->IP(R) |
        | |        +--------+    whenever IP(R) changes.      |
        | |        |  RVS   |<------------------------------+ |
        | |        |        |                               | |
        | V     +->| HI->IP |--+                            | |
      +-----+   |  +--------+  |                          +-----+
      |     |---+              +------------------------->|     |
      |  I  |    #5 First Message of HIP Base Exchange    |  R  |
      |     |                                             |     |
      |     |<--------------------------------------------|     |
      |     |-------------------------------------------->|     |
      |     |<--------------------------------------------|     |
      +-----+       #6 Remainder of HIP Base Exchange     +-----+

     Figure 3: HIP Lookup and Base Exchange with Rendezvous Server

   Figure 3 shows a HIP lookup and Base Exchange involving a Rendezvous
   Server. Here, HIP node R is using Rendezvous Server RVS. In step #1,
   it updates RVS with its current IP addresses IP(R). Then, in step #2,
   R registers the Rendezvous Server's IP addresses IP(RVS) in its
   FQDN(R)->IP(RVS) DNS entry.

   In step #3, a second HIP node I issues a DNS lookup on FQDN(R) to
   obtain R's Host Identities HI(R) and IP addresses. The lookup returns
   R's Host Identities HI(R) in step #4. The DNS reply also includes the
   IP addresses of the Rendezvous Server IP(RVS) (instead of IP(R),
   because R's current addresses are unknown to the DNS.)

   In step #5, node I initiates the HIP Base Exchange. It addresses the
   first packet of the HIP Base Exchange to IP(RVS). Upon receipt, the
   Rendezvous Server relays the packet to one of R's current IP
   addresses IP(R). The remainder of the HIP Base Exchange then occurs
   directly between I and R in step #6.

   When Rendezvous Servers maintain the HI->IP information, they may
   support more efficient update operations compared to dynamic DNS
   updates (Section 3.1). Unlike the DNS, Rendezvous Servers do not
   provide a lookup service. Instead, they use the HI->IP information to



Eggert                   Expires August 5, 2004                 [Page 9]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   actively relay traffic between HIP nodes.

   This approach changes the role of the IP addresses stored in a DNS
   entry. Traditionally, nodes were directly reachable at the IP
   addresses listed in their DNS entry. HIP Rendezvous Server change
   this basic property by replacing the IP addresses of their client
   nodes in the DNS with their own. The IP addresses in a DNS entry
   hence no longer directly designate interfaces of an endpoint.
   Instead, they identify interfaces of a node that can relay packets to
   the endpoint.

   When two HIP nodes communicate, this change has few consequences. HIP
   decouples higher layers from underlying IP addresses. However, when
   HIP and non-HIP nodes communicate, this change has a significant
   impact on the overall architecture. Section 4 will discuss the
   implications in detail.



































Eggert                   Expires August 5, 2004                [Page 10]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


4. Communication Between HIP and Non-HIP Nodes

   Section 2 and Section 3 have discussed communication between HIP
   nodes. This section focuses on communication between HIP and non-HIP
   nodes. Two different scenarios exist. First, a HIP initiator may
   start communication with a non-HIP recipient. Second, a non-HIP
   initiator may try to contact a HIP recipient.

   Without Rendezvous Servers, communication between HIP and non-HIP
   nodes remains identical to the current Internet. Transport-layer
   protocols bind directly to IP addresses. When IP addresses change,
   due to mobility or other reasons, transport-layer connections break.

   Rendezvous Servers may establish some of HIP's benefits even if one
   of the endpoints does not support it. Rendezvous Servers live at
   static IP addresses. They can maintain ongoing transport-layer
   connections by acting as a relays for HIP nodes whose IP addresses
   may change. The discussion in the remainder of this section assumes
   that HIP nodes utilize Rendezvous Servers to maintain the HI->IP
   information as described in Section 3.

   The HIP architecture document [2] discusses the role of Rendezvous
   Servers in HIP communication. However, it does not currently describe
   the details of how Rendezvous Server relay traffic between HIP and
   non-HIP nodes. The remainder of this section presents this aspect of
   Rendezvous Servers.

4.1 Non-HIP Initiator to HIP Responder

   In the first scenario, a non-HIP initiator starts communication with
   a HIP node. The HIP node is using Rendezvous Servers. Figure 4 shows
   this case.

   Steps #1-4 remain unchanged from the HIP-HIP case shown in Figure 3
   and discussed in Section 3.2. HIP node R registers the IP addresses
   of its Rendezvous Server RVS in the DNS. It also keeps RVS updated
   with its current IP addresses IP(R).

   When non-HIP node I starts communication with R, it performs a DNS
   lookup on FQDN(R) and receives HI(R) and IP(RVS) in return. Since I
   does not support HIP, it disregards the Host Identity HI(R) returned
   by the DNS lookup. Instead, it sets up transport-layer connections
   using the IP addresses IP(RVS) obtained from the DNS. The Rendezvous
   Server RVS must then transparently relay the communication to one of
   R's current IP addresses IP(R) in step #5.






Eggert                   Expires August 5, 2004                [Page 11]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


               #3 FQDN(R)       +----------+ #2 Register IP(RVS) in
       +----------------------->|   DNS    |    FQDN(R)->IP(RVS).
       | +----------------------|          |<--------------------+
       | |   #4 HI(R), IP(RVS)  | FQDN->HI |                     |
       | |                      | FQDN->IP |                     |
       | |                      +----------+                     |
       | |                                                       |
       | |                       #1 Update IP(R) in HI(R)->IP(R) |
       | |                          whenever IP(R) changes.      |
       | |                         +---------------------------+ |
       | |                         |                           | |
       | V                         V                           | |
   +---------+                 +--------+                  +---------+
   |    I    |                 |  RVS   |                  |    R    |
   |         |                 |        |                  |         |
   | Non-HIP |<--------------->| HI->IP |<---------------->|   HIP   |
   +---------+                 +--------+                  +---------+
                  #5 RVS transparently relays packets
                     IP(I)<->IP(RVS) to/from IP(R).

   Figure 4: Non-HIP initiator to HIP responder via Rendezvous Server

   End-to-end communication between I and R is complicated by the fact
   that R's DNS entry lists IP addresses IP(RVS). The addresses IP(RVS)
   belong to the Rendezvous Server RVS and not R, the endpoint of the
   communication. I's transport layer will thus bind connections to R to
   IP addresses IP(I) and IP(RVS). Section 4.3 will discuss the
   implications.

4.2 HIP Initiator to Non-HIP Responder

   This section describes a second scenario, where a HIP node initiates
   communication with a non-HIP node. Figure 5 shows this case.

   As before, the HIP node I keeps its Rendezvous server RVS updated
   about its current IP addresses IP(I) in step #2. It also registers
   the IP addresses of the Rendezvous Server IP(RVS) in its DNS entry in
   step #2, instead of its own.

   In step #3, I initiates a transport-layer connection to R by
   performing a domain name lookup on FQDN(R). The DNS reply in step #4
   contains R's IP addresses IP(R) but no Host Identities, because R is
   not a HIP node.








Eggert                   Expires August 5, 2004                [Page 12]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


       #2 Register IP(RVS) in
          FQDN(I)->IP(RVS).     +----------+
    +-------------------------->|   DNS    |
    |                           |          |
    |          #3 FQDN(R)       | FQDN->HI |<--------------------+
    |  +----------------------->| FQDN->IP |                     |
    |  | +----------------------|          |                     |
    |  | |      #4 IP(I)        +----------+                     |
    |  | |                                                       |
    |  | |  #1 Update IP(I) in HI(I)->IP(I)                      |
    |  | |     whenever IP(I) changes.                           |
    |  | | +-------------------------------+                     |
    |  | | |                               |                     |
    |  | V |                               V                     |
   +---------+                         +--------+          +---------+
   |    I    |                         |  RVS   |          |    R    |
   |         |                         |        |          |         |
   |   HIP   |<----------------------->| HI->IP |<-------->| Non-HIP |
   +---------+                         +--------+          +---------+
                         #5 RVS translates/relays packets
                            IP(I)<->IP(R) to/from IP(RVS).

   Figure 5: HIP initiator to Non-HIP responder via Rendezvous Server

   If I uses IP(R) to establish a direct transport-layer connection with
   R, the connection will break when R's IP addresses change. Instead, R
   relays its traffic through Rendezvous Server RVS in step #5. Since
   the IP addresses of RVS are static, the transport-layer connection
   between I and R remains unaffected from changes to R's IP addresses.

4.3 Discussion

   As illustrated by the two scenarios described in Section 4.1 and
   Section 4.2, Rendezvous Servers can isolate non-HIP nodes from
   changes to their HIP peers' IP addresses. Binding transport-layer
   connections to static IP addresses of Rendezvous Servers, instead of
   the more volatile addresses of HIP peers, allows connections between
   HIP and non-HIP nodes to retain some of the benefits of HIP-HIP
   connections.

   The current HIP architecture document [2] requires HIP nodes using
   Rendezvous Servers to register the Rendezvous Server's IP addresses
   in the DNS. Consequently, Rendezvous Servers become explicit
   connections endpoints. This causes several challenges for end-to-end
   communication, as discussed in the next sections.






Eggert                   Expires August 5, 2004                [Page 13]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


4.3.1 Relaying Overhead

   The first issue is relaying overhead. When HIP nodes communicate,
   Rendezvous Servers will only need to relay the first packet of a HIP
   Base Exchange. The remaining HIP Base Exchange packets, as well as
   all subsequent data packets, will flow directly between the HIP
   nodes.

   This is not the case for communication between HIP and non-HIP nodes.
   A non-HIP node will bind its transport-layer connection to the IP
   address obtained by looking up the HIP peer's domain name in the DNS.
   This will be the address of the Rendezvous Server.

   Consequently, all data from the non-HIP to the HIP node will flow
   through the Rendezvous Server. This can cause significant relaying
   overhead. It can also increase the communication delay between the
   nodes, further affecting performance.

   Relaying overhead will be difficult to eliminate. In order to provide
   some of the benefits of HIP, non-HIP peers communicating with HIP
   nodes must be able to bind their transport-layer connections to
   static IP addresses. This constraint implies the presence of a
   statically addressed relay somewhere in the system.

4.3.2 Return Traffic

   A second issue is return traffic from the HIP node to the non-HIP
   node. Because a non-HIP node binds its transport-layer connection to
   its peer's IP address, it will not accept return traffic from a
   different address than it is sending to. Since all traffic from the
   non-HIP node is addressed to the Rendezvous Server, the non-HIP node
   will expect to receive return traffic from that source address.

   Several approaches may address this issue. First, the HIP node may
   relay all its return traffic through the Rendezvous Server as well.
   This causes additional relaying overhead. Second, the HIP node may
   spoof the IP address of the Rendezvous Server when sending return
   traffic. This may cause problems when firewalls along the path
   perform ingress filtering [7]. Finally, the approach described in
   Section 5 can also eliminate this issue.

4.3.3 Node Identification

   A third issue is identification of the specific HIP node that a
   Rendezvous Server must relay arriving packets to. Packets arriving
   from non-HIP nodes are simple IP packets addressed to the Rendezvous
   Server. They do not contain Host Identities or other information that
   will allow the Rendezvous Server to identify the correct HIP node for



Eggert                   Expires August 5, 2004                [Page 14]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   relaying.

   One solution has the Rendezvous Server use multiple IP addresses.
   Each of the HIP nodes for which it provides service receives one
   unique IP address. The HIP node will then register this unique IP
   address in the DNS. Hence, the Rendezvous Server can use the
   destination IP addresses of arriving packets to identify the HIP node
   to which they must be relayed to. The approach described in Section 5
   uses a similar scheme.

   A downside of registering unique IP addresses per node is a more
   complex protocol between Rendezvous Servers and its HIP nodes.
   Furthermore, Rendezvous Servers serving many HIP nodes may require
   many IP addresses.

4.3.4 Network Address Translation

   The HIP architecture document [2] uses the term "forwarding" to
   describe the operation by which a Rendezvous Server enables the
   exchange of packets between communicating nodes. This document uses
   the term "relaying" instead, to indicate that mechanisms other than
   IP forwarding may suit the same purpose.

   One such approach for relaying packets between HIP and non-HIP nodes
   is Network Address Translation [8]. When acting as a Network Address
   Translator, a Rendezvous Server will rewrite the IP headers of
   packets exchanged between communicating nodes.

   The use of Network Address Translation remains problematic [9][10].
   Avoiding its use in the Rendezvous Server may improve protocol and
   application compatibility. Section 5 will present a rendezvous
   mechanism that relays using simple IP forwarding instead, avoiding
   possible issues due to the use of Network Address Translation.


















Eggert                   Expires August 5, 2004                [Page 15]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


5. Rendezvous Broker

   This section describes Rendezvous Brokers. Rendezvous Brokers provide
   a modified HIP rendezvous mechanism that addresses some of the issues
   discussed in Section 4.

   Rendezvous Brokers are named for their similarity to tunnels brokers
   [11]. Rendezvous Brokers also share commonalities with MobileIP's
   Home Agents [12] as well as systems for leasing IP subnets [17].

      Note: Rendezvous Brokers described in this section may be similar
      to the Packet Forwarding Agents outlined in [18]. While this
      similarity is under discussion, this document will use the term
      Rendezvous Broker for clarity. If the two concepts are deemed
      identical, terminology may change.

   Rendezvous Brokers are IP routers and manage delegations of
   globally-routable IP subnets. Rendezvous Brokers may be located
   anywhere in the network. HIP has no concept of home networks (unlike
   MobileIP [12]) that would tie Rendezvous Brokers to access networks.

   When a HIP node requests rendezvous service, the Rendezvous Broker
   delegates a unique, globally-routable IP address (or prefix) to the
   HIP node. HIP node and Rendezvous Broker establish a tunnel using the
   delegated IP address as the HIP node's tunnel endpoint address. The
   Rendezvous Broker installs a route towards the delegated IP address
   via the tunnel. At the end of this process, the HIP node is globally
   reachable by non-HIP nodes at the delegated IP address obtained from
   the Rendezvous Broker.

   Figure 6 illustrates this process. In step #1, HIP node R registers
   its Host Identity HI(R) with the Rendezvous Broker RVB. In step #2, R
   receives an IP address IP(T-R) from RVB. This IP address is
   globally-routable and delegated to RVB.

   The Rendezvous Broker and the HIP node R then establish a tunnel
   between themselves in step #3. IP(T-R) is the IP address of R's
   tunnel endpoint, T-RVB the endpoint address of the Rendezvous Broker.
   The tunnel encapsulates packets with IP(RVB) and IP(R). RVB then
   installs a route that forwards packets addressed to IP(T-R) over the
   tunnel.

   In step #4, R registers the IP address obtained from RVB in its DNS
   entry. When the non-HIP initiator I performs a DNS lookup in step #6,
   it receives IP(T-R) from the DNS (along with HI(R), which it
   ignores). I then initiates a transport-layer connection from IP(I) to
   IP(T-R). Packets to IP(T-R) will be routed to the RVB, because it is
   the router for the subnet out of which IP(T-R) was allocated. The RVB



Eggert                   Expires August 5, 2004                [Page 16]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   will then forward such packets over the tunnel to R due to the route
   installed in step #3.

               #5 FQDN(R)       +----------+ #4 Register IP(RVB-R) in
       +----------------------->|   DNS    |    FQDN(R)->IP(T-R).
       | +----------------------|          |<--------------------+
       | |  #6 HI(R), IP(T-R)   | FQDN->HI |                     |
       | |                      | FQDN->IP |                     |
       | |                      +----------+                     |
       | V                                                       |
   +---------+         +--------+          #1 HI(R)         +---------+
   |         |         |        |<--------------------------|         |
   |    I    |         |  RVB   |-------------------------->|    R    |
   |         |         |        |         #2 IP(T-R)        |         |
   |         |         |        |                           |         |
   | Non-HIP |         | HI->IP |<------------------------->|   HIP   |
   |         |         |        |  #3 Setup tunnel          |         |
   |         |         |        |     IP(T-RVB)<->IP(T-R).  |         |
   |         |         |        |                           |         |
   |         |<------->|        |<------------------------->|         |
   +---------+         +--------+  #7 RVB forwards packets  +---------+
                                      IP(I)<->IP(T-R)
                                      via the tunnel.

   Figure 6: Non-HIP initiator to HIP responder via Rendezvous Broker

   The next sections will compare Rendezvous Brokers to Rendezvous
   Servers and discuss several aspects of Rendezvous Brokers in more
   detail.

5.1 Comparison to Rendezvous Servers

   Rendezvous Brokers address some of the shortcomings of Rendezvous
   Servers raised in Section 4.3. One difference is that the IP
   addresses in a HIP node's DNS entry again identify interfaces of the
   HIP node itself. With Rendezvous Servers, the DNS entry instead
   identifies interfaces of the Rendezvous Server.

   This simplifies the operation of the Rendezvous Broker. It performs
   simple IP forwarding of packets that already carry the addresses of
   their final source and destination endpoints. Network Address
   Translation, or other schemes that relay by modifying packet headers,
   are not required. This may improve application and protocol
   compatibility.

   Because Rendezvous Brokers are IP routers, additional mechanisms to
   identify the correct HIP destination node for arriving packets are
   not required. The globally-routable destination IP address already



Eggert                   Expires August 5, 2004                [Page 17]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   acts as a unique indicator of the final destination.

5.2 Mobility

   Rendezvous Brokers offer mobility support that is equivalent to
   Rendezvous Servers. HIP nodes already notify their Rendezvous Servers
   when their IP addresses change. Rendezvous Brokers also require such
   notification.

   When the IP addresses of a HIP node changes, the Rendezvous Broker
   and the HIP node must reconfigure the tunnel between them. This
   reconfiguration only affects the IP addresses used for tunnel
   encapsulation. The addresses of the tunnel endpoints remain
   unchanged. Transport-layer connections bound to a HIP node's tunnel
   endpoint address thus remain unaffected.

   HIP nodes may change Rendezvous Servers over time and they may use
   multiple Rendezvous Servers at the same time. The same is true for
   Rendezvous Brokers. Both Rendezvous Servers and Rendezvous Brokers
   may be located anywhere in the network; unlike MobileIP [12], HIP has
   no notion of home networks. By separating rendezvous mechanisms from
   topological locations, HIP allows nodes to choose Rendezvous Servers
   or Brokers based on local criteria, including network connectivity,
   location, or mobility.

5.3 Tunneling

   This document does not further define the specifics of the tunneling
   mechanism used between a Rendezvous Broker and its HIP nodes.
   Possible tunneling mechanisms include [19][20][21][22][23]. Different
   tunneling mechanisms incur different overheads. Some may also offer
   better traversal of Network Address Translators or firewalls.

   Similarly, the tunnel setup protocol between Rendezvous Brokers and
   HIP nodes is currently unspecified. Candidate tunnel management
   approaches include [24][25][26].

   Rendezvous Brokers forward all traffic from non-HIP nodes to HIP
   nodes over tunnels. For the return traffic from HIP nodes to non-HIP
   nodes two options exist. First, return traffic could also flow over
   tunnel. Second, return traffic could flow through the base network
   over one of the HIP node's interfaces. The second alternative may
   offer increased performance due to the avoidance of triangle routing.
   However, firewalls that perform ingress filtering could prevent
   communication [7].

   Another aspect of using tunnels to connect Rendezvous Brokers and
   their HIP nodes is reduced Maximum Transmission Units. Implementation



Eggert                   Expires August 5, 2004                [Page 18]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   issues in the network stacks of end systems and routers can lead to
   communication problems in such scenarios [27].

















































Eggert                   Expires August 5, 2004                [Page 19]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


6. Security Considerations

   The security aspects of different HIP rendezvous mechanisms are
   currently being investigated. They will be discussed in a future
   revision of this document.














































Eggert                   Expires August 5, 2004                [Page 20]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


7. Acknowledgments

   The following people have provided thoughtful and helpful suggestions
   that have improved this document: Marcus Brunner, Simon Schuetz,
   Martin Stiemerling, and Juergen Quittek.














































Eggert                   Expires August 5, 2004                [Page 21]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


Normative References

   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

   [2]   Moskowitz, R., "Host Identity Protocol Architecture",
         draft-moskowitz-hip-arch-05 (work in progress), October 2003.

   [3]   Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity
         Protocol", draft-moskowitz-hip-08 (work in progress), October
         2003.

   [4]   Nikander, P., "End-Host Mobility and Multi-Homing with Host
         Identity Protocol", draft-nikander-hip-mm-01 (work in
         progress), January 2004.

   [5]   Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
         April 1997.

   [6]   Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", RFC 3007, November 2000.

   [7]   Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.

   [8]   Srisuresh, P. and K. Egevang, "Traditional IP Network Address
         Translator (Traditional NAT)", RFC 3022, January 2001.

   [9]   Hain, T., "Architectural Implications of NAT", RFC 2993,
         November 2000.

   [10]  Senie, D., "Network Address Translator (NAT)-Friendly
         Application Design Guidelines", RFC 3235, January 2002.

   [11]  Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel
         Broker", RFC 3053, January 2001.

   [12]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
         2002.










Eggert                   Expires August 5, 2004                [Page 22]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


Informative References

   [13]  Saltzer, J., "On the Naming and Binding of Network
         Destinations", RFC 1498, August 1993.

   [14]  Sunshine, C., "Addressing Problems in Multi-Network Systems",
         IEN 178, April 1981.

   [15]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [16]  Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467,
         February 2003.

   [17]  Touch, J., Eggert, L. and Y. Wang, "TetherNet Anti-NAT - Secure
         Internet Subnet Rental System", Proc. 3rd DARPA Information
         Survivability Conference and Exposition (DISCEX-III) 2003,
         April 2003.

   [18]  Nikander, P., Ylitalo, J. and J. Wall, "Integrating Security,
         Mobility, and Multi-Homing in a HIP Way", Proc. Network and
         Distributed Systems Security Symposium (NDSS) 2003, February
         2003.

   [19]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
         1996.

   [20]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
         Address Translation (NAT) Devices", RFC 3519, May 2003.

   [21]  Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
         "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

   [22]  Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP",
         draft-nikander-esp-beet-mode-00 (work in progress), October
         2003.

   [23]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
         B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
         August 1999.

   [24]  Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC
         2107, February 1997.

   [25]  Beijnum, I., "On Demand Tunneling For Multihoming",
         draft-van-beijnum-multi6-odt-00 (work in progress), January
         2004.




Eggert                   Expires August 5, 2004                [Page 23]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   [26]  Touch, J., "Dynamic Internet overlay deployment and management
         using the X-Bone", Computer Networks Vol. 36, No. 2-3, July
         2001.

   [27]  Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923,
         September 2000.


Author's Address

   Lars Eggert
   NEC Network Laboratories
   Kurfuersten-Anlage 36
   Heidelberg  69115
   DE

   Phone: +49 6221 90511 43
   Fax:   +49 6221 90511 55
   EMail: lars.eggert@netlab.nec.de
   URI:   http://www.netlab.nec.de/































Eggert                   Expires August 5, 2004                [Page 24]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


Appendix A. Document Revision History

   +-----------+-------------------------------------------------------+
   | Revision  | Comments                                              |
   +-----------+-------------------------------------------------------+
   | 00        | Initial version.                                      |
   +-----------+-------------------------------------------------------+












































Eggert                   Expires August 5, 2004                [Page 25]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Eggert                   Expires August 5, 2004                [Page 26]


Internet-Draft         HIP Rendezvous Mechanisms           February 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Eggert                   Expires August 5, 2004                [Page 27]