idnits 2.17.1 draft-laganier-ipv6-khi-05.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 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 583. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 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 (September 8, 2006) is 6411 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) ** Downref: Normative reference to an Informational draft: draft-huston-ipv6-iana-specials (ref. 'I-D.huston-ipv6-iana-specials') ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-06 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Expires: March 12, 2007 J. Laganier 5 DoCoMo Euro-Labs 6 F. Dupont 7 CELAR 8 September 8, 2006 10 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers 11 (ORCHID) 12 draft-laganier-ipv6-khi-05 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 March 12, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 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. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Rationale and intent . . . . . . . . . . . . . . . . . . . 3 67 1.2. ORCHID properties . . . . . . . . . . . . . . . . . . . . 4 68 1.3. Expected use of ORCHIDs . . . . . . . . . . . . . . . . . 5 69 1.4. Action plan . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Cryptographic Hash Identifier Construction . . . . . . . . . . 5 72 3. Routing Considerations . . . . . . . . . . . . . . . . . . . . 6 73 3.1. Overlay Routing . . . . . . . . . . . . . . . . . . . . . 7 74 4. Collision Considerations . . . . . . . . . . . . . . . . . . . 8 75 5. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9.1. Normative references . . . . . . . . . . . . . . . . . . . 12 81 9.2. Informative references . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 83 Intellectual Property and Copyright Statements . . . . . . . . . . 14 85 1. Introduction 87 This document introduces Overlay Routable Cryptographic Hash 88 Identifiers (ORCHID), a new class of IP-address-like identifiers. 89 These identifiers are intended to be globally unique in a statistical 90 sense (see Section 4), non-routable at the IP layer, and routable at 91 some overlay layer. The identifiers are securely bound, via a secure 92 hash function, to the concatenation of an input bitstring and a 93 context tag. Typically, but not necessarily, the input bitstring 94 will include a suitably encoded public cryptographic key. 96 1.1. Rationale and intent 98 These identifiers are expected to be used at the existing IPv6 99 Application Programming Interfaces (API) and application protocols 100 between consenting hosts. They may be defined and used in different 101 contexts, suitable for different overlay protocols. Examples of 102 these include Host Identity Tags (HIT) in the Host Identity Protocol 103 (HIP) [I-D.ietf-hip-base] and Temporary Mobile Identifiers (TMI) for 104 Mobile IPv6 Privacy Extension [I-D.dupont-mip6-privacyext]. 106 As these identifiers are expected to be used alongside with IPv6 107 addresses at both applications and APIs, co-ordination is desired to 108 make sure that an ORCHID is not inappropriately taken for a vanilla 109 IPv6 address and vice versa. In practice, allocation of a separate 110 prefix for ORCHIDs seems to suffice, making them compatible with IPv6 111 addresses at the upper layers while simultaneously making it trivial 112 to prevent their usage at the IP layer. 114 While being technically possible to use ORCHIDs between consenting 115 hosts without any co-ordination with the IETF and the IANA, the 116 authors would consider such practice potentially dangerous. A 117 specific danger would be realised if the IETF community later decided 118 to use the ORCHID prefix for some different purpose. In that case, 119 hosts using the ORCHID prefix would be, for practical purposes, 120 unable to use the prefix for the other, new purpose. That would lead 121 to partial balkanisation of the Internet, similar to what has 122 happened as a result of historical hijackings of non-RFC1918 IPv4 123 addresses for private use. 125 The whole need for the proposed allocation grows from the desire to 126 be able to use ORCHIDs with existing applications and APIs. This 127 desire leads to the potential conflict, mentioned above. Resolving 128 the conflict requires the proposed allocation. 130 One can argue that the desire to use these kinds of identifiers via 131 existing APIs is architecturally wrong, and there is some truth in 132 that argument. Indeed, it would be more desirable to introduce a new 133 API and update all applications to use identifiers, rather than 134 locators, via that new API. That is exactly what we expect to happen 135 in the longer run. 137 However, given the current state of the Internet, we do not consider 138 it viable to introduce any changes that, at once, require 139 applications to be rewritten and host stacks to be updated. Rather 140 than that, we believe in piece-wise architectural changes that 141 require only one of the existing assets to be touched. ORCHIDs are 142 designed to address this situation: to allow people to experiment 143 with protocol stack extensions, such as secure overlay routing, HIP, 144 or Mobile IP privacy extensions, without requiring them to update 145 their applications. The goal is to facilitate large-scale 146 experiments with minimum user effort. 148 For example, there already exists, at the time of this writing, HIP 149 implementations that run fully in user space, using the operating 150 system to divert a certain part of the IPv6 address space to a user 151 level daemon for HIP processing. In practical terms, those 152 implementations are already now using a certain IPv6 prefix for 153 differentiating HIP identifiers from IPv6 addresses, allowing them 154 both to be used by the existing applications via the existing APIs. 156 This document argues for no more than allocating an experimental 157 prefix for such purposes, thereby paving the way for large-scale 158 experiments with cryptographic identifiers without the dangers caused 159 by address-space hijacking. 161 1.2. ORCHID properties 163 ORCHIDs are designed to have the following properties: 164 o Statistical uniqueness; see also Section 4 165 o Secure binding to the input parameters used in their generation 166 (i.e., the context identifier and a bitstring.) 167 o Conformance with the IPv6 global unicast address format as defined 168 in Section 2.5.4 of [RFC3513]. 169 o Aggregation under a single IPv6 prefix. Note that this is only 170 needed due to the co-ordination need, as indicated above. Without 171 such co-ordination need, the ORCHID name space could potentially 172 be completely flat. 173 o Non-routability at the IP layer, by design. 174 o Routability at some overlay layer, making them, from an 175 application point of view, semantically similar to IPv6 addresses. 177 As mentioned above, ORCHIDs are intended to be generated and used in 178 different contexts, as suitable for different mechanisms and 179 protocols. The context identifier is meant to be used to 180 differentiate between the different contexts; see Section 4 for a 181 discussion of the related API and kernel level implementation issues, 182 and Section 5 for the design choices explaining why the context 183 identifiers are used. 185 1.3. Expected use of ORCHIDs 187 Examples of identifiers and protocols that are expected to adopt the 188 ORCHID format include Host Identity Tags (HIT) in the Host Identity 189 Protocol [I-D.ietf-hip-base] and the Temporary Mobile Identifiers 190 (TMI) in the Simple Privacy Extension for Mobile IPv6 [I-D.dupont- 191 mip6-privacyext]. The format is designed to be extensible to allow 192 other experimental proposals to share the same 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 := SHA1( Hash Input ) 215 ORCHID := Prefix | Encode_n( 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. 229 We propose sharing the name space introduced for CGA 230 Type Tags; see RFC 3972 and 231 http://www.iana.org/assignments/cga-message-types 233 Encode_n( ): An extraction function which output is obtained by 234 extracting the middle 100-bits long bitstring from the 235 argument bitstring. 237 Prefix : A constant 28-bits long bitstring value, 238 TBD, assigned by IANA. 240 To form an ORCHID, two pieces of input data are needed. The first 241 piece can be any bitstring, but is typically expected to contain a 242 public cryptographic key and some other data. The second piece is a 243 context identifier, which is an 128-bits-long datum, allocated as 244 specified in Section 7. Each specific experiment (such as HIP HITs 245 or MIP6 TMIs) is expected to allocate their own, specific context 246 identifier. 248 The input bitstring and context identifier are concatenated to form 249 an input datum, which is then fed to the cryptographic hash function 250 SHA1 [RFC3174]. The result of the hash function is processed by an 251 encoding function, resulting in an n-bits-long value. This value is 252 prepended with the ORCHID prefix. The result is the ORCHID, an 128- 253 bits-long bitstring that can be used at the IPv6 APIs in hosts 254 participating to the particular experiment. 256 3. Routing Considerations 257 ORCHIDs are designed to serve as location independent end-point- 258 identifiers rather than IP-layer locators. Therefore, routers MAY be 259 configured not to forward any packets containing an ORCHID as a 260 source or a destination address. If the destination address is a 261 ORCHID but the source address is a valid unicast source address, 262 routers MAY be configured to generate an ICMP Destination 263 Unreachable, Administratively Prohibited message. 265 Due to the experimental nature of ORCHIDs, router software MUST NOT 266 include any special handling code for ORCHIDs. In other words, the 267 non-routability property of ORCHIDs, if implemented, MUST be 268 implemented via configuration and NOT by hard-wired software code. 269 At this time, it is RECOMMENDED that the default router configuration 270 does not handle ORCHIDs in any special way. In other words, there is 271 no need to touch existing or new routers due to this experiment. If 272 such reason should later appear, for example, due to a faulty 273 implementation leaking ORCHIDs to the IP layer, the prefix can be and 274 should be blocked by a simple configuration rule. 276 3.1. Overlay Routing 278 As mentioned multiple times, ORCHIDs are designed to be non-routable 279 at the IP layer. However, there are multiple ongoing research 280 efforts for creating various overlay routing and resolution 281 mechanisms for flat identifiers. For example, the Host Identity 282 Indirection Infrastructure (Hi3) [Hi3] and a Node Identity 283 Internetworking Architecture (NodeID) [NodeID] proposals outline ways 284 for using a Distributed Hash Table to forward HIP packets based on 285 the Host Identity Tag. 287 What is common to the various research proposals is that they create 288 a new kind of resolution or routing infrastructure on the top of the 289 existing Internet routing structure. In practical terms, they allow 290 delivery of packets based on flat, non-routable identifiers, 291 utilising information stored in a distributed data base. Usually the 292 database used is based on Distributed Hash Tables. This effectively 293 creates a new routing network on the top of the existing IP-based 294 routing network, capable of routing packets that are not addressed by 295 IP addresses but some other kind of identifiers. 297 Typical benefits from overlay routing include location independence, 298 more scalable multi-cast, any-cast, and multi-homing support than in 299 IP, and better DoS resistance than in the vanilla Internet. The main 300 drawback is typically an order of magnitude slower performance, 301 caused by an easily largish number of extra look-up or forwarding 302 steps needed. Consequently, in most practical cases the overlay 303 routing system is used only during initial protocol state set-up (cf. 304 TCP handshake), after which the communicating end-points exchange 305 packets directly with IP, bypassing the overlay network. 307 The net result of the typical overlay routing approaches is a 308 communication service whose basic functionality is comparable to that 309 of provided by classical IP but that provides considerably better 310 resilience that vanilla IP in dynamic networking environments. Some 311 experiments also introduce additional functionality, such as enhanced 312 security or ability to effectively route through several IP 313 addressing domains. 315 The authors expect ORCHIDs to become fully routable, via one or more 316 overlay systems, before the end of the experiment. 318 4. Collision Considerations 320 As noted above, the aim is that ORCHIDs are globally unique in a 321 statistical sense. That is, given the ORCHID referring to a given 322 entity, the probability of the same ORCHID being used to refer to 323 another entity elsewhere in the Internet must be sufficiently low so 324 that it can be ignored for most practical purposes. We believe that 325 the presented design meets this goal; see Section 5. 327 Consider next the very rare case that some ORCHID happens to refer to 328 two different entities at the same time at two different locations in 329 the Internet. Even in that case the probability of this fact 330 becoming visible (and therefore a matter of consideration) at any 331 single location in the Internet is negligible. For the vast majority 332 of cases the two simultaneous uses of the ORCHID will never cross 333 each other. However, while rare such collisions are still possible. 334 This section gives reasonable guidelines on how to mitigate the 335 consequences in the case such a collision happens. 337 As mentioned above, ORCHIDs are expected to be used at the legacy 338 IPv6 APIs between consenting hosts. The context ID is intended to 339 differentiate between the various experiments, or contexts, sharing 340 the ORCHID name space. However, the context ID is not present in the 341 ORCHID itself, but only in front of the input bitstring as an input 342 to the hash function. While this may lead to certain implementation- 343 related complications, we believe that the trade-off of allowing the 344 hash result part of an ORCHID being longer more than pays off the 345 cost. 347 Now, because ORCHIDs are not routable at the IP layer, in order to 348 send packets using ORCHIDs at the API level, the sending host must 349 have additional overlay state within the stack in order to determine 350 parameters (e.g. what locators) to use in the outgoing packet. An 351 underlying assumption here, and a matter of fact in the proposals 352 that the authors are aware of, is that there is an overlay protocol 353 for setting up and maintaining this additional state. It is assumed 354 that the state-set-up protocol carries the input bitstring, and that 355 the resulting ORCHID-related state in the stack can be associated 356 back with the appropriate context and state-set-up protocol. 358 Even though ORCHID collisions are expected to be extremely rare, two 359 kinds of collisions may still happen. First, it is possible that two 360 different input bitstrings within the same context may map to the 361 same ORCHID. In that case, the state-set-up mechanism is expected to 362 resolve the conflict, for example, by indicating to the peer that the 363 ORCHID in question is already in use. 365 A second type of collision may happen if two input bitstrings, used 366 in different usage contexts, map to the same ORCHID. In this case 367 the main confusion is about which context to use. In order to 368 prevent these types of collisions, it is RECOMMENDED that 369 implementations that simultaneously support multiple different 370 contexts maintain a node-wide unified database of known ORCHIDs, and 371 indicate a conflict if any of the mechanisms attempt to register a 372 ORCHID that is already in use. For example, if a given ORCHID is 373 already being used as a HIT in HIP, it cannot simultaneously be used 374 as a TMI in Mobile IP. Instead, if Mobile IP attempts to use the 375 ORCHID, it will be notified (by the kernel) that the ORCHID in 376 question is already in use. 378 5. Design Choices 380 The design of this name space faces two competing forces: 381 As many bits as possible should be preserved for the hash result. 382 It should be possible to share the name space between multiple 383 mechanisms. 385 The desire to have a long hash result requires the prefix to be as 386 short as possible, and to use few (if any) bits for additional 387 encoding. The present design takes this desire to the maxim: all the 388 bits beyond the prefix are used as hash output. This leaves no bits 389 in the ORCHID itself available for identifying the context. 390 Additionally, due to security considerations, the present design 391 REQUIRES that the hash function used in constructing ORCHIDs be 392 constant; see Section 6. 394 The authors explicitly considered including a hash extension 395 mechanism, similar to the one in CGA [RFC3972], but decided to leave 396 it out. There were two reasons: desire for simplicity, and the 397 somewhat unclear IPR situation around the hash extension mechanism. 398 If there is a future revision of this document, we strongly advise 399 the future authors to reconsider the decision. 401 The desire to allow multiple mechanism to share the name space has 402 been resolved by including the context identifier in the hash 403 function input. While this does not allow the mechanism to be 404 directly inferred from a ORCHID, it allows one to verify that a given 405 input bitstring and ORCHID belong to a given context, with high 406 probability; but see also Section 6. 408 6. Security Considerations 410 ORCHIDs are designed to be securely bound to the context identifier 411 and the bitstring used as the input parameters during their 412 generation. To provide this property, the ORCHID generation 413 algorithm relies on the second-preimage resistance (a.k.a. one-way) 414 property of the hash function used in the generation [RFC4270]. To 415 have this property, and to avoid collisions, it is important that the 416 allocated prefix is as short as possible, leaving as many bits as 417 possible for the hash output. 419 All mechanism using ORCHIDs MUST use exactly the same mechanism for 420 generating a ORCHID from the input bitstring. Allowing different 421 mechanisms, without explicitly encoding the mechanism in the ORCHID 422 itself, would allow so called bidding down attacks. That is, if 423 multiple different hash functions were allowed in constructing 424 ORCHIDs in a given shared name space, and if one of the hash 425 functions became insecure, that would allow attacks against even 426 those ORCHIDs that had been constructed using the other, still secure 427 hash functions. 429 Due to the desire to keep the hash output value as long as possible, 430 the present design allows only one method for constructing ORCHIDs 431 from input bitstrings. If other methods (perhaps using more secure 432 hash functions) are later needed, they MUST use a different prefix. 433 Consequently, the suggested method to react to the hash result 434 becoming too short, due to increased computational power or to the 435 used hash function becoming insecure due to advances in cryptology, 436 is to allocate a new prefix and cease to use the present one. 438 As of today, SHA1 [RFC3174] is considered as satisfying the second- 439 preimage resistance requirement Hash output of 100 bits is considered 440 to have a low enough probability of collisions. 442 In order to preserve a low enough probability of collisions (see 443 Section 4), each method MUST utilize a mechanism that makes sure that 444 the distinct input bitstrings are either unique or statistically 445 unique, within that context. There are several possible methods to 446 ensure that; for example, one can include into the input bitstring a 447 globally maintained counter value, a pseudo-random number of 448 sufficient entropy (minimum 100 bits), or a randomly generated public 449 cryptographic key. The Context ID makes sure that input bitstrings 450 from different contexts never overlap. These together make sure that 451 the probability of collisions is determined only by the probability 452 of natural collisions in the hash space and is not increased by a 453 possibility of colliding input bit strings. 455 7. IANA Considerations 457 IANA is requested to allocate a temporary non-routable prefix from 458 the IPv6 address space. As per [I-D.huston-ipv6-iana-specials], the 459 prefix shall be drawn out of the IANA Special Purpose Address Block, 460 namely 2001:0000::/23, in support of the experimental usage described 461 in this document. The allocation will require updating the IANA IPv6 462 Special Purpose Address Registry. 464 During the discussions related to this draft, it was suggested that 465 other identifier spaces may be later allocated from this block. 466 However, this document does not define such a policy or allocations. 468 The Context Identifier (or Context ID) is a randomly generated value 469 defining the usage context of a ORCHID. This document defines no 470 specific value. 472 We propose sharing the name space introduced for CGA Type Tags. 473 Hence, defining new values would follow the rules of Section 8 of 474 [RFC3972], i.e., on a First Come First Served basis. The policy will 475 require updating the policy for assignment in the CGA Message Type 476 name space. 478 8. Acknowledgments 480 Special thanks to Geoff Huston for his sharp but constructive critic 481 during the development of this memo. Tom Henderson helped to clarify 482 a number of issues. This document has also been improved by reviews, 483 comments and discussions originating from the IPv6, Internet Area, 484 and IETF communities. 486 Julien Laganier is partly funded by Ambient Networks, a research 487 project supported by the European Commission under its Sixth 488 Framework Program. The views and conclusions contained herein are 489 those of the authors and should not be interpreted as necessarily 490 representing the official policies or endorsements, either expressed 491 or implied, of the Ambient Networks project or the European 492 Commission. 494 9. References 496 9.1. Normative references 498 [I-D.huston-ipv6-iana-specials] 499 Huston, G., "Administration of the IANA Special Purpose 500 Address Block", draft-huston-ipv6-iana-specials-01 (work 501 in progress), December 2005. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 507 (SHA1)", RFC 3174, September 2001. 509 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 510 (IPv6) Addressing Architecture", RFC 3513, April 2003. 512 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 513 RFC 3972, March 2005. 515 9.2. Informative references 517 [Hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity 518 Indirection Infrastructure (Hi3)", November 2004. 520 [I-D.dupont-mip6-privacyext] 521 Dupont, F., "A Simple Privacy Extension for Mobile IPv6", 522 draft-dupont-mip6-privacyext-04 (work in progress), 523 July 2006. 525 [I-D.ietf-hip-base] 526 Moskowitz, R., "Host Identity Protocol", 527 draft-ietf-hip-base-06 (work in progress), June 2006. 529 [NodeID] Ahlgren, B., Arkko, J., Eggert, L., and J. Rajahalme, "A 530 Node Identity Internetworking Architecture (NodeID)", 531 April 2006. 533 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 534 Hashes in Internet Protocols", RFC 4270, November 2005. 536 Authors' Addresses 538 Pekka Nikander 539 Ericsson Research Nomadic Lab 540 JORVAS FI-02420 541 Finland 543 Phone: +358 9 299 1 544 Email: pekka.nikander@nomadiclab.com 546 Julien Laganier 547 DoCoMo Communications Laboratories Europe GmbH 548 Landsberger Strasse 312 549 Munich 80687 550 Germany 552 Phone: +49 89 56824 231 553 Email: julien.ietf@laposte.net 554 URI: http://www.docomolab-euro.com/ 556 Francis Dupont 557 CELAR 559 Email: Francis.Dupont@point6.net 561 Intellectual Property Statement 563 The IETF takes no position regarding the validity or scope of any 564 Intellectual Property Rights or other rights that might be claimed to 565 pertain to the implementation or use of the technology described in 566 this document or the extent to which any license under such rights 567 might or might not be available; nor does it represent that it has 568 made any independent effort to identify any such rights. Information 569 on the procedures with respect to rights in RFC documents can be 570 found in BCP 78 and BCP 79. 572 Copies of IPR disclosures made to the IETF Secretariat and any 573 assurances of licenses to be made available, or the result of an 574 attempt made to obtain a general license or permission for the use of 575 such proprietary rights by implementers or users of this 576 specification can be obtained from the IETF on-line IPR repository at 577 http://www.ietf.org/ipr. 579 The IETF invites any interested party to bring to its attention any 580 copyrights, patents or patent applications, or other proprietary 581 rights that may cover technology that may be required to implement 582 this standard. Please address the information to the IETF at 583 ietf-ipr@ietf.org. 585 Disclaimer of Validity 587 This document and the information contained herein are provided on an 588 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 589 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 590 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 591 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 592 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 593 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 595 Copyright Statement 597 Copyright (C) The Internet Society (2006). This document is subject 598 to the rights, licenses and restrictions contained in BCP 78, and 599 except as set forth therein, the authors retain all their rights. 601 Acknowledgment 603 Funding for the RFC Editor function is currently provided by the 604 Internet Society.