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]