idnits 2.17.1 draft-ietf-hip-rfc5204-bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5204, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4790 days in the past. Is this intentional? 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 (-20) exists of draft-ietf-hip-rfc5201-bis-05 == Outdated reference: A later version (-11) exists of draft-ietf-hip-rfc5203-bis-00 == Outdated reference: A later version (-10) exists of draft-ietf-hip-rfc5205-bis-00 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-14) exists of draft-ietf-hip-rfc5206-bis-01 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft Juniper Networks 4 Obsoletes: 5204 (if approved) L. Eggert 5 Intended status: Standards Track Nokia 6 Expires: September 15, 2011 March 14, 2011 8 Host Identity Protocol (HIP) Rendezvous Extension 9 draft-ietf-hip-rfc5204-bis-01 11 Abstract 13 This document defines a rendezvous extension for the Host Identity 14 Protocol (HIP). The rendezvous extension extends HIP and the HIP 15 registration extension for initiating communication between HIP nodes 16 via HIP rendezvous servers. Rendezvous servers improve reachability 17 and operation when HIP nodes are multi-homed or mobile. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 15, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 56 3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5 57 3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 5 58 3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6 59 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7 60 4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7 61 4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8 62 4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8 63 4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9 64 4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10 65 4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10 66 4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10 67 4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11 68 4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11 69 4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 The Host Identity Protocol (HIP) Architecture [RFC4423] introduces 81 the rendezvous mechanism to help a HIP node to contact a frequently 82 moving HIP node. The rendezvous mechanism involves a third party, 83 the rendezvous server (RVS), which serves as an initial contact point 84 ("rendezvous point") for its clients. The clients of an RVS are HIP 85 nodes that use the HIP Registration Extension 86 [I-D.ietf-hip-rfc5203-bis] to register their HIT->IP address mappings 87 with the RVS. After this registration, other HIP nodes can initiate 88 a base exchange using the IP address of the RVS instead of the 89 current IP address of the node they attempt to contact. Essentially, 90 the clients of an RVS become reachable at the RVS's IP address. 91 Peers can initiate a HIP base exchange with the IP address of the 92 RVS, which will relay this initial communication such that the base 93 exchange may successfully complete. 95 2. Terminology 97 This section defines terms used throughout the remainder of this 98 specification. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 In addition to the terminology defined in the HIP specification 105 [I-D.ietf-hip-rfc5201-bis] and the HIP Registration Extension 106 [I-D.ietf-hip-rfc5203-bis], this document defines and uses the 107 following terms: 109 Rendezvous Service 110 A HIP service provided by a rendezvous server to its rendezvous 111 clients. The rendezvous server offers to relay some of the 112 arriving base exchange packets between the initiator and 113 responder. 115 Rendezvous Server (RVS) 116 A HIP registrar providing rendezvous service. 118 Rendezvous Client 119 A HIP requester that has registered for rendezvous service at a 120 rendezvous server. 122 Rendezvous Registration 123 A HIP registration for rendezvous service, established between a 124 rendezvous server and a rendezvous client. 126 3. Overview of Rendezvous Server Operation 128 Figure 1 shows a simple HIP base exchange without a rendezvous 129 server, in which the initiator initiates the exchange directly with 130 the responder by sending an I1 packet to the responder's IP address, 131 as per the HIP specification [I-D.ietf-hip-rfc5201-bis]. 133 +-----+ +-----+ 134 | |-------I1------>| | 135 | I |<------R1-------| R | 136 | |-------I2------>| | 137 | |<------R2-------| | 138 +-----+ +-----+ 140 Figure 1: HIP base exchange without rendezvous server. 142 The End-Host Mobility and Multihoming with the Host Identity 143 Protocol specification [I-D.ietf-hip-rfc5206-bis] allows a HIP node 144 to notify its peers about changes in its set of IP addresses. This 145 specification presumes initial reachability of the two nodes with 146 respect to each other. 148 However, such a HIP node MAY also want to be reachable to other 149 future correspondent peers that are unaware of its location change. 150 The HIP Architecture [RFC4423] introduces rendezvous servers with 151 whom a HIP node MAY register its host identity tags (HITs) and 152 current IP addresses. An RVS relays HIP packets arriving for these 153 HITs to the node's registered IP addresses. When a HIP node has 154 registered with an RVS, it SHOULD record the IP address of its RVS in 155 its DNS record, using the HIP DNS resource record type defined in the 156 HIP DNS Extension [I-D.ietf-hip-rfc5205-bis]. 158 +-----+ 159 +--I1--->| RVS |---I1--+ 160 | +-----+ | 161 | v 162 +-----+ +-----+ 163 | |<------R1-------| | 164 | I |-------I2------>| R | 165 | |<------R2-------| | 166 +-----+ +-----+ 168 Figure 2: HIP base exchange with a rendezvous server. 170 Figure 2 shows a HIP base exchange involving a rendezvous server. It 171 is assumed that HIP node R previously registered its HITs and current 172 IP addresses with the RVS, using the HIP Registration Extension 173 [I-D.ietf-hip-rfc5203-bis]. When the initiator I tries to establish 174 contact with the responder R, it must send the I1 of the base 175 exchange either to one of R's IP addresses (if known via DNS or other 176 means) or to one of R's rendezvous servers. Here, I obtains the IP 177 address of R's rendezvous server from R's DNS record and then sends 178 the I1 packet of the HIP base exchange to RVS. RVS, noticing that 179 the HIT contained in the arriving I1 packet is not one of its own, 180 MUST check its current registrations to determine if it needs to 181 relay the packets. Here, it determines that the HIT belongs to R and 182 then relays the I1 packet to the registered IP address. R then 183 completes the base exchange without further assistance from RVS by 184 sending an R1 directly to the I's IP address, as obtained from the I1 185 packet. In this specification, the client of the RVS is always the 186 responder. However, there might be reasons to allow a client to 187 initiate a base exchange through its own RVS, like NAT and firewall 188 traversal. This specification does not address such scenarios, which 189 should be specified in other documents. 191 3.1. Diagram Notation 193 Notation Significance 194 -------- ------------ 196 I, R I and R are the respective source and destination IP 197 addresses in the IP header. 199 HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the 200 responder's HITs in the packet, respectively. 202 REG_REQ A REG_REQUEST parameter is present in the HIP header. 204 REG_RES A REG_RESPONSE parameter is present in the HIP header. 206 FROM:I A FROM parameter containing the IP address I is 207 present in the HIP header. 209 RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with the 210 appropriate registration key is present in the HIP 211 header. 213 VIA:RVS A VIA_RVS parameter containing the IP address RVS of a 214 rendezvous server is present in the HIP header. 216 3.2. Rendezvous Client Registration 218 Before a rendezvous server starts to relay HIP packets to a 219 rendezvous client, the rendezvous client needs to register with it to 220 receive rendezvous service by using the HIP Registration Extension 221 [I-D.ietf-hip-rfc5203-bis] as illustrated in the following schema: 223 +-----+ +-----+ 224 | | I1 | | 225 | |--------------------------->| | 226 | |<---------------------------| | 227 | I | R1(REG_INFO) | RVS | 228 | | I2(REG_REQ) | | 229 | |--------------------------->| | 230 | |<---------------------------| | 231 | | R2(REG_RES) | | 232 +-----+ +-----+ 234 Rendezvous client registering with a rendezvous server. 236 3.3. Relaying the Base Exchange 238 If a HIP node and one of its rendezvous servers have a rendezvous 239 registration, the rendezvous servers relay inbound I1 packets (that 240 contain one of the client's HITs) by rewriting the IP header. They 241 replace the destination IP address of the I1 packet with one of the 242 IP addresses of the owner of the HIT, i.e., the rendezvous client. 243 They MUST also recompute the IP checksum accordingly. 245 Because of egress filtering on the path from the RVS to the client 246 [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source 247 IP address, i.e., the IP address of I, with one of its own IP 248 addresses. The replacement IP address SHOULD be chosen according to 249 relevant IPv4 and IPv6 specifications [RFC1122][RFC3484]. Because 250 this replacement conceals the initiator's IP address, the RVS MUST 251 append a FROM parameter containing the original source IP address of 252 the packet. This FROM parameter MUST be integrity protected by an 253 RVS_HMAC keyed with the corresponding rendezvous registration 254 integrity key [I-D.ietf-hip-rfc5203-bis]. 256 I1(RVS, R, HIT-I, HIT-R 257 I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) 258 +----------------------->| |--------------------+ 259 | | RVS | | 260 | | | | 261 | +---------+ | 262 | V 263 +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ 264 | |<---------------------------------------------| | 265 | | | | 266 | I | I2(I, R, HIT-I, HIT-R) | R | 267 | |--------------------------------------------->| | 268 | |<---------------------------------------------| | 269 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 271 Rendezvous server rewriting IP addresses. 273 This modification of HIP packets at a rendezvous server can be 274 problematic because the HIP protocol uses integrity checks. Because 275 the I1 does not include HMAC or SIGNATURE parameters, these two end- 276 to-end integrity checks are unaffected by the operation of rendezvous 277 servers. 279 The RVS SHOULD verify the checksum field of an I1 packet before doing 280 any modifications. After modification, it MUST recompute the 281 checksum field using the updated HIP header, which possibly included 282 new FROM and RVS_HMAC parameters, and a pseudo-header containing the 283 updated source and destination IP addresses. This enables the 284 responder to validate the checksum of the I1 packet "as is", without 285 having to parse any FROM parameters. 287 4. Rendezvous Server Extensions 289 This section describes extensions to the HIP Registration Extension 290 [I-D.ietf-hip-rfc5203-bis], allowing a HIP node to register with a 291 rendezvous server for rendezvous service and notify the RVS aware of 292 changes to its current location. It also describes an extension to 293 the HIP specification [I-D.ietf-hip-rfc5201-bis] itself, allowing 294 establishment of HIP associations via one or more HIP rendezvous 295 server(s). 297 4.1. RENDEZVOUS Registration Type 299 This specification defines an additional registration for the HIP 300 Registration Extension [I-D.ietf-hip-rfc5203-bis] that allows 301 registering with a rendezvous server for rendezvous service. 303 Number Registration Type 304 ------ ----------------- 305 1 RENDEZVOUS 307 4.2. Parameter Formats and Processing 309 4.2.1. RVS_HMAC Parameter 311 The RVS_HMAC is a non-critical parameter whose only difference with 312 the HMAC parameter defined in the HIP specification 313 [I-D.ietf-hip-rfc5201-bis] is its "type" code. This change causes it 314 to be located after the FROM parameter (as opposed to the HMAC): 316 Type 65500 317 Length Variable. Length in octets, excluding Type, Length, and 318 Padding. 319 HMAC HMAC computed over the HIP packet, excluding the 320 RVS_HMAC parameter and any following parameters. The 321 HMAC is keyed with the appropriate HIP integrity key 322 (HIP-lg or HIP-gl) established when rendezvous 323 registration happened. The HIP "checksum" field MUST be set 324 to zero, and the HIP header length in the HIP common header 325 MUST be calculated not to cover any excluded parameter 326 when the HMAC is calculated. The size of the 327 HMAC is the natural size of the hash computation 328 output depending on the used hash function. 330 To allow a rendezvous client and its RVS to verify the integrity of 331 packets flowing between them, both SHOULD protect packets with an 332 added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity 333 key established while registration occurred. A valid RVS_HMAC SHOULD 334 be present on every packet flowing between a client and a server and 335 MUST be present when a FROM parameter is processed. 337 4.2.2. FROM Parameter 339 0 1 2 3 340 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Type | Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 | Address | 346 | | 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Type 65498 351 Length 16 352 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. 354 A rendezvous server MUST add a FROM parameter containing the original 355 source IP address of a HIP packet whenever the source IP address in 356 the IP header is rewritten. If one or more FROM parameters are 357 already present, the new FROM parameter MUST be appended after the 358 existing ones. 360 Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC 361 protecting the packet integrity, especially the IP address included 362 in the FROM parameter. 364 4.2.3. VIA_RVS Parameter 366 0 1 2 3 367 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 | Address | 373 | | 374 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 . . . 377 . . . 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | | 380 | Address | 381 | | 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Type 65502 386 Length Variable 387 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. 389 After the responder receives a relayed I1 packet, it can begin to 390 send HIP packets addressed to the initiator's IP address, without 391 further assistance from an RVS. For debugging purposes, it MAY 392 include a subset of the IP addresses of its RVSs in some of these 393 packets. When a responder does so, it MUST append a newly created 394 VIA_RVS parameter at the end of the HIP packet. The main goal of 395 using the VIA_RVS parameter is to allow operators to diagnose 396 possible issues encountered while establishing a HIP association via 397 an RVS. 399 4.3. Modified Packets Processing 401 The following subsections describe the differences of processing of 402 I1 and R1 while a rendezvous server is involved in the base exchange. 404 4.3.1. Processing Outgoing I1 Packets 406 An initiator SHOULD NOT send an opportunistic I1 with a NULL 407 destination HIT to an IP address that is known to be a rendezvous 408 server address, unless it wants to establish a HIP association with 409 the rendezvous server itself and does not know its HIT. 411 When an RVS rewrites the source IP address of an I1 packet due to 412 egress filtering, it MUST add a FROM parameter to the I1 that 413 contains the initiator's source IP address. This FROM parameter MUST 414 be protected by an RVS_HMAC keyed with the integrity key established 415 at rendezvous registration. 417 4.3.2. Processing Incoming I1 Packets 419 When a rendezvous server receives an I1 whose destination HIT is not 420 its own, it consults its registration database to find a registration 421 for the rendezvous service established by the HIT owner. If it finds 422 an appropriate registration, it relays the packet to the registered 423 IP address. If it does not find an appropriate registration, it 424 drops the packet. 426 A rendezvous server SHOULD interpret any incoming opportunistic I1 427 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to 428 itself and SHOULD NOT attempt to relay it to one of its clients. 430 When a rendezvous client receives an I1, it MUST validate any present 431 RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet 432 SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM 433 parameter is present, the packet MUST be dropped. 435 A rendezvous client acting as responder SHOULD drop opportunistic I1s 436 that include a FROM parameter, because this indicates that the I1 has 437 been relayed. 439 4.3.3. Processing Outgoing R1 Packets 441 When a responder replies to an I1 relayed via an RVS, it MUST append 442 to the regular R1 header a VIA_RVS parameter containing the IP 443 addresses of the traversed RVSs. 445 4.3.4. Processing Incoming R1 Packets 447 The HIP specification [I-D.ietf-hip-rfc5201-bis] mandates that a 448 system receiving an R1 MUST first check to see if it has sent an I1 449 to the originator of the R1 (i.e., the system is in state I1-SENT). 450 When the R1 is replying to a relayed I1, this check SHOULD be based 451 on HITs only. In case the IP addresses are also checked, then the 452 source IP address MUST be checked against the IP address included in 453 the VIA_RVS parameter. 455 5. Security Considerations 457 This section discusses the known threats introduced by these HIP 458 extensions and the implications on the overall security of HIP. In 459 particular, it argues that the extensions described in this document 460 do not introduce additional threats to the Host Identity Protocol. 462 It is difficult to encompass the whole scope of threats introduced by 463 rendezvous servers because their presence has implications both at 464 the IP and HIP layers. In particular, these extensions might allow 465 for redirection, amplification, and reflection attacks at the IP 466 layer, as well as attacks on the HIP layer itself, for example, man- 467 in-the-middle attacks against the HIP base exchange. 469 If an initiator has a priori knowledge of the responder's host 470 identity when it first contacts the responder via an RVS, it has a 471 means to verify the signatures in the HIP base exchange, which 472 protects against man-in-the-middle attacks. 474 If an initiator does not have a priori knowledge of the responder's 475 host identity (so-called "opportunistic initiators"), it is almost 476 impossible to defend the HIP exchange against these attacks, because 477 the public keys exchanged cannot be authenticated. The only approach 478 would be to mitigate hijacking threats on HIP state by requiring an 479 R1 answering an opportunistic I1 to come from the same IP address 480 that originally sent the I1. This procedure retains a level of 481 security that is equivalent to what exists in the Internet today. 483 However, for reasons of simplicity, this specification does not allow 484 the establishment of a HIP association via a rendezvous server in an 485 opportunistic manner. 487 6. IANA Considerations 489 This section is to be interpreted according to the Guidelines for 490 Writing an IANA Considerations Section in RFCs [RFC2434]. 492 This document updates the IANA Registry for HIP Parameters Types by 493 assigning new HIP Parameter Types values for the new HIP Parameters 494 defined in Section 4.2: 496 o RVS_HMAC (defined in Section 4.2.1) 498 o FROM (defined in Section 4.2.2) 500 o VIA_RVS (defined in Section 4.2.3) 501 This document defines an additional registration for the HIP 502 Registration Extension [I-D.ietf-hip-rfc5203-bis] that allows 503 registering with a rendezvous server for rendezvous service. 505 Number Registration Type 506 ------ ----------------- 507 1 RENDEZVOUS 509 7. Acknowledgments 511 The following people have provided thoughtful and helpful discussions 512 and/or suggestions that have improved this document: Marcus Brunner, 513 Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino 514 Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin 515 Stiemerling, and Juergen Quittek. 517 8. References 519 8.1. Normative References 521 [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and 522 T. Henderson, "Host Identity Protocol 523 Version 2 (HIPv2)", 524 draft-ietf-hip-rfc5201-bis-05 (work in 525 progress), March 2011. 527 [I-D.ietf-hip-rfc5203-bis] Laganier, J., Koponen, T., and L. Eggert, 528 "Host Identity Protocol (HIP) 529 Registration Extension", 530 draft-ietf-hip-rfc5203-bis-00 (work in 531 progress), August 2010. 533 [I-D.ietf-hip-rfc5205-bis] Laganier, J., "Host Identity Protocol 534 (HIP) Domain Name System (DNS) 535 Extension", draft-ietf-hip-rfc5205-bis-00 536 (work in progress), August 2010. 538 [RFC1122] Braden, R., "Requirements for Internet 539 Hosts - Communication Layers", STD 3, 540 RFC 1122, October 1989. 542 [RFC2119] Bradner, S., "Key words for use in RFCs 543 to Indicate Requirement Levels", BCP 14, 544 RFC 2119, March 1997. 546 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines 547 for Writing an IANA Considerations 548 Section in RFCs", BCP 26, RFC 2434, 549 October 1998. 551 [RFC3484] Draves, R., "Default Address Selection 552 for Internet Protocol version 6 (IPv6)", 553 RFC 3484, February 2003. 555 8.2. Informative References 557 [I-D.ietf-hip-rfc5206-bis] Nikander, P., Henderson, T., Vogt, C., 558 and J. Arkko, "Host Mobility with the 559 Host Identity Protocol", 560 draft-ietf-hip-rfc5206-bis-01 (work in 561 progress), October 2010. 563 [RFC2827] Ferguson, P. and D. Senie, "Network 564 Ingress Filtering: Defeating Denial of 565 Service Attacks which employ IP Source 566 Address Spoofing", BCP 38, RFC 2827, 567 May 2000. 569 [RFC3013] Killalea, T., "Recommended Internet 570 Service Provider Security Services and 571 Procedures", BCP 46, RFC 3013, 572 November 2000. 574 [RFC4423] Moskowitz, R. and P. Nikander, "Host 575 Identity Protocol (HIP) Architecture", 576 RFC 4423, May 2006. 578 Appendix A. Changes from RFC 5204 580 o Updated HIP references to revised HIP specifications. 582 Authors' Addresses 584 Julien Laganier 585 Juniper Networks 586 1094 North Mathilda Avenue 587 Sunnyvale, CA 94089 588 USA 590 Phone: +1 408 936 0385 591 EMail: julien.ietf@gmail.com 592 Lars Eggert 593 Nokia Research Center 594 P.O. Box 407 595 Nokia Group 00045 596 Finland 598 Phone: +358 50 48 24461 599 EMail: lars.eggert@nokia.com 600 URI: http://research.nokia.com/people/lars_eggert/