idnits 2.17.1 draft-ietf-shim6-applicability-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 734. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 724. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 5, 2006) is 6529 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) -- Looks like a reference, but probably isn't: '1' on line 154 -- Looks like a reference, but probably isn't: '2' on line 155 == Unused Reference: 'I-D.ietf-shim6-failure-detection' is defined on line 610, but no explicit reference was found in the text == Unused Reference: 'I-D.bagnulo-ipv6-rfc3484-update' is defined on line 664, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-03 == Outdated reference: A later version (-05) exists of draft-ietf-shim6-hba-01 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-05 == Outdated reference: A later version (-01) exists of draft-nordmark-shim6-esd-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.nordmark-shim6-esd' ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Afilias Canada 4 Expires: December 7, 2006 M. Bagnulo 5 UC3M 6 June 5, 2006 8 Applicability Statement for the Level 3 Multihoming Shim Protocol 9 (Shim6) 10 draft-ietf-shim6-applicability-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 7, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document discusses the applicability of the Shim6 IPv6 protocol 44 element and associated support protocols to provide site multihoming 45 capabilities in IPv6. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Application scenarios . . . . . . . . . . . . . . . . . . . . 4 51 3. Address Configuration . . . . . . . . . . . . . . . . . . . . 6 52 3.1. Protocol Version (IPv4 vs. IPv6) . . . . . . . . . . . . . 6 53 3.2. Prefix Lengths . . . . . . . . . . . . . . . . . . . . . . 6 54 3.3. Address Generation . . . . . . . . . . . . . . . . . . . . 6 55 3.4. Use of CGA vs. HBA . . . . . . . . . . . . . . . . . . . . 7 56 4. Shim6 Capabilities . . . . . . . . . . . . . . . . . . . . . . 8 57 4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 8 58 4.1.1. Establishing Communications After an Outage . . . . . 8 59 4.1.2. Short-Lived Communications . . . . . . . . . . . . . . 8 60 4.1.3. Long-Lived Communications . . . . . . . . . . . . . . 9 61 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 9 62 4.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 9 63 5. Interaction with Other Protocols . . . . . . . . . . . . . . . 11 64 5.1. Shim6 and Mobile IPv6 . . . . . . . . . . . . . . . . . . 11 65 5.1.1. Multi-homed Home Network . . . . . . . . . . . . . . . 11 66 5.1.2. Shim6 between the HA and the MN . . . . . . . . . . . 13 67 5.1.3. Shim6-based Route Optimization . . . . . . . . . . . . 13 68 5.2. Shim6 and SeND . . . . . . . . . . . . . . . . . . . . . . 14 69 5.3. Shim6 and SCTP . . . . . . . . . . . . . . . . . . . . . . 14 70 5.4. Shim6 and NEMO . . . . . . . . . . . . . . . . . . . . . . 14 71 5.5. Shim6 and HIP . . . . . . . . . . . . . . . . . . . . . . 15 72 6. Security considerations . . . . . . . . . . . . . . . . . . . 16 73 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17 74 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 80 Intellectual Property and Copyright Statements . . . . . . . . . . 23 82 1. Introduction 84 Site multi-homing is an arrangement by which a site may use multiple 85 paths to the rest of the Internet, to provide better reliability for 86 traffic passing in and out of the site than would be possible with a 87 single path. Some of the motivations for operators to multi-home 88 their network are described in [RFC3582]. 90 In IPv4, site multi-homing is achieved by introducing the additional 91 state required to allow session resilience over re-homing events to 92 the global Internet routing system (sometimes referred to as the 93 Default-Free Zone, or DFZ) [RFC4116]. There is concern that this 94 approach will not scale [RFC3221]. 96 In IPv6, site multi-homing in the style of IPv4 is not generally 97 available to end sites due to a strict policy of route aggregation in 98 the DFZ. Site multi-homing for sites without PI addresses is 99 achieved by assigning multiple addresses to each host, one or more 100 from each provider. This multi-homing approach provides no 101 transport-layer stability across re-homing events. 103 Shim6 introduces transport-layer mobility across re-homing events 104 using a layer-3 shim approach. State information relating to the 105 multi-homing of two endpoints exchanging unicast traffic is retained 106 on the endpoints themselves, rather than in the network. 107 Communications between Shim6-capable hosts and Shim6-incapable hosts 108 proceed as normal, but without the benefit of transport-layer 109 stability. The Shim6 approach is thought to have better scaling 110 properties with respect to the state held in the DFZ than the IPv4 111 approach. 113 This note describes the applicability of the Level 3 multihoming 114 (hereafter Shim6) protocol defined in [I-D.ietf-shim6-proto] and the 115 failure detection mechanisms defined in [I-D.ietf-shim6-failure- 116 detection]. 118 2. Application scenarios 120 The goal of the Shim6 protocol is to support locator agility in 121 established communications: different layer-3 endpoint addresses may 122 be used to exchange packets as part of the same transport-layer 123 session, all the time presenting a consistent identifier pair to 124 upper-layer protocols. 126 In order to be useful, the Shim6 protocol requires that at least one 127 of the peers has more than one address (locator). In the event of 128 communications failure between an active pair of addresses, the Shim6 129 protocol will attempt to reestablish communication by trying 130 different combinations of locators. 132 While the Shim6 protocol does not impose any requirements on the 133 disposition of the locators involved in this process, the scenario in 134 which the Shim6 protocol is expected to operate is that of a multi- 135 homed site which is connected to multiple transit providers, and 136 which receives an IPv6 prefix from each of them. This configuration 137 is intended to provide protection for the end-site in the event of a 138 failure in some subset of the available transit providers without 139 requiring the end-site to acquire provider-independent (PI) address 140 space. 142 ,------------------------------------. ,----------------. 143 | Rest of the Internet +-------+ Remote Host H' | 144 `--+-----------+------------------+--' `----------------' 145 | | | L'[1] ... L'[m] 146 ,---+----. ,---+----. ,----+---. 147 | ISP[1] | | ISP[2] | ...... | ISP[n] | 148 `---+----' `---+----' `----+---' 149 | | | 150 ,---+-----------+------------------+---. 151 | Multi-Homed Site S assigned | 152 | prefixes P[1], P[2], ..., P[n] | 153 | | 154 | ,--------. L[1] = P[1]:iid[1], | 155 | | Host H | L[2] = P[2]:iid[2], ... | 156 | `--------' L[n] = P[n]:iid[n] | 157 `--------------------------------------' 159 Figure 1 161 In the scenario illustrated in Figure 1 host H communicates with some 162 remote host H'. Each of the addresses L[i] configured on host H in 163 the multi-homed site S can be reached through provider ISP[i] only, 164 since ISP[i] is solely responsible for originating a covering prefix 165 for P[i] to the rest of the Internet. 167 The use of locator L[i] on H hence causes inbound traffic towards H 168 to be routed through ISP[i]. Changing the locator used from L[i] to 169 L[j] will have the effect of re-routing inbound traffic to H from 170 ISP[i] to ISP[j]. This is the central mechanism by which the Shim6 171 protocol aims to provide multi-homing functionality: by changing 172 locators, the H can change the upstream ISP used to route inbound 173 packets towards itself. Corresponding control of the outbound path 174 for packets from H towards H' is shared between the locator L'[j] 175 chosen by H', and the administrative exit selection policy of site S. 177 The Shim6 protocol has other potential applications beyond site 178 multi-homing. For example, since Shim6 is a host-based protocol, it 179 can also be used to support session mobility between interfaces on a 180 multi-homed host. A failure in communication between a multi-homed 181 host and some other, remote host might be repaired by selection of a 182 locator associated with a different interface. 184 3. Address Configuration 186 3.1. Protocol Version (IPv4 vs. IPv6) 188 The Shim6 protocol is defined only for IPv6. However, there is no 189 fundamental reason why a Shim6-like approach could not support IPv4 190 addresses as locators, either to provide multi-homing support to 191 IPv4-numbered sites, or as part of an IPv4/IPv6 transition strategy. 192 Some extensions to the shim6 protocol for supporting IPv4 locators 193 have been proposed in [I-D.nordmark-shim6-esd]. 195 The Shim6 protocol, as specified for IPv6, incorporates cryptographic 196 elements in the construction of locators (see [RFC3972], [I-D.ietf- 197 shim6-hba]). Since IPv4 addresses are insufficiently large to 198 contain addresses constructed in this fashion, direct implementation 199 of Shim6 as specified for IPv6 for use with IPv4 addresses might 200 require protocol modifications. 202 3.2. Prefix Lengths 204 The Shim6 protocol does not assume that all the addresses assigned to 205 the multihomed site have the same prefix length. 207 The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve 208 encoding information in the lower 64 bits of locators. This imposes 209 the requirement on address assignment to Shim6-capable hosts that all 210 interface addresses should be able to accommodate 64-bit interface 211 identifiers. This requirement is also imposed by CGA [RFC3972]. 213 3.3. Address Generation 215 The security of the Shim6 protocol is based on the use of CGA and HBA 216 addresses. 218 CGA and HBA can be generated through the stateless auto-configuration 219 mechanism defined in [RFC2462] with the additional considerations 220 presented in [RFC3972] and [I-D.ietf-shim6-hba]. 222 Stateful address auto-configuration using DHCP [RFC3315] is not 223 currently supported, because there is no defined mechanism to convey 224 the CGA Parameter Data Structure and other relevant information from 225 the DHCP server to the host. The definition of such mechanisms seems 226 to be quite straightforward in the case of the HBA, since only the 227 CGA Parameter Data Structure needs to be delivered from the DHCP 228 server to the Shim6 host, and that data structure does not contain 229 any secret information. In the case of CGAs, however, private key 230 information must be exchanged as well as the CGA Parameter Data 231 Structure. 233 3.4. Use of CGA vs. HBA 235 The choice between CGA and HBA is a trade-off between flexibility and 236 performance. 238 The use of HBA is more efficient in the sense that addresses require 239 less computation than CBA, involving only hash operations for both 240 the generation and the verification of locator sets. However, with 241 HBA the locator set is determined during the generation process, and 242 cannot be subsequently changed; addition of new locators to that 243 initial set is not supported, except by re-generation of the entire 244 set which will cause all addresses to change. 246 Use of CGA is more computationally expensive, involving public key 247 cryptography in the verification of locator sets. However, CGAs are 248 more flexible in the sense that they support the dynamic modification 249 of locator sets. 251 CGAs are well suited to support dynamic environments such as mobile 252 hosts, where the locator set must be changed frequently. HBAs are 253 better suited for static sites where the prefix set remains 254 relatively stable. 256 It should be noted that, since HBAs are defined as a CGA extension, 257 it is possible to generate hybrid HBA/CGA structures that incorporate 258 the strengths of both: i.e. that a single address can be used as an 259 HBA, enabling computationally-cheap validation amongst a fixed set of 260 addresses, and also as a CGA, enabling dynamic manipulation of the 261 locator set. For additional details, see [I-D.ietf-shim6-hba]. 263 4. Shim6 Capabilities 265 4.1. Fault Tolerance 267 4.1.1. Establishing Communications After an Outage 269 If a host within a multihomed site attempts to establish 270 communication with a remote host outside the site while one of the 271 site's transit paths has failed, and selects an local locator from 272 which to source packets which corresponds to the failed transit path, 273 bidirectional communication between the two hosts will not succeed. 274 The failure of the transit path will not, in general, be known in 275 advance to the host. 277 In order to establish communication, the initiating host must try 278 different combinations of (source, destination) locator until it 279 finds a pair that works. The mechanism for this default address 280 selection is described in [RFC3484]; commentary on this mechanism in 281 the context of multi-homed environments can be found in [I-D.bagnulo- 282 ipv6-rfc3484-update]. 284 Since Shim6 context is normally only established between two hosts 285 after initial communication has been established, there is no 286 opportunity for shim6 to participate in the discovery of a suitable, 287 initial (source, destination) locator pair. 289 4.1.2. Short-Lived Communications 291 The Shim6 context establishment operation requires a 4-way packet 292 exchange, and involves some overhead on the participating hosts in 293 memory and CPU. 295 For short-lived exchanges between two hosts, the benefit of 296 establishing a Shim6 context might not exceed the cost, perhaps 297 because the protocols concerned are tolerant of failure and can 298 arrange their own recovery (e.g. DNS) or because the frequency of 299 re-homing events is sufficiently low that the probability of such a 300 failure occuring during a short-lived exchange is not considered 301 significant. 303 It is anticipated that the exchange of Shim6 context will provide 304 most benefit for exchanges between hosts which are long-lived. For 305 this reason the default behaviour of Shim6-capable hosts is expected 306 to employ deferred context setup. This default behaviour will be 307 able to be overridden by applications which prefer immediate context 308 establishment regardless of transaction longeivity. 310 It must be noted that all the above considerations refer to lifetime 311 of the contact between the peers and not about the lifetime of the 312 particular connection (e.g. TCP connection). In other words, the 313 shim6 context is established between ULID pairs and it affects all 314 the communication between these ULIDs. So, two nodes that perform 315 multiple short lived communications with the same ULID pair would 316 benefit as much from the shim features as two nodes having a single 317 long-lived communication. 319 4.1.3. Long-Lived Communications 321 As discussed in Section 4.1.2, hosts engaged in long-lived 322 communications will suffer lower proportional overhead, and greater 323 probability of benefit than those performing brief transactions. 325 Deferred context setup ensures that session establishment time will 326 not be increased by the use of Shim6. 328 4.2. Load Balancing 330 The Shim6 protocol does not support load balancing within a single 331 context: all packets associated with a particular context are 332 exchanged using a single locator pair per direction, with the 333 exception of forked contexts which involve the upper-layer protocol. 335 It may be possible to extend the shim6 protocol to use multiple 336 locator pairs in a single context, but the impact of such an 337 extension on upper-layer protocols (e.g. on TCP congestion control) 338 should be considered carefully. 340 When many contexts are considered together in aggregate, e.g. on a 341 single host which participates in many simultaneous contexts or in a 342 site full of hosts, some degree of load sharing should occur 343 naturally due to the selection of different locator pairs in each 344 context. There is no mechanism defined to ensure that this natral 345 load sharing is arranged to provide a statistical balance between 346 transit providers, however. 348 4.3. Traffic Engineering 350 The Shim6 protocol provides some lightweight traffic engineering 351 capabilities in the form of the Locator Preferences option, which 352 allows a host to inform a remote host of local preferences for 353 locator selection. 355 This mechanism is only available after a Shim6 context has been 356 established, and is a host-based capability rather than a site-based 357 capability. There is no defined mechanism which would allow use of 358 the Locator Preferences option amongst a site full of hosts to be 359 managed centrally. 361 5. Interaction with Other Protocols 363 5.1. Shim6 and Mobile IPv6 365 Three scenarios where the Shim6 protocol and the MIPv6 protocol MIPv6 366 protocol [RFC3775] might be used simultaneously have been considered. 368 5.1.1. Multi-homed Home Network 370 In this case, the Home Network of the Mobile Node (MN) is multi- 371 homed. This implies the availability of multiple Home Network 372 prefixes, resulting on multiple HoAs for each MN. Since the MN is a 373 node within a multihomed site, it seems reasonable to expect that the 374 MN should able to benefit from the multihoming capabilities provided 375 by the Shim6 protocol. Moreover, the MN needs to be able to obtain 376 the multihoming benefits even when it is roaming away from the Home 377 Network: if the MN is away from the Home Network while the Home 378 Network suffers a failure in a transit path, the MN should be able to 379 continue communicating using alternate paths to reach the Home 380 Network. 382 The resulting scenario is the following: 384 +------------------------------------+ 385 | Internet | 386 +------------------------------------+ 387 | | 388 +----+ +----+ 389 |ISP1| |ISP2| 390 +----+ +----+ 391 | | 392 +------------------------------------+ 393 | Multihomed Home Network | 394 | Prefixes: P1 and P2 | 395 | | 396 | Home Agent | 397 | // | 398 +------------------//----------------+ 399 // 400 // 401 +-----+ 402 | MN | HoA1, HoA2 403 +-----+ 405 Figure 2 407 So, in this configuration, the shim6 protocol is used to provide 408 multihoming supports to all the nodes within the multihomed sites 409 (including the mobile nodes) and the MIPv6 protocol is used to 410 support mobility of the mobile nodes of the multihomed site. 412 The proposed protocol architecture would be the following: 414 +--------------+ 415 | Application | 416 +--------------+ 417 | Transport | 418 +--------------+ 419 | IP | 420 | +----------+ | 421 | | IPSec | | 422 | +----------+<--ULIDs 423 | | shim6 | | 424 | +----------+<--HoAs 425 | | MIPv6 | | 426 | +----------+<--CoAs 427 | | 428 +--------------+ 430 Figure 3 432 In this architecture, the upper layer protocols and IPSec would use 433 ULIDs of the shim6 protocol. Only the HoAs will be presented to the 434 shim6 layer as potential ULIDs. The shim6 protocol will then be used 435 to provide failover between different HoAs. This is useful to 436 preserve established communications when an outage affects the path 437 through the ISP that has delegated the HoA used for initiating the 438 communication (similarly to the case of a host within a multihomed 439 site). The CoAs are not presented to the shim6 layer and are not 440 included in the local locator set in this case. The CoAs are managed 441 by the MIPv6 layer, that binds each HoA to a CoA. 443 So, in this case, the ULP select a ULID pair for the communication. 444 The shim6 protocol translates the ULID pair to an alternative locator 445 is case that is needed. Both the ULIDs and the alternative locators 446 are HoAs. Next, the MIPv6 layer maps the selected HoA to the 447 corresponding CoA, and this is the actual address included in the 448 wire. 450 The shim6 context is established between the MN and the CN, and it 451 would allow the communication to use all the available HoAs to 452 provide fault tolerance. The MIPv6 protocol is used between the MN 453 and the HA in the case of the bidirectional tunnel mode and between 454 the MN and the CN in case of the RO mode. 456 5.1.2. Shim6 between the HA and the MN 458 Another scenario where a shim6-MIPv6 interaction may be useful is the 459 case where a shim6 context is established between the MN and the Home 460 Agent (HA) in order to provide fault tolerance capabilities to the 461 bidirectional tunnel between them. 463 Consider the case where the HA has multiple addresses (whether 464 because the Home Network is multihomed or because the HA has multiple 465 interfaces) and/or the MN has multiple addresses (whether because the 466 visited network is multihomed or because the MN has multiple 467 interfaces). In this case, if a failure affects the address pair 468 that is being used to run the tunnel between the MN and HA, 469 additional mechanisms need to be used to preserve the communication. 471 One possibility would be to use MIPv6 capabilities, by simply 472 changing the CoA used as the tunnel endpoint. However, MIPv6 lacks 473 of failure detection mechanisms that would allow the MN and/or the HA 474 to detect the failure and trigger the usage of an alternative 475 address. Shim6 provides such failure detection protocol, so one 476 possibility would be re-use the failure detection function from the 477 shim6 failure detection protocol in MIPv6. In this case, the shim6 478 protocol wouldn�t be used to create shim6 context and provide 479 fault tolerance, but just the failure detection functionality would 480 be re-used. 482 The other possibility would be to use the shim6 protocol to create a 483 shim6 context between the HA and the MN so that the shim6 detects any 484 failure and re-homes the communication in a transparent fashion to 485 MIPv6. In this case, the shim6 protocol would be associated to the 486 tunnel interface 488 5.1.3. Shim6-based Route Optimization 490 Another scenario where it may be reasonable to support the 491 simultaneous operation of MIPv6 and the shim6 protocol is to achieve 492 some form of shim6-based Route Optimization. This case is similar to 493 the one described in the multihomed home network section, the 494 difference being that both the HoAs and the CoAs available in the MN 495 are presented to the shim6 layer. The result is that the shim6 layer 496 can select a CoA as an alternative address for an ongoing 497 communication resulting in a route optimization mechanism. In this 498 case, the shim6 protocol is used to provide both fault tolerance and 499 route optimization, while the MIPv6 protocol is used for initial 500 contact and non-optimized communications. 502 5.2. Shim6 and SeND 504 Secure Neighbour Discovery (SeND) [RFC3971] uses CGAs to prove 505 address ownership for Neighbour Discovery [RFC2461]. The Shim6 506 protocol can use either CGAs or HBAs to protect locator sets included 507 in Shim6 contexts. It is expected that some hosts will need to 508 participate in both SeND and Shim6 simultaneously. 510 In the case that both the SeND and Shim6 protocols are using the CGA 511 technique to generate addresses, then there is no conflict: the host 512 will generate addresses for both purposes as CGAs, and since it will 513 be in control of the associated private key, the same CGA can be used 514 for the different protocols. 516 In the case that a Shim6-capable host is using HBAs to protect its 517 locator sets, the host will need to generate hybrid HBA/CGA addresses 518 as defined in [I-D.ietf-shim6-hba] and discussed briefly in 519 Section 3.4. In this case, the CGA Parameter Data Structure 520 containing a valid public key and the Multi-Prefix extension is 521 included as inputs to the hash function. 523 5.3. Shim6 and SCTP 525 The SCTP [RFC2960] protocol provides a reliable, stream-based 526 communications channel between two hosts which provides a superset of 527 the capabilities of TCP. One of the notable features of SCTP is that 528 it allows the exchange of endpoint addresses between hosts, and is 529 able to recover from the failure of a particular endpoint pair in a 530 manner which is conceptually similar to locator selection in Shim6. 532 SCTP is a transport-layer protocol, higher in the protocol stack than 533 Shim6, and hence there is no fundamental incompatibility which would 534 prevent a Shim6-capable host from communicating using SCTP. 536 However, since SCTP and Shim6 both aim to exchange addressing 537 information between hosts in order to meet the same general goal, it 538 is possible that their simultaneous use might result in unexpected 539 behaviour, e.g. due to race conditions. 541 The capabilities of SCTP with respect to path maintenance of a 542 reliable, connection-oriented stream protocol are more extensive than 543 the more general layer-3 locator agility provided by Shim6. It is 544 recommended that Shim6 is not used for SCTP sessions, and that path 545 maintenance is provided solely by SCTP. 547 5.4. Shim6 and NEMO 549 The NEMO [RFC3963] protocol extensions to MIPv6 allow a Mobile 550 Network to communicate through a bidirectional tunnel via a Mobile 551 Router (MR) to a NEMO-compliant Home Agent (HA) located in a Home 552 Network. 554 If either or both of the MR or HA are multi-homed, then a Shim6 555 context established between them preserves the integrity of the 556 bidirectional tunnel between them in the event that a transit failure 557 occurs between them. The MR in this case can be considered to be 558 immobile either side of the failure event, and the Shim6 protocol 559 provides a stable pair of ULIDs for the tunnel endopints. 561 Once the tunnel between MR and HA is established, hosts within the 562 Mobile Network which are Shim6-capable can establish contexts with 563 remote hosts in order to receive the same multi-homing benefits as 564 any host located within the Home Network. 566 5.5. Shim6 and HIP 568 Placeholder. 570 6. Security considerations 572 This section will be completed before publication is requested. 574 7. Change History 576 This section should be removed prior to publication. 578 The list of Normative References to this document includes internet 579 drafts; publication of those documents on the standards track is a 580 prerequisite for the publication of this document, as-is. 582 draft-ietf-shim6-applicability-01: Added text for section 2 583 (Application scenarios), section 3 (About Address Configuration), 584 section 4 (Resulting shim6 capabilities) and section 5 585 (Interactions with other protocols). 587 draft-ietf-shim6-applicability-00: First draft, largely incomplete, 588 submitted to facilitate comments on general structure and 589 approach. 591 8. Contributors 593 The anlysis on the interaction between the Shim6 protocol and the 594 other protocols presented in this note benefited from the advice of 595 various people including Erik Nordmark, Hesham Soliman, Vijay 596 Devarpalli, John Loughney and Dave Thaler. 598 9. Acknowledgements 600 Joe Abley's work was supported in part by the US National Science 601 Foundation (research grant SCI-0427144) and DNS-OARC. 603 Marcelo Bagnulo worked on this document while visiting Ericsson 604 Research Laboratory Nomadiclab. 606 10. References 608 10.1. Normative References 610 [I-D.ietf-shim6-failure-detection] 611 Arkko, J. and I. Beijnum, "Failure Detection and Locator 612 Pair Exploration Protocol for IPv6 Multihoming", 613 draft-ietf-shim6-failure-detection-03 (work in progress), 614 December 2005. 616 [I-D.ietf-shim6-hba] 617 Bagnulo, M., "Hash Based Addresses (HBA)", 618 draft-ietf-shim6-hba-01 (work in progress), October 2005. 620 [I-D.ietf-shim6-proto] 621 Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 622 protocol", draft-ietf-shim6-proto-05 (work in progress), 623 May 2006. 625 [I-D.nordmark-shim6-esd] 626 Nordmark, E., "Extended Shim6 Design for ID/loc split and 627 Traffic Engineering", draft-nordmark-shim6-esd-00 (work in 628 progress), February 2006. 630 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 631 Discovery for IP Version 6 (IPv6)", RFC 2461, 632 December 1998. 634 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 635 Autoconfiguration", RFC 2462, December 1998. 637 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 638 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 639 Zhang, L., and V. Paxson, "Stream Control Transmission 640 Protocol", RFC 2960, October 2000. 642 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 643 and M. Carney, "Dynamic Host Configuration Protocol for 644 IPv6 (DHCPv6)", RFC 3315, July 2003. 646 [RFC3484] Draves, R., "Default Address Selection for Internet 647 Protocol version 6 (IPv6)", RFC 3484, February 2003. 649 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 650 in IPv6", RFC 3775, June 2004. 652 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 653 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 654 RFC 3963, January 2005. 656 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 657 Neighbor Discovery (SEND)", RFC 3971, March 2005. 659 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 660 RFC 3972, March 2005. 662 10.2. Informative References 664 [I-D.bagnulo-ipv6-rfc3484-update] 665 Bagnulo, M., "Updating RFC 3484 for multihoming support", 666 draft-bagnulo-ipv6-rfc3484-update-00 (work in progress), 667 December 2005. 669 [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the 670 Internet", RFC 3221, December 2001. 672 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 673 Multihoming Architectures", RFC 3582, August 2003. 675 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 676 Gill, "IPv4 Multihoming Practices and Limitations", 677 RFC 4116, July 2005. 679 Authors' Addresses 681 Joe Abley 682 Afilias Canada, Inc. 683 Suite 204 684 4141 Yonge Street 685 Toronto, Ontario M2P 2A8 686 Canada 688 Phone: +1 416 673 4176 689 Email: jabley@ca.afilias.info 690 URI: http://afilias.info/ 692 Marcelo Bagnulo 693 Universidad Carlos III de Madrid 694 Av. Universidad 30 695 Leganes, Madrid 28911 696 Spain 698 Phone: +34 91 6248814 699 Email: marcelo@it.uc3m.es 700 URI: http://www.it.uc3m.es/ 702 Intellectual Property Statement 704 The IETF takes no position regarding the validity or scope of any 705 Intellectual Property Rights or other rights that might be claimed to 706 pertain to the implementation or use of the technology described in 707 this document or the extent to which any license under such rights 708 might or might not be available; nor does it represent that it has 709 made any independent effort to identify any such rights. Information 710 on the procedures with respect to rights in RFC documents can be 711 found in BCP 78 and BCP 79. 713 Copies of IPR disclosures made to the IETF Secretariat and any 714 assurances of licenses to be made available, or the result of an 715 attempt made to obtain a general license or permission for the use of 716 such proprietary rights by implementers or users of this 717 specification can be obtained from the IETF on-line IPR repository at 718 http://www.ietf.org/ipr. 720 The IETF invites any interested party to bring to its attention any 721 copyrights, patents or patent applications, or other proprietary 722 rights that may cover technology that may be required to implement 723 this standard. Please address the information to the IETF at 724 ietf-ipr@ietf.org. 726 Disclaimer of Validity 728 This document and the information contained herein are provided on an 729 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 730 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 731 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 732 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 733 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 734 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 736 Copyright Statement 738 Copyright (C) The Internet Society (2006). This document is subject 739 to the rights, licenses and restrictions contained in BCP 78, and 740 except as set forth therein, the authors retain all their rights. 742 Acknowledgment 744 Funding for the RFC Editor function is currently provided by the 745 Internet Society.