idnits 2.17.00 (12 Aug 2021) /tmp/idnits50887/draft-eggert-hip-rendezvous-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1224. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1201. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1214. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1230), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 25 longer pages, the longest (page 23) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 926: '...re used, the DNS MUST NOT return R's I...' Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 19, 2004) is 6508 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-05 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-02) exists of draft-nikander-hip-mm-01 -- Possible downref: Normative reference to a draft: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 2993 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 3235 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. '11') ** Obsolete normative reference: RFC 3344 (ref. '12') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '15') (Obsoleted by RFC 4301) == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-00 Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Host Identity Protocol (HIP) L. Eggert 2 Internet-Draft M. Liebsch 3 Expires: January 17, 2005 NEC 4 July 19, 2004 6 Design Aspects of Host Identity Protocol (HIP) Rendezvous Mechanisms 7 draft-eggert-hip-rendezvous-01 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. This document may not be modified, and derivative works of 15 it may not be created, except to publish it as an RFC and to 16 translate it into languages other than English. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 17, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document discusses design aspects of rendezvous mechanisms for 43 the Host Identity Protocol (HIP). Rendezvous mechanisms, such as HIP 44 rendezvous servers, improve operation when HIP nodes are multi-homed 45 or mobile. They can also facilitate communication between HIP and 46 non-HIP nodes. Possible rendezvous mechanisms differ in performance, 47 compatibility and impact on the HIP and Internet architectures. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Communication Between HIP Nodes . . . . . . . . . . . . . . . 4 53 3. Communication Between Mobile or Multi-Homed HIP Nodes . . . . 6 54 3.1 Mobility and Multi-Homing with DNS Updates . . . . . . . . 6 55 3.2 Mobility and Multi-Homing with Rendezvous Servers . . . . 7 56 4. Communication Between HIP and Non-HIP Nodes . . . . . . . . . 9 57 4.1 Non-HIP Initiator to HIP Responder . . . . . . . . . . . . 10 58 4.2 HIP Initiator to Non-HIP Responder . . . . . . . . . . . . 11 59 4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 60 4.3.1 Relaying Overhead . . . . . . . . . . . . . . . . . . 12 61 4.3.2 Return Traffic . . . . . . . . . . . . . . . . . . . . 12 62 4.3.3 Node Identification . . . . . . . . . . . . . . . . . 13 63 4.3.4 Network Address Translation . . . . . . . . . . . . . 13 64 5. Rendezvous Broker . . . . . . . . . . . . . . . . . . . . . . 14 65 5.1 Comparison to Rendezvous Servers . . . . . . . . . . . . . 15 66 5.2 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 5.3 Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 16 68 6. Location Privacy with HIP . . . . . . . . . . . . . . . . . . 17 69 6.1 Location Privacy Between HIP Nodes . . . . . . . . . . . . 17 70 6.1.1 Distributing HIP Functionality . . . . . . . . . . . . 17 71 6.1.2 Communication with Local Rendezvous Agents . . . . . . 20 72 6.1.3 Communication with First-Hop Attendants . . . . . . . 21 73 6.2 Location Privacy between HIP and Non-HIP Nodes . . . . . . 22 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 77 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 78 9.2 Informative References . . . . . . . . . . . . . . . . . . . 24 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 80 A. Document Revision History . . . . . . . . . . . . . . . . . . 26 81 Intellectual Property and Copyright Statements . . . . . . . . 27 83 1. Introduction 85 The current Internet uses two global namespaces: domain names and IP 86 addresses. The Domain Name System (DNS) provides a two-way lookup 87 service between the two [1]. Domain names are symbolic identifiers 88 for sets of IP addresses. 90 IP addresses have two uses. First, they are topological locators for 91 network attachment points. Second, they act as names for the 92 attached network interfaces. Saltzer [13] discusses these naming 93 concepts in detail. 95 Routing and other network-layer mechanisms are based on the locator 96 aspects of IP addresses. Transport-layer protocols and mechanisms 97 typically use IP addresses in their role as names for communication 98 endpoints. 100 This dual use of IP addresses limits the flexibility of the Internet 101 architecture. The need to avoid readdressing in order to maintain 102 existing transport-layer connections complicates advanced 103 functionality, such as mobility, multi-homing or network composition. 104 Sunshine summarizes the consequences of addressing on advanced 105 network functions [14]. 107 The Host Identity Protocol (HIP) architecture [2] defines a new third 108 namespace. The host identity namespace decouples the name and 109 locator roles currently filled by IP addresses. Instead of mapping 110 domain names directly into IP addresses, HIP maps domain names into 111 host identities, and host identities into IP addresses. 112 Transport-layer mechanisms operate on host identities instead of 113 using IP addresses as endpoint names. Network-layer mechanisms 114 continue to use IP addresses as pure locators. 116 Without HIP, nodes establish transport-layer connections by first 117 looking up the fully-qualified domain name (FQDN) of a peer in the 118 DNS. A successful DNS lookup returns the peer's IP addresses. A 119 node uses one of the returned IP addresses to initiate 120 transport-layer communication with a peer node. 122 HIP nodes will also look up the domain name of desired peers in the 123 DNS. When a successful lookup includes a peer's host identities, HIP 124 nodes perform a HIP base exchange before establishing transport-layer 125 connections. The HIP base exchange authenticates the end hosts and 126 can bootstrap encryption of the subsequent communication with IPsec 127 [15]. The HIP specification [3] discusses the details of the base 128 exchange and the related protocol exchanges. 130 After the base exchange, HIP nodes use host identities instead of IP 131 addresses for transport-layer connections with a peer. The HIP layer 132 in the network stack internally translates host identities (HI) into 133 network-layer IP addresses. This additional mapping between host 134 identities and IP addresses (HI->IP) is logically separate from the 135 first mapping between fully-qualified domain names and host 136 identities (FQDN->HI). 138 For application and transport-layer compatibility, the FQDN->HI 139 mapping must remain in the DNS. However, the HI->IP mapping is 140 internal to the HIP layer and may be performed in a number of ways. 141 Different lookup mechanism may support communication between two 142 mobile or multi-homed HIP nodes better [4]. 144 Transparent communication between HIP and non-HIP nodes places 145 additional restrictions on the lookup mechanisms. For example, 146 non-HIP nodes expect DNS lookups to return IP addresses, requiring 147 the HI->IP mapping (or a representation thereof) to remain in the 148 DNS. Section 4 discusses communication between HIP and non-HIP nodes 149 and describes different alternatives that support it. 151 2. Communication Between HIP Nodes 153 In the current Internet, the DNS provides a FQDN->IP mapping. With 154 HIP, it must continue to provide a mapping based on domain names. 155 This allows transport-layer connections to bind to host identities 156 instead of IP addresses transparently. 158 Instead of mapping domain names directly into IP addresses 159 (FQDN->IP), with HIP the DNS maps them to host identities (FQDN->HI). 160 In a second step, another lookup that is internal to the HIP-layer 161 translates the host identities into IP addresses for network-layer 162 delivery (HI->IP). 164 Several alternative approaches are possible for maintaining the 165 HI->IP information. The DNS can maintain this mapping along with the 166 FQDN->HI mapping. Alternatively, a database separate from the DNS 167 can manage this information. This section discusses the different 168 approaches and their implications on communication between two HIP 169 nodes. Section 4 will discuss the compatibility aspects of the 170 alternatives described here when HIP and non-HIP nodes communicate. 172 The HIP architecture and protocol specifications suggest storing host 173 identities along with a node's IP addresses in the DNS [2][3]. The 174 index for both tables will be domain names. Logically, the DNS will 175 thus contain two separate mappings: FQDN->HI and FQDN->IP. 177 #1 FQDN(R) +----------+ 178 +-------------------->| DNS | 179 | +-------------------| | 180 | | #2 HI(R), IP(R) | FQDN->HI | 181 | | | FQDN->IP | 182 | | +----------+ 183 | V 184 +-----+ #3 HIP base exchange +-----+ 185 | |-------------------------------->| | 186 | I |<--------------------------------| R | 187 | |-------------------------------->| | 188 | |<--------------------------------| | 189 +-----+ +-----+ 191 Figure 1: HIP lookup and base exchange 193 Figure 1 shows the lookup steps and HIP base exchange when a node's 194 host identities are stored alongside its IP addresses. In step #1, 195 the initiator I performs a DNS lookup on R's domain name FQDN(R). 196 The DNS server responds with both R's host identities HI(R) and its 197 IP addresses IP(R) in step #2. 199 The initiator I uses both pieces of information to perform the HIP 200 base exchange with R in step #3. (The details of the base exchange, 201 specified in [3], are not relevant to this discussion and will thus 202 be omitted.) 204 Note that the DNS does not currently store the HI->IP mapping 205 directly. Instead, a DNS lookup on a domain name returns both its 206 FQDN->HI and FQDN->IP entries. The HIP stack then implicitly 207 constructs the HI->IP mapping based on the HI and IP information 208 returned by the DNS lookup. In the example in Figure 1, the FQDN(R) 209 lookup in step #1 returns both HI(R) and IP(R) in step #2. HIP 210 implicitly constructs the HI(R)->IP(R) mapping based on the 211 assumption that HI(R) is reachable at IP(R). 213 One disadvantage of this approach is that a node's domain name is 214 required to obtain both its host identities and its IP addresses. 215 Even if a HIP node already knows the host identity of a HIP peer 216 through other means, it cannot currently obtain the peer's IP 217 addresses through the DNS. The DNS does not maintain an explicit 218 HI->IP table, but instead indexes host identities only by domain 219 names. 221 A reverse HIP->FQDN DNS mapping could address this limitation. HIP 222 nodes would then look up a HIP peer's domain name through its host 223 identity. They would then use the returned domain name to find the 224 peer's IP addresses in a second lookup. However, the DNS may not be 225 structurally suited to maintain the reverse HIP->FQDN mapping. As 226 the main Internet-wide database, the DNS is already being overloaded 227 with functionality that might be better handled with new mechanisms 228 [16]. Finally, the additional reverse lookup would increase the 229 latency of the HIP base exchange. 231 3. Communication Between Mobile or Multi-Homed HIP Nodes 233 HIP decouples domain names from IP addresses. Because transport 234 protocols bind to host identities, they remain unaware if the set of 235 IP addresses associated with a host identity changes. This change 236 can have various reasons, including, but not limited to, mobility and 237 multi-homing. 239 Proposed extensions for mobility and multi-homing [4] allow a HIP 240 node to notify its peers about changes in its set of IP addresses. 241 These extensions require an established HIP association between two 242 nodes, i.e., a completed HIP base exchange. 244 In addition to notifying its current peers about changes in its IP 245 addresses, a HIP node must also update its HI->IP mapping in response 246 to IP address changes. Otherwise, HIP base exchanges from new peers 247 could fail because they try to contact the node at an IP address it 248 is no longer reachable at. 250 3.1 Mobility and Multi-Homing with DNS Updates 252 If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP 253 table, nodes can dynamically update their DNS entry in a secure 254 fashion [5][6]. The DNS server maintaining the information will then 255 sign and distribute the updated zone. 257 Figure 2 shows an example of this scenario. In step #1, R registers 258 its FQDN(R)->IP(R) entry in the DNS. It will dynamically update the 259 DNS entry whenever its IP addresses IP(R) change. Because the DNS 260 always contains R's current IP addresses, node I can perform a HIP 261 base exchange with R at its new IP address (steps #2-4). 263 One drawback of using dynamic DNS updates in this way is the cost of 264 updating secure zones. Re-signing an entire zone whenever the IP 265 addresses of one entry change places a high cost on the DNS server. 266 Using dynamic DNS to update HI->IP mappings may thus not be 267 appropriate when changes of IP addresses are frequent. 269 #2 FQDN(R) +----------+ 270 +-------------------->| DNS | 271 | +-------------------| |<------+ 272 | | #3 HI(R), IP(R) | FQDN->HI | | #1 Update 273 | | | FQDN->IP | | FQDN(R)->IP(R) 274 | | +----------+ | whenever IP(R) 275 | V | changes. 276 +-----+ #4 HIP base exchange +-----+ 277 | |-------------------------------->| | 278 | I |<--------------------------------| R | 279 | |-------------------------------->| | 280 | |<--------------------------------| | 281 +-----+ +-----+ 283 Figure 2: HIP lookup and base exchange with DNS updates 285 A simple, operational change could help limit the costs of frequent 286 DNS updates. Instead of recomputing a zone after each dynamic 287 update, a DNS server could aggregate the modifications and only 288 perform zone updates periodically. The disadvantage of this approach 289 is that HIP nodes may be unreachable until the DNS server distributes 290 the updated zone. 292 Another concern with using the DNS to support HIP node mobility is 293 the propagation time of updated DNS entries. DNS servers frequently 294 cache DNS responses to reduce the load on the primary servers. 295 During the time-to-live associated with a DNS response, DNS servers 296 may answer additional requests for the same DNS entry from their 297 local caches instead of contacting the primary servers. Thus, even 298 after a HIP node updates its DNS entry, the DNS can still serve the 299 old entry until the cached responses expire. This can lead to 300 communication problems, because peers may try to contact a HIP node 301 at an IP address it is no longer reachable at. 303 3.2 Mobility and Multi-Homing with Rendezvous Servers 305 The HIP architecture tries to greatly reduce the frequency of Dynamic 306 DNS updates by introducing rendezvous servers [2]. Instead of 307 registering its current set of IP addresses in its HI->IP entry in 308 the DNS, a HIP node may instead register the IP addresses of its 309 rendezvous servers. Because the IP addresses of rendezvous servers 310 are assumed to change only infrequently, this approach can 311 significantly reduce the load on DNS servers. 313 Rendezvous servers maintain a mapping between the host identities of 314 HIP nodes for which they provide service and the node's current IP 315 addresses. HIP nodes must notify their rendezvous servers about any 316 changes in their IP addresses. This approach effectively relocates 317 the HI->IP information - and the burden of keeping it current - from 318 the DNS to the rendezvous servers. This can reduce update costs 319 under the assumption that rendezvous servers provide more efficient 320 ways of maintaining HI->IP tables. 322 When a packet destined for one of its HIP nodes arrives at a 323 rendezvous server, it relays the packet to one of the HIP node's 324 current IP addresses. Due to the specifics of the HIP, only the 325 first packet of a HIP base exchange will require such relaying [2]. 326 Subsequent packet of the HIP base exchange and all further data 327 packets will directly flow between the HIP nodes, bypassing the 328 rendezvous server. 330 #3 FQDN(R) +----------+ #2 Register IP(RVS) in 331 +--------------------->| DNS | FQDN(R)->IP(RVS). 332 | +--------------------| |<------------------+ 333 | | #4 HI(R), IP(RVS) | FQDN->HI | | 334 | | | FQDN->IP | | 335 | | +----------+ | 336 | | | 337 | | #1 Update IP(R) in HI(R)->IP(R) | 338 | | +--------+ whenever IP(R) changes. | 339 | | | RVS |<------------------------------+ | 340 | | | | | | 341 | V +->| HI->IP |--+ | | 342 +-----+ | +--------+ | +-----+ 343 | |---+ +------------------------->| | 344 | I | #5 First Message of HIP base exchange | R | 345 | | | | 346 | |<--------------------------------------------| | 347 | |-------------------------------------------->| | 348 | |<--------------------------------------------| | 349 +-----+ #6 Remainder of HIP base exchange +-----+ 351 Figure 3: HIP lookup and base exchange with rendezvous server 353 Figure 3 shows a HIP lookup and base exchange involving a rendezvous 354 server. Here, HIP node R is using rendezvous server RVS. In step 355 #1, it updates RVS with its current IP addresses IP(R). Then, in 356 step #2, R registers the rendezvous server's IP addresses IP(RVS) in 357 its FQDN(R)->IP(RVS) DNS entry. 359 In step #3, a second HIP node I issues a DNS lookup on FQDN(R) to 360 obtain R's host identities HI(R) and IP addresses. The lookup 361 returns R's host identities HI(R) in step #4. The DNS reply also 362 includes the IP addresses of the rendezvous server IP(RVS) (instead 363 of IP(R), because R's current addresses are unknown to the DNS.) 364 In step #5, node I initiates the HIP base exchange. It addresses the 365 first packet of the HIP base exchange to IP(RVS). Upon receipt, the 366 rendezvous server relays the packet to one of R's current IP 367 addresses IP(R). The remainder of the HIP base exchange then occurs 368 directly between I and R in step #6. 370 When rendezvous servers maintain the HI->IP information, they may 371 support more efficient update operations compared to dynamic DNS 372 updates (Section 3.1). Unlike the DNS, rendezvous servers do not 373 provide a lookup service. Instead, they use the HI->IP information 374 to actively relay traffic between HIP nodes. 376 This approach changes the role of the IP addresses stored in a DNS 377 entry. Traditionally, nodes were directly reachable at the IP 378 addresses listed in their DNS entry. HIP rendezvous server change 379 this basic property by replacing the IP addresses of their client 380 nodes in the DNS with their own. The IP addresses in a DNS entry 381 hence no longer directly designate interfaces of an endpoint. 382 Instead, they identify interfaces of a node that can relay packets to 383 the endpoint. 385 When two HIP nodes communicate, this change has few consequences. 386 HIP decouples higher layers from underlying IP addresses. However, 387 when HIP and non-HIP nodes communicate, this change has a significant 388 impact on the overall architecture. Section 4 will discuss the 389 implications in detail. 391 4. Communication Between HIP and Non-HIP Nodes 393 Section 2 and Section 3 have discussed communication between HIP 394 nodes. This section focuses on communication between HIP and non-HIP 395 nodes. Two different scenarios exist. First, a HIP initiator may 396 start communication with a non-HIP recipient. Second, a non-HIP 397 initiator may try to contact a HIP recipient. 399 Without rendezvous servers, communication between HIP and non-HIP 400 nodes remains identical to the current Internet. Transport-layer 401 protocols bind directly to IP addresses. When IP addresses change, 402 due to mobility or other reasons, transport-layer connections break. 404 Rendezvous servers may establish some of HIP's benefits even if one 405 of the endpoints does not support it. Rendezvous servers live at 406 static IP addresses. They can maintain ongoing transport-layer 407 connections by acting as a relays for HIP nodes whose IP addresses 408 may change. The discussion in the remainder of this section assumes 409 that HIP nodes utilize rendezvous servers to maintain the HI->IP 410 information as described in Section 3. 412 The HIP architecture document [2] discusses the role of rendezvous 413 servers in HIP communication. However, it does not currently 414 describe the details of how rendezvous server relay traffic between 415 HIP and non-HIP nodes. The remainder of this section presents this 416 aspect of rendezvous servers. 418 4.1 Non-HIP Initiator to HIP Responder 420 In the first scenario, a non-HIP initiator starts communication with 421 a HIP node. The HIP node is using rendezvous servers. Figure 4 422 shows this case. 424 #3 FQDN(R) +----------+ #2 Register IP(RVS) in 425 +----------------------->| DNS | FQDN(R)->IP(RVS). 426 | +----------------------| |<--------------------+ 427 | | #4 HI(R), IP(RVS) | FQDN->HI | | 428 | | | FQDN->IP | | 429 | | +----------+ | 430 | | | 431 | | #1 Update IP(R) in HI(R)->IP(R) | 432 | | whenever IP(R) changes. | 433 | | +---------------------------+ | 434 | | | | | 435 | V V | | 436 +---------+ +--------+ +---------+ 437 | I | | RVS | | R | 438 | | | | | | 439 | Non-HIP |<--------------->| HI->IP |<---------------->| HIP | 440 +---------+ +--------+ +---------+ 441 #5 RVS transparently relays packets 442 IP(I)<->IP(RVS) to/from IP(R). 444 Figure 4: Non-HIP initiator to HIP responder via rendezvous server 446 Steps #1-4 remain unchanged from the HIP-HIP case shown in Figure 3 447 and discussed in Section 3.2. HIP node R registers the IP addresses 448 of its rendezvous server RVS in the DNS. It also keeps RVS updated 449 with its current IP addresses IP(R). 451 When non-HIP node I starts communication with R, it performs a DNS 452 lookup on FQDN(R) and receives HI(R) and IP(RVS) in return. Since I 453 does not support HIP, it disregards the host identity HI(R) returned 454 by the DNS lookup. Instead, it sets up transport-layer connections 455 using the IP addresses IP(RVS) obtained from the DNS. The rendezvous 456 server RVS must then transparently relay the communication to one of 457 R's current IP addresses IP(R) in step #5. 459 End-to-end communication between I and R is complicated by the fact 460 that R's DNS entry lists IP addresses IP(RVS). The addresses IP(RVS) 461 belong to the rendezvous server RVS and not R, the endpoint of the 462 communication. I's transport layer will thus bind connections to R 463 to IP addresses IP(I) and IP(RVS). Section 4.3 will discuss the 464 implications. 466 4.2 HIP Initiator to Non-HIP Responder 468 This section describes a second scenario, where a HIP node initiates 469 communication with a non-HIP node. Figure 5 shows this case. 471 As before, the HIP node I keeps its rendezvous server RVS updated 472 about its current IP addresses IP(I) in step #2. It also registers 473 the IP addresses of the rendezvous server IP(RVS) in its DNS entry in 474 step #2, instead of its own. 476 In step #3, I initiates a transport-layer connection to R by 477 performing a domain name lookup on FQDN(R). The DNS reply in step #4 478 contains R's IP addresses IP(R) but no host identities, because R is 479 not a HIP node. 481 #2 Register IP(RVS) in 482 FQDN(I)->IP(RVS). +----------+ 483 +-------------------------->| DNS | 484 | | | 485 | #3 FQDN(R) | FQDN->HI |<--------------------+ 486 | +----------------------->| FQDN->IP | | 487 | | +----------------------| | | 488 | | | #4 IP(R) +----------+ | 489 | | | | 490 | | | #1 Update IP(I) in HI(I)->IP(I) | 491 | | | whenever IP(I) changes. | 492 | | | +-------------------------------+ | 493 | | | | | | 494 | | V | V | 495 +---------+ +--------+ +---------+ 496 | I | | RVS | | R | 497 | | | | | | 498 | HIP |<----------------------->| HI->IP |<-------->| Non-HIP | 499 +---------+ +--------+ +---------+ 500 #5 RVS translates/relays packets 501 IP(I)<->IP(R) to/from IP(RVS). 503 Figure 5: HIP initiator to non-HIP responder via rendezvous server 505 If I uses IP(R) to establish a direct transport-layer connection with 506 R, the connection will break when R's IP addresses change. Instead, 507 R relays its traffic through rendezvous server RVS in step #5. Since 508 the IP addresses of RVS are static, the transport-layer connection 509 between I and R remains unaffected from changes to R's IP addresses. 511 4.3 Discussion 513 As illustrated by the two scenarios described in Section 4.1 and 514 Section 4.2, rendezvous servers can isolate non-HIP nodes from 515 changes to their HIP peers' IP addresses. Binding transport-layer 516 connections to static IP addresses of rendezvous servers, instead of 517 the more volatile addresses of HIP peers, allows connections between 518 HIP and non-HIP nodes to retain some of the benefits of HIP-HIP 519 connections. 521 The current HIP architecture document [2] requires HIP nodes using 522 rendezvous servers to register the rendezvous server's IP addresses 523 in the DNS. Consequently, rendezvous servers become explicit 524 connections endpoints. This causes several challenges for end-to-end 525 communication, as discussed in the next sections. 527 4.3.1 Relaying Overhead 529 The first issue is relaying overhead. When HIP nodes communicate, 530 rendezvous servers will only need to relay the first packet of a HIP 531 base exchange. The remaining HIP base exchange packets, as well as 532 all subsequent data packets, will flow directly between the HIP 533 nodes. 535 This is not the case for communication between HIP and non-HIP nodes. 536 A non-HIP node will bind its transport-layer connection to the IP 537 address obtained by looking up the HIP peer's domain name in the DNS. 538 This will be the address of the rendezvous server. 540 Consequently, all data from the non-HIP to the HIP node will flow 541 through the rendezvous server. This can cause significant relaying 542 overhead. It can also increase the communication delay between the 543 nodes, further affecting performance. 545 Relaying overhead will be difficult to eliminate. In order to 546 provide some of the benefits of HIP, non-HIP peers communicating with 547 HIP nodes must be able to bind their transport-layer connections to 548 static IP addresses. This constraint implies the presence of a 549 statically addressed relay somewhere in the system. 551 4.3.2 Return Traffic 553 A second issue is return traffic from the HIP node to the non-HIP 554 node. Because a non-HIP node binds its transport-layer connection to 555 its peer's IP address, it will not accept return traffic from a 556 different address than it is sending to. Since all traffic from the 557 non-HIP node is addressed to the rendezvous server, the non-HIP node 558 will expect to receive return traffic from that source address. 560 Several approaches may address this issue. First, the HIP node may 561 relay all its return traffic through the rendezvous server as well. 562 This causes additional relaying overhead. Second, the HIP node may 563 spoof the IP address of the rendezvous server when sending return 564 traffic. This may cause problems when firewalls along the path 565 perform ingress filtering [7]. Finally, the approach described in 566 Section 5 can also eliminate this issue. 568 4.3.3 Node Identification 570 A third issue is identification of the specific HIP node that a 571 rendezvous server must relay arriving packets to. Packets arriving 572 from non-HIP nodes are simple IP packets addressed to the rendezvous 573 server. They do not contain host identities or other information 574 that will allow the rendezvous server to identify the correct HIP 575 node for relaying. 577 One solution has the rendezvous server use multiple IP addresses. 578 Each of the HIP nodes for which it provides service receives one 579 unique IP address. The HIP node will then register this unique IP 580 address in the DNS. Hence, the rendezvous server can use the 581 destination IP addresses of arriving packets to identify the HIP node 582 to which they must be relayed to. The approach described in Section 583 5 uses a similar scheme. 585 A downside of registering unique IP addresses per node is a more 586 complex protocol between rendezvous servers and its HIP nodes. 587 Furthermore, rendezvous servers serving many HIP nodes may require 588 many IP addresses. 590 4.3.4 Network Address Translation 592 The HIP architecture document [2] uses the term "forwarding" to 593 describe the operation by which a rendezvous server enables the 594 exchange of packets between communicating nodes. This document uses 595 the term "relaying" instead, to indicate that mechanisms other than 596 IP forwarding may suit the same purpose. 598 One such approach for relaying packets between HIP and non-HIP nodes 599 is Network Address Translation [8]. When acting as a Network Address 600 Translator, a rendezvous server will rewrite the IP headers of 601 packets exchanged between communicating nodes. 603 The use of network address translation remains problematic [9][10]. 605 Avoiding its use in the rendezvous server may improve protocol and 606 application compatibility. Section 5 will present a rendezvous 607 mechanism that relays using simple IP forwarding instead, avoiding 608 possible issues due to the use of network address translation. 610 5. Rendezvous Broker 612 This section describes rendezvous brokers. Rendezvous brokers 613 provide a modified HIP rendezvous mechanism that addresses some of 614 the issues discussed in Section 4. 616 Rendezvous brokers are named for their similarity to tunnels brokers 617 [11]. Rendezvous brokers also share commonalities with MobileIP's 618 Home Agents [12] as well as systems for leasing IP subnets [17]. 620 Note: Rendezvous brokers described in this section may be similar 621 to the "packet forwarding agents" outlined in [18]. While this 622 similarity is under discussion, this document will use the term 623 "rendezvous broker" for clarity. If the two concepts are deemed 624 identical, terminology may change. 626 Rendezvous brokers are IP routers and manage delegations of 627 globally-routable IP subnets. Rendezvous brokers may be located 628 anywhere in the network. HIP has no concept of home networks (unlike 629 MobileIP [12]) that would tie rendezvous brokers to access networks. 631 When a HIP node requests rendezvous service, the rendezvous broker 632 delegates a unique, globally-routable IP address (or prefix) to the 633 HIP node. HIP node and rendezvous broker establish a tunnel using 634 the delegated IP address as the HIP node's tunnel endpoint address. 635 The rendezvous broker installs a route towards the delegated IP 636 address via the tunnel. At the end of this process, the HIP node is 637 globally reachable by non-HIP nodes at the delegated IP address 638 obtained from the rendezvous broker. 640 Figure 6 illustrates this process. In step #1, HIP node R registers 641 its host identity HI(R) with the rendezvous broker RVB. In step #2, 642 R receives an IP address IP(T-R) from RVB. This IP address is 643 globally-routable and delegated to RVB. 645 The rendezvous broker and the HIP node R then establish a tunnel 646 between themselves in step #3. IP(T-R) is the IP address of R's 647 tunnel endpoint, T-RVB the endpoint address of the rendezvous broker. 648 The tunnel encapsulates packets with IP(RVB) and IP(R). RVB then 649 installs a route that forwards packets addressed to IP(T-R) over the 650 tunnel. 652 In step #4, R registers the IP address obtained from RVB in its DNS 653 entry. When the non-HIP initiator I performs a DNS lookup in step 654 #5, it receives IP(T-R) from the DNS in step #6 (along with HI(R), 655 which it ignores). I then initiates a transport-layer connection 656 from IP(I) to IP(T-R). Packets to IP(T-R) will be routed to the RVB, 657 because it is the router for the subnet out of which IP(T-R) was 658 allocated. The RVB will then forward such packets over the tunnel to 659 R due to the route installed in step #3. 661 #5 FQDN(R) +----------+ #4 Register IP(RVB-R) in 662 +----------------------->| DNS | FQDN(R)->IP(T-R). 663 | +----------------------| |<--------------------+ 664 | | #6 HI(R), IP(T-R) | FQDN->HI | | 665 | | | FQDN->IP | | 666 | | +----------+ | 667 | V | 668 +---------+ +--------+ #1 HI(R) +---------+ 669 | | | |<--------------------------| | 670 | I | | RVB |-------------------------->| R | 671 | | | | #2 IP(T-R) | | 672 | | | | | | 673 | Non-HIP | | HI->IP |<------------------------->| HIP | 674 | | | | #3 Setup tunnel | | 675 | | | | IP(T-RVB)<->IP(T-R). | | 676 | | | | | | 677 | |<------->| |<------------------------->| | 678 +---------+ +--------+ #7 RVB forwards packets +---------+ 679 IP(I)<->IP(T-R) 680 via the tunnel. 682 Figure 6: Non-HIP initiator to HIP responder via rendezvous broker 684 The next sections will compare rendezvous brokers to rendezvous 685 servers and discuss several aspects of rendezvous brokers in more 686 detail. 688 5.1 Comparison to Rendezvous Servers 690 Rendezvous brokers address some of the shortcomings of rendezvous 691 servers raised in Section 4.3. One difference is that the IP 692 addresses in a HIP node's DNS entry again identify interfaces of the 693 HIP node itself. With rendezvous servers, the DNS entry instead 694 identifies interfaces of the rendezvous server. 696 This simplifies the operation of the rendezvous broker. It performs 697 simple IP forwarding of packets that already carry the addresses of 698 their final source and destination endpoints. Network Address 699 Translation, or other schemes that relay by modifying packet headers, 700 are not required. This may improve application and protocol 701 compatibility. 703 Because rendezvous brokers are IP routers, additional mechanisms to 704 identify the correct HIP destination node for arriving packets are 705 not required. The globally-routable destination IP address already 706 acts as a unique indicator of the final destination. 708 5.2 Mobility 710 Rendezvous brokers offer mobility support that is equivalent to 711 rendezvous servers. HIP nodes already notify their rendezvous 712 servers when their IP addresses change. Rendezvous brokers also 713 require such notification. 715 When the IP addresses of a HIP node changes, the rendezvous broker 716 and the HIP node must reconfigure the tunnel between them. This 717 reconfiguration only affects the IP addresses used for tunnel 718 encapsulation. The addresses of the tunnel endpoints remain 719 unchanged. Transport-layer connections bound to a HIP node's tunnel 720 endpoint address thus remain unaffected. 722 HIP nodes may change rendezvous servers over time and they may use 723 multiple rendezvous servers at the same time. The same is true for 724 rendezvous brokers. Both rendezvous servers and rendezvous brokers 725 may be located anywhere in the network; unlike MobileIP [12], HIP has 726 no notion of home networks. By separating rendezvous mechanisms from 727 topological locations, HIP allows nodes to choose rendezvous servers 728 or Brokers based on local criteria, including network connectivity, 729 location, or mobility. 731 5.3 Tunneling 733 This document does not further define the specifics of the tunneling 734 mechanism used between a rendezvous broker and its HIP nodes. 735 Possible tunneling mechanisms include [19][20][21][22][23]. 736 Different tunneling mechanisms incur different overheads. Some may 737 also offer better traversal of Network Address Translators or 738 firewalls. 740 Similarly, the tunnel setup protocol between rendezvous brokers and 741 HIP nodes is currently unspecified. Candidate tunnel management 742 approaches include [24][25][26]. 744 Rendezvous brokers forward all traffic from non-HIP nodes to HIP 745 nodes over tunnels. For the return traffic from HIP nodes to non-HIP 746 nodes two options exist. First, return traffic could also flow over 747 tunnel. Second, return traffic could flow through the base network 748 over one of the HIP node's interfaces. The second alternative may 749 offer increased performance due to the avoidance of triangle routing. 750 However, firewalls that perform ingress filtering could prevent 751 communication [7]. 753 Another aspect of using tunnels to connect rendezvous brokers and 754 their HIP nodes is reduced Maximum Transmission Units. 755 Implementation issues in the network stacks of end systems and 756 routers can lead to communication problems in such scenarios [27]. 758 6. Location Privacy with HIP 760 Section 3.2 discussed HIP rendezvous servers and Section 5 discussed 761 HIP rendezvous brokers. One common characteristic of these 762 approaches is end-to-end addressing, i.e., initiator and responder of 763 HIP associations eventually learn the other's current IP address. 764 Because IP addresses have topological relevance, they may allow to 765 deduce additional information about the peer, such as their ISP or 766 even geographical location. In some cases, this is undesirable. 768 The current HIP architecture does not support location privacy. It 769 exposes peer IP addresses, which in their function as locators can be 770 used to deduce additional information about peers. If location 771 privacy is a non-functional requirement for HIP, the current 772 architecture must be augmented. 774 Rendezvous brokers, as described in Section 5, maintain bindings 775 between peers' local and globally visible IP addresses. Rendezvous 776 brokers may thus already support some degree of location privacy, 777 because they only make a host's global IP addresses visible to its 778 peers. This, however, requires all traffic to flow through the 779 broker. 781 One key limitation of the current HIP architecture with regard to 782 location privacy is that it implicitly requires the end hosts to 783 resolves their peers' host identities into the corresponding IP 784 addresses. This does not change even with rendezvous brokers; they 785 still reveal the peers' global IP addresses to the end hosts. 787 The following sections discuss extensions to the current HIP 788 architecture that establish location privacy, i.e., do not reveal the 789 IP addresses associated with a node's network interfaces to its 790 peers. 792 6.1 Location Privacy Between HIP Nodes 794 6.1.1 Distributing HIP Functionality 796 With HIP, transport-layer services bind to host identities instead of 797 IP addresses. Resolution of the destination's host identity to its 798 associated IP addresses implicitly occurs at the host identity layer 799 and may involve additional communication with remote entities, such 800 as the DNS. This is because the network layer requires packets to be 801 addressed with the appropriate IP addresses to allow traffic 802 forwarding towards the final destination. Figure 7 illustrates this 803 view of the HIP protocol stack. 805 +---------------------+ 806 | Transport Layer | pairs 807 +---------------------+ 809 +---------------------+ 810 | Host Identity Layer | Host Identity 811 +---------------------+ | 812 | translation 813 +---------------------+ V 814 | Network Layer | IP address 815 +---------------------+ | 816 | ARP, ND 817 +---------------------+ V 818 | Link Layer | LL address 819 +---------------------+ 821 Figure 7: HIP architecture reference model 823 One approach to support a limited degree of location privacy using 824 HIP is to have both the initiator and the responder of a HIP 825 association use rendezvous brokers throughout a communication. This 826 approach, however, still reveals the remote host's globally visible 827 IP addresses, because the tunneled IP packet between a host and its 828 RVB contains the peer's global IP address. It does hide local 829 movement and the associated changes of a host's local IP address 830 though. 832 A more complete approach to establish location privacy is to split up 833 the HIP architecture and relocate some pieces of the HIP 834 functionality into new network entities. Figure 8 shows one example 835 of such an approach of splitting and relocating HIP functionality and 836 the following sections discuss it in more detail. 838 When HIP functionality is relocated, destination networks become 839 similar to IP-based mobile communication networks. They comprise of 840 various network components (agents, brokers, servers, gateways) and 841 access routers that provide mobile hosts with wired or wireless 842 access to an infrastructure. In such environments, HIP should not 843 expose the IP addresses of a host to its peers. Consequently, it 844 must hide or obfuscate them at least on the last hop between a host 845 and its access router. 847 HIP: HIP with functional split: 849 Host | Host Network 850 --------------------+----------------------------------------- 851 Host Identity | Host Identity Host Identity 852 | | | | 853 | translation | +----------------->| translation 854 | | | 855 v | v 856 HI associated IP | known IP address of HI associated 857 IP address | translating network IP address 858 | | entity | 859 | | | | 860 | | | | 861 | ARP, ND | | | ARP, ND 862 V | V V 863 LL address | LL address LL address 865 Figure 8: Relocating HIP functions into the network 867 The proposed functional split separates the HI-to-IP address 868 resolution from the end host's HIP layer and relocates it to an 869 entity inside the network. Instead of addressing their peers 870 directly, hosts now address a network entity that then resolves the 871 HI to the IP address apparently associated with the remote host. 872 ("Apparently", because that address may in fact belong to another 873 network entity that will deliver to the remote host.) Consequently, 874 the IP addresses used by the end host's HIP layer is that of a 875 "well-known" network component. Various possibilities for the 876 relocation of the HIP lookup exist. The following sections describe 877 one approach that relocates the resolution function to an enhanced 878 rendezvous server that hosts have previously registered with. To 879 avoid ambiguities with the previously described rendezvous servers 880 and brokers, the discussion will use the term "rendezvous agent" for 881 this new entity. (This terminology may change in future revisions of 882 this document.) 884 Two separate scenarios for communication involving a rendezvous agent 885 (RVA) exist. First, hosts may address all traffic to the RVA. 886 Hence, the RVA address is the well-known address that the host's HIP 887 layers use according to the functional split in Figure 8. In the 888 second case, hosts address all packets to their current access 889 routers, which act as relays between the hosts and their RVAs. 891 The following figures extend the notation used in the beginning of 892 this document. Initiator and responder hosts are still I and R, 893 respectively. The local IP address of host X is IP_L(X) whereas its 894 global IP address, maintained by the RVAs, is IP_G(X). 896 6.1.2 Communication with Local Rendezvous Agents 898 This scenario assumes that mobile hosts are allowed to communicate 899 directly with their associated local RVAs. They have previously 900 registered with the RVAs as described in Figure 8. 902 Figure 9 shows the operation of the protocol when a host directly 903 communicates with its RVA. It also illustrates the case where I and 904 R are located in different domains. 906 Domain A | Domain B 907 | 908 (1) +---------------+ | 909 FQDN(R) |+-----+ +-----+| | 910 +---->|| DNS | | DB || | 911 | |+-----+ +-----+| | 912 | +---------------+ | 913 | (4) ^ | 914 | (2) HI(R) | (5) | 915 | HI(R) | IP_G(R) | 916 v v | 917 +---+ (3) HI(R) +-----+ / +-----+ +---+ 918 | I |<--------->|RVA-I|<--------------->|RVA-R|<--------->| R | 919 +---+IP_L(I) +-----+IP_G(I) / IP_G(R)+-----+ IP_L(R)+---+ 920 | 922 Figure 9: Direct communication between host and rendezvous agent 924 When I wants to establish communication with R, it first resolves 925 FQDN(R) into the associated HI(R), possibly via the DNS. When 926 rendezvous agents are used, the DNS MUST NOT return R's IP addresses 927 IP(R). I then sends its packets to R to its RVA (RVA-I) and 928 includes R's HI(R). When RVA-I receives the packets destined for R, 929 it resolves HI(R) into R's global IP address IP_G(R) with the help of 930 a currently unspecified database (DB). This database may or may not 931 be collocated with the DNS. 933 >From then on, RVA-I serves as a proxy between I and R's RVA (RVA-R). 934 RVA-I will never expose IP_G(I), much less IP_L(I), and RVA-R does 935 the same. Communication between the RVAs occurs with the hosts' 936 global IP addresses IP_G(I) and IP_G(R), while packets forwarding 937 between a host and its RVA uses the local IP addresses IP_L(I) and 938 IP_L(R). 940 One disadvantage of this approach is that it places a high load on 941 the RVAs caused by relaying of all traffic. To limit load on a 942 particular RVA, multiple RVAs may serve the registered hosts of a 943 domain to distribute load. Domains may coordinate load distribution 944 when hosts first attempt to register with an RVA. The specifics of 945 such mechanisms are out of the scope of this document. 947 Some service providers may have policies that forbid mobile hosts to 948 communicate directly with network components and require them to use 949 controlled edge relays. This provides some measure of protection by 950 hiding the actual location and IP addresses of the network 951 components. Under such a policy, HIP relays or attendants might be 952 collocated with access routers. The next section briefly discusses 953 this case. 955 6.1.3 Communication with First-Hop Attendants 957 This section assumes that a policy prohibits mobile hosts to 958 communicate directly with RVAs, but requires them to use attendants. 959 These attendants may be collocated with a domain's access routers and 960 serve as relays for IP packets between a host and its associated 961 RVAs. 963 Hosts usually know the IP address of their access router. A default 964 router's IP address can thus serve as the well-known IP address used 965 by the host's HIP layer. The access router's relaying function may 966 also support RVA discovery by processing hosts' discovery or 967 registration request and assign them an alias address to identify 968 their assigned RVA. This approach uniquely identifies RVAs without 969 revealing their IP address to the mobile hosts. Access routers map 970 these aliases into the associated RVA's IP address. (This 971 description simplifies the process for the purposes of discussion. 972 The specifics of attendant functionality are out of the scope of this 973 draft.) 975 Communication establishment is similar to the scenario described in 976 Figure 9, but no direct path exist between a host and its RVA. 977 Instead, as shown in Figure 10, the access router terminates the path 978 and sets up a new one towards the host or the RVA, respectively. 979 (The current revision of this document does not yet discuss the 980 details of the require IP addressing schemes and binding maintenance. 981 A future revision may investigate these issues.) 983 One advantage of this architecture is that it does not reveal the 984 RVAs' IP addresses to the mobile hosts. The attendants that are 985 collocated with the access routers relay all communication, including 986 signaling and data traffic. A second advantage is that attendants 987 can support discovery of appropriate RVAs before or during a host's 988 registration process. 990 Domain A | Domain B 991 | 992 (1) +---------------+ | 993 FQDN(R) |+-----+ +-----+| | 994 +----------->|| DNS | | DB || | 995 | |+-----+ +-----+| | 996 | +---------------+ | 997 | (4) ^ | 998 | (2) HI(R) | (5) | 999 | HI(R) | IP_G(R) | 1000 v v | 1001 +---+ (3) HI(R) +----+ +-----+ / +-----+ +----+ +---+ 1002 | I |<--------->|AR-I|<-->|RVA-I|<----->|RVA-R|<-->|AR-R|<-->| R | 1003 +---+ +----+ +-----+ / +-----+ +----+ +---+ 1004 | 1006 Figure 10: Indirect communication between host and rendezvous agent 1008 A disadvantage of the attendant-based architecture is that two relays 1009 per host exist, bringing the total number of relays along the path 1010 from I to R to four. This is because access routers now encapsulate 1011 and decapsulate packets in addition to the RVAs. This introduces 1012 additional per-packet processing overhead and increases forwarding 1013 delays. 1015 In addition, this solution is difficult to realize without 1016 introducing and maintaining state at the RVAs and attendants. This 1017 can affect scalability and performance of the access routers. 1019 6.2 Location Privacy between HIP and Non-HIP Nodes 1021 Extending the proposed approaches for establishing location privacy 1022 to include communication with non-HIP nodes is difficult. They 1023 require the initiator to transmit the peer's host identity to the 1024 translating function inside the network. Including HI(R) in the HIP 1025 header easily meets this requirement for HIP nodes. For non-HIP 1026 nodes, this is not an option. Furthermore, non-HIP nodes require a 1027 static identifier to replace the HI for communication, which some 1028 entity in the network must then transparently resolve. A static IP 1029 address might be such an identifier, for example, using MobileIP, 1030 which offers the peer's "home address" for such a purpose. 1032 One approach to transmit a peer's static IP address to the 1033 translating network entity (or RVA) could be IP tunneling. Host I 1034 addresses R's static IP address in the inner, tunneled packet, 1035 whereas the outer IP header addresses the RVA (assuming direct 1036 communication between a host and its RVA.) The RVA terminates the 1037 tunnel, decapsulates the packet and resolves R's static IP address to 1038 R's globally visible IP address IP_G(R). 1040 As above, packets between RVAs use IP_G(I) and IP_G(R) as addresses, 1041 respectively. Packets between a host and its RVA use the host's 1042 local IP address and the RVA's address in the outer IP header, 1043 whereas the inner header must use the static IP addresses of both. 1045 7. Security Considerations 1047 The security aspects of different HIP rendezvous mechanisms are 1048 currently being investigated. They will be discussed in a future 1049 revision of this document. 1051 8. Acknowledgments 1053 The following people have helped to improve this document through 1054 thoughtful suggestions: Marcus Brunner, Tom Henderson, Mika Kousa, 1055 Pekka Nikander, Simon Schuetz, Martin Stiemerling, and Juergen 1056 Quittek. 1058 9. References 1060 9.1 Normative References 1062 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 1063 13, RFC 1034, November 1987. 1065 [2] Moskowitz, R., "Host Identity Protocol Architecture", 1066 draft-moskowitz-hip-arch-05 (work in progress), October 2003. 1068 [3] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity 1069 Protocol", draft-moskowitz-hip-09 (work in progress), February 1070 2004. 1072 [4] Nikander, P., "End-Host Mobility and Multi-Homing with Host 1073 Identity Protocol", draft-nikander-hip-mm-01 (work in 1074 progress), January 2004. 1076 [5] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic 1077 Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 1078 April 1997. 1080 [6] Wellington, B., "Secure Domain Name System (DNS) Dynamic 1081 Update", RFC 3007, November 2000. 1083 [7] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1084 Defeating Denial of Service Attacks which employ IP Source 1085 Address Spoofing", BCP 38, RFC 2827, May 2000. 1087 [8] Srisuresh, P. and K. Egevang, "Traditional IP Network Address 1088 Translator (Traditional NAT)", RFC 3022, January 2001. 1090 [9] Hain, T., "Architectural Implications of NAT", RFC 2993, 1091 November 2000. 1093 [10] Senie, D., "Network Address Translator (NAT)-Friendly 1094 Application Design Guidelines", RFC 3235, January 2002. 1096 [11] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel 1097 Broker", RFC 3053, January 2001. 1099 [12] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 1100 2002. 1102 9.2 Informative References 1104 [13] Saltzer, J., "On the Naming and Binding of Network 1105 Destinations", RFC 1498, August 1993. 1107 [14] Sunshine, C., "Addressing Problems in Multi-Network Systems", 1108 IEN 178, April 1981. 1110 [15] Kent, S. and R. Atkinson, "Security Architecture for the 1111 Internet Protocol", RFC 2401, November 1998. 1113 [16] Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467, 1114 February 2003. 1116 [17] Touch, J., Eggert, L. and Y. Wang, "TetherNet Anti-NAT - Secure 1117 Internet Subnet Rental System", Proc. 3rd DARPA Information 1118 Survivability Conference and Exposition (DISCEX-III) 2003, 1119 April 2003. 1121 [18] Nikander, P., Ylitalo, J. and J. Wall, "Integrating Security, 1122 Mobility, and Multi-Homing in a HIP Way", Proc. Network and 1123 Distributed Systems Security Symposium (NDSS) 2003, February 1124 2003. 1126 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1127 1996. 1129 [20] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network 1130 Address Translation (NAT) Devices", RFC 3519, May 2003. 1132 [21] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, 1133 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 1135 [22] Nikander, P., "A Bound End-to-End Tunnel (BEET) mode for ESP", 1136 draft-nikander-esp-beet-mode-00 (work in progress), October 1137 2003. 1139 [23] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and 1140 B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, 1141 August 1999. 1143 [24] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 1144 2107, February 1997. 1146 [25] Beijnum, I., "On Demand Tunneling For Multihoming", 1147 draft-van-beijnum-multi6-odt-00 (work in progress), January 1148 2004. 1150 [26] Touch, J., "Dynamic Internet overlay deployment and management 1151 using the X-Bone", Computer Networks Vol. 36, No. 2-3, July 1152 2001. 1154 [27] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, 1155 September 2000. 1157 Authors' Addresses 1159 Lars Eggert 1160 NEC Network Laboratories 1161 Kurfuerstenanlage 36 1162 Heidelberg 69115 1163 DE 1165 Phone: +49 6221 90511 43 1166 Fax: +49 6221 90511 55 1167 EMail: lars.eggert@netlab.nec.de 1168 URI: http://www.netlab.nec.de/ 1170 Marco Liebsch 1171 NEC Network Laboratories 1172 Kurfuerstenanlage 36 1173 Heidelberg 69115 1174 DE 1176 Phone: +49 6221 90511 46 1177 Fax: +49 6221 90511 55 1178 EMail: marco.liebsch@netlab.nec.de 1179 URI: http://www.netlab.nec.de/ 1181 Appendix A. Document Revision History 1183 +-----------+-------------------------------------------------------+ 1184 | Revision | Comments | 1185 +-----------+-------------------------------------------------------+ 1186 | 00 | Initial version. | 1187 | 01 | Add discussion on HIP location privacy and rendezvous | 1188 | | agents. Minor fixes to figures and their descriptive | 1189 | | text. Use boilerplate from RFC 3667. | 1190 +-----------+-------------------------------------------------------+ 1192 Intellectual Property Statement 1194 The IETF takes no position regarding the validity or scope of any 1195 Intellectual Property Rights or other rights that might be claimed to 1196 pertain to the implementation or use of the technology described in 1197 this document or the extent to which any license under such rights 1198 might or might not be available; nor does it represent that it has 1199 made any independent effort to identify any such rights. Information 1200 on the procedures with respect to rights in RFC documents can be 1201 found in BCP 78 and BCP 79. 1203 Copies of IPR disclosures made to the IETF Secretariat and any 1204 assurances of licenses to be made available, or the result of an 1205 attempt made to obtain a general license or permission for the use of 1206 such proprietary rights by implementers or users of this 1207 specification can be obtained from the IETF on-line IPR repository at 1208 http://www.ietf.org/ipr. 1210 The IETF invites any interested party to bring to its attention any 1211 copyrights, patents or patent applications, or other proprietary 1212 rights that may cover technology that may be required to implement 1213 this standard. Please address the information to the IETF at 1214 ietf-ipr@ietf.org. 1216 Disclaimer of Validity 1218 This document and the information contained herein are provided on an 1219 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1220 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1221 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1222 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1223 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1224 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1226 Copyright Statement 1228 Copyright (C) The Internet Society (2004). This document is subject 1229 to the rights, licenses and restrictions contained in BCP 78, and 1230 except as set forth therein, the authors retain all their rights. 1232 Acknowledgment 1234 Funding for the RFC Editor function is currently provided by the 1235 Internet Society.