idnits 2.17.1 draft-ietf-hip-rfc5204-bis-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 17, 2015) is 3052 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 (-11) exists of draft-ietf-hip-rfc5203-bis-09 == Outdated reference: A later version (-10) exists of draft-ietf-hip-rfc5205-bis-08 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-20) exists of draft-ietf-hip-rfc4423-bis-13 == Outdated reference: A later version (-14) exists of draft-ietf-hip-rfc5206-bis-09 -- Obsolete informational reference (is this intentional?): RFC 5204 (Obsoleted by RFC 8004) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft Luminate Wireless, Inc. 4 Obsoletes: 5204 (if approved) L. Eggert 5 Intended status: Standards Track NetApp 6 Expires: June 19, 2016 December 17, 2015 8 Host Identity Protocol (HIP) Rendezvous Extension 9 draft-ietf-hip-rfc5204-bis-07 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. This 18 document obsoletes RFC5204. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 19, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 3 57 3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Rendezvous Client Registration . . . . . . . . . . . . . 5 59 3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . 6 60 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . 7 61 4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . 7 62 4.2. Parameter Formats and Processing . . . . . . . . . . . . 7 63 4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . 7 64 4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . 8 65 4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 8 66 4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9 67 4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . 9 68 4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . 10 69 4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . 10 70 4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . 10 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 8.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Appendix A. Changes from RFC 5204 . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 The Host Identity Protocol (HIP) Architecture 83 [I-D.ietf-hip-rfc4423-bis] introduces the rendezvous mechanism to 84 help a HIP node to contact a frequently moving HIP node. The 85 rendezvous mechanism involves a third party, the rendezvous server 86 (RVS), which serves as an initial contact point ("rendezvous point") 87 for its clients. The clients of an RVS are HIP nodes that use the 88 HIP Registration Extension [I-D.ietf-hip-rfc5203-bis] to register 89 their HIT->IP address mappings with the RVS. After this 90 registration, other HIP nodes can initiate a base exchange using the 91 IP address of the RVS instead of the current IP address of the node 92 they attempt to contact. Essentially, the clients of an RVS become 93 reachable at the RVS's IP address. Peers can initiate a HIP base 94 exchange with the IP address of the RVS, which will relay this 95 initial communication such that the base exchange may successfully 96 complete. 98 2. Terminology 100 This section defines terms used throughout the remainder of this 101 specification. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 In addition to the terminology defined in the HIP specification 108 [RFC7401] and the HIP Registration Extension 109 [I-D.ietf-hip-rfc5203-bis], this document defines and uses the 110 following terms: 112 Rendezvous Service 113 A HIP service provided by a rendezvous server to its rendezvous 114 clients. The rendezvous server offers to relay some of the 115 arriving base exchange packets between the initiator and 116 responder. 118 Rendezvous Server (RVS) 119 A HIP registrar providing rendezvous service. 121 Rendezvous Client 122 A HIP requester that has registered for rendezvous service at a 123 rendezvous server. 125 Rendezvous Registration 126 A HIP registration for rendezvous service, established between a 127 rendezvous server and a rendezvous client. 129 3. Overview of Rendezvous Server Operation 131 Figure 1 shows a simple HIP base exchange without a rendezvous 132 server, in which the initiator initiates the exchange directly with 133 the responder by sending an I1 packet to the responder's IP address, 134 as per the HIP specification [RFC7401]. 136 +-----+ +-----+ 137 | |-------I1------>| | 138 | I |<------R1-------| R | 139 | |-------I2------>| | 140 | |<------R2-------| | 141 +-----+ +-----+ 143 Figure 1: HIP base exchange without rendezvous server. 145 The End-Host Mobility and Multihoming with the Host Identity Protocol 146 specification [I-D.ietf-hip-rfc5206-bis] allows a HIP node to notify 147 its peers about changes in its set of IP addresses. This 148 specification presumes initial reachability of the two nodes with 149 respect to each other. 151 However, such a HIP node MAY also want to be reachable to other 152 future correspondent peers that are unaware of its location change. 153 The HIP Architecture [I-D.ietf-hip-rfc4423-bis] introduces rendezvous 154 servers with whom a HIP node MAY register its host identity tags 155 (HITs) and current IP addresses. An RVS relays HIP packets arriving 156 for these HITs to the node's registered IP addresses. When a HIP 157 node has registered with an RVS, it SHOULD record the IP address of 158 its RVS in its DNS record, using the HIP DNS resource record type 159 defined in the HIP DNS Extension [I-D.ietf-hip-rfc5205-bis]. 161 +-----+ 162 +--I1--->| RVS |---I1--+ 163 | +-----+ | 164 | v 165 +-----+ +-----+ 166 | |<------R1-------| | 167 | I |-------I2------>| R | 168 | |<------R2-------| | 169 +-----+ +-----+ 171 Figure 2: HIP base exchange with a rendezvous server. 173 Figure 2 shows a HIP base exchange involving a rendezvous server. It 174 is assumed that HIP node R previously registered its HITs and current 175 IP addresses with the RVS, using the HIP Registration Extension 176 [I-D.ietf-hip-rfc5203-bis]. When the initiator I tries to establish 177 contact with the responder R, it must send the I1 of the base 178 exchange either to one of R's IP addresses (if known via DNS or other 179 means) or to one of R's rendezvous servers. Here, I obtains the IP 180 address of R's rendezvous server from R's DNS record and then sends 181 the I1 packet of the HIP base exchange to RVS. RVS, noticing that 182 the HIT contained in the arriving I1 packet is not one of its own, 183 MUST check its current registrations to determine if it needs to 184 relay the packets. Here, it determines that the HIT belongs to R and 185 then relays the I1 packet to the registered IP address. R then 186 completes the base exchange without further assistance from RVS by 187 sending an R1 directly to the I's IP address, as obtained from the I1 188 packet. In this specification, the client of the RVS is always the 189 responder. However, there might be reasons to allow a client to 190 initiate a base exchange through its own RVS, like NAT and firewall 191 traversal. This specification does not address such scenarios, which 192 should be specified in other documents. 194 3.1. Diagram Notation 196 Notation Significance 197 -------- ------------ 199 I, R I and R are the respective source and destination IP 200 addresses in the IP header. 202 HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the 203 responder's HITs in the packet, respectively. 205 REG_REQ A REG_REQUEST parameter is present in the HIP header. 207 REG_RES A REG_RESPONSE parameter is present in the HIP header. 209 FROM:I A FROM parameter containing the IP address I is 210 present in the HIP header. 212 RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with 213 the appropriate registration key is present in the HIP 214 header. 216 VIA:RVS A VIA_RVS parameter containing the IP address RVS of 217 a rendezvous server is present in the HIP header. 219 3.2. Rendezvous Client Registration 221 Before a rendezvous server starts to relay HIP packets to a 222 rendezvous client, the rendezvous client needs to register with it to 223 receive rendezvous service by using the HIP Registration Extension 224 [I-D.ietf-hip-rfc5203-bis] as illustrated in the following schema: 226 +-----+ +-----+ 227 | | I1 | | 228 | |--------------------------->| | 229 | |<---------------------------| | 230 | I | R1(REG_INFO) | RVS | 231 | | I2(REG_REQ) | | 232 | |--------------------------->| | 233 | |<---------------------------| | 234 | | R2(REG_RES) | | 235 +-----+ +-----+ 237 Rendezvous client registering with a rendezvous server. 239 3.3. Relaying the Base Exchange 241 If a HIP node and one of its rendezvous servers have a rendezvous 242 registration, the rendezvous servers relay inbound I1 packets (that 243 contain one of the client's HITs) by rewriting the IP header. They 244 replace the destination IP address of the I1 packet with one of the 245 IP addresses of the owner of the HIT, i.e., the rendezvous client. 246 They MUST also recompute the IP checksum accordingly. 248 Because of egress filtering on the path from the RVS to the client 249 [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source 250 IP address, i.e., the IP address of I, with one of its own IP 251 addresses. The replacement IP address SHOULD be chosen according to 252 relevant IPv4 and IPv6 specifications [RFC1122][RFC6724]. Because 253 this replacement conceals the initiator's IP address, the RVS MUST 254 append a FROM parameter containing the original source IP address of 255 the packet. This FROM parameter MUST be integrity protected by an 256 RVS_HMAC keyed with the corresponding rendezvous registration 257 integrity key [I-D.ietf-hip-rfc5203-bis]. 259 I1(RVS, R, HIT-I, HIT-R 260 I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) 261 +----------------------->| |--------------------+ 262 | | RVS | | 263 | | | | 264 | +---------+ | 265 | V 266 +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ 267 | |<---------------------------------------------| | 268 | | | | 269 | I | I2(I, R, HIT-I, HIT-R) | R | 270 | |--------------------------------------------->| | 271 | |<---------------------------------------------| | 272 +-----+ R2(R, I, HIT-R, HIT-I) +-----+ 274 Rendezvous server rewriting IP addresses. 276 This modification of HIP packets at a rendezvous server can be 277 problematic because the HIP protocol uses integrity checks. Because 278 the I1 does not include HMAC or SIGNATURE parameters, these two end- 279 to-end integrity checks are unaffected by the operation of rendezvous 280 servers. 282 The RVS SHOULD verify the checksum field of an I1 packet before doing 283 any modifications. After modification, it MUST recompute the 284 checksum field using the updated HIP header, which possibly included 285 new FROM and RVS_HMAC parameters, and a pseudo-header containing the 286 updated source and destination IP addresses. This enables the 287 responder to validate the checksum of the I1 packet "as is", without 288 having to parse any FROM parameters. 290 4. Rendezvous Server Extensions 292 This section describes extensions to the HIP Registration Extension 293 [I-D.ietf-hip-rfc5203-bis], allowing a HIP node to register with a 294 rendezvous server for rendezvous service and notify the RVS aware of 295 changes to its current location. It also describes an extension to 296 the HIP specification [RFC7401] itself, allowing establishment of HIP 297 associations via one or more HIP rendezvous server(s). 299 4.1. RENDEZVOUS Registration Type 301 This specification defines an additional registration for the HIP 302 Registration Extension [I-D.ietf-hip-rfc5203-bis] that allows 303 registering with a rendezvous server for rendezvous service. 305 Number Registration Type 306 ------ ----------------- 307 1 RENDEZVOUS 309 4.2. Parameter Formats and Processing 311 4.2.1. RVS_HMAC Parameter 313 The RVS_HMAC is a non-critical parameter whose only difference with 314 the HMAC parameter defined in the HIP specification [RFC7401] is its 315 "type" code. This change causes it to be located after the FROM 316 parameter (as opposed to the HMAC): 318 Type 65500 319 Length Variable. Length in octets, excluding Type, Length, and 320 Padding. 321 HMAC HMAC computed over the HIP packet, excluding the 322 RVS_HMAC parameter and any following parameters. The 323 HMAC is keyed with the appropriate HIP integrity key 324 (HIP-lg or HIP-gl) established when rendezvous 325 registration happened. The HIP "checksum" field MUST be 326 set to zero, and the HIP header length in the HIP common 327 header MUST be calculated not to cover any excluded 328 parameter when the HMAC is calculated. The size of the 329 HMAC is the natural size of the hash computation 330 output depending on the used hash function. 332 To allow a rendezvous client and its RVS to verify the integrity of 333 packets flowing between them, both SHOULD protect packets with an 334 added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity 335 key established while registration occurred. A valid RVS_HMAC SHOULD 336 be present on every packet flowing between a client and a server and 337 MUST be present when a FROM parameter is processed. 339 4.2.2. FROM Parameter 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Type | Length | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | | 347 | Address | 348 | | 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Type 65498 353 Length 16 354 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. 356 A rendezvous server MUST add a FROM parameter containing the original 357 source IP address of a HIP packet whenever the source IP address in 358 the IP header is rewritten. If one or more FROM parameters are 359 already present, the new FROM parameter MUST be appended after the 360 existing ones. 362 Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC 363 protecting the packet integrity, especially the IP address included 364 in the FROM parameter. 366 4.2.3. VIA_RVS Parameter 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Type | Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | | 373 | Address | 374 | | 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 . . . 378 . . . 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 | Address | 382 | | 383 | | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Type 65502 387 Length Variable 388 Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. 390 After the responder receives a relayed I1 packet, it can begin to 391 send HIP packets addressed to the initiator's IP address, without 392 further assistance from an RVS. For debugging purposes, it MUST 393 append a newly created VIA_RVS parameter at the end of the R1 packet 394 that contains the IP address of the RVS that relayed the I1 packet. 395 Including more than one IP address in the VIA_RVS parameter is 396 outside the scope of this specification. The main goal of using the 397 VIA_RVS parameter is to allow operators to diagnose possible issues 398 encountered while establishing a HIP association via an RVS. 400 4.3. Modified Packets Processing 402 The following subsections describe the differences of processing of 403 I1 and R1 while a rendezvous server is involved in the base exchange. 405 4.3.1. Processing Outgoing I1 Packets 407 An initiator SHOULD NOT send an opportunistic I1 with a NULL 408 destination HIT to an IP address that is known to be a rendezvous 409 server address, unless it wants to establish a HIP association with 410 the rendezvous server itself and does not know its HIT. 412 When an RVS rewrites the source IP address of an I1 packet due to 413 egress filtering, it MUST add a FROM parameter to the I1 that 414 contains the initiator's source IP address. This FROM parameter MUST 415 be protected by an RVS_HMAC keyed with the integrity key established 416 at rendezvous registration. 418 4.3.2. Processing Incoming I1 Packets 420 When a rendezvous server receives an I1 whose destination HIT is not 421 its own, it consults its registration database to find a registration 422 for the rendezvous service established by the HIT owner. If it finds 423 an appropriate registration, it relays the packet to the registered 424 IP address. If it does not find an appropriate registration, it 425 drops the packet. 427 A rendezvous server SHOULD interpret any incoming opportunistic I1 428 (i.e., an I1 with a NULL destination HIT) as an I1 addressed to 429 itself and SHOULD NOT attempt to relay it to one of its clients. 431 When a rendezvous client receives an I1, it MUST validate any present 432 RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet 433 SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM 434 parameter is present, the packet MUST be dropped. 436 A rendezvous client acting as responder SHOULD drop opportunistic I1s 437 that include a FROM parameter, because this indicates that the I1 has 438 been relayed. 440 4.3.3. Processing Outgoing R1 Packets 442 When a responder replies to an I1 relayed via an RVS, it MUST append 443 to the regular R1 header a VIA_RVS parameter containing the IP 444 addresses of the traversed RVSs. 446 4.3.4. Processing Incoming R1 Packets 448 The HIP specification [RFC7401] mandates that a system receiving an 449 R1 MUST first check to see if it has sent an I1 to the originator of 450 the R1 (i.e., the system is in state I1-SENT). When the R1 is 451 replying to a relayed I1, this check SHOULD be based on HITs only. 452 In case the IP addresses are also checked, then the source IP address 453 MUST be checked against the IP address included in the VIA_RVS 454 parameter. 456 5. Security Considerations 458 This section discusses the known threats introduced by these HIP 459 extensions and the implications on the overall security of HIP. In 460 particular, it argues that the extensions described in this document 461 do not introduce additional threats to the Host Identity Protocol. 463 It is difficult to encompass the whole scope of threats introduced by 464 rendezvous servers because their presence has implications both at 465 the IP and HIP layers. In particular, these extensions might allow 466 for redirection, amplification, and reflection attacks at the IP 467 layer, as well as attacks on the HIP layer itself, for example, man- 468 in-the-middle attacks against the HIP base exchange. 470 If an initiator has a priori knowledge of the responder's host 471 identity when it first contacts the responder via an RVS, it has a 472 means to verify the signatures in the HIP base exchange, which 473 protects against man-in-the-middle attacks. 475 If an initiator does not have a priori knowledge of the responder's 476 host identity (so-called "opportunistic initiators"), it is almost 477 impossible to defend the HIP exchange against these attacks, because 478 the public keys exchanged cannot be authenticated. The only approach 479 would be to mitigate hijacking threats on HIP state by requiring an 480 R1 answering an opportunistic I1 to come from the same IP address 481 that originally sent the I1. This procedure retains a level of 482 security that is equivalent to what exists in the Internet today. 484 However, for reasons of simplicity, this specification does not allow 485 the establishment of a HIP association via a rendezvous server in an 486 opportunistic manner. 488 6. IANA Considerations 490 This section is to be interpreted according to the Guidelines for 491 Writing an IANA Considerations Section in RFCs [RFC5226]. 493 This document updates the IANA Registry for HIP Parameters Types by 494 replacing references to [RFC5204] by references to this document. 496 7. Acknowledgments 498 The following people have provided thoughtful and helpful discussions 499 and/or suggestions that have improved this document: Marcus Brunner, 500 Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino 501 Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin 502 Stiemerling, and Juergen Quittek. 504 Lars Eggert has received funding from the European Union's Horizon 505 2020 research and innovation program 2014-2018 under grant agreement 506 No. 644866. This document reflects only the authors' views and the 507 European Commission is not responsible for any use that may be made 508 of the information it contains. 510 Thanks to Joel M. Halpern for performing the Gen-ART review of this 511 document as part of the publication process. 513 8. References 515 8.1. Normative References 517 [I-D.ietf-hip-rfc5203-bis] 518 Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 519 Registration Extension", draft-ietf-hip-rfc5203-bis-09 520 (work in progress), June 2015. 522 [I-D.ietf-hip-rfc5205-bis] 523 Laganier, J., "Host Identity Protocol (HIP) Domain Name 524 System (DNS) Extension", draft-ietf-hip-rfc5205-bis-08 525 (work in progress), December 2015. 527 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 528 Communication Layers", STD 3, RFC 1122, 529 DOI 10.17487/RFC1122, October 1989, 530 . 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, 534 DOI 10.17487/RFC2119, March 1997, 535 . 537 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 538 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 539 DOI 10.17487/RFC5226, May 2008, 540 . 542 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 543 "Default Address Selection for Internet Protocol Version 6 544 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 545 . 547 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 548 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 549 RFC 7401, DOI 10.17487/RFC7401, April 2015, 550 . 552 8.2. Informative References 554 [I-D.ietf-hip-rfc4423-bis] 555 Moskowitz, R. and M. Komu, "Host Identity Protocol 556 Architecture", draft-ietf-hip-rfc4423-bis-13 (work in 557 progress), December 2015. 559 [I-D.ietf-hip-rfc5206-bis] 560 Henderson, T., Vogt, C., and J. Arkko, "Host Mobility with 561 the Host Identity Protocol", draft-ietf-hip-rfc5206-bis-09 562 (work in progress), July 2015. 564 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 565 Defeating Denial of Service Attacks which employ IP Source 566 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 567 May 2000, . 569 [RFC3013] Killalea, T., "Recommended Internet Service Provider 570 Security Services and Procedures", BCP 46, RFC 3013, 571 DOI 10.17487/RFC3013, November 2000, 572 . 574 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 575 Rendezvous Extension", RFC 5204, DOI 10.17487/RFC5204, 576 April 2008, . 578 Appendix A. Changes from RFC 5204 580 o Updated HIP references to revised HIP specifications. 582 Authors' Addresses 584 Julien Laganier 585 Luminate Wireless, Inc. 586 Cupertino, CA 587 USA 589 EMail: julien.ietf@gmail.com 591 Lars Eggert 592 NetApp 593 Sonnenallee 1 594 Kirchheim 85551 595 Germany 597 Phone: +49 151 12055791 598 EMail: lars@netapp.com 599 URI: http://eggert.org