idnits 2.17.1 draft-laganier-ipv6-khi-01.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 247: '...r locators. Therefore, routers MAY be...' RFC 2119 keyword, line 251: '... routers MAY be configured to genera...' RFC 2119 keyword, line 254: '...e of ORCHIDs, router software MUST NOT...' RFC 2119 keyword, line 256: '...ty of ORCHIDs, if implemented, MUST be...' RFC 2119 keyword, line 258: '...this time, it is RECOMMENDED that the ...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == 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 (March 1, 2006) is 6631 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) == Unused Reference: 'RFC3587' is defined on line 525, but no explicit reference was found in the text -- No information found for draft-irtf-cfrg-sha1-ime - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.irtf-cfrg-sha1-ime' ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) == Outdated reference: A later version (-04) exists of draft-dupont-mip6-privacyext-03 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-00 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: September 2, 2006 J. Laganier 5 DoCoMo Euro-Labs 6 F. Dupont 7 CELAR 8 March 1, 2006 10 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers 11 (ORCHID) 12 draft-laganier-ipv6-khi-01 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. 20 This document may not be modified, and derivative works of it may not 21 be created, except to publish it as an RFC and to translate it into 22 languages other than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 2, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document introduces Overlay Routable Cryptographic Hash 49 Identifiers (ORCHID) as a new, experimental class of IPv6-address- 50 like identifiers. These identifiers are intended to be used as end- 51 point identifiers at applications and APIs and not as identifiers for 52 network location at the IP layer, i.e., locators. They are designed 53 to appear as application layer entities and at the existing IPv6 54 APIs, but they should not appear in actual IPv6 headers. To make 55 them more like vanilla IPv6 addresses, they are expected to be 56 routable at an overlay level. Consequently, while they are 57 considered as non-routable addresses from the IPv6 layer point of 58 view, all existing IPv6 applications are expected to be able to use 59 them in a manner compatible with current IPv6 addresses. 61 This document requests IANA to allocate a temporary prefix out of the 62 IPv6 addressing space for Overlay Routable Cryptographic Hash 63 Identifiers. 65 1. Introduction 67 This document introduces Overlay Routable Cryptographic Hash 68 Identifiers (ORCHID), a new class of IP-address-like identifiers. 69 These identifiers are intended to be globally unique in a statistical 70 sense (see Section 4), non-routable at the IP layer, and routable at 71 some overlay layer. The identifiers are securely bound, via a secure 72 hash function, to the concatenation of an input bitstring and a 73 context tag. Typically, but not necessarily, the input bitstring 74 will include a suitably encoded public cryptographic key. 76 1.1. Rationale and intent 78 These identifiers are expected to be used at the existing IPv6 APIs 79 and application protocols between consenting hosts. They may be 80 defined and used in different contexts, suitable for different 81 overlay protocols. Examples of these include Host Identity Tags 82 (HIT) in the Host Identity Protocol (HIP) [I-D.ietf-hip-base] and 83 Temporary Mobile Identifiers (TMI) for Mobile IPv6 Privacy Extension 84 [I-D.dupont-mip6-privacyext]. 86 As these identifiers are expected to be used alongside with IPv6 87 addresses at both applications and APIs, co-ordination is desired to 88 make sure that an ORCHID is not inappropriately taken for a vanilla 89 IPv6 address and vice versa. In practice, allocation of a separate 90 prefix for ORCHIDs seems to suffice, making them compatible with IPv6 91 addresses at the upper layers while simultaneously making it trivial 92 to prevent their usage at the IP layer. 94 While being technically possible to use ORCHIDs between consenting 95 hosts without any co-ordination with the IETF and the IANA, the 96 authors would consider such practice potentially dangerous. A 97 specific danger would be realised if the IETF community later decided 98 to use the ORCHID prefix for some different purpose. In that case, 99 hosts using the ORCHID prefix would be, for practical purposes, 100 unable to use the prefix for the other, new purpose. That would lead 101 to partial balkanisation of the Internet, similar to what has 102 happened as a result of historical hijackings of non-RFC1918 IPv4 103 addresses for private use. 105 The whole need for the proposed allocation grows from the desire to 106 be able to use ORCHIDs with existing applications and APIs. This 107 desire leads to the potential conflict, mentioned above. Resolving 108 the conflict requires the proposed allocation. 110 One can argue that the desire to use these kinds of identifiers via 111 existing APIs is architecturally wrong, and there is some truth in 112 that argument. Indeed, it would be more desirable to introduce a new 113 API and update all applications to use identifiers, rather than 114 locators, via that new API. That is exactly what we expect to happen 115 in the longer run. 117 However, given the current state of the Internet, we do not consider 118 it viable to introduce any changes that, at once, require 119 applications to be rewritten and host stacks to be updated. Rather 120 than that, we believe in piece-wise architectural changes that 121 require only one of the existing assets to be touched. ORCHIDs are 122 designed to address this situation: to allow people to experiment 123 with protocol stack extensions, such as secure overlay routing, HIP, 124 or Mobile IP privacy extensions, without requiring them to update 125 their applications. The goal is to facilitate large-scale 126 experiments with minimum user effort. 128 For example, there already exists, at the time of this writing, HIP 129 implementations that run fully in user space, using the operating 130 system to divert a certain part of the IPv6 address space to a user 131 level daemon for HIP processing. In practical terms, those 132 implementations are already now using a certain IPv6 prefix for 133 differentiating HIP identifiers from IPv6 addresses, allowing them 134 both to be used by the existing applications via the existing APIs. 136 This document argues for no more than allocating an experimental 137 prefix for such purposes, thereby paving the way for large-scale 138 experiments with cryptographic identifiers without the dangers caused 139 by address-space hijacking. 141 1.2. ORCHID properties 143 ORCHIDs are designed to have the following properties: 145 o Statistically uniqueness; see also Section 4 146 o Secure binding to the input parameters used in their generation 147 (i.e., the context identifier and a bitstring.) 148 o Conformance with the IPv6 global unicast address format as defined 149 in Section 2.5.4 of [RFC3513]. 150 o Aggregation under a single IPv6 prefix. Note that this is only 151 needed due to the co-ordination need, as indicated above. Without 152 such co-ordination need, the ORCHID name space could potentially 153 be completely flat. 154 o Non-routability at the IP layer, by design. 155 o Routability at some overlay layer, making them, from an 156 application point of view, semantically similar to IPv6 addresses. 158 As mentioned above, ORCHIDs are intended to be generated and used in 159 different contexts, as suitable for different mechanisms and 160 protocols. The context identifier is meant to be used to 161 differentiate between the different contexts; see Section 4 for a 162 discussion of the related API and kernel level implementation issues, 163 and Section 5 for the design choices explaining why the context 164 identifiers are used. 166 1.3. Expected use of ORCHIDs 168 Examples of identifiers and protocols that are expected to adopt the 169 ORCHID format include Host Identity Tags (HIT) in the Host Identity 170 Protocol [I-D.ietf-hip-base] and the Temporary Mobile Identifiers 171 (TMI) in the Simple Privacy Extension for Mobile IPv6 [I-D.dupont- 172 mip6-privacyext]. The format is designed to be extensible to allow 173 other experimental proposals to share the same name space. 175 1.4. Action plan 177 This document requests IANA to allocate an experimental prefix out of 178 the IPv6 addressing space for Overlay Routable Cryptographic Hash 179 Identifiers. 181 2. Cryptographic Hash Identifier Construction 183 An ORCHID is generated using the algorithm below. The algorithm 184 takes a bitstring and a context identifier as input and produces an 185 ORCHID as output. 187 Input := any bitstring 188 Hash Input := Context ID | Input 189 Hash := SHA1( Expand( Hash Input ) ) 190 ORCHID := Prefix | Encode_n( Hash ) 192 where: 194 | : Denotes concatenation of bitstrings 196 Input : A bitstring unique or statistically unique within a 197 given context. The bitstring is intended to be 198 associated with the to-be-created ORCHID, in the 199 given context. 201 Context ID : A randomly generated value defining the expected usage 202 context for the particular ORCHID. 204 As a baseline (TO BE DISCUSSED), we propose sharing the 205 name space introduced for CGA Type Tags; see 206 http://www.iana.org/assignments/cga-message-types 207 and RFC 3972. 209 Expand( ) : An expansion function designed to overcome recent 210 attacks on SHA-1. 212 As a baseline (TO BE DISCUSSED), we propose using the 213 method defined in [I-D.irtf-cfrg-sha1-ime]. 215 Alternatively, it would be possible to use some other 216 hash function, such as SHA-256, instead of SHA-1. 218 Encode_n( ): An extraction function which output is obtained by 219 extracting an -bits-long bitstring from the argument 220 bitstring. 222 As a baseline (TO BE DISCUSSED), we propose taking 223 middlemost bits from the SHA1 output. 225 Prefix : A constant ( 128 - bits long ) bitstring value, 226 TBD, assigned by IANA. 228 To form an ORCHID, two pieces of input data are needed. The first 229 piece can be any bitstring, but is typically expected to contain a 230 public cryptographic key and some other data. The second piece is a 231 context identifier, which is an 128-bits-long datum, allocated as 232 specified in Section 7. Each specific experiment (such as HIP HITs 233 or MIP6 TMIs) is expected to allocate their own, specific context 234 identifier. 236 The input bitstring and context identifier are concatenated to form 237 an input datum, which is then fed to a cryptographic hash function. 238 The result of the hash function is processed by an encoding function, 239 resulting in an n-bits-long value. This value is prepended with the 240 ORCHID prefix. The result is the ORCHID, an 128-bits-long bitstring 241 that can be used at the IPv6 APIs in hosts participating to the 242 particular experiment. 244 3. Routing Considerations 246 ORCHIDs are designed to serve as location independent end-point- 247 identifiers rather than IP-layer locators. Therefore, routers MAY be 248 configured not to forward any packets containing an ORCHID as a 249 source or a destination address. If the destination address is a 250 ORCHID but the source address is a valid unicast source address, 251 routers MAY be configured to generate an ICMP Destination 252 Unreachable, Administratively Prohibited message. 254 Due to the experimental nature of ORCHIDs, router software MUST NOT 255 include any special handling code for ORCHIDs. In other words, the 256 non-routability property of ORCHIDs, if implemented, MUST be 257 implemented via configuration and NOT by hard-wired software code. 258 At this time, it is RECOMMENDED that the default router configuration 259 does not handle ORCHIDs in any special way. In other words, there is 260 no need to touch existing or new routers due to this experiment. If 261 such reason should later appear, for example, due to a faulty 262 implementation leaking ORCHIDs to the IP layer, the prefix can be and 263 should be blocked by a simple configuration rule. 265 3.1. Overlay Routing 267 As mentioned multiple times, ORCHIDs are designed to be non-routable 268 at the IP layer. However, there are multiple ongoing research 269 efforts for creating various overlay routing and resolution 270 mechanisms for flat identifiers. For example, the Host Identity 271 Indirection Infrastructure (Hi3) [hi3] proposal outlines a way for 272 using a Distributed Hash Table to forward HIP packets based on the 273 Host Identity Tag. 275 What is common to the various research proposals is that they create 276 a new kind of resolution or routing infrastructure on the top of the 277 existing Internet routing structure. In practical terms, they allow 278 delivery of packets based on flat, non-routable identifiers, 279 utilising information stored in a distributed data base. Usually the 280 database used is based on Distributed Hash Tables. This effectively 281 creates a new routing network on the top of the existing IP-based 282 routing network, capable of routing packets that are not addressed by 283 IP addresses but some other kind of identifiers. 285 Typical benefits from overlay routing include location independence, 286 more scalable multi-cast, any-cast, and multi-homing support than in 287 IP, and better DoS resistance than in the vanilla Internet. The main 288 drawback is typically an order of magnitude slower performance, 289 caused by an easily largish number of extra look-up or forwarding 290 steps needed. Consequently, in most practical cases the overlay 291 routing system is used only during initial protocol state set-up (cf. 292 TCP handshake), after which the communicating end-points exchange 293 packets directly with IP, bypassing the overlay network. 295 The net result of the typical overlay routing approaches is a 296 communication service whose basic functionality is comparable to that 297 of provided by classical IP but that provides considerably better 298 resilience that vanilla IP in dynamic networking environments. Some 299 experiments also introduce additional functionality, such as enhanced 300 security or ability to effectively route through several IP 301 addressing domains. 303 The authors expect ORCHIDs to become fully routable, via one or more 304 overlay systems, before the end of the experiment. 306 4. Collision Considerations 308 As noted above, the aim is that ORCHIDs are globally unique in a 309 statistical sense. That is, given the ORCHID referring to a given 310 entity, the probability of the same ORCHID being used to refer to 311 another entity elsewhere in the Internet must be sufficiently low so 312 that it can be ignored for most practical purposes. We believe that 313 the presented design meets this goal; see Section 5. 315 Consider next the very rare case that some ORCHID happens to refer to 316 two different entities at the same time at two different locations in 317 the Internet. Even in that case the probability of this fact 318 becoming visible (and therefore a matter of consideration) at any 319 single location in the Internet is negligible. For the vast majority 320 of cases the two simultaneous uses of the ORCHID will never cross 321 each other. However, while rare such collisions are still possible. 322 This section gives reasonable guidelines on how to mitigate the 323 consequences in the case such a collision happens. 325 As mentioned above, ORCHIDs are expected to be used at the legacy 326 IPv6 APIs between consenting hosts. The context ID is intended to 327 differentiate between the various experiments, or contexts, sharing 328 the ORCHID name space. However, the context ID is not present in the 329 ORCHID itself, but only in front of the input bitstring as an input 330 to the hash function. While this may lead to certain implementation- 331 related complications, we believe that the trade-off of allowing the 332 hash result part of an ORCHID being longer more than pays off the 333 cost. 335 Now, because ORCHIDs are not routable at the IP layer, in order to 336 send packets using ORCHIDs at the API level, the sending host must 337 have additional overlay state within the stack in order to determine 338 parameters (e.g. what locators) to use in the outgoing packet. An 339 underlying assumption here, and a matter of fact in the proposals 340 that the authors are aware of, is that there is an overlay protocol 341 for setting up and maintaining this additional state. It is assumed 342 that the state-set-up protocol carries the input bitstring, and that 343 the resulting ORCHID-related state in the stack can be associated 344 back with the appropriate context and state-set-up protocol. 346 Even though ORCHID collisions are expected to be extremely rare, two 347 kinds of collisions may still happen. First, it is possible that two 348 different input bitstrings within the same context may map to the 349 same ORCHID. In that case, the state-set-up mechanism is expected to 350 resolve the conflict, for example, by indicating to the peer that the 351 ORCHID in question is already in use. 353 A second type of collision may happen if two input bitstrings, used 354 in different usage contexts, map to the same ORCHID. In this case 355 the main confusion is about which context to use. In order to 356 prevent these types of collisions, it is RECOMMENDED that 357 implementations that simultaneously support multiple different 358 contexts maintain a node-wide unified database of known ORCHIDs, and 359 indicate a conflict if any of the mechanisms attempt to register a 360 ORCHID that is already in use. For example, if a given ORCHID is 361 already being used as a HIT in HIP, it cannot simultaneously be used 362 as a TMI in Mobile IP. Instead, if Mobile IP attempts to use the 363 ORCHID, it will be notified (by the kernel) that the ORCHID in 364 question is already in use. 366 5. Design Choices 368 The design of this name space faces two competing forces: 369 As many bits as possible should be preserved for the hash result. 370 It should be possible to share the name space between multiple 371 mechanisms. 373 The desire to have a long hash result requires the prefix to be as 374 short as possible, and to use few (if any) bits for additional 375 encoding. The present design takes this desire to the maxim: all the 376 bits beyond the prefix are used as hash output. This leaves no bits 377 in the ORCHID itself available for identifying the context. 378 Additionally, due to security considerations, the present design 379 REQUIRES that the hash function used in constructing ORCHIDs be 380 constant; see Section 6. 382 The authors explicitly considered including a hash extension 383 mechanism, similar to the one in CGA [RFC3972], but decided to leave 384 it out. There were two reasons: desire for simplicity, and the 385 somewhat unclear IPR situation around the hash extension mechanism. 386 If there is a future revision of this document, we strongly advise 387 the future authors to reconsider the decision. 389 The desire to allow multiple mechanism to share the name space has 390 been resolved by including the context identifier in the hash 391 function input. While this does not allow the mechanism to be 392 directly inferred from a ORCHID, it allows one to verify that a given 393 input bitstring and ORCHID belong to a given context, with high 394 probability; but see also Section 6. 396 6. Security Considerations 398 ORCHIDs are designed to be securely bound to the context identifier 399 and the bitstring used as the input parameters during their 400 generation. To provide this property, the ORCHID generation 401 algorithm relies on the second-preimage resistance (a.k.a. one-way) 402 property of the hash function used in the generation [RFC4270]. To 403 have this property, and to avoid collisions, it is important that the 404 allocated prefix is as short as possible, leaving as many bits as 405 possible for the hash output. 407 All mechanism using ORCHIDs MUST use exactly the same mechanism for 408 generating a ORCHID from the input bitstring. Allowing different 409 mechanisms, without explicitly encoding the mechanism in the ORCHID 410 itself, would allow so called bidding down attacks. That is, if 411 multiple different hash functions were allowed in constructing 412 ORCHIDs in a given shared name space, and if one of the hash 413 functions became insecure, that would allow attacks against even 414 those ORCHIDs that had been constructed using the other, still secure 415 hash functions. 417 Due to the desire to keep the hash output value as long as possible, 418 the present design allows only one method for constructing ORCHIDs 419 from input bitstrings. If other methods (perhaps using more secure 420 hash functions) are later needed, they MUST use a different prefix. 421 Consequently, the suggested method to react to the hash result 422 becoming too short, due to increased computational power or to the 423 used hash function becoming insecure due to advances in cryptology, 424 is to allocate a new prefix and cease to use the present one. 426 As of today, SHA-1 applied in conjunction with a proper expansion 427 function of the hash input is considered as satisfying the second- 428 preimage resistance requirement [I-D.irtf-cfrg-sha1-ime]. Hash 429 output of at least 100 bits, but preferably up to 120 bits, is 430 considered to have a low enough probability of collisions. 432 In order to preserve a low enough probability of collisions (see 433 Section 4), each method MUST utilize a mechanism that makes sure that 434 the distinct input bitstrings are either unique or statistically 435 unique, within that context. There are several possible methods to 436 ensure that; for example, one can include into the input bitstring a 437 globally maintained counter value, a pseudo-random number of 438 sufficient entropy (minimum 120 bits), or a randomly generated public 439 cryptographic key. The Context ID makes sure that input bitstrings 440 from different contexts never overlap. These together make sure that 441 the probability of collisions is determined only by the probability 442 of natural collisions in the hash space and is not increased by a 443 possibility of colliding input bit strings. 445 7. IANA Considerations 447 IANA is requested to allocate a temporary non-routable prefix from 448 the IPv6 address space. As per Sections 2.5.1 and 2.5.4 of 449 [RFC3513], the prefix must be allocated from the 0000::/3 block, 450 since ORCHIDs do not have a 64-bit interface identifier part. The 451 allocation will require updating 452 http://www.iana.org/assignments/ipv6-address-space 454 As a baseline (TO BE DISCUSSED), we propose an 8-bit prefix to be 455 allocated from the 1000::/4 block. During the discussions related to 456 this draft, it was suggested that other identifier spaces may be 457 later allocated from this block. However, this document does not 458 define such a policy or allocations. 460 The Context Identifier (or Context ID) is a randomly generated value 461 defining the usage context of a ORCHID. This document defines no 462 specific value. 464 As a baseline (TO BE DISCUSSED), we propose sharing the name space 465 introduced for CGA Type Tags. Hence, defining new values would 466 follow the rules of Section 8 of [RFC3972], i.e., on a First Come 467 First Served basis. The policy will require updating the policy for 468 http://www.iana.org/assignments/cga-message-types 470 8. Acknowledgments 472 Julien Laganier is partly funded by Ambient Networks, a research 473 project supported by the European Commission under its Sixth 474 Framework Program. 476 Special thanks to Geoff Huston for his sharp but constructive critic 477 during the development of this memo. Tom Henderson helped to clarify 478 a number of issues. 480 9. Version history 482 9.1. -00 to -01 484 The name Keyed Hash Identifier (KHI) was replaced with Overlay 485 Routable Cryptographic Hash Identifier (ORCHID). However, the draft 486 name was not changed. 488 More text added to explain the rationale behind the proposed 489 allocation. 491 Text changed to emphasise that while ORCHIDs are expected to be non- 492 routable at the IP-layer, they are expected to become fully routable 493 and/or resolvable at some upper, overlay layer, thereby making their 494 basic semantics fully compatible with IPv6 addresses. 496 Removed the proposed expiration date. If such an expiration date is 497 needed, it can be added later during the discussions. 499 10. References 501 10.1. Normative references 503 [I-D.irtf-cfrg-sha1-ime] 504 Blumenthal, U., Jutla, C., and A. Patthak, "SHA1-IME: A 505 SHA-1 Variant with Provably Good Message Expansion Code", 506 November 2005. 508 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 509 (IPv6) Addressing Architecture", RFC 3513, April 2003. 511 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 512 RFC 3972, March 2005. 514 10.2. Informative references 516 [I-D.dupont-mip6-privacyext] 517 Dupont, F., "A Simple Privacy Extension for Mobile IPv6", 518 draft-dupont-mip6-privacyext-03 (work in progress), 519 January 2006. 521 [I-D.ietf-hip-base] 522 Moskowitz, R., "Host Identity Protocol", 523 draft-ietf-hip-base-00 (work in progress), June 2004. 525 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 526 Unicast Address Format", RFC 3587, August 2003. 528 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic 529 Hashes in Internet Protocols", RFC 4270, November 2005. 531 [hi3] Nikander, P., Arkko, J., and B. Ohlman, "Host Identity 532 Indirection Infrastructure (Hi3)", Nov 2004. 534 Authors' Addresses 536 Pekka Nikander 537 Ericsson Research Nomadic Lab 538 JORVAS FI-02420 539 FINLAND 541 Phone: +358 9 299 1 542 Email: pekka.nikander@nomadiclab.com 544 Julien Laganier 545 DoCoMo Communications Laboratories Europe GmbH 546 Landsberger Strasse 312 547 Munich 80687 548 Germany 550 Phone: +49 89 56824 231 551 Email: julien.ietf@laposte.net 552 URI: http://www.docomolab-euro.com/ 554 Francis Dupont 555 CELAR 557 Email: Francis.Dupont@point6.net 559 Intellectual Property Statement 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Disclaimer of Validity 585 This document and the information contained herein are provided on an 586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 588 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 589 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 590 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Copyright Statement 595 Copyright (C) The Internet Society (2006). This document is subject 596 to the rights, licenses and restrictions contained in BCP 78, and 597 except as set forth therein, the authors retain all their rights. 599 Acknowledgment 601 Funding for the RFC Editor function is currently provided by the 602 Internet Society.