[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Host Identity Protocol (HIP)                                   L. Eggert
Internet-Draft                                                M. Liebsch
Expires: January 17, 2005                                            NEC
                                                           July 19, 2004



  Design Aspects of Host Identity Protocol (HIP) Rendezvous Mechanisms
                     draft-eggert-hip-rendezvous-01


Status of this Memo


   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.  This document may not be modified, and derivative works of
   it may not be created, except to publish it as an RFC and to
   translate it into languages other than English.


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


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


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


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


   This Internet-Draft will expire on January 17, 2005.


Copyright Notice


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


Abstract


   This document discusses design aspects of 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 & Liebsch        Expires January 17, 2005                [Page 1]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Communication Between HIP Nodes  . . . . . . . . . . . . . . .  4
   3.  Communication Between Mobile or Multi-Homed HIP Nodes  . . . .  6
     3.1   Mobility and Multi-Homing with DNS Updates . . . . . . . .  6
     3.2   Mobility and Multi-Homing with Rendezvous Servers  . . . .  7
   4.  Communication Between HIP and Non-HIP Nodes  . . . . . . . . .  9
     4.1   Non-HIP Initiator to HIP Responder . . . . . . . . . . . . 10
     4.2   HIP Initiator to Non-HIP Responder . . . . . . . . . . . . 11
     4.3   Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12
       4.3.1   Relaying Overhead  . . . . . . . . . . . . . . . . . . 12
       4.3.2   Return Traffic . . . . . . . . . . . . . . . . . . . . 12
       4.3.3   Node Identification  . . . . . . . . . . . . . . . . . 13
       4.3.4   Network Address Translation  . . . . . . . . . . . . . 13
   5.  Rendezvous Broker  . . . . . . . . . . . . . . . . . . . . . . 14
     5.1   Comparison to Rendezvous Servers . . . . . . . . . . . . . 15
     5.2   Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.3   Tunneling  . . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Location Privacy with HIP  . . . . . . . . . . . . . . . . . . 17
     6.1   Location Privacy Between HIP Nodes . . . . . . . . . . . . 17
       6.1.1   Distributing HIP Functionality . . . . . . . . . . . . 17
       6.1.2   Communication with Local Rendezvous Agents . . . . . . 20
       6.1.3   Communication with First-Hop Attendants  . . . . . . . 21
     6.2   Location Privacy between HIP and Non-HIP Nodes . . . . . . 22
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   9.1   Normative References . . . . . . . . . . . . . . . . . . . . 23
   9.2   Informative References . . . . . . . . . . . . . . . . . . . 24
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
   A.  Document Revision History  . . . . . . . . . . . . . . . . . . 26
       Intellectual Property and Copyright Statements . . . . . . . . 27



















Eggert & Liebsch        Expires January 17, 2005                [Page 2]


Internet-Draft       HIP Rendezvous Design Aspects             July 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 & Liebsch        Expires January 17, 2005                [Page 3]


Internet-Draft       HIP Rendezvous Design Aspects             July 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.


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.







Eggert & Liebsch        Expires January 17, 2005                [Page 4]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



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


   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




Eggert & Liebsch        Expires January 17, 2005                [Page 5]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   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.


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.


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


   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.









Eggert & Liebsch        Expires January 17, 2005                [Page 6]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



              #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


   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




Eggert & Liebsch        Expires January 17, 2005                [Page 7]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



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





Eggert & Liebsch        Expires January 17, 2005                [Page 8]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



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


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.





Eggert & Liebsch        Expires January 17, 2005                [Page 9]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   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.


               #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


   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.


   End-to-end communication between I and R is complicated by the fact




Eggert & Liebsch        Expires January 17, 2005               [Page 10]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   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.


       #2 Register IP(RVS) in
          FQDN(I)->IP(RVS).     +----------+
    +-------------------------->|   DNS    |
    |                           |          |
    |          #3 FQDN(R)       | FQDN->HI |<--------------------+
    |  +----------------------->| FQDN->IP |                     |
    |  | +----------------------|          |                     |
    |  | |      #4 IP(R)        +----------+                     |
    |  | |                                                       |
    |  | |  #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




Eggert & Liebsch        Expires January 17, 2005               [Page 11]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   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.


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




Eggert & Liebsch        Expires January 17, 2005               [Page 12]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



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




Eggert & Liebsch        Expires January 17, 2005               [Page 13]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   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.


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




Eggert & Liebsch        Expires January 17, 2005               [Page 14]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   entry.  When the non-HIP initiator I performs a DNS lookup in step
   #5, it receives IP(T-R) from the DNS in step #6 (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 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




Eggert & Liebsch        Expires January 17, 2005               [Page 15]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



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




Eggert & Liebsch        Expires January 17, 2005               [Page 16]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   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 issues in the network stacks of end systems and
   routers can lead to communication problems in such scenarios [27].


6.  Location Privacy with HIP


   Section 3.2 discussed HIP rendezvous servers and Section 5 discussed
   HIP rendezvous brokers.  One common characteristic of these
   approaches is end-to-end addressing, i.e., initiator and responder of
   HIP associations eventually learn the other's current IP address.
   Because IP addresses have topological relevance, they may allow to
   deduce additional information about the peer, such as their ISP or
   even geographical location.  In some cases, this is undesirable.


   The current HIP architecture does not support location privacy.  It
   exposes peer IP addresses, which in their function as locators can be
   used to deduce additional information about peers.  If location
   privacy is a non-functional requirement for HIP, the current
   architecture must be augmented.


   Rendezvous brokers, as described in Section 5, maintain bindings
   between peers' local and globally visible IP addresses.  Rendezvous
   brokers may thus already support some degree of location privacy,
   because they only make a host's global IP addresses visible to its
   peers.  This, however, requires all traffic to flow through the
   broker.


   One key limitation of the current HIP architecture with regard to
   location privacy is that it implicitly requires the end hosts to
   resolves their peers' host identities into the corresponding IP
   addresses.  This does not change even with rendezvous brokers; they
   still reveal the peers' global IP addresses to the end hosts.


   The following sections discuss extensions to the current HIP
   architecture that establish location privacy, i.e., do not reveal the
   IP addresses associated with a node's network interfaces to its
   peers.


6.1  Location Privacy Between HIP Nodes


6.1.1  Distributing HIP Functionality


   With HIP, transport-layer services bind to host identities instead of




Eggert & Liebsch        Expires January 17, 2005               [Page 17]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   IP addresses.  Resolution of the destination's host identity to its
   associated IP addresses implicitly occurs at the host identity layer
   and may involve additional communication with remote entities, such
   as the DNS.  This is because the network layer requires packets to be
   addressed with the appropriate IP addresses to allow traffic
   forwarding towards the final destination.  Figure 7 illustrates this
   view of the HIP protocol stack.


                  +---------------------+
                  |   Transport Layer   |  <HI, port> pairs
                  +---------------------+


                  +---------------------+
                  | Host Identity Layer |  Host Identity
                  +---------------------+      |
                                               | translation
                  +---------------------+      V
                  |    Network Layer    |  IP address
                  +---------------------+      |
                                               | ARP, ND
                  +---------------------+      V
                  |     Link Layer      |  LL address
                  +---------------------+


               Figure 7: HIP architecture reference model


   One approach to support a limited degree of location privacy using
   HIP is to have both the initiator and the responder of a HIP
   association use rendezvous brokers throughout a communication.  This
   approach, however, still reveals the remote host's globally visible
   IP addresses, because the tunneled IP packet between a host and its
   RVB contains the peer's global IP address.  It does hide local
   movement and the associated changes of a host's local IP address
   though.


   A more complete approach to establish location privacy is to split up
   the HIP architecture and relocate some pieces of the HIP
   functionality into new network entities.  Figure 8 shows one example
   of such an approach of splitting and relocating HIP functionality and
   the following sections discuss it in more detail.


   When HIP functionality is relocated, destination networks become
   similar to IP-based mobile communication networks.  They comprise of
   various network components (agents, brokers, servers, gateways) and
   access routers that provide mobile hosts with wired or wireless
   access to an infrastructure.  In such environments, HIP should not
   expose the IP addresses of a host to its peers.  Consequently, it
   must hide or obfuscate them at least on the last hop between a host




Eggert & Liebsch        Expires January 17, 2005               [Page 18]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   and its access router.


         HIP:                    HIP with functional split:


         Host            |        Host             Network
     --------------------+-----------------------------------------
     Host Identity       |    Host Identity      Host Identity
          |              |         |                  |
          | translation  |         +----------------->| translation
          |              |                            |
          v              |                            v
    HI associated IP     | known IP address of  HI associated
      IP address         | translating network    IP address
          |              |       entity               |
          |              |         |                  |
          |              |         |                  |
          | ARP, ND      |         |                  | ARP, ND
          V              |         V                  V
      LL address         |     LL address         LL address


          Figure 8: Relocating HIP functions into the network


   The proposed functional split separates the HI-to-IP address
   resolution from the end host's HIP layer and relocates it to an
   entity inside the network.  Instead of addressing their peers
   directly, hosts now address a network entity that then resolves the
   HI to the IP address apparently associated with the remote host.
   ("Apparently", because that address may in fact belong to another
   network entity that will deliver to the remote host.) Consequently,
   the IP addresses used by the end host's HIP layer is that of a
   "well-known" network component.  Various possibilities for the
   relocation of the HIP lookup exist.  The following sections describe
   one approach that relocates the resolution function to an enhanced
   rendezvous server that hosts have previously registered with.  To
   avoid ambiguities with the previously described rendezvous servers
   and brokers, the discussion will use the term "rendezvous agent" for
   this new entity.  (This terminology may change in future revisions of
   this document.)


   Two separate scenarios for communication involving a rendezvous agent
   (RVA) exist.  First, hosts may address all traffic to the RVA.
   Hence, the RVA address is the well-known address that the host's HIP
   layers use according to the functional split in Figure 8.  In the
   second case, hosts address all packets to their current access
   routers, which act as relays between the hosts and their RVAs.


   The following figures extend the notation used in the beginning of
   this document.  Initiator and responder hosts are still I and R,




Eggert & Liebsch        Expires January 17, 2005               [Page 19]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   respectively.  The local IP address of host X is IP_L(X) whereas its
   global IP address, maintained by the RVAs, is IP_G(X).


6.1.2  Communication with Local Rendezvous Agents


   This scenario assumes that mobile hosts are allowed to communicate
   directly with their associated local RVAs.  They have previously
   registered with the RVAs as described in Figure 8.


   Figure 9 shows the operation of the protocol when a host directly
   communicates with its RVA.  It also illustrates the case where I and
   R are located in different domains.


                   Domain A       |      Domain B
                                  |
   (1)     +---------------+      |
   FQDN(R) |+-----+ +-----+|      |
     +---->|| DNS | | DB  ||      |
     |     |+-----+ +-----+|      |
     |     +---------------+      |
     |           (4)   ^          |
     | (2)       HI(R) | (5)      |
     | HI(R)           | IP_G(R)  |
     v                 v          |
   +---+ (3) HI(R) +-----+        /        +-----+           +---+
   | I |<--------->|RVA-I|<--------------->|RVA-R|<--------->| R |
   +---+IP_L(I)    +-----+IP_G(I) / IP_G(R)+-----+    IP_L(R)+---+
                                  |


    Figure 9: Direct communication between host and rendezvous agent


   When I wants to establish communication with R, it first resolves
   FQDN(R) into the associated HI(R), possibly via the DNS.  When
   rendezvous agents are used, the DNS MUST NOT return R's IP addresses
   IP(R).  I then sends its packets to R to its RVA  (RVA-I) and
   includes R's HI(R).  When RVA-I receives the packets destined for R,
   it resolves HI(R) into R's global IP address IP_G(R) with the help of
   a currently unspecified database (DB).  This database may or may not
   be collocated with the DNS.


   >From then on, RVA-I serves as a proxy between I and R's RVA (RVA-R).
   RVA-I will never expose IP_G(I), much less IP_L(I), and RVA-R does
   the same.  Communication between the RVAs occurs with the hosts'
   global IP addresses IP_G(I) and IP_G(R), while packets forwarding
   between a host and its RVA uses the local IP addresses IP_L(I) and
   IP_L(R).


   One disadvantage of this approach is that it places a high load on




Eggert & Liebsch        Expires January 17, 2005               [Page 20]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   the RVAs caused by relaying of all traffic.  To limit load on a
   particular RVA, multiple RVAs may serve the registered hosts of a
   domain to distribute load.  Domains may coordinate load distribution
   when hosts first attempt to register with an RVA.  The specifics of
   such mechanisms are out of the scope of this document.


   Some service providers may have policies that forbid mobile hosts to
   communicate directly with network components and require them to use
   controlled edge relays.  This provides some measure of protection by
   hiding the actual location and IP addresses of the network
   components.  Under such a policy, HIP relays or attendants might be
   collocated with access routers.  The next section briefly discusses
   this case.


6.1.3  Communication with First-Hop Attendants


   This section assumes that a policy prohibits mobile hosts to
   communicate directly with RVAs, but requires them to use attendants.
   These attendants may be collocated with a domain's access routers and
   serve as relays for IP packets between a host and its associated
   RVAs.


   Hosts usually know the IP address of their access router.  A default
   router's IP address can thus serve as the well-known IP address used
   by the host's HIP layer.  The access router's relaying function may
   also support RVA discovery by processing hosts' discovery or
   registration request and assign them an alias address to identify
   their assigned RVA.  This approach uniquely identifies RVAs without
   revealing their IP address to the mobile hosts.  Access routers map
   these aliases into the associated RVA's IP address.  (This
   description simplifies the process for the purposes of discussion.
   The specifics of attendant functionality are out of the scope of this
   draft.)


   Communication establishment is similar to the scenario described in
   Figure 9, but no direct path exist between a host and its RVA.
   Instead, as shown in Figure 10, the access router terminates the path
   and sets up a new one towards the host or the RVA, respectively.
   (The current revision of this document does not yet discuss the
   details of the require IP addressing schemes and binding maintenance.
   A future revision may investigate these issues.)


   One advantage of this architecture is that it does not reveal the
   RVAs' IP addresses to the mobile hosts.  The attendants that are
   collocated with the access routers relay all communication, including
   signaling and data traffic.  A second advantage is that attendants
   can support discovery of appropriate RVAs before or during a host's
   registration process.




