idnits 2.17.1 draft-laganier-ipv6-khi-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 620. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2007) is 6275 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 (-10) exists of draft-ietf-hip-base-07 -- Obsolete informational reference (is this intentional?): RFC 4773 (Obsoleted by RFC 6890) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Nikander 3 Internet-Draft Ericsson Research Nomadic Lab 4 Intended status: Standards Track J. Laganier 5 Expires: August 18, 2007 DoCoMo Euro-Labs 6 F. Dupont 7 CELAR 8 February 14, 2007 10 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers 11 (ORCHID) 12 draft-laganier-ipv6-khi-07 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 18, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document introduces Overlay Routable Cryptographic Hash 46 Identifiers (ORCHID) as a new, experimental class of IPv6-address- 47 like identifiers. These identifiers are intended to be used as end- 48 point identifiers at applications and Application Programming 49 Interfaces (API) and not as identifiers for network location at the 50 IP layer, i.e., locators. They are designed to appear as application 51 layer entities and at the existing IPv6 APIs, but they should not 52 appear in actual IPv6 headers. To make them more like vanilla IPv6 53 addresses, they are expected to be routable at an overlay level. 54 Consequently, while they are considered as non-routable addresses 55 from the IPv6 layer point of view, all existing IPv6 applications are 56 expected to be able to use them in a manner compatible with current 57 IPv6 addresses. 59 This document requests IANA to allocate a temporary prefix out of the 60 IPv6 addressing space for Overlay Routable Cryptographic Hash 61 Identifiers. By default, the prefix will be returned to IANA in 62 2027, continued use requiring IETF consensus. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Rationale and intent . . . . . . . . . . . . . . . . . . . 3 68 1.2. ORCHID properties . . . . . . . . . . . . . . . . . . . . 4 69 1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5 70 1.4. Action plan . . . . . . . . . . . . . . . . . . . . . . . 5 71 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5 73 3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7 74 3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 7 75 4. Collision Considerations . . . . . . . . . . . . . . . . . . . 8 76 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. Normative references . . . . . . . . . . . . . . . . . . . 12 82 9.2. Informative references . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 Intellectual Property and Copyright Statements . . . . . . . . . . 14 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) [I-D.ietf-hip-base] and Temporary Mobile Identifiers (TMI) for 105 Mobile IPv6 Privacy Extension [I-D.dupont-mip6-privacyext]. 107 As these identifiers are expected to be used alongside 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-RFC1918 IPv4 124 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 longer 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, those 153 implementations are already now 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 no more than allocating an experimental 158 prefix for such purposes, thereby paving the way for large-scale 159 experiments with cryptographic identifiers without the dangers caused 160 by address-space hijacking. 162 1.2. ORCHID properties 164 ORCHIDs are designed to have the following properties: 165 o Statistical uniqueness; see also Section 4 166 o Secure binding to the input parameters used in their generation 167 (i.e., the context identifier and a bitstring.) 168 o Aggregation under a single IPv6 prefix. Note that this is only 169 needed due to the co-ordination need, as indicated above. Without 170 such co-ordination need, the ORCHID name space could potentially 171 be completely flat. 172 o Non-routability at the IP layer, by design. 173 o Routability at some overlay layer, making them, from an 174 application point of view, semantically similar to IPv6 addresses. 176 As mentioned above, ORCHIDs are intended to be generated and used in 177 different contexts, as suitable for different mechanisms and 178 protocols. The context identifier is meant to be used to 179 differentiate between the different contexts; see Section 4 for a 180 discussion of the related API and kernel level implementation issues, 181 and Section 5 for the design choices explaining why the context 182 identifiers are used. 184 1.3. Expected use of ORCHIDs 186 Examples of identifiers and protocols that are expected to adopt the 187 ORCHID format include Host Identity Tags (HIT) in the Host Identity 188 Protocol [I-D.ietf-hip-base] and the Temporary Mobile Identifiers 189 (TMI) in the Simple Privacy Extension for Mobile IPv6 190 [I-D.dupont-mip6-privacyext]. The format is designed to be 191 extensible to allow other experimental proposals to share the same 192 name space. 194 1.4. Action plan 196 This document requests IANA to allocate an experimental prefix out of 197 the IPv6 addressing space for Overlay Routable Cryptographic Hash 198 Identifiers. 200 1.5. Terminology 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 2. Cryptographic Hash Identifier Construction 208 An ORCHID is generated using the algorithm below. The algorithm 209 takes a bitstring and a context identifier as input and produces an 210 ORCHID as output. 212 Input := any bitstring 213 Hash Input := Context ID | Input 214 Hash := Hash_function( Hash Input ) 215 ORCHID := Prefix | Encode_100( Hash ) 217 where: 219 | : Denotes concatenation of bitstrings 221 Input : A bitstring unique or statistically unique within a 222 given context. The bitstring is intended to be 223 associated with the to-be-created ORCHID, in the 224 given context. 226 Context ID : A randomly generated value defining the expected usage 227 context for the particular ORCHID and the hash 228 function to be used for generation of ORCHIDs in this 229 context. These values are allocated out of the the 230 name space introduced for CGA Type Tags; see RFC 3972 231 and http://www.iana.org/assignments/cga-message-types 233 Hash_function : The one way hash function (i.e. hash function with 234 pre-image resistance and second pre-image resistance) 235 to be used according to the document defining the 236 context usage identified by the Context ID. 237 For example, the current version of the HIP 238 specification defines SHA1 [RFC3174] as the hash 239 function to be used to generate ORCHIDs used in the 240 HIP protocol [I-D.ietf-hip-base]. 242 Encode_100( ) : An extraction function which output is obtained by 243 extracting the middle 100-bit long bitstring from the 244 argument bitstring. 246 Prefix : A constant 28-bit long bitstring value, TBD, assigned 247 by IANA. 249 To form an ORCHID, two pieces of input data are needed. The first 250 piece can be any bitstring, but is typically expected to contain a 251 public cryptographic key and some other data. The second piece is a 252 context identifier, which is an 128-bit-long datum, allocated as 253 specified in Section 7. Each specific experiment (such as HIP HITs 254 or MIP6 TMIs) is expected to allocate their own, specific context 255 identifier. 257 The input bitstring and context identifier are concatenated to form 258 an input datum, which is then fed to the cryptographic hash function 259 to be used according to the document defining the context usage 260 identified by the Context ID. The result of the hash function is 261 processed by an encoding function, resulting in an 100-bit-long 262 value. This value is prepended with the 28-bit ORCHID prefix. The 263 result is the ORCHID, an 128-bit-long bitstring that can be used at 264 the IPv6 APIs in hosts participating to the particular experiment. 266 The ORCHID prefix is allocated under the IPv6 global unicast address 267 block. Hence, ORCHIDs are undistinguishable from IPv6 global unicast 268 addresses. However, it should be noted that ORCHIDs do not conform 269 with the IPv6 global unicast address format defined in Section 2.5.4 270 of [RFC4291] since they do not have a 64-bit Interface ID formatted 271 as described in Section 2.5.1. of [RFC4291]. 273 3. Routing Considerations 275 ORCHIDs are designed to serve as location independent end-point- 276 identifiers rather than IP-layer locators. Therefore, routers MAY be 277 configured not to forward any packets containing an ORCHID as a 278 source or a destination address. If the destination address is a 279 ORCHID but the source address is a valid unicast source address, 280 routers MAY be configured to generate an ICMP Destination 281 Unreachable, Administratively Prohibited message. 283 Due to the experimental nature of ORCHIDs, router software MUST NOT 284 include any special handling code for ORCHIDs. In other words, the 285 non-routability property of ORCHIDs, if implemented, MUST be 286 implemented via configuration and NOT by hard-wired software code. 287 At this time, it is RECOMMENDED that the default router configuration 288 does not handle ORCHIDs in any special way. In other words, there is 289 no need to touch existing or new routers due to this experiment. If 290 such reason should later appear, for example, due to a faulty 291 implementation leaking ORCHIDs to the IP layer, the prefix can be and 292 should be blocked by a simple configuration rule. 294 3.1. Overlay Routing 296 As mentioned multiple times, ORCHIDs are designed to be non-routable 297 at the IP layer. However, there are multiple ongoing research 298 efforts for creating various overlay routing and resolution 299 mechanisms for flat identifiers. For example, the Host Identity 300 Indirection Infrastructure (Hi3) [Hi3] and a Node Identity 301 Internetworking Architecture (NodeID) [NodeID] proposals outline ways 302 for using a Distributed Hash Table to forward HIP packets based on 303 the Host Identity Tag. 305 What is common to the various research proposals is that they create 306 a new kind of resolution or routing infrastructure on the top of the 307 existing Internet routing structure. In practical terms, they allow 308 delivery of packets based on flat, non-routable identifiers, 309 utilising information stored in a distributed data base. Usually the 310 database used is based on Distributed Hash Tables. This effectively 311 creates a new routing network on the top of the existing IP-based 312 routing network, capable of routing packets that are not addressed by 313 IP addresses but some other kind of identifiers. 315 Typical benefits from overlay routing include location independence, 316 more scalable multi-cast, any-cast, and multi-homing support than in 317 IP, and better DoS resistance than in the vanilla Internet. The main 318 drawback is typically an order of magnitude slower performance, 319 caused by an easily largish number of extra look-up or forwarding 320 steps needed. Consequently, in most practical cases the overlay 321 routing system is used only during initial protocol state set-up (cf. 322 TCP handshake), after which the communicating end-points exchange 323 packets directly with IP, bypassing the overlay network. 325 The net result of the typical overlay routing approaches is a 326 communication service whose basic functionality is comparable to that 327 of provided by classical IP but that provides considerably better 328 resilience that vanilla IP in dynamic networking environments. Some 329 experiments also introduce additional 28-bit functionality, such as 330 enhanced security or ability to effectively route through several IP 331 addressing domains. 333 The authors expect ORCHIDs to become fully routable, via one or more 334 overlay systems, before the end of the experiment. 336 4. Collision Considerations 338 As noted above, the aim is that ORCHIDs are globally unique in a 339 statistical sense. That is, given the ORCHID referring to a given 340 entity, the probability of the same ORCHID being used to refer to 341 another entity elsewhere in the Internet must be sufficiently low so 342 that it can be ignored for most practical purposes. We believe that 343 the presented design meets this goal; see Section 5. 345 Consider next the very rare case that some ORCHID happens to refer to 346 two different entities at the same time at two different locations in 347 the Internet. Even in that case the probability of this fact 348 becoming visible (and therefore a matter of consideration) at any 349 single location in the Internet is negligible. For the vast majority 350 of cases the two simultaneous uses of the ORCHID will never cross 351 each other. However, while rare such collisions are still possible. 352 This section gives reasonable guidelines on how to mitigate the 353 consequences in the case such a collision happens. 355 As mentioned above, ORCHIDs are expected to be used at the legacy 356 IPv6 APIs between consenting hosts. The context ID is intended to 357 differentiate between the various experiments, or contexts, sharing 358 the ORCHID name space. However, the context ID is not present in the 359 ORCHID itself, but only in front of the input bitstring as an input 360 to the hash function. While this may lead to certain implementation- 361 related complications, we believe that the trade-off of allowing the 362 hash result part of an ORCHID being longer more than pays off the 363 cost. 365 Now, because ORCHIDs are not routable at the IP layer, in order to 366 send packets using ORCHIDs at the API level, the sending host must 367 have additional overlay state within the stack in order to determine 368 parameters (e.g. what locators) to use in the outgoing packet. An 369 underlying assumption here, and a matter of fact in the proposals 370 that the authors are aware of, is that there is an overlay protocol 371 for setting up and maintaining this additional state. It is assumed 372 that the state-set-up protocol carries the input bitstring, and that 373 the resulting ORCHID-related state in the stack can be associated 374 back with the appropriate context and state-set-up protocol. 376 Even though ORCHID collisions are expected to be extremely rare, two 377 kinds of collisions may still happen. First, it is possible that two 378 different input bitstrings within the same context may map to the 379 same ORCHID. In that case, the state-set-up mechanism is expected to 380 resolve the conflict, for example, by indicating to the peer that the 381 ORCHID in question is already in use. 383 A second type of collision may happen if two input bitstrings, used 384 in different usage contexts, map to the same ORCHID. In this case 385 the main confusion is about which context to use. In order to 386 prevent these types of collisions, it is RECOMMENDED that 387 implementations that simultaneously support multiple different 388 contexts maintain a node-wide unified database of known ORCHIDs, and 389 indicate a conflict if any of the mechanisms attempt to register a 390 ORCHID that is already in use. For example, if a given ORCHID is 391 already being used as a HIT in HIP, it cannot simultaneously be used 392 as a TMI in Mobile IP. Instead, if Mobile IP attempts to use the 393 ORCHID, it will be notified (by the kernel) that the ORCHID in 394 question is already in use. 396 5. Design Choices 398 The design of this name space faces two competing forces: 400 o As many bits as possible should be preserved for the hash result. 401 o It should be possible to share the name space between multiple 402 mechanisms. 404 The desire to have a long hash result requires the prefix to be as 405 short as possible, and to use few (if any) bits for additional 406 encoding. The present design takes this desire to the maxim: all the 407 bits beyond the prefix are used as hash output. This leaves no bits 408 in the ORCHID itself available for identifying the context. 409 Additionally, due to security considerations, the present design 410 REQUIRES that the hash function used in constructing ORCHIDs be 411 constant; see Section 6. 413 The authors explicitly considered including a hash extension 414 mechanism, similar to the one in CGA [RFC3972], but decided to leave 415 it out. There were two reasons: desire for simplicity, and the 416 somewhat unclear IPR situation around the hash extension mechanism. 417 If there is a future revision of this document, we strongly advise 418 the future authors to reconsider the decision. 420 The desire to allow multiple mechanism to share the name space has 421 been resolved by including the context identifier in the hash 422 function input. While this does not allow the mechanism to be 423 directly inferred from a ORCHID, it allows one to verify that a given 424 input bitstring and ORCHID belong to a given context, with high 425 probability; but see also Section 6. 427 6. Security Considerations 429 ORCHIDs are designed to be securely bound to the Context ID and the 430 bitstring used as the input parameters during their generation. To 431 provide this property, the ORCHID generation algorithm relies on the 432 second-preimage resistance (a.k.a. one-way) property of the hash 433 function used in the generation [RFC4270]. To have this property, 434 and to avoid collisions, it is important that the allocated prefix is 435 as short as possible, leaving as many bits as possible for the hash 436 output. 438 For a given Context ID, all mechanisms using ORCHIDs MUST use exactly 439 the same mechanism for generating a ORCHID from the input bitstring. 440 Allowing different mechanisms, without explicitly encoding the 441 mechanism in the Context ID or the ORCHID itself, would allow so 442 called bidding down attacks. That is, if multiple different hash 443 functions were allowed in constructing ORCHIDs valid for the same 444 Context ID, and if one of the hash functions became insecure, that 445 would allow attacks against even those ORCHIDs valid for the same 446 Context ID that had been constructed using the other, still secure 447 hash functions. 449 Due to the desire to keep the hash output value as long as possible, 450 the hash function is not encoded in the ORCHID itself, but rather in 451 the Context ID. Therefore, the present design allows only one method 452 per given Context ID for constructing ORCHIDs from input bitstrings. 453 If other methods (perhaps using more secure hash functions) are later 454 needed, they MUST use a different Context ID. Consequently, the 455 suggested method to react to the hash result becoming too short, due 456 to increased computational power or to the used hash function 457 becoming insecure due to advances in cryptology, is to allocate a new 458 Context ID and cease to use the present one. 460 As of today, SHA1 [RFC3174] is considered as satisfying the second- 461 preimage resistance requirement. The current version of the HIP 462 specification defines SHA1 [RFC3174] as the hash function to be used 463 to generate ORCHIDs for the Context ID used by the HIP protocol 464 [I-D.ietf-hip-base]. 466 In order to preserve a low enough probability of collisions (see 467 Section 4), each method MUST utilize a mechanism that makes sure that 468 the distinct input bitstrings are either unique or statistically 469 unique, within that context. There are several possible methods to 470 ensure that; for example, one can include into the input bitstring a 471 globally maintained counter value, a pseudo-random number of 472 sufficient entropy (minimum 100 bits), or a randomly generated public 473 cryptographic key. The Context ID makes sure that input bitstrings 474 from different contexts never overlap. These together make sure that 475 the probability of collisions is determined only by the probability 476 of natural collisions in the hash space and is not increased by a 477 possibility of colliding input bitstrings. 479 7. IANA Considerations 481 IANA is requested to allocate a temporary non-routable 28-bit prefix 482 from the IPv6 address space. By default, the prefix will be returned 483 to IANA in 2027, continued use requiring IETF consensus. As per 484 [RFC4773], the 28-bit prefix shall be drawn out of the IANA Special 485 Purpose Address Block, namely 2001:0000::/23, in support of the 486 experimental usage described in this document. The allocation will 487 require updating the IANA IPv6 Special Purpose Address Registry. 489 During the discussions related to this draft, it was suggested that 490 other identifier spaces may be later allocated from this block. 491 However, this document does not define such a policy or allocations. 493 The Context Identifier (or Context ID) is a randomly generated value 494 defining the usage context of a ORCHID and the hash function to be 495 used for generation of ORCHIDs in this context. This document 496 defines no specific value. 498 We propose sharing the name space introduced for CGA Type Tags. 499 Hence, defining new values would follow the rules of Section 8 of 500 [RFC3972], i.e., on a First Come First Served basis. 502 8. Acknowledgments 504 Special thanks to Geoff Huston for his sharp but constructive critic 505 during the development of this memo. Tom Henderson helped to clarify 506 a number of issues. This document has also been improved by reviews, 507 comments and discussions originating from the IPv6, Internet Area, 508 and IETF communities. 510 Julien Laganier is partly funded by Ambient Networks, a research 511 project supported by the European Commission under its Sixth 512 Framework Program. The views and conclusions contained herein are 513 those of the authors and should not be interpreted as necessarily 514 representing the official policies or endorsements, either expressed 515 or implied, of the Ambient Networks project or the European 516 Commission. 518 9. References 520 9.1. Normative references 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, March 1997. 525 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 526 RFC 3972, March 2005. 528 9.2. Informative references 530 [Hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity 531 Indirection Infrastructure (Hi3)", November 2004. 533 [I-D.dupont-mip6-privacyext] 534 Dupont, F., "A Simple Privacy Extension for Mobile IPv6", 535 draft-dupont-mip6-privacyext-04 (work in progress), 536 July 2006. 538 [I-D.ietf-hip-base] 539 Moskowitz, R., "Host Identity Protocol", 540 draft-ietf-hip-base-07 (work in progress), February 2007. 542 [NodeID] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A 543 Node Identity Internetworking Architecture (NodeID)", 544 April 2006. 546 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 547 (SHA1)", RFC 3174, September 2001. 549 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 550 Hashes in Internet Protocols", RFC 4270, November 2005. 552 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 553 Architecture", RFC 4291, February 2006. 555 [RFC4773] Huston, G., "Administration of the IANA Special Purpose 556 IPv6 Address Block", RFC 4773, December 2006. 558 Authors' Addresses 560 Pekka Nikander 561 Ericsson Research Nomadic Lab 562 JORVAS FI-02420 563 Finland 565 Phone: +358 9 299 1 566 Email: pekka.nikander@nomadiclab.com 568 Julien Laganier 569 DoCoMo Communications Laboratories Europe GmbH 570 Landsberger Strasse 312 571 Munich 80687 572 Germany 574 Phone: +49 89 56824 231 575 Email: julien.ietf@laposte.net 577 Francis Dupont 578 CELAR 580 Email: Francis.Dupont@point6.net 582 Full Copyright Statement 584 Copyright (C) The IETF Trust (2007). 586 This document is subject to the rights, licenses and restrictions 587 contained in BCP 78, and except as set forth therein, the authors 588 retain all their rights. 590 This document and the information contained herein are provided on an 591 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 592 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 593 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 594 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 595 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 596 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 598 Intellectual Property 600 The IETF takes no position regarding the validity or scope of any 601 Intellectual Property Rights or other rights that might be claimed to 602 pertain to the implementation or use of the technology described in 603 this document or the extent to which any license under such rights 604 might or might not be available; nor does it represent that it has 605 made any independent effort to identify any such rights. Information 606 on the procedures with respect to rights in RFC documents can be 607 found in BCP 78 and BCP 79. 609 Copies of IPR disclosures made to the IETF Secretariat and any 610 assurances of licenses to be made available, or the result of an 611 attempt made to obtain a general license or permission for the use of 612 such proprietary rights by implementers or users of this 613 specification can be obtained from the IETF on-line IPR repository at 614 http://www.ietf.org/ipr. 616 The IETF invites any interested party to bring to its attention any 617 copyrights, patents or patent applications, or other proprietary 618 rights that may cover technology that may be required to implement 619 this standard. Please address the information to the IETF at 620 ietf-ipr@ietf.org. 622 Acknowledgment 624 Funding for the RFC Editor function is provided by the IETF 625 Administrative Support Activity (IASA).