idnits 2.17.1 draft-ietf-hip-rfc4843-bis-03.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 abstract seems to contain references ([RFC4843]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC4843, but the abstract doesn't seem to directly say this. It does mention RFC4843 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2012) is 4207 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-09 -- Obsolete informational reference (is this intentional?): RFC 4773 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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: 4843 (if approved) F. Dupont 5 Intended status: Standards Track Internet Systems Consortium 6 Expires: March 24, 2013 September 20, 2012 8 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers 9 Version 2 (ORCHIDv2) 10 draft-ietf-hip-rfc4843-bis-03 12 Abstract 14 This document specifies an updated Overlay Routable Cryptographich 15 Hash Identifiers format that obsoletes the earlier format defined in 16 [RFC4843]. These identifiers are intended to be used as endpoint 17 identifiers at applications and Application Programming Interfaces 18 (API) and not as identifiers for network location at the IP layer, 19 i.e., locators. They are designed to appear as application layer 20 entities and at the existing IPv6 APIs, but they should not appear in 21 actual IPv6 headers. To make them more like vanilla IPv6 addresses, 22 they are expected to be routable at an overlay level. Consequently, 23 while they are considered non-routable addresses from the IPv6 layer 24 point-of-view, all existing IPv6 applications are expected to be able 25 to use them in a manner compatible with current IPv6 addresses. 27 The Overlay Routable Cryptographic Hash Identifiers originally 28 defined in [RFC4843] lacked a mechanism for cryptographic algorithm 29 agility. The updated ORCHID format specified in this document 30 removes this limitation by encoding in the identifier itself an index 31 to the suite of cryptographic algorithms in use. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 24, 2013. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . . 3 69 1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4 70 1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5 71 1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5 72 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5 74 3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7 75 3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 7 76 4. Collision Considerations . . . . . . . . . . . . . . . . . . . 8 77 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative references . . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative references . . . . . . . . . . . . . . . . . . 12 85 Appendix A. Changes from RFC 4843 . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 This document introduces Overlay Routable Cryptographic Hash 90 Identifiers (ORCHID), a new class of IP address-like identifiers. 91 These identifiers are intended to be globally unique in a statistical 92 sense (see Section 4), non-routable at the IP layer, and routable at 93 some overlay layer. The identifiers are securely bound, via a secure 94 hash function, to the concatenation of an input bitstring and a 95 context tag. Typically, but not necessarily, the input bitstring 96 will include a suitably encoded public cryptographic key. 98 1.1. Rationale and Intent 100 These identifiers are expected to be used at the existing IPv6 101 Application Programming Interfaces (API) and application protocols 102 between consenting hosts. They may be defined and used in different 103 contexts, suitable for different overlay protocols. Examples of 104 these include Host Identity Tags (HIT) in the Host Identity Protocol 105 (HIP) [I-D.ietf-hip-rfc5201-bis] and Temporary Mobile Identifiers 106 (TMI) for Mobile IPv6 Privacy Extension [PRIVACYTEXT]. 108 As these identifiers are expected to be used along with IPv6 109 addresses at both applications and APIs, co-ordination is desired to 110 make sure that an ORCHID is not inappropriately taken for a vanilla 111 IPv6 address and vice versa. In practice, allocation of a separate 112 prefix for ORCHIDs seems to suffice, making them compatible with IPv6 113 addresses at the upper layers while simultaneously making it trivial 114 to prevent their usage at the IP layer. 116 While being technically possible to use ORCHIDs between consenting 117 hosts without any co-ordination with the IETF and the IANA, the 118 authors would consider such practice potentially dangerous. A 119 specific danger would be realised if the IETF community later decided 120 to use the ORCHID prefix for some different purpose. In that case, 121 hosts using the ORCHID prefix would be, for practical purposes, 122 unable to use the prefix for the other new purpose. That would lead 123 to partial balkanisation of the Internet, similar to what has 124 happened as a result of historical hijackings of non-RFC 1918 125 [RFC1918] IPv4 addresses for private use. 127 The whole need for the proposed allocation grows from the desire to 128 be able to use ORCHIDs with existing applications and APIs. This 129 desire leads to the potential conflict, mentioned above. Resolving 130 the conflict requires the proposed allocation. 132 One can argue that the desire to use these kinds of identifiers via 133 existing APIs is architecturally wrong, and there is some truth in 134 that argument. Indeed, it would be more desirable to introduce a new 135 API and update all applications to use identifiers, rather than 136 locators, via that new API. That is exactly what we expect to happen 137 in the long run. 139 However, given the current state of the Internet, we do not consider 140 it viable to introduce any changes that, at once, require 141 applications to be rewritten and host stacks to be updated. Rather 142 than that, we believe in piece-wise architectural changes that 143 require only one of the existing assets to be touched. ORCHIDs are 144 designed to address this situation: to allow people to experiment 145 with protocol stack extensions, such as secure overlay routing, HIP, 146 or Mobile IP privacy extensions, without requiring them to update 147 their applications. The goal is to facilitate large-scale 148 experiments with minimum user effort. 150 For example, there already exists, at the time of this writing, HIP 151 implementations that run fully in user space, using the operating 152 system to divert a certain part of the IPv6 address space to a user 153 level daemon for HIP processing. In practical terms, these 154 implementations are already using a certain IPv6 prefix for 155 differentiating HIP identifiers from IPv6 addresses, allowing them 156 both to be used by the existing applications via the existing APIs. 158 The Overlay Routable Cryptographic Hash Identifiers originally 159 defined in [RFC4843] lacked a mechanism for cryptographic algorithm 160 agility. The updated ORCHID format specified in this document 161 removes this limitation by encoding in the identifier itself an index 162 to the suite of cryptographic algorithms in use. 164 Because the updated ORCHIDv2 format is not backward compatible with 165 the earlier one, IANA is requested to allocate a new 28-bit prefix 166 out of the IANA IPv6 Special Purpose Address Block, namely 2001: 167 0000::/23, as per [RFC4773]. The prefix that was temporarily 168 allocated for the experimental ORCHID is to be returned to IANA in 169 2014 [RFC4843]. 171 1.2. ORCHID Properties 173 ORCHIDs are designed to have the following properties: 175 o Statistical uniqueness; also see Section 4 177 o Secure binding to the input parameters used in their generation 178 (i.e., the context identifier and a bitstring). 180 o Aggregation under a single IPv6 prefix. Note that this is only 181 needed due to the co-ordination need as indicated above. Without 182 such co-ordination need, the ORCHID namespace could potentially be 183 completely flat. 185 o Non-routability at the IP layer, by design. 187 o Routability at some overlay layer, making them, from an 188 application point of view, semantically similar to IPv6 addresses. 190 As mentioned above, ORCHIDs are intended to be generated and used in 191 different contexts, as suitable for different mechanisms and 192 protocols. The context identifier is meant to be used to 193 differentiate between the different contexts; see Section 4 for a 194 discussion of the related API and kernel level implementation issues, 195 and Section 5 for the design choices explaining why the context 196 identifiers are used. 198 1.3. Expected use of ORCHIDs 200 Examples of identifiers and protocols that are expected to adopt the 201 ORCHID format include Host Identity Tags (HIT) in the Host Identity 202 Protocol [I-D.ietf-hip-rfc5201-bis] and the Temporary Mobile 203 Identifiers (TMI) in the Simple Privacy Extension for Mobile IPv6 204 [PRIVACYTEXT]. The format is designed to be extensible to allow 205 other experimental proposals to share the same namespace. 207 1.4. Action Plan 209 This document requests IANA to allocate a prefix out of the IPv6 210 addressing space for Overlay Routable Cryptographic Hash Identifiers. 212 1.5. Terminology 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 2. Cryptographic Hash Identifier Construction 220 An ORCHID is generated using the ORCHID Generation Algorithm (OGA) 221 below. The algorithm takes a bitstring and a context identifier as 222 input and produces an ORCHID as output. The hash function used in 223 the ORCHID Generation Algorithm is defined for each OGA identifier by 224 the specification for the respective usage context (e.g., HIPv2). 226 Input := any bitstring 227 OGA ID := 4-bits Orchid Generation Algorithm identifier 228 Hash Input := Context ID | Input 229 Hash := Hash_function( Hash Input ) 230 ORCHID := Prefix | Encode_96( Hash ) 232 where: 234 | : Denotes concatenation of bitstrings 236 Input : A bitstring that is unique or statistically unique 237 within a given context. The bitstring is intended 238 to be associated with the to-be-created ORCHID in 239 the given context. 241 Context ID : A randomly generated value defining the expected 242 usage context for the particular ORCHID and the 243 hash function to be used for generation of ORCHIDs 244 in this context. These values are allocated out of 245 the namespace introduced for CGA Type Tags; see RFC 246 3972 and 247 http://www.iana.org/assignments/cga-message-types. 249 OGA ID : A 4-bit long identifier for the Hash_function 250 in use within the specific usage context. 252 Hash_function : The one-way hash function (i.e., hash function 253 with pre-image resistance and second pre-image 254 resistance) to be used as identified by the 255 value for the OGA ID according document 256 defining the context usage identified by the 257 Context ID. For example, the version 2 of the 258 HIP specification defines SHA1 [RFC3174] as 259 the hash function to be used to generate 260 ORCHIDv2 used in the HIPv2 protocol when the 261 OGA ID is 3 [I-D.ietf-hip-rfc5201-bis]. 263 Encode_96( ) : An extraction function in which output is obtained 264 by extracting the middle 96-bit-long bitstring 265 from the argument bitstring. 267 Prefix : A constant 28-bit-long bitstring value 268 (IANA TBD 2001:11::/28 ?). 270 To form an ORCHID, two pieces of input data are needed. The first 271 piece can be any bitstring, but is typically expected to contain a 272 public cryptographic key and some other data. The second piece is a 273 context identifier, which is a 128-bit-long datum, allocated as 274 specified in Section 7. Each specific experiment (such as HIP HITs 275 or MIP6 TMIs) is expected to allocate their own, specific context 276 identifier. 278 The input bitstring and context identifier are concatenated to form 279 an input datum, which is then fed to the cryptographic hash function 280 to be used for the value of the OGA identifier according to the 281 document defining the context usage identified by the Context ID. 282 The result of the hash function is processed by an encoding function, 283 resulting in a 96-bit-long value. This value is prepended with the 284 concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID. The 285 result is the ORCHID, a 128-bit-long bitstring that can be used at 286 the IPv6 APIs in hosts participating to the particular experiment. 288 The ORCHID prefix is allocated under the IPv6 global unicast address 289 block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast 290 addresses. However, it should be noted that ORCHIDs do not conform 291 with the IPv6 global unicast address format defined in Section 2.5.4 292 of [RFC4291] since they do not have a 64-bit Interface ID formatted 293 as described in Section 2.5.1. of [RFC4291]. 295 3. Routing Considerations 297 ORCHIDs are designed to serve as location independent endpoint- 298 identifiers rather than IP-layer locators. Therefore, routers MAY be 299 configured not to forward any packets containing an ORCHID as a 300 source or a destination address. If the destination address is an 301 ORCHID but the source address is a valid unicast source address, 302 routers MAY be configured to generate an ICMP Destination 303 Unreachable, Administratively Prohibited message. 305 Due to the experimental nature of ORCHIDs, router software MUST NOT 306 include any special handling code for ORCHIDs. In other words, the 307 non-routability property of ORCHIDs, if implemented, MUST be 308 implemented via configuration and NOT by hardwired software code. At 309 this time, it is RECOMMENDED that the default router configuration 310 not handle ORCHIDs in any special way. In other words, there is no 311 need to touch existing or new routers due to this experiment. If 312 such a reason should later appear, for example, due to a faulty 313 implementation leaking ORCHIDs to the IP layer, the prefix can be and 314 should be blocked by a simple configuration rule. 316 3.1. Overlay Routing 318 As mentioned multiple times, ORCHIDs are designed to be non-routable 319 at the IP layer. However, there are multiple ongoing research 320 efforts for creating various overlay routing and resolution 321 mechanisms for flat identifiers. For example, the Host Identity 322 Indirection Infrastructure (Hi3) [Hi3] and Node Identity 323 Internetworking Architecture (NodeID) [NodeID] proposals, outline 324 ways for using a Distributed Hash Table to forward HIP packets based 325 on the Host Identity Tag. 327 What is common to the various research proposals is that they create 328 a new kind of resolution or routing infrastructure on top of the 329 existing Internet routing structure. In practical terms, they allow 330 delivery of packets based on flat, non-routable identifiers, 331 utilising information stored in a distributed database. Usually, the 332 database used is based on Distributed Hash Tables. This effectively 333 creates a new routing network on top of the existing IP-based routing 334 network, capable of routing packets that are not addressed by IP 335 addresses but some other kind of identifiers. 337 Typical benefits from overlay routing include location independence, 338 more scalable multicast, anycast, and multihoming support than in IP, 339 and better DoS resistance than in the vanilla Internet. The main 340 drawback is typically an order of magnitude of slower performance, 341 caused by an easily largish number of extra look-up or forwarding 342 steps needed. Consequently, in most practical cases, the overlay 343 routing system is used only during initial protocol state set-up (cf. 344 TCP handshake), after which the communicating endpoints exchange 345 packets directly with IP, bypassing the overlay network. 347 The net result of the typical overlay routing approaches is a 348 communication service whose basic functionality is comparable to that 349 provided by classical IP but provides considerably better resilience 350 that vanilla IP in dynamic networking environments. Some experiments 351 also introduce additional functionality, such as enhanced security or 352 ability to effectively route through several IP addressing domains. 354 The authors expect ORCHIDs to become fully routable, via one or more 355 overlay systems, before the end of the experiment. 357 4. Collision Considerations 359 As noted above, the aim is that ORCHIDs are globally unique in a 360 statistical sense. That is, given the ORCHID referring to a given 361 entity, the probability of the same ORCHID being used to refer to 362 another entity elsewhere in the Internet must be sufficiently low so 363 that it can be ignored for most practical purposes. We believe that 364 the presented design meets this goal; see Section 5. 366 Consider next the very rare case that some ORCHID happens to refer to 367 two different entities at the same time, at two different locations 368 in the Internet. Even in this case, the probability of this fact 369 becoming visible (and therefore a matter of consideration) at any 370 single location in the Internet is negligible. For the vast majority 371 of cases, the two simultaneous uses of the ORCHID will never cross 372 each other. However, while rare, such collisions are still possible. 373 This section gives reasonable guidelines on how to mitigate the 374 consequences in the case that such a collision happens. 376 As mentioned above, ORCHIDs are expected to be used at the legacy 377 IPv6 APIs between consenting hosts. The context ID is intended to 378 differentiate between the various experiments, or contexts, sharing 379 the ORCHID namespace. However, the context ID is not present in the 380 ORCHID itself, but only in front of the input bitstring as an input 381 to the hash function. While this may lead to certain implementation- 382 related complications, we believe that the trade-off of allowing the 383 hash result part of an ORCHID being longer more than pays off the 384 cost. 386 Because ORCHIDs are not routable at the IP layer, in order to send 387 packets using ORCHIDs at the API level, the sending host must have 388 additional overlay state within the stack to determine which 389 parameters (e.g., what locators) to use in the outgoing packet. An 390 underlying assumption here, and a matter of fact in the proposals 391 that the authors are aware of, is that there is an overlay protocol 392 for setting up and maintaining this additional state. It is assumed 393 that the state-set-up protocol carries the input bitstring, and that 394 the resulting ORCHID-related state in the stack can be associated 395 back with the appropriate context and state-set-up protocol. 397 Even though ORCHID collisions are expected to be extremely rare, two 398 kinds of collisions may still happen. First, it is possible that two 399 different input bitstrings within the same context may map to the 400 same ORCHID. In this case, the state-set-up mechanism is expected to 401 resolve the conflict, for example, by indicating to the peer that the 402 ORCHID in question is already in use. 404 A second type of collision may happen if two input bitstrings, used 405 in different usage contexts, map to the same ORCHID. In this case, 406 the main confusion is about which context to use. In order to 407 prevent these types of collisions, it is RECOMMENDED that 408 implementations that simultaneously support multiple different 409 contexts maintain a node-wide unified database of known ORCHIDs, and 410 indicate a conflict if any of the mechanisms attempt to register an 411 ORCHID that is already in use. For example, if a given ORCHID is 412 already being used as a HIT in HIP, it cannot simultaneously be used 413 as a TMI in Mobile IP. Instead, if Mobile IP attempts to use the 414 ORCHID, it will be notified (by the kernel) that the ORCHID in 415 question is already in use. 417 5. Design Choices 419 The design of this namespace faces two competing forces: 421 o As many bits as possible should be preserved for the hash result. 423 o It should be possible to share the namespace between multiple 424 mechanisms. 426 The desire to have a long hash result requires that the prefix be as 427 short as possible, and use few (if any) bits for additional encoding. 428 The present design takes this desire to the maximum: all the bits 429 beyond the prefix and the ORCHID generation algorithm identifier are 430 used as hash output. This leaves no bits in the ORCHID itself 431 available for identifying the context, however the 4 bits used to 432 encode the ORCHID generation algorithm identifier provides 433 cryptographich agility with respect to the hash function in use for a 434 given context; see Section 6. 436 The desire to allow multiple mechanisms to share the namespace has 437 been resolved by including the context identifier in the hash- 438 function input. While this does not allow the mechanism to be 439 directly inferred from a ORCHID, it allows one to verify that a given 440 input bitstring and ORCHID belong to a given context, with high- 441 probability; but also see Section 6. 443 6. Security Considerations 445 ORCHIDs are designed to be securely bound to the Context ID and the 446 bitstring used as the input parameters during their generation. To 447 provide this property, the ORCHID generation algorithm relies on the 448 second-preimage resistance (a.k.a. one-way) property of the hash 449 function used in the generation [RFC4270]. To have this property and 450 to avoid collisions, it is important that the allocated prefix is as 451 short as possible, leaving as many bits as possible for the hash 452 output. 454 For a given Context ID, all mechanisms using ORCHIDs MUST use exactly 455 the same mechanism for generating an ORCHID from the input bitstring. 456 Allowing different mechanisms, without explicitly encoding the 457 mechanism in the Context ID or the ORCHID itself, would allow so- 458 called bidding-down attacks. That is, if multiple different hash 459 functions were allowed to construct ORCHIDs valid for the same 460 Context ID, and if one of the hash functions became insecure, that 461 would allow attacks against even those ORCHIDs valid for the same 462 Context ID that had been constructed using the other, still secure 463 hash functions. 465 An identifier for the hash function to be used for the ORCHID 466 generation is encoded in the ORCHID itself, while the semantic for 467 the values taken by this identifier are defined separately for each 468 Context ID. Therefore, the present design allows to use different 469 hash functions to be used per given Context ID for constructing 470 ORCHIDs from input bitstrings. If more secure hash functions are 471 later needed, newer values for the ORCHID generation algorithm can be 472 defined for the given Context ID. 474 In order to preserve a low enough probability of collisions (see 475 Section 4), each method MUST utilize a mechanism that makes sure that 476 the distinct input bitstrings are either unique or statistically 477 unique within that context. There are several possible methods to 478 ensure this; for example, one can include into the input bitstring a 479 globally maintained counter value, a pseudo-random number of 480 sufficient entropy (minimum 96 bits), or a randomly generated public 481 cryptographic key. The Context ID makes sure that input bitstrings 482 from different contexts never overlap. These together make sure that 483 the probability of collisions is determined only by the probability 484 of natural collisions in the hash space and is not increased by a 485 possibility of colliding input bitstrings. 487 7. IANA Considerations 489 Because the updated ORCHIDv2 format is not backward compatible with 490 the earlier one, IANA is requested to allocate a new 28-bit prefix 491 out of the IANA IPv6 Special Purpose Address Block, namely 2001: 492 0000::/23, as per [RFC4773]. The prefix that was temporarily 493 allocated for the experimental ORCHID is to be returned to IANA in 494 2014 [RFC4843]. 496 The Context Identifier (or Context ID) is a randomly generated value 497 defining the usage context of an ORCHID and the hash function to be 498 used for generation of ORCHIDs in this context. This document 499 defines no specific value. The Context ID shares the name space 500 introduced for CGA Type Tags. Hence, defining new values follows the 501 rules of Section 8 of [RFC3972], i.e., First Come First Served. 503 8. Contributors 505 Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an 506 earlier, experimental version of this specification [RFC4843]. 508 9. Acknowledgments 510 Special thanks to Geoff Huston for his sharp but constructive 511 critique during the development of this memo. Tom Henderson helped 512 to clarify a number of issues. This document has also been improved 513 by reviews, comments, and discussions originating from the IPv6, 514 Internet Area, and IETF communities. 516 10. References 518 10.1. Normative references 520 [RFC2119] Bradner, S., "Key words for use in RFCs 521 to Indicate Requirement Levels", BCP 14, 522 RFC 2119, March 1997. 524 [RFC3972] Aura, T., "Cryptographically Generated 525 Addresses (CGA)", RFC 3972, March 2005. 527 10.2. Informative references 529 [Hi3] Nikander, P., Arkko, J., and B. Ohlman, 530 "Host Identity Indirection Infrastructure 531 (Hi3)", November 2004. 533 [I-D.ietf-hip-rfc5201-bis] Moskowitz, R., Heer, T., Jokela, P., and 534 T. Henderson, "Host Identity Protocol 535 Version 2 (HIPv2)", 536 draft-ietf-hip-rfc5201-bis-09 (work in 537 progress), July 2012. 539 [NodeID] Ahlgren, B., Arkko, J., Eggert, L., and 540 J. Rajahalme, "A Node Identity 541 Internetworking Architecture (NodeID)", 542 April 2006. 544 [PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension 545 for Mobile IPv6", Work in Progress, 546 July 2006. 548 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, 549 D., Groot, G., and E. Lear, "Address 550 Allocation for Private Internets", BCP 5, 551 RFC 1918, February 1996. 553 [RFC3174] Eastlake, D. and P. Jones, "US Secure 554 Hash Algorithm 1 (SHA1)", RFC 3174, 555 September 2001. 557 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on 558 Cryptographic Hashes in Internet 559 Protocols", RFC 4270, November 2005. 561 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 562 Addressing Architecture", RFC 4291, 563 February 2006. 565 [RFC4773] Huston, G., "Administration of the IANA 566 Special Purpose IPv6 Address Block", 567 RFC 4773, December 2006. 569 [RFC4843] Nikander, P., Laganier, J., and F. 570 Dupont, "An IPv6 Prefix for Overlay 571 Routable Cryptographic Hash Identifiers 572 (ORCHID)", RFC 4843, April 2007. 574 Appendix A. Changes from RFC 4843 576 o Updated HIP references to revised HIP specifications. 578 o The Overlay Routable Cryptographic Hash Identifiers originally 579 defined in [RFC4843] lacked a mechanism for cryptographic 580 algorithm agility. The updated ORCHID format specified in this 581 document removes this limitation by encoding in the identifier 582 itself an index to the suite of cryptographic algorithms in use. 584 Authors' Addresses 586 Julien Laganier 587 Juniper Networks 588 1094 North Mathilda Avenue 589 Sunnyvale, CA 94089 590 USA 592 Phone: +1 408 936 0385 593 EMail: julien.ietf@gmail.com 595 Francis Dupont 596 Internet Systems Consortium 598 EMail: fdupont@isc.org