Eggert & Liebsch        Expires January 17, 2005               [Page 21]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



                         Domain A       |      Domain B
                                        |
          (1)     +---------------+     |
          FQDN(R) |+-----+ +-----+|     |
     +----------->|| DNS | | DB  ||     |
     |            |+-----+ +-----+|     |
     |            +---------------+     |
     |                  (4)   ^         |
     | (2)              HI(R) | (5)     |
     | HI(R)                  | IP_G(R) |
     v                        v         |
   +---+ (3) HI(R) +----+    +-----+    /  +-----+    +----+    +---+
   | I |<--------->|AR-I|<-->|RVA-I|<----->|RVA-R|<-->|AR-R|<-->| R |
   +---+           +----+    +-----+    /  +-----+    +----+    +---+
                                        |


  Figure 10: Indirect communication between host and rendezvous agent


   A disadvantage of the attendant-based architecture is that two relays
   per host exist, bringing the total number of relays along the path
   from I to R to four.  This is because access routers now encapsulate
   and decapsulate packets in addition to the RVAs.  This introduces
   additional per-packet processing overhead and increases forwarding
   delays.


   In addition, this solution is difficult to realize without
   introducing and maintaining state at the RVAs and attendants.  This
   can affect scalability and performance of the access routers.


6.2  Location Privacy between HIP and Non-HIP Nodes


   Extending the proposed approaches for establishing location privacy
   to include communication with non-HIP nodes is difficult.  They
   require the initiator to transmit the peer's host identity to the
   translating function inside the network.  Including HI(R) in the HIP
   header easily meets this requirement for HIP nodes.  For non-HIP
   nodes, this is not an option.  Furthermore, non-HIP nodes require a
   static identifier to replace the HI for communication, which some
   entity in the network must then transparently resolve.  A static IP
   address might be such an identifier, for example, using MobileIP,
   which offers the peer's "home address" for such a purpose.


   One approach to transmit a peer's static IP address to the
   translating network entity (or RVA) could be IP tunneling.  Host I
   addresses R's static IP address in the inner, tunneled packet,
   whereas the outer IP header addresses the RVA (assuming direct
   communication between a host and its RVA.) The RVA terminates the
   tunnel, decapsulates the packet and resolves R's static IP address to




