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