idnits 2.17.1 draft-ietf-hip-rfc4843-bis-00.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 : ---------------------------------------------------------------------------- == 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 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 (August 20, 2010) is 4998 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) -- 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: 0 errors (**), 0 flaws (~~), 2 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 QUALCOMM Inc. 4 Obsoletes: 4843 (if approved) F. Dupont 5 Intended status: Standards Track ISC 6 Expires: February 21, 2011 August 20, 2010 8 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers 9 (ORCHID) 10 draft-ietf-hip-rfc4843-bis-00 12 Abstract 14 This document introduces Overlay Routable Cryptographic Hash 15 Identifiers (ORCHID) as a new, experimental class of IPv6-address- 16 like identifiers. These identifiers are intended to be used as 17 endpoint identifiers at applications and Application Programming 18 Interfaces (API) and not as identifiers for network location at the 19 IP layer, i.e., locators. They are designed to appear as application 20 layer entities and at the existing IPv6 APIs, but they should not 21 appear in actual IPv6 headers. To make them more like vanilla IPv6 22 addresses, they are expected to be routable at an overlay level. 23 Consequently, while they are considered non-routable addresses from 24 the IPv6 layer point-of-view, all existing IPv6 applications are 25 expected to be able to use them in a manner compatible with current 26 IPv6 addresses. 28 This document requests IANA to allocate a temporary prefix out of the 29 IPv6 addressing space for Overlay Routable Cryptographic Hash 30 Identifiers. By default, the prefix will be returned to IANA in 31 2014, with continued use requiring IETF consensus. 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 February 21, 2011. 50 Copyright Notice 52 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative references . . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative references . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 This document introduces Overlay Routable Cryptographic Hash 89 Identifiers (ORCHID), a new class of IP address-like identifiers. 90 These identifiers are intended to be globally unique in a statistical 91 sense (see Section 4), non-routable at the IP layer, and routable at 92 some overlay layer. The identifiers are securely bound, via a secure 93 hash function, to the concatenation of an input bitstring and a 94 context tag. Typically, but not necessarily, the input bitstring 95 will include a suitably encoded public cryptographic key. 97 1.1. Rationale and Intent 99 These identifiers are expected to be used at the existing IPv6 100 Application Programming Interfaces (API) and application protocols 101 between consenting hosts. They may be defined and used in different 102 contexts, suitable for different overlay protocols. Examples of 103 these include Host Identity Tags (HIT) in the Host Identity Protocol 104 (HIP) [HIP-BASE] and Temporary Mobile Identifiers (TMI) for Mobile 105 IPv6 Privacy Extension [PRIVACYTEXT]. 107 As these identifiers are expected to be used along with IPv6 108 addresses at both applications and APIs, co-ordination is desired to 109 make sure that an ORCHID is not inappropriately taken for a vanilla 110 IPv6 address and vice versa. In practice, allocation of a separate 111 prefix for ORCHIDs seems to suffice, making them compatible with IPv6 112 addresses at the upper layers while simultaneously making it trivial 113 to prevent their usage at the IP layer. 115 While being technically possible to use ORCHIDs between consenting 116 hosts without any co-ordination with the IETF and the IANA, the 117 authors would consider such practice potentially dangerous. A 118 specific danger would be realised if the IETF community later decided 119 to use the ORCHID prefix for some different purpose. In that case, 120 hosts using the ORCHID prefix would be, for practical purposes, 121 unable to use the prefix for the other new purpose. That would lead 122 to partial balkanisation of the Internet, similar to what has 123 happened as a result of historical hijackings of non-RFC 1918 124 [RFC1918] IPv4 addresses for private use. 126 The whole need for the proposed allocation grows from the desire to 127 be able to use ORCHIDs with existing applications and APIs. This 128 desire leads to the potential conflict, mentioned above. Resolving 129 the conflict requires the proposed allocation. 131 One can argue that the desire to use these kinds of identifiers via 132 existing APIs is architecturally wrong, and there is some truth in 133 that argument. Indeed, it would be more desirable to introduce a new 134 API and update all applications to use identifiers, rather than 135 locators, via that new API. That is exactly what we expect to happen 136 in the long run. 138 However, given the current state of the Internet, we do not consider 139 it viable to introduce any changes that, at once, require 140 applications to be rewritten and host stacks to be updated. Rather 141 than that, we believe in piece-wise architectural changes that 142 require only one of the existing assets to be touched. ORCHIDs are 143 designed to address this situation: to allow people to experiment 144 with protocol stack extensions, such as secure overlay routing, HIP, 145 or Mobile IP privacy extensions, without requiring them to update 146 their applications. The goal is to facilitate large-scale 147 experiments with minimum user effort. 149 For example, there already exists, at the time of this writing, HIP 150 implementations that run fully in user space, using the operating 151 system to divert a certain part of the IPv6 address space to a user 152 level daemon for HIP processing. In practical terms, these 153 implementations are already using a certain IPv6 prefix for 154 differentiating HIP identifiers from IPv6 addresses, allowing them 155 both to be used by the existing applications via the existing APIs. 157 This document argues for allocating an experimental prefix for such 158 purposes, thereby paving the way for large-scale experiments with 159 cryptographic identifiers without the dangers caused by address-space 160 hijacking. 162 1.2. ORCHID Properties 164 ORCHIDs are designed to have the following properties: 166 o Statistical uniqueness; also see Section 4 168 o Secure binding to the input parameters used in their generation 169 (i.e., the context identifier and a bitstring). 171 o Aggregation under a single IPv6 prefix. Note that this is only 172 needed due to the co-ordination need as indicated above. Without 173 such co-ordination need, the ORCHID namespace could potentially be 174 completely flat. 176 o Non-routability at the IP layer, by design. 178 o Routability at some overlay layer, making them, from an 179 application point of view, semantically similar to IPv6 addresses. 181 As mentioned above, ORCHIDs are intended to be generated and used in 182 different contexts, as suitable for different mechanisms and 183 protocols. The context identifier is meant to be used to 184 differentiate between the different contexts; see Section 4 for a 185 discussion of the related API and kernel level implementation issues, 186 and Section 5 for the design choices explaining why the context 187 identifiers are used. 189 1.3. Expected use of ORCHIDs 191 Examples of identifiers and protocols that are expected to adopt the 192 ORCHID format include Host Identity Tags (HIT) in the Host Identity 193 Protocol [HIP-BASE] and the Temporary Mobile Identifiers (TMI) in the 194 Simple Privacy Extension for Mobile IPv6 [PRIVACYTEXT]. The format 195 is designed to be extensible to allow other experimental proposals to 196 share the same namespace. 198 1.4. Action Plan 200 This document requests IANA to allocate an experimental prefix out of 201 the IPv6 addressing space for Overlay Routable Cryptographic Hash 202 Identifiers. 204 1.5. Terminology 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in [RFC2119]. 210 2. Cryptographic Hash Identifier Construction 212 An ORCHID is generated using the algorithm below. The algorithm 213 takes a bitstring and a context identifier as input and produces an 214 ORCHID as output. 216 Input := any bitstring 217 Hash Input := Context ID | Input 218 Hash := Hash_function( Hash Input ) 219 ORCHID := Prefix | Encode_100( Hash ) 221 where: 223 | : Denotes concatenation of bitstrings 225 Input : A bitstring that is unique or statistically unique 226 within a given context. The bitstring is intended 227 to be associated with the to-be-created ORCHID in 228 the given context. 230 Context ID : A randomly generated value defining the expected 231 usage context for the particular ORCHID and the 232 hash function to be used for generation of ORCHIDs 233 in this context. These values are allocated out of 234 the namespace introduced for CGA Type Tags; see RFC 235 3972 and 236 http://www.iana.org/assignments/cga-message-types. 238 Hash_function : The one-way hash function (i.e., hash function with 239 pre-image resistance and second pre-image 240 resistance) to be used according to the document 241 defining the context usage identified by the 242 Context ID. For example, the current version of 243 the HIP specification defines SHA1 [RFC3174] as 244 the hash function to be used to generate ORCHIDs 245 used in the HIP protocol [HIP-BASE]. 247 Encode_100( ) : An extraction function in which output is obtained 248 by extracting the middle 100-bit-long bitstring 249 from the argument bitstring. 251 Prefix : A constant 28-bit-long bitstring value 252 (2001:10::/28). 254 To form an ORCHID, two pieces of input data are needed. The first 255 piece can be any bitstring, but is typically expected to contain a 256 public cryptographic key and some other data. The second piece is a 257 context identifier, which is a 128-bit-long datum, allocated as 258 specified in Section 7. Each specific experiment (such as HIP HITs 259 or MIP6 TMIs) is expected to allocate their own, specific context 260 identifier. 262 The input bitstring and context identifier are concatenated to form 263 an input datum, which is then fed to the cryptographic hash function 264 to be used according to the document defining the context usage 265 identified by the Context ID. The result of the hash function is 266 processed by an encoding function, resulting in a 100-bit-long value. 267 This value is prepended with the 28-bit ORCHID prefix. The result is 268 the ORCHID, a 128-bit-long bitstring that can be used at the IPv6 269 APIs in hosts participating to the particular experiment. 271 The ORCHID prefix is allocated under the IPv6 global unicast address 272 block. Hence, ORCHIDs are indistinguishable from IPv6 global unicast 273 addresses. However, it should be noted that ORCHIDs do not conform 274 with the IPv6 global unicast address format defined in Section 2.5.4 275 of [RFC4291] since they do not have a 64-bit Interface ID formatted 276 as described in Section 2.5.1. of [RFC4291]. 278 3. Routing Considerations 280 ORCHIDs are designed to serve as location independent endpoint- 281 identifiers rather than IP-layer locators. Therefore, routers MAY be 282 configured not to forward any packets containing an ORCHID as a 283 source or a destination address. If the destination address is an 284 ORCHID but the source address is a valid unicast source address, 285 routers MAY be configured to generate an ICMP Destination 286 Unreachable, Administratively Prohibited message. 288 Due to the experimental nature of ORCHIDs, router software MUST NOT 289 include any special handling code for ORCHIDs. In other words, the 290 non-routability property of ORCHIDs, if implemented, MUST be 291 implemented via configuration and NOT by hardwired software code. At 292 this time, it is RECOMMENDED that the default router configuration 293 not handle ORCHIDs in any special way. In other words, there is no 294 need to touch existing or new routers due to this experiment. If 295 such a reason should later appear, for example, due to a faulty 296 implementation leaking ORCHIDs to the IP layer, the prefix can be and 297 should be blocked by a simple configuration rule. 299 3.1. Overlay Routing 301 As mentioned multiple times, ORCHIDs are designed to be non-routable 302 at the IP layer. However, there are multiple ongoing research 303 efforts for creating various overlay routing and resolution 304 mechanisms for flat identifiers. For example, the Host Identity 305 Indirection Infrastructure (Hi3) [Hi3] and Node Identity 306 Internetworking Architecture (NodeID) [NodeID] proposals, outline 307 ways for using a Distributed Hash Table to forward HIP packets based 308 on the Host Identity Tag. 310 What is common to the various research proposals is that they create 311 a new kind of resolution or routing infrastructure on top of the 312 existing Internet routing structure. In practical terms, they allow 313 delivery of packets based on flat, non-routable identifiers, 314 utilising information stored in a distributed database. Usually, the 315 database used is based on Distributed Hash Tables. This effectively 316 creates a new routing network on top of the existing IP-based routing 317 network, capable of routing packets that are not addressed by IP 318 addresses but some other kind of identifiers. 320 Typical benefits from overlay routing include location independence, 321 more scalable multicast, anycast, and multihoming support than in IP, 322 and better DoS resistance than in the vanilla Internet. The main 323 drawback is typically an order of magnitude of slower performance, 324 caused by an easily largish number of extra look-up or forwarding 325 steps needed. Consequently, in most practical cases, the overlay 326 routing system is used only during initial protocol state set-up (cf. 327 TCP handshake), after which the communicating endpoints exchange 328 packets directly with IP, bypassing the overlay network. 330 The net result of the typical overlay routing approaches is a 331 communication service whose basic functionality is comparable to that 332 provided by classical IP but provides considerably better resilience 333 that vanilla IP in dynamic networking environments. Some experiments 334 also introduce additional functionality, such as enhanced security or 335 ability to effectively route through several IP addressing domains. 337 The authors expect ORCHIDs to become fully routable, via one or more 338 overlay systems, before the end of the experiment. 340 4. Collision Considerations 342 As noted above, the aim is that ORCHIDs are globally unique in a 343 statistical sense. That is, given the ORCHID referring to a given 344 entity, the probability of the same ORCHID being used to refer to 345 another entity elsewhere in the Internet must be sufficiently low so 346 that it can be ignored for most practical purposes. We believe that 347 the presented design meets this goal; see Section 5. 349 Consider next the very rare case that some ORCHID happens to refer to 350 two different entities at the same time, at two different locations 351 in the Internet. Even in this case, the probability of this fact 352 becoming visible (and therefore a matter of consideration) at any 353 single location in the Internet is negligible. For the vast majority 354 of cases, the two simultaneous uses of the ORCHID will never cross 355 each other. However, while rare, such collisions are still possible. 356 This section gives reasonable guidelines on how to mitigate the 357 consequences in the case that such a collision happens. 359 As mentioned above, ORCHIDs are expected to be used at the legacy 360 IPv6 APIs between consenting hosts. The context ID is intended to 361 differentiate between the various experiments, or contexts, sharing 362 the ORCHID namespace. However, the context ID is not present in the 363 ORCHID itself, but only in front of the input bitstring as an input 364 to the hash function. While this may lead to certain implementation- 365 related complications, we believe that the trade-off of allowing the 366 hash result part of an ORCHID being longer more than pays off the 367 cost. 369 Because ORCHIDs are not routable at the IP layer, in order to send 370 packets using ORCHIDs at the API level, the sending host must have 371 additional overlay state within the stack to determine which 372 parameters (e.g., what locators) to use in the outgoing packet. An 373 underlying assumption here, and a matter of fact in the proposals 374 that the authors are aware of, is that there is an overlay protocol 375 for setting up and maintaining this additional state. It is assumed 376 that the state-set-up protocol carries the input bitstring, and that 377 the resulting ORCHID-related state in the stack can be associated 378 back with the appropriate context and state-set-up protocol. 380 Even though ORCHID collisions are expected to be extremely rare, two 381 kinds of collisions may still happen. First, it is possible that two 382 different input bitstrings within the same context may map to the 383 same ORCHID. In this case, the state-set-up mechanism is expected to 384 resolve the conflict, for example, by indicating to the peer that the 385 ORCHID in question is already in use. 387 A second type of collision may happen if two input bitstrings, used 388 in different usage contexts, map to the same ORCHID. In this case, 389 the main confusion is about which context to use. In order to 390 prevent these types of collisions, it is RECOMMENDED that 391 implementations that simultaneously support multiple different 392 contexts maintain a node-wide unified database of known ORCHIDs, and 393 indicate a conflict if any of the mechanisms attempt to register an 394 ORCHID that is already in use. For example, if a given ORCHID is 395 already being used as a HIT in HIP, it cannot simultaneously be used 396 as a TMI in Mobile IP. Instead, if Mobile IP attempts to use the 397 ORCHID, it will be notified (by the kernel) that the ORCHID in 398 question is already in use. 400 5. Design Choices 402 The design of this namespace faces two competing forces: 404 o As many bits as possible should be preserved for the hash result. 406 o It should be possible to share the namespace between multiple 407 mechanisms. 409 The desire to have a long hash result requires that the prefix be as 410 short as possible, and use few (if any) bits for additional encoding. 411 The present design takes this desire to the maxim: all the bits 412 beyond the prefix are used as hash output. This leaves no bits in 413 the ORCHID itself available for identifying the context. 414 Additionally, due to security considerations, the present design 415 REQUIRES that the hash function used in constructing ORCHIDs be 416 constant; see Section 6. 418 The authors explicitly considered including a hash-extension 419 mechanism, similar to the one in CGA [RFC3972], but decided to leave 420 it out. There were two reasons: desire for simplicity, and the 421 somewhat unclear IPR situation around the hash-extension mechanism. 422 If there is a future revision of this document, we strongly advise 423 the future authors to reconsider the decision. 425 The desire to allow multiple mechanisms to share the namespace has 426 been resolved by including the context identifier in the hash- 427 function input. While this does not allow the mechanism to be 428 directly inferred from a ORCHID, it allows one to verify that a given 429 input bitstring and ORCHID belong to a given context, with high- 430 probability; but also see Section 6. 432 6. Security Considerations 434 ORCHIDs are designed to be securely bound to the Context ID and the 435 bitstring used as the input parameters during their generation. To 436 provide this property, the ORCHID generation algorithm relies on the 437 second-preimage resistance (a.k.a. one-way) property of the hash 438 function used in the generation [RFC4270]. To have this property and 439 to avoid collisions, it is important that the allocated prefix is as 440 short as possible, leaving as many bits as possible for the hash 441 output. 443 For a given Context ID, all mechanisms using ORCHIDs MUST use exactly 444 the same mechanism for generating an ORCHID from the input bitstring. 445 Allowing different mechanisms, without explicitly encoding the 446 mechanism in the Context ID or the ORCHID itself, would allow so- 447 called bidding-down attacks. That is, if multiple different hash 448 functions were allowed to construct ORCHIDs valid for the same 449 Context ID, and if one of the hash functions became insecure, that 450 would allow attacks against even those ORCHIDs valid for the same 451 Context ID that had been constructed using the other, still secure 452 hash functions. 454 Due to the desire to keep the hash output value as long as possible, 455 the hash function is not encoded in the ORCHID itself, but rather in 456 the Context ID. Therefore, the present design allows only one method 457 per given Context ID for constructing ORCHIDs from input bitstrings. 458 If other methods (perhaps using more secure hash functions) are later 459 needed, they MUST use a different Context ID. Consequently, the 460 suggested method to react to the hash result becoming too short, due 461 to increased computational power, or to the used hash function 462 becoming insecure due to advances in cryptology, is to allocate a new 463 Context ID and cease to use the present one. 465 As of today, SHA1 [RFC3174] is considered as satisfying the second- 466 preimage resistance requirement. The current version of the HIP 467 specification defines SHA1 [RFC3174] as the hash function to be used 468 to generate ORCHIDs for the Context ID used by the HIP protocol 469 [HIP-BASE]. 471 In order to preserve a low enough probability of collisions (see 472 Section 4), each method MUST utilize a mechanism that makes sure that 473 the distinct input bitstrings are either unique or statistically 474 unique within that context. There are several possible methods to 475 ensure this; for example, one can include into the input bitstring a 476 globally maintained counter value, a pseudo-random number of 477 sufficient entropy (minimum 100 bits), or a randomly generated public 478 cryptographic key. The Context ID makes sure that input bitstrings 479 from different contexts never overlap. These together make sure that 480 the probability of collisions is determined only by the probability 481 of natural collisions in the hash space and is not increased by a 482 possibility of colliding input bitstrings. 484 7. IANA Considerations 486 IANA allocated a temporary non-routable 28-bit prefix from the IPv6 487 address space. By default, the prefix will be returned to IANA in 488 2014, continued use requiring IETF consensus. As per [RFC4773], the 489 28-bit prefix was drawn out of the IANA Special Purpose Address 490 Block, namely 2001:0000::/23, in support of the experimental usage 491 described in this document. IANA has updated the IPv6 Special 492 Purpose Address Registry. 494 During the discussions related to this document, it was suggested 495 that other identifier spaces may be allocated from this block later. 496 However, this document does not define such a policy or allocations. 498 The Context Identifier (or Context ID) is a randomly generated value 499 defining the usage context of an ORCHID and the hash function to be 500 used for generation of ORCHIDs in this context. This document 501 defines no specific value. 503 We propose sharing the name space introduced for CGA Type Tags. 504 Hence, defining new values would follow the rules of Section 8 of 505 [RFC3972], i.e., on a First Come First Served basis. 507 8. Contributors 509 Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an 510 earlier, experimental version of this specification [RFC4843]. 512 9. Acknowledgments 514 Special thanks to Geoff Huston for his sharp but constructive 515 critique during the development of this memo. Tom Henderson helped 516 to clarify a number of issues. This document has also been improved 517 by reviews, comments, and discussions originating from the IPv6, 518 Internet Area, and IETF communities. 520 Julien Laganier is partly funded by Ambient Networks, a research 521 project supported by the European Commission under its Sixth 522 Framework Program. The views and conclusions contained herein are 523 those of the authors and should not be interpreted as necessarily 524 representing the official policies or endorsements, either expressed 525 or implied, of the Ambient Networks project or the European 526 Commission. 528 10. References 530 10.1. Normative references 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC3972] Aura, T., "Cryptographically Generated Addresses 536 (CGA)", RFC 3972, March 2005. 538 10.2. Informative references 540 [HIP-BASE] Moskowitz, R., "Host Identity Protocol", Work 541 in Progress, February 2007. 543 [Hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity 544 Indirection Infrastructure (Hi3)", November 2004. 546 [NodeID] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, 547 "A Node Identity Internetworking Architecture 548 (NodeID)", April 2006. 550 [PRIVACYTEXT] Dupont, F., "A Simple Privacy Extension for Mobile 551 IPv6", Work in Progress, July 2006. 553 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., 554 and E. Lear, "Address Allocation for Private 555 Internets", BCP 5, RFC 1918, February 1996. 557 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 558 (SHA1)", RFC 3174, September 2001. 560 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 561 Hashes in Internet Protocols", RFC 4270, 562 November 2005. 564 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 565 Architecture", RFC 4291, February 2006. 567 [RFC4773] Huston, G., "Administration of the IANA Special 568 Purpose IPv6 Address Block", RFC 4773, December 2006. 570 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 571 Prefix for Overlay Routable Cryptographic Hash 572 Identifiers (ORCHID)", RFC 4843, April 2007. 574 Authors' Addresses 576 Julien Laganier 577 QUALCOMM Incorporated 578 5775 Morehouse Drive 579 San Diego, CA 92121 580 USA 582 Phone: +1 858 858 3538 583 EMail: julienl@qualcomm.com 585 Francis Dupont 586 ISC 588 EMail: Francis.Dupont@fdupont.fr