Eggert & Liebsch        Expires January 17, 2005               [Page 22]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



   R's globally visible IP address IP_G(R).


   As above, packets between RVAs use IP_G(I) and IP_G(R) as addresses,
   respectively.  Packets between a host and its RVA use the host's
   local IP address and the RVA's address in the outer IP header,
   whereas the inner header must use the static IP addresses of both.


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


8.  Acknowledgments


   The following people have helped to improve this document through
   thoughtful suggestions: Marcus Brunner, Tom Henderson, Mika Kousa,
   Pekka Nikander, Simon Schuetz, Martin Stiemerling, and Juergen
   Quittek.


9.  References


9.1  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-09 (work in progress), February
         2004.


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




Eggert & Liebsch        Expires January 17, 2005               [Page 23]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



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


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





Eggert & Liebsch        Expires January 17, 2005               [Page 24]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



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


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



Authors' Addresses


   Lars Eggert
   NEC Network Laboratories
   Kurfuerstenanlage 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/



   Marco Liebsch
   NEC Network Laboratories
   Kurfuerstenanlage 36
   Heidelberg  69115
   DE


   Phone: +49 6221 90511 46
   Fax:   +49 6221 90511 55
   EMail: marco.liebsch@netlab.nec.de
   URI:   http://www.netlab.nec.de/





Eggert & Liebsch        Expires January 17, 2005               [Page 25]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



Appendix A.  Document Revision History


   +-----------+-------------------------------------------------------+
   | Revision  | Comments                                              |
   +-----------+-------------------------------------------------------+
   | 00        | Initial version.                                      |
   | 01        | Add discussion on HIP location privacy and rendezvous |
   |           | agents. Minor fixes to figures and their descriptive  |
   |           | text. Use boilerplate from RFC 3667.                  |
   +-----------+-------------------------------------------------------+










































Eggert & Liebsch        Expires January 17, 2005               [Page 26]


Internet-Draft       HIP Rendezvous Design Aspects             July 2004



Intellectual Property Statement


   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.



Disclaimer of Validity


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



Copyright Statement


   Copyright (C) The Internet Society (2004).  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.



Acknowledgment


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





Eggert & Liebsch        Expires January 17, 2005               [Page 27]