idnits 2.17.1 draft-ietf-shim6-functional-dec-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 603. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 593. ** 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 221: '...ihoming protocol MUST do an initial (o...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 272 has weird spacing: '...context estab...' == Line 278 has weird spacing: '... Since both ...' -- 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 (July 15, 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3041 (ref. '1') (Obsoleted by RFC 4941) -- No information found for draft-multi6dt-failure-detection - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bagnulo 3 Internet-Draft UC3M 4 Expires: January 16, 2006 J. Arkko 5 Ericsson 6 July 15, 2005 8 Functional decomposition of the multihoming protocol 9 draft-ietf-shim6-functional-dec-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 16, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 In this note we will present a functional decomposition of the 43 multihomig protocol i.e. the protocol for preserving established 44 communications in multihomed environments. We will do so by 45 describing a protocol walkthrough, presenting which functions have to 46 be performed at each stage and the messages required to accomplish 47 them. The functional decomposition presented in this draft is based 48 on the general functional analysis of multihoming approaches 49 presented in [3]. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Initial contact . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1 Initial contact . . . . . . . . . . . . . . . . . . . . . 4 56 2.2 Failure during startup . . . . . . . . . . . . . . . . . . 4 57 3. Capabilities detection and shim host-pair context 58 establishment . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1 Capabilities detection . . . . . . . . . . . . . . . . . . 6 60 3.1.1 Node Configuration . . . . . . . . . . . . . . . . . . 6 61 3.1.2 DNS Configuration . . . . . . . . . . . . . . . . . . 6 62 3.1.3 Host-Based Dynamic Discovery . . . . . . . . . . . . . 7 63 3.1.4 Timing . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2 Shim host-pair context establishment . . . . . . . . . . . 8 65 3.2.1 Security Information . . . . . . . . . . . . . . . . . 9 66 3.2.2 DoS protection. . . . . . . . . . . . . . . . . . . . 9 67 3.2.3 Resulting shim host-pair context establishement 68 exchange . . . . . . . . . . . . . . . . . . . . . . . 10 69 4. Locator set management . . . . . . . . . . . . . . . . . . . . 11 70 4.1 Security of the exchange for adding locators . . . . . . . 11 71 4.2 Security of the exchange for deleting locators . . . . . . 11 72 5. Re-homing procedure . . . . . . . . . . . . . . . . . . . . . 13 73 5.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Removal of shim session state . . . . . . . . . . . . . . . . 15 75 6.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 7. Security considerations . . . . . . . . . . . . . . . . . . . 16 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 9.1 Normative References . . . . . . . . . . . . . . . . . . . 18 80 9.2 Informative References . . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 82 Intellectual Property and Copyright Statements . . . . . . . . 19 84 1. Introduction 86 In this note we will present a functional decomposition of the 87 multihoming protocol i.e. the protocol for preserving established 88 communications in multihomed environments. We will do so by 89 describing a protocol walkthrough, presenting which functions have to 90 be performed at each stage and the messages required to accomplish 91 them. The functional decomposition presented in this draft is based 92 on the general functional analysis of multihoming approaches 93 presented in [3]. 95 We will first present some possible procedures for the initial 96 contact and session state establishment. Next, we will consider the 97 management of the available locator set. Then, we will consider the 98 re-homing of an ongoing communication and finally we will deal with 99 session state removal. 101 This note is agnostic to the security mechanism used in protecting 102 the control messages related to multihoming. However, when it is 103 deemed necessary, a security analysis that attempts to understand the 104 security required for the message exchange will be included. 106 2. Initial contact 108 2.1 Initial contact 110 During the initial contact, the minimum information that has to be 111 exchanged by the two communicating nodes is: the identifiers that 112 have to be presented to the upper layers, and a reachable locator for 113 each node. In the case that the the identifier presented to the 114 upper layers is a valid reachable locator, then only this address 115 that will perform both roles has to be exchanged. If this is the 116 case, no special multihoming features are required. This means that 117 as long as the identifier and the locator used are the same IPv6 118 address, there is no need to perform any special multihoming exchange 119 for the initial contact and regular IPv6 can be used. However, if an 120 identifier that is different from the locator used for exchanging the 121 initial packet is used, then the multihoming protocol has to be used 122 even to perform the initial contact between the two nodes, starting 123 by the capabilities detection procedure described in section 2.1.2. 125 2.2 Failure during startup 127 In the case that the locator used for initial contact is unreachable, 128 there are two possible approaches that can be followed: 130 One approach is to simply retry the initial contact using a 131 different locator. This means that the initial contact procedure 132 is started all over again, using a different locator. This 133 approach is likely to be the one required when the shim-capable 134 host is establishing communications with legacy hosts that don't 135 support the multihoming protocol. In this case, the address 136 included in the initial packet is both the locator and the 137 identifier and if it is not reachable, an alternative address has 138 to be used. Such retrying would by default occur at the 139 application layer, which is aware of the multiple addresses. It 140 might be possible to optimize this should the transport protocol 141 be made aware of the multiple addresses. 143 Another approach is to change locator while preserving the 144 identifier. This approach is not supported by legacy IPv6 nodes, 145 so the multihoming protocol has to be used in this approach. 146 However, this scheme would allow to recover from failures on 147 locators used for initial contact in a upper layer transparent 148 fashion. However, if this is the case, the full multihoming 149 protocol has to be used for initial contact, starting by the 150 capabilities detection procedure described next. 152 3. Capabilities detection and shim host-pair context establishment 154 When a shim capable host desires to obtain the enhanced features 155 provided by the multihoming protocol in the communications 156 established with a given peer node, it has to first determine if shim 157 capabilities are available in the peer node and second establish a 158 shim host-pair context, as defined in [5].In this section we will 159 analyze the different mechanisms to perform both actions. 161 3.1 Capabilities detection 163 This section presents a number of possible approaches for the 164 capability detection, and analyzes their properties. 166 3.1.1 Node Configuration 168 A simplistic approach would be to require the shim capability from 169 peers, if a node supports the shim and has been configured to use it. 170 However, this would severely limit the ability of the node to 171 communicate until the feature is widely supported. 173 3.1.2 DNS Configuration 175 A better configuration-based approach would be to add some 176 information to the DNS to tell the peers whether the target node 177 supports the shim or not. For instance, a new RR record could be 178 used. This way each node could dynamically decide whether it can run 179 the shim with the peer or not. This could often be known before 180 actually attempting to communicate. 182 This approach requires that every node that wishes to use the shim 183 must have a DNS entry. In addition, the ability to use shim and the 184 information stored to the DNS may not always be synchronized. For 185 instance, changing the operating system might remove shim capability 186 from a particular user's machine, leading to a need for updating DNS. 187 This synchronization problem could be avoided by the use of Dynamic 188 DNS updates -- with the implied requirements for setting up a 189 security association between the DNS servers and client machines. 191 Similarly, the manually updated DNS approach requires support for 192 Dynamic DNS [2] where RFC 3041 [1] or other dynamically changing 193 addresses are used. 195 Finally, all DNS-based approaches suffer from an an administrative 196 split between the actual nodes and the ones storing data about them; 197 establishing Dynamic DNS or manual updates may be hard for a private 198 subscriber of a large operator, for instance. 200 On the other hand, a DNS-based mechanism may work well if the chosen 201 Multi6 protocol is based on the use of DNS, such as in NOID [4]. 203 3.1.3 Host-Based Dynamic Discovery 205 A host-based mechanism discovers the shim-capability directly between 206 the communicating nodes. Two variants of this mechanism exist: 208 Independent 210 This mechanism adds a message pair for the discovery. If the peer 211 responds to the message that the initiator sends, then both nodes 212 know that they support the shim. 214 Integrated 216 This mechanism uses the rest of the shim signaling, doing both 217 actual shim work and capability detection at the same time. 219 In the interest of reducing number of initial communications latency, 220 the second approach would be preferrable. We also argue that a 221 multihoming protocol MUST do an initial (or at least an early) 222 signaling exchange in any case. This is because the nodes need to 223 discover alternate locators PRIOR to a multihoming event disabling 224 the current ones. For instance, lets assume hosts A and B 225 communicate over two separate links without going through the 226 Internet. Lets further assume the nodes use plain IPv6 at the 227 beginning without shim, and use one of the links and its prefix P for 228 communication, with addresses P::A and P::B. If this link goes down, 229 the obvious multihoming solution would be to switch to Q::A and Q::B, 230 the other link and its prefix. However, neither side is aware that 231 the other node is available under the Q prefix, so communications can 232 not continue. 234 On the other hand, the integrated approach makes the initial packets 235 larger which is a disadvantage when the peer does not support 236 multihoming. However, we do not expect the shim part of the initial 237 packets to be large or contain many addresses on the average, so this 238 seems like a good engineering tradeoff. 240 3.1.4 Timing 242 Capability detection needs to occurr prior to or at the same time as 243 Multi6 state is created between peers. If the capabilities are 244 stored in DNS, a convenient time to look this information is at the 245 time a DNS query is made (even if it may not always lead to an actual 246 communication attempt later). If host-based discovery is used, the 247 best time to perform it is in the initial Multi6 exchange packets. 249 The capabilities of the peer must be remembered while the shim state 250 exists; the state persistence is discussed in Section 5 of [4]. The 251 capabilities should preferrably be cached even beyond this, in order 252 to avoid discovering the capabilities and/or locators of peers when 253 they are contacted again within a small time frame. 255 Negative caching should be used to remember the peers which do not 256 support multihoming. Depending on the type of the chosen capability 257 detection mechanisms, this state is indexed either by an IP address 258 or by both IP addresses and identifiers. The latter becomes 259 necessary if DNS configuration indicates an identifier and Multi6 260 cabability, but the node refuses to communicate using the shim. 262 3.2 Shim host-pair context establishment 264 Once that the the shim protocol support is confirmed, the ULP 265 identifiers associated to the shim host-pair context need to be 266 defined. 268 With respect to locator exchange, it is clear that at least one 269 locator (the one included in the source address field of the packet) 270 is exchanged in the initial contact. The question would be if 271 additional locators are needed to be exchanged during the shim host- 272 pair context establishment phase. Several considerations should be 273 taken into account at this point: On one hand, the capability of 274 recovering from an outage may depend on knowing alternative locators 275 of the other node. It is clear that a node is aware of its own 276 locators, so a possible approach would be that if a failure is 277 detected, the node simply tries to communicate using an alternative 278 source locator. Since both nodes behave this way, a failure in any 279 single locator used in the communication can be recovered. However, 280 in the case that both locators used in the communication fail 281 simultaneously, the approach of trying different source addresses 282 will not be enough to restore the communication. This is basically 283 because retrying with a different source address assumes that at 284 least on of the original locators is working. So, in order to be 285 able to provide fault tolerance support in the situations when both 286 locators fail simultaneously, it is required that at least one of the 287 nodes is aware of multiple locators of its correspondent node. On 288 the other hand, exchanging alternative locator information imposes an 289 additional overhead in the communication, which is only useful if an 290 outage occurs (which is supposed not to be so frequent). 292 In conclusion, adding additional locators in the shim host-pair 293 context establishment exchange provides enhanced fault tolerance but 294 it imposes an additional cost. A reasonable approach would be that 295 the shim host-pair context establishment exchange should support the 296 exchange of additional locators, but should not mandate it. In 297 addition, the multihoming protocol should support the exchange 298 additional locators during the lifetime of the session. 300 Besides the identifiers and locators associated to the shim session, 301 it may be required to negotiate Context Tags that allow to identify 302 data packets that belong to that shim host-pair context. The need of 303 such Context Tags depends on the demultiplexing mechanism used, as 304 described in [5] 306 3.2.1 Security Information 308 In addition, it seems that security related information needs to be 309 exchanged during the shim host-pair context establishment exchange. 311 Including a sort of cookie/key/hash chain anchor in the exchange, 312 limits the potential attackers to those present in the path during 313 this initial exchange. It also implies that in order to complete the 314 exchange, the other node must be receiving the reply packets. In 315 addition, such key would be useful to secure future exchanges. So, 316 it seems a good option to exchange a shared secret during the shim 317 host-pair context establishment exchange. 319 The exchange of additional security information may be required to 320 provide protection against future attacks, depending on the security 321 scheme used. 323 3.2.2 DoS protection. 325 Depending on the mechanism used to provide protection against future 326 attacks, the shim host-pair context establishment exchange may more 327 or less susceptible to DoS attacks. If the security mechanism used 328 requires a considerable amount of processing, it may be used to 329 launch a DoS attack consuming the processing power of the receiver. 330 In addition, after the exchange is completed, a state is created in 331 each node, storing information about identifiers, multiple locators, 332 keys and so on. Such state requires memory, so it can be used by a 333 malicious node to generate a DoS attack based in memory consumption. 334 In order to provide some protection from these attacks, the receiver 335 node should not create any state until the initiating node has done 336 so. This can be achieved by using a 4 way exchange, where the 337 receiver does not create any state until the third packet and the 338 initiator has to prove that it has some state created after receiving 339 the second packet. This can be done by the initiator by showing some 340 information received in the second packet and that the receiver can 341 regenerate without requiring some specific information (like hashing 342 a key and the initiator address). The result is not a complete 343 protection from such attacks, since the resulting state in the 344 receiver is long lived, and the attacker can discard its state after 345 finishing the 4 way handshake. However, after the 4 way handshake, 346 the receiver will know a valid locator of the attacker, which can be 347 used to track the attacker. 349 3.2.3 Resulting shim host-pair context establishement exchange 351 Initiator Receiver 352 | P1 | 353 |-------------------------->| 354 | P2 | 355 |<--------------------------| 356 | P3 | 357 |-------------------------->| 358 | P4 | 359 |<--------------------------| 361 P1 is essentially a request to initiate an exchange. It will also be 362 used to detect the shim capability of the receiver. 364 P2 will provide the information needed by the initiator to prove that 365 he has some state about this communication. So, P2 will contain 366 something like a Hash of a secret key of the receiver (common to all 367 initiators) and the initiator's address. The receiver will receive 368 P1 and generate P2 without creating any state specific to this 369 communication. It would be possible to also include the alternative 370 locators of the receiver in P2. The question about this if this 371 couldn't be used as an amplifier to launch other DoS attacks to third 372 parties. 374 P3 will contain the Hash obtained in P2. In addition, it will 375 contain the identifier used for this communication and it may contain 376 alternative locator information. In addition, information to 377 validate the locator set may be included. Finally, the key/cookie/ 378 hash chain anchor related information is also included. 380 P4 serves as an acknowledgment of the information received in P3 and 381 it also includes information about alternative locators, identifier 382 and key/cookie/hash chain anchor related information that hasn't been 383 exchanged yet. 385 4. Locator set management 387 The management of the locator set involves adding new locators and 388 removing existing locators. 390 The reasons for adding a new locator are pretty straightforward: 391 there is an additional locator that the holder node wants to add to 392 the available set. The reasons for that may be that a new locator is 393 available in the node (e.g. a mobile node) or simply that the node 394 wants to obtain enhanced fault tolerance by adding additional 395 locators to the available set. 397 The reasons for deleting an existing locator are essentially local. 398 Nodes have local information about the status of their own locators. 399 In case that one of the locators becomes unavailable for some reason 400 (e.g. it is deprecated through Router Advertisement) it would make 401 sense to inform the other nodes that this locator should no longer be 402 used. 404 There are two possible approaches to the addition and removal of 405 locators: atomic and differential approaches. Atomic approaches 406 essentially send the complete locators set each time that a variation 407 in the locator set occurs. In this case, there is only one message 408 exchange defined i.e. a message that informs about the new locator 409 set and an acknowledgment message. Differential messages send the 410 differences between the existing locator set and the new one. In 411 this case, a message for adding a new locator and another message for 412 deleting locators have to be defined. Both messages can be 413 acknowledged. The atomic approach imposes additional overhead, since 414 all the locator set has to be exchanged each time while the 415 differential approach requires re-synchronization of both ends 416 through changes i.e. that both ends have the same idea about what the 417 current locator set is. 419 4.1 Security of the exchange for adding locators 421 The additional locators conveyed through this mechanism should belong 422 to the node that performed the initial exchange. Security 423 information must be included in this messages to prove that. One 424 possibility is to include information about the key/cookie/hash chain 425 defined in the initial exchange. This is not enough to prevent 426 future attacks. In order to provide future attack protection, 427 alternative schemes like HBA or CGAs has to be used. 429 4.2 Security of the exchange for deleting locators 431 The security required for the message for removing a locator may be 432 achieved using the key/cookie/hash chain information created during 433 the initial contact exchange. 435 5. Re-homing procedure 437 The re-homing procedure occurs when a new locator pair is to be used 438 for the communication. The reason for a re-homing is essentially 439 that the current locator pair is no longer working. The re-homing 440 procedure involves detecting that the locator pair currently in use 441 is no longer working, exploring alternative locator pairs and re- 442 homing the communication to the reachable locator pair. 444 In order to verify that a locator pair is working, a Reachability 445 Test exchange is needed. This can be used to check if the locator 446 pair that is being used is working properly or to explore if 447 potential locator pairs are working. In addition, in the last case, 448 the Reachability Test is also a mechanism to prevent thrid-party 449 flooding attacks. 451 The Reachability Test exchange includes the following packets: 453 Reachability Test (RT) packet: including the random nonce and 454 maybe information related to the initial key/cookie/hash chain 456 Reachability Test Reply (RTR) packet: include the nonce of the RT 457 packet and maybe information related to the initial key/cookie/ 458 hash chain 460 In the case that a bidirectional path is available, the pair of 461 locators contained in the RT and RTR packets will be the same. 462 However, if only two disjoints unidirectional paths are available, 463 the locators contained in the RT will differ from the ones included 464 in the RTR. Additional discussion on this topic can be found in [6]. 466 5.1 Security 468 In any case, it is required to know if there is a node replying at 469 the other end. The messages should include a nonce in order to match 470 the replies with original messages. In addition, the nonce should be 471 randomly selected, imposing the reception of the initial message to 472 be able to properly generate the reply. Finally, including 473 information related to the key/cookie/hash chain defined in the 474 initial exchange would guarantee that only the node involved in the 475 initial exchange can participate in the reachability exchange 476 (depending on the particular mechanism, this may be more or less 477 expensive) In the case that the mechanism is used to prevent third- 478 party flooding attacks additional security measures are needed, since 479 any shim capable host would reply to a Reachability Test request, 480 precluding its usage as flooding attack prevention. So, in order to 481 use this mechanism to prevent flooding, additional checks are needed. 482 One option would be to include information related to the key/cookie/ 483 hash chain defined in the initial exchange as described above. 484 Another option would be to require that nodes only reply Reachability 485 Test requests coming from nodes that they are already communicating 486 with. 488 6. Removal of shim session state 490 There are essentially two approaches for discarding an existing state 491 about locators, keys and identifiers of a correspondent node: a 492 coordinated approach and an unilateral approach. 494 In the unilateral approach, each node discards the information about 495 the other node without coordination with the other node based on some 496 local timers and heuristics. No packet exchange is required for 497 this. In this case, it would be possible that one of the nodes has 498 discarded the state while the other node still hasn't. In this case, 499 an error message may be required to inform about the situation. 501 In the coordinated approach, there is a closing exchange that is 502 performed in order to coordinate the process, in order to make sure 503 that both nodes discard the state related to the previous 504 communication. This would require a pair of messages Close and 505 Close-ACK. 507 6.1 Security 509 The Close message has to be secured using the key/cookie/hash chain 510 information created during the initial contact exchange. 512 7. Security considerations 514 The security requirements of each message exchange considered in this 515 note are detailed in the same section where the message exchange is 516 analyzed. 518 8. Contributors 520 This document was originally produced of a MULTI6 design team 521 consisting of (in alphabetical order): Jari Arkko, Marcelo Bagnulo 522 Braun, Iljitsch van Beijnum, Geoff Huston, Erik Nordmark, Margaret 523 Wasserman, and Jukka Ylitalo. 525 9. References 527 9.1 Normative References 529 [1] Narten, T. and R. Draves, "Privacy Extensions for Stateless 530 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 532 [2] Wellington, B., "Secure Domain Name System (DNS) Dynamic 533 Update", RFC 3007, November 2000. 535 9.2 Informative References 537 [3] Huston, G., "Architectural Approaches to Multi-Homing for IPv6", 538 draft-huston-multi6-architectures-01 (work in progress), 539 June 2004. 541 [4] Nordmark, E., "Multihoming without IP Identifiers", 542 draft-nordmark-multi6-noid-02 (work in progress), July 2004. 544 [5] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", 545 draft-nordmark-multi6dt-shim-00.txt (work in progress), 546 October 2004. 548 [6] Arkko, J., "Failure Detection and Locator Selection in Multi6", 549 draft-multi6dt-failure-detection-00 (work in progress), 550 October 2004. 552 Authors' Addresses 554 Marcelo Bagnulo 555 Universidad Carlos III de Madrid 556 Av. Universidad 30 557 Leganes, Madrid 28911 558 SPAIN 560 Phone: 34 91 6249500 561 Email: marcelo@it.uc3m.es 562 URI: http://www.it.uc3m.es 564 Jari Arkko 565 Ericsson 566 Jorvas 02420 567 Finland 569 Email: jari.arkko@ericsson.com 571 Intellectual Property Statement 573 The IETF takes no position regarding the validity or scope of any 574 Intellectual Property Rights or other rights that might be claimed to 575 pertain to the implementation or use of the technology described in 576 this document or the extent to which any license under such rights 577 might or might not be available; nor does it represent that it has 578 made any independent effort to identify any such rights. Information 579 on the procedures with respect to rights in RFC documents can be 580 found in BCP 78 and BCP 79. 582 Copies of IPR disclosures made to the IETF Secretariat and any 583 assurances of licenses to be made available, or the result of an 584 attempt made to obtain a general license or permission for the use of 585 such proprietary rights by implementers or users of this 586 specification can be obtained from the IETF on-line IPR repository at 587 http://www.ietf.org/ipr. 589 The IETF invites any interested party to bring to its attention any 590 copyrights, patents or patent applications, or other proprietary 591 rights that may cover technology that may be required to implement 592 this standard. Please address the information to the IETF at 593 ietf-ipr@ietf.org. 595 Disclaimer of Validity 597 This document and the information contained herein are provided on an 598 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 599 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 600 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 601 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 602 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 603 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 605 Copyright Statement 607 Copyright (C) The Internet Society (2005). This document is subject 608 to the rights, licenses and restrictions contained in BCP 78, and 609 except as set forth therein, the authors retain all their rights. 611 Acknowledgment 613 Funding for the RFC Editor function is currently provided by the 614 Internet Society.