idnits 2.17.1 draft-ietf-shim6-applicability-02.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 864. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 888. ** 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 issues found here. 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 (October 23, 2006) is 6395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 157 -- Looks like a reference, but probably isn't: '2' on line 158 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-06 == Outdated reference: A later version (-05) exists of draft-ietf-shim6-hba-02 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-05 ** 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 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-01) exists of draft-bagnulo-shim6-privacy-00 == Outdated reference: A later version (-09) exists of draft-nikander-esp-beet-mode-06 == Outdated reference: A later version (-01) exists of draft-nordmark-shim6-esd-00 Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 9 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 Intended status: Informational M. Bagnulo 5 Expires: April 26, 2007 UC3M 6 October 23, 2006 8 Applicability Statement for the Level 3 Multihoming Shim Protocol 9 (shim6) 10 draft-ietf-shim6-applicability-02 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 April 26, 2007. 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 . . . . . . . . . . . . . . . . . . . . 3 51 3. Address Configuration . . . . . . . . . . . . . . . . . . . . 5 52 3.1. Protocol Version (IPv4 vs. IPv6) . . . . . . . . . . . . . 5 53 3.2. Prefix Lengths . . . . . . . . . . . . . . . . . . . . . . 5 54 3.3. Address Generation . . . . . . . . . . . . . . . . . . . . 6 55 3.4. Use of CGA vs. HBA . . . . . . . . . . . . . . . . . . . . 6 56 4. shim6 Capabilities . . . . . . . . . . . . . . . . . . . . . . 7 57 4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 7 58 4.1.1. Establishing Communications After an Outage . . . . . 7 59 4.1.2. Short-Lived Communications . . . . . . . . . . . . . . 7 60 4.1.3. Long-Lived Communications . . . . . . . . . . . . . . 8 61 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 9 63 5. Interaction with Other Protocols . . . . . . . . . . . . . . . 9 64 5.1. shim6 and Mobile IPv6 . . . . . . . . . . . . . . . . . . 9 65 5.1.1. Multi-homed Home Network . . . . . . . . . . . . . . . 9 66 5.1.2. shim6 Between the HA and the MN . . . . . . . . . . . 12 67 5.2. shim6 and SeND . . . . . . . . . . . . . . . . . . . . . . 12 68 5.3. shim6 and SCTP . . . . . . . . . . . . . . . . . . . . . . 13 69 5.4. shim6 and NEMO . . . . . . . . . . . . . . . . . . . . . . 13 70 5.5. shim6 and HIP . . . . . . . . . . . . . . . . . . . . . . 14 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 16 73 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 74 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 80 Intellectual Property and Copyright Statements . . . . . . . . . . 20 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 116 [I-D.ietf-shim6-failure-detection]. 118 The terminology used in this document, including terms like locator, 119 and ULID, is defined in [I-D.ietf-shim6-proto]. 121 2. Application Scenarios 123 The goal of the shim6 protocol is to support locator agility in 124 established communications: different layer-3 endpoint addresses may 125 be used to exchange packets as part of the same transport-layer 126 session, all the time presenting a consistent identifier pair to 127 upper-layer protocols. 129 In order to be useful, the shim6 protocol requires that at least one 130 of the peers has more than one address (locator). In the event of 131 communications failure between an active pair of addresses, the shim6 132 protocol will attempt to reestablish communication by trying 133 different combinations of locators. 135 While other multi-addressing scenarios are not precluded, the 136 scenario in which the shim6 protocol is expected to operate is that 137 of a multi-homed site which is connected to multiple transit 138 providers, and which receives an IPv6 prefix from each of them. This 139 configuration is intended to provide protection for the end-site in 140 the event of a failure in some subset of the available transit 141 providers without requiring the end-site to acquire provider- 142 independent (PI) address space or requiring any particular 143 cooperation between the transit providers. 145 ,------------------------------------. ,----------------. 146 | Rest of the Internet +-------+ Remote Host R | 147 `--+-----------+------------------+--' `----------------' 148 | | | LR[1] ... LR[m] 149 ,---+----. ,---+----. ,----+---. 150 | ISP[1] | | ISP[2] | ...... | ISP[n] | 151 `---+----' `---+----' `----+---' 152 | | | 153 ,---+-----------+------------------+---. 154 | Multi-Homed Site S assigned | 155 | prefixes P[1], P[2], ..., P[n] | 156 | | 157 | ,--------. L[1] = P[1]:iid[1], | 158 | | Host H | L[2] = P[2]:iid[2], ... | 159 | `--------' L[n] = P[n]:iid[n] | 160 `--------------------------------------' 162 Figure 1 164 In the scenario illustrated in Figure 1 host H communicates with some 165 remote host R. Each of the addresses L[i] configured on host H in the 166 multi-homed site S can be reached through provider ISP[i] only, since 167 ISP[i] is solely responsible for originating a covering prefix for 168 P[i] to the rest of the Internet. 170 The use of locator L[i] on H hence causes inbound traffic towards H 171 to be routed through ISP[i]. Changing the locator used from L[i] to 172 L[j] will have the effect of re-routing inbound traffic to H from 173 ISP[i] to ISP[j]. This is the central mechanism by which the shim6 174 protocol aims to provide multi-homing functionality: by changing 175 locators, the H can change the upstream ISP used to route inbound 176 packets towards itself. Corresponding control of the outbound path 177 for packets from H towards R is shared between the locator LR[j] 178 chosen by R, and the administrative exit selection policy of site S. 180 The shim6 protocol has other potential applications beyond site 181 multi-homing. For example, since shim6 is a host-based protocol, it 182 can also be used to support hpost multihoming. In this case, a 183 failure in communication between a multi-homed host and some other, 184 remote host might be repaired by selection of a locator associated 185 with a different interface. 187 3. Address Configuration 189 3.1. Protocol Version (IPv4 vs. IPv6) 191 The shim6 protocol is defined only for IPv6. However, there is no 192 fundamental reason why a shim6-like approach could not support IPv4 193 addresses as locators, either to provide multi-homing support to 194 IPv4-numbered sites, or as part of an IPv4/IPv6 transition strategy. 195 Some extensions to the shim6 protocol for supporting IPv4 locators 196 have been proposed in [I-D.nordmark-shim6-esd]. 198 The shim6 protocol, as specified for IPv6, incorporates cryptographic 199 elements in the construction of locators (see [RFC3972], 200 [I-D.ietf-shim6-hba]). Since IPv4 addresses are insufficiently large 201 to contain addresses constructed in this fashion, direct 202 implementation of shim6 as specified for IPv6 for use with IPv4 203 addresses might require protocol modifications. 205 In addition, there are other considerations to take into account when 206 considering the support of IPv4 addresses, in particular IPv4 207 locators. In partiuclar, using multiple IPv4 addresses in a single 208 host in order to support shim6 style of multihoming would result in 209 an increased IPv4 address consuption, which with the current rate of 210 IPv4 addresses would be problematic. In addition, in order to be 211 useful, shim6 IPv4 support would require NAT traversal mechanisms 212 which are not defined yet and that would imply additional conpelxity 213 (As any other NAT traversal mechanism). 215 3.2. Prefix Lengths 217 The shim6 protocol does not assume that all the addresses assigned to 218 the multihomed site have the same prefix length. 220 The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve 221 encoding information in the lower 64 bits of locators. This imposes 222 the requirement on address assignment to shim6-capable hosts that all 223 interface addresses should be able to accommodate 64-bit interface 224 identifiers. This requirement is also imposed by CGA [RFC3972]. 225 However it should be noted that this is imposed by RFC3513 [RFC3513] 227 3.3. Address Generation 229 The security of the shim6 protocol is based on the use of CGA and HBA 230 addresses. 232 CGA and HBA can be generated through the stateless auto-configuration 233 mechanism defined in [RFC2462] with the additional considerations 234 presented in [RFC3972] and [I-D.ietf-shim6-hba]. 236 Stateful address auto-configuration using DHCP [RFC3315] is not 237 currently supported, because there is no defined mechanism to convey 238 the CGA Parameter Data Structure and other relevant information from 239 the DHCP server to the host. The definition of such mechanisms seems 240 to be quite straightforward in the case of the HBA, since only the 241 CGA Parameter Data Structure needs to be delivered from the DHCP 242 server to the shim6 host, and that data structure does not contain 243 any secret information. In the case of CGAs, however, private key 244 information must be exchanged as well as the CGA Parameter Data 245 Structure. 247 3.4. Use of CGA vs. HBA 249 The choice between CGA and HBA is a trade-off between flexibility and 250 performance. 252 The use of HBA is more efficient in the sense that addresses require 253 less computation than CBA, involving only hash operations for both 254 the generation and the verification of locator sets. However, with 255 HBA the locator set is determined during the generation process, and 256 cannot be subsequently changed; addition of new locators to that 257 initial set is not supported, except by re-generation of the entire 258 set which will cause all addresses to change. 260 Use of CGA is more computationally expensive, involving public key 261 cryptography in the verification of locator sets. However, CGAs are 262 more flexible in the sense that they support the dynamic modification 263 of locator sets. 265 CGAs are well suited to support dynamic environments such as mobile 266 hosts, where the locator set must be changed frequently. HBAs are 267 better suited for static sites where the prefix set remains 268 relatively stable. 270 It should be noted that, since HBAs are defined as a CGA extension, 271 it is possible to generate hybrid HBA/CGA structures that incorporate 272 the strengths of both: i.e. that a single address can be used as an 273 HBA, enabling computationally-cheap validation amongst a fixed set of 274 addresses, and also as a CGA, enabling dynamic manipulation of the 275 locator set. For additional details, see [I-D.ietf-shim6-hba]. 277 4. shim6 Capabilities 279 4.1. Fault Tolerance 281 4.1.1. Establishing Communications After an Outage 283 If a host within a multihomed site attempts to establish 284 communication with a remote host outside the site while one of the 285 site's transit paths has failed, and selects an local locator from 286 which to source packets which corresponds to the failed transit path, 287 bidirectional communication between the two hosts will not succeed. 288 The failure of the transit path will not, in general, be known in 289 advance to the host. 291 In order to establish communication, the initiating host must try 292 different combinations of (source, destination) locator until it 293 finds a pair that works. The mechanism for this default address 294 selection is described in [RFC3484]; commentary on this mechanism in 295 the context of multi-homed environments can be found in 296 [I-D.bagnulo-ipv6-rfc3484-update]. 298 Since shim6 context is normally only established between two hosts 299 after initial communication has been established, there is no 300 opportunity for shim6 to participate in the discovery of a suitable, 301 initial (source, destination) locator pair. 303 4.1.2. Short-Lived Communications 305 The shim6 context establishment operation requires a 4-way packet 306 exchange, and involves some overhead on the participating hosts in 307 memory and CPU. 309 For short-lived exchanges between two hosts, the benefit of 310 establishing a shim6 context might not exceed the cost, perhaps 311 because the protocols concerned are tolerant of failure and can 312 arrange their own recovery (e.g. DNS) or because the frequency of 313 re-homing events is sufficiently low that the probability of such a 314 failure occuring during a short-lived exchange is not considered 315 significant. 317 It is anticipated that the exchange of shim6 context will provide 318 most benefit for exchanges between hosts which are long-lived. For 319 this reason the default behaviour of shim6-capable hosts is expected 320 to employ deferred context setup. This default behaviour will be 321 able to be overridden by applications which prefer immediate context 322 establishment regardless of transaction longeivity. 324 It must be noted that all the above considerations refer to lifetime 325 of the contact between the peers and not about the lifetime of the 326 particular connection (e.g. TCP connection). In other words, the 327 shim6 context is established between ULID pairs and it affects all 328 the communication between these ULIDs. So, two nodes that perform 329 multiple short lived communications with the same ULID pair would 330 benefit as much from the shim features as two nodes having a single 331 long-lived communication. One example of such scenario would be a 332 web client software downloading web contents from a server with over 333 multiple TCP connections. Each TCP connection is short-lived, but 334 the communication/contact between the two ULID could be long-lived. 336 4.1.3. Long-Lived Communications 338 As discussed in Section 4.1.2, hosts engaged in long-lived 339 communications will suffer lower proportional overhead, and greater 340 probability of benefit than those performing brief transactions. 342 Deferred context setup ensures that session establishment time will 343 not be increased by the use of shim6. 345 4.2. Load Balancing 347 The shim6 protocol does not support load balancing within a single 348 context: all packets associated with a particular context are 349 exchanged using a single locator pair per direction, with the 350 exception of forked contexts which involve the upper-layer protocol. 352 It may be possible to extend the shim6 protocol to use multiple 353 locator pairs in a single context, but the impact of such an 354 extension on upper-layer protocols (e.g. on TCP congestion control) 355 should be considered carefully. 357 When many contexts are considered together in aggregate, e.g. on a 358 single host which participates in many simultaneous contexts or in a 359 site full of hosts, some degree of load sharing should occur 360 naturally due to the selection of different locator pairs in each 361 context. There is no mechanism defined to ensure that this natral 362 load sharing is arranged to provide a statistical balance between 363 transit providers, however. 365 4.3. Traffic Engineering 367 The shim6 protocol provides some lightweight traffic engineering 368 capabilities in the form of the Locator Preferences option, which 369 allows a host to inform a remote host of local preferences for 370 locator selection. 372 This mechanism is only available after a shim6 context has been 373 established, and is a host-based capability rather than a site-based 374 capability. There is no defined mechanism which would allow use of 375 the Locator Preferences option amongst a site full of hosts to be 376 managed centrally. 378 5. Interaction with Other Protocols 380 5.1. shim6 and Mobile IPv6 382 Multiple scenarios where the shim6 protocol and the MIPv6 protocol 383 MIPv6 protocol [RFC3775] might be used simultaneously have been 384 considered. 386 5.1.1. Multi-homed Home Network 388 In this case, the Home Network of the Mobile Node (MN) is multi- 389 homed. This implies the availability of multiple Home Network 390 prefixes, resulting on multiple HoAs for each MN. Since the MN is a 391 node within a multihomed site, it seems reasonable to expect that the 392 MN should able to benefit from the multihoming capabilities provided 393 by the shim6 protocol. Moreover, the MN needs to be able to obtain 394 the multihoming benefits even when it is roaming away from the Home 395 Network: if the MN is away from the Home Network while the Home 396 Network suffers a failure in a transit path, the MN should be able to 397 continue communicating using alternate paths to reach the Home 398 Network. 400 The resulting scenario is the following: 402 +------------------------------------+ 403 | Internet | 404 +------------------------------------+ 405 | | 406 +----+ +----+ 407 |ISP1| |ISP2| 408 +----+ +----+ 409 | | 410 +------------------------------------+ 411 | Multihomed Home Network | 412 | Prefixes: P1 and P2 | 413 | | 414 | Home Agent | 415 | // | 416 +------------------//----------------+ 417 // 418 // 419 +-----+ 420 | MN | HoA1, HoA2 421 +-----+ 423 Figure 2 425 So, in this configuration, the shim6 protocol is used to provide 426 multihoming supports to all the nodes within the multihomed sites 427 (including the mobile nodes) and the MIPv6 protocol is used to 428 support mobility of the mobile nodes of the multihomed site. 430 The proposed protocol architecture would be the following: 432 +--------------+ 433 | Application | 434 +--------------+ 435 | Transport | 436 +--------------+ 437 | IP | 438 | +----------+ | 439 | | IPSec | | 440 | +----------+<--ULIDs 441 | | shim6 | | 442 | +----------+<--HoAs 443 | | MIPv6 | | 444 | +----------+<--CoAs 445 | | 446 +--------------+ 448 Figure 3 450 In this architecture, the upper layer protocols and IPSec would use 451 ULIDs of the shim6 protocol. Only the HoAs will be presented to the 452 shim6 layer as potential ULIDs. The shim6 protocol will then be used 453 to provide failover between different HoAs. This is useful to 454 preserve established communications when an outage affects the path 455 through the ISP that has delegated the HoA used for initiating the 456 communication (similarly to the case of a host within a multihomed 457 site). The CoAs are not presented to the shim6 layer and are not 458 included in the local locator set in this case. The CoAs are managed 459 by the MIPv6 layer, that binds each HoA to a CoA. 461 So, in this case, the ULP select a ULID pair for the communication. 462 The shim6 protocol translates the ULID pair to an alternative locator 463 is case that is needed. Both the ULIDs and the alternative locators 464 are HoAs. Next, the MIPv6 layer maps the selected HoA to the 465 corresponding CoA, and this is the actual address included in the 466 wire. 468 The shim6 context is established between the MN and the CN, and it 469 would allow the communication to use all the available HoAs to 470 provide fault tolerance. The MIPv6 protocol is used between the MN 471 and the HA in the case of the bidirectional tunnel mode and between 472 the MN and the CN in case of the RO mode. 474 5.1.2. shim6 Between the HA and the MN 476 Another scenario where a shim6-MIPv6 interaction may be useful is the 477 case where a shim6 context is established between the MN and the Home 478 Agent (HA) in order to provide fault tolerance capabilities to the 479 bidirectional tunnel between them. 481 Consider the case where the HA has multiple addresses (whether 482 because the Home Network is multihomed or because the HA has multiple 483 interfaces) and/or the MN has multiple addresses (whether because the 484 visited network is multihomed or because the MN has multiple 485 interfaces). In this case, if a failure affects the address pair 486 that is being used to run the tunnel between the MN and HA, 487 additional mechanisms need to be used to preserve the communication. 489 One possibility would be to use MIPv6 capabilities, by simply 490 changing the CoA used as the tunnel endpoint. However, MIPv6 lacks 491 of failure detection mechanisms that would allow the MN and/or the HA 492 to detect the failure and trigger the usage of an alternative 493 address. shim6 provides such failure detection protocol, so one 494 possibility would be re-use the failure detection function from the 495 shim6 failure detection protocol in MIPv6. In this case, the shim6 496 protocol wouldn't be used to create shim6 context and provide fault 497 tolerance, but just the failure detection functionality would be re- 498 used. 500 The other possibility would be to use the shim6 protocol to create a 501 shim6 context between the HA and the MN so that the shim6 detects any 502 failure and re-homes the communication in a transparent fashion to 503 MIPv6. In this case, the shim6 protocol would be associated to the 504 tunnel interface. 506 5.2. shim6 and SeND 508 Secure Neighbour Discovery (SeND) [RFC3971] uses CGAs to prove 509 address ownership for Neighbour Discovery [RFC2461]. The shim6 510 protocol can use either CGAs or HBAs to protect locator sets included 511 in shim6 contexts. It is expected that some hosts will need to 512 participate in both SeND and shim6 simultaneously. 514 In the case that both the SeND and shim6 protocols are using the CGA 515 technique to generate addresses, then there is no conflict: the host 516 will generate addresses for both purposes as CGAs, and since it will 517 be in control of the associated private key, the same CGA can be used 518 for the different protocols. 520 In the case that a shim6-capable host is using HBAs to protect its 521 locator sets, the host will need to generate hybrid HBA/CGA addresses 522 as defined in [I-D.ietf-shim6-hba] and discussed briefly in 523 Section 3.4. In this case, the CGA Parameter Data Structure 524 containing a valid public key and the Multi-Prefix extension is 525 included as inputs to the hash function. 527 5.3. shim6 and SCTP 529 The SCTP [RFC2960] protocol provides a reliable, stream-based 530 communications channel between two hosts which provides a superset of 531 the capabilities of TCP. One of the notable features of SCTP is that 532 it allows the exchange of endpoint addresses between hosts, and is 533 able to recover from the failure of a particular endpoint pair in a 534 manner which is conceptually similar to locator selection in shim6. 536 SCTP is a transport-layer protocol, higher in the protocol stack than 537 shim6, and hence there is no fundamental incompatibility which would 538 prevent a shim6-capable host from communicating using SCTP. 540 However, since SCTP and shim6 both aim to exchange addressing 541 information between hosts in order to meet the same general goal, it 542 is possible that their simultaneous use might result in unexpected 543 behaviour, e.g. due to race conditions. 545 The capabilities of SCTP with respect to path maintenance of a 546 reliable, connection-oriented stream protocol are more extensive than 547 the more general layer-3 locator agility provided by shim6. It is 548 recommended that shim6 is not used for SCTP sessions, and that path 549 maintenance is provided solely by SCTP. There are at least two ways 550 to implement this behaviour. One option would be the stack, and in 551 particular the shim6 sublayer knows when a socket is SCTP and then 552 does not creates a shim6 context in this case. The other option is 553 that the upper layer, SCTP in this case, informs using a shim6 554 capable API like the one proposed in 555 [I-D.sugimoto-multihome-shim-api] that no shim6 context must be 556 created for this particular communication. 558 5.4. shim6 and NEMO 560 The NEMO [RFC3963] protocol extensions to MIPv6 allow a Mobile 561 Network to communicate through a bidirectional tunnel via a Mobile 562 Router (MR) to a NEMO-compliant Home Agent (HA) located in a Home 563 Network. 565 If either or both of the MR or HA are multi-homed, then a shim6 566 context established between them preserves the integrity of the 567 bidirectional tunnel between them in the event that a transit failure 568 occurs between them. The MR in this case can be considered to be 569 immobile either side of the failure event, and the shim6 protocol 570 provides a stable pair of ULIDs for the tunnel endopints. 572 Once the tunnel between MR and HA is established, hosts within the 573 Mobile Network which are shim6-capable can establish contexts with 574 remote hosts in order to receive the same multi-homing benefits as 575 any host located within the Home Network. 577 5.5. shim6 and HIP 579 shim6 and the Host Identity Protocol (HIP) HIP [RFC4423] are 580 architecturally similar in that both solutions allow a host, 581 communicating with another like-enabled host, to use possibly 582 multiple or different locators to support communications between 583 stable ULIDs. The signalling exchange to establish demultiplexing 584 context on both hosts is very similar between the two protocols. 585 However, there are a few key differences. First, shim6 avoids 586 defining a new namespace for ULIDs, preferring instead to use a 587 routable locator as a ULID, while HIP uses public keys and hashes 588 thereof as ULIDs. The use of a routable locator as ULID better 589 supports deferred context establishment, application callbacks, and 590 application referrals, and avoids management and resolution costs of 591 a new namespace, but requires additional security mechanisms to 592 securely bind the ULID with the locators. In HIP, the use of a 593 public key or hash as a ULID allows the context establishment 594 protocol to use the key to sign messages that bind the key to the 595 locators. Second, shim6 uses an explicit context header on data 596 packets for which the ULIDs differ from the locators in use (this 597 header is only needed after a failure/rehoming event occurs), while 598 HIP compresses this context tag into the ESP SPI field of a BEET-mode 599 security association BEET [I-D.nikander-esp-beet-mode]. Third, HIP 600 as presently defined requires the use of public-key operations in its 601 signalling exchange and ESP encryption in the data plane, while the 602 use of shim6 requires neither (if only HBA addresses are used). HIP 603 by default provides data protection, while this is non-goal for 604 shim6. 606 The shim6 working group was chartered to provide a solution to a 607 specific problem while minimizing deployment disruption, while HIP is 608 considered more of an experimental approach intended to solve several 609 more general problems (mobility, multihoming, loss of end-to-end 610 addressing transparency) through an explicit identifier/locator 611 split. Communicating hosts that are willing and interested to run 612 HIP (perhaps extended with shim6's failure detection protocol) likely 613 have no reason to also run shim6. In this sense, HIP may be viewed 614 as a possible long-term evolution or extension of the shim6 615 architecture, or one possible implementation of the extended shim6 616 design ESD [I-D.nordmark-shim6-esd]. 618 6. Security Considerations 620 This section considers the applicability of the shim6 protocol from a 621 security perspective. This means, what security features can expect 622 applications and users of the shim6 protocol. 624 First of all, it should be noted that the shim6 protocol is not a 625 security protocol, like for instance HIP. This means that as opposed 626 to HIP, it is an explicit non goal of the shim6 protocol to provide 627 enhanced security for the communications that use the shim6 protocol. 628 The goal of the shim6 protocol design, in temrs of security is not to 629 introduce new vulnerabilities that were not present in the current 630 non-shim6 enabled communications. In particular, it is an explicit 631 non goal of the shim6 protocol security not to provide protection 632 from on path attackers. On path attackers are able to sniff and 633 spoof packets in the current Internet, and they are able to do the 634 same in shim6 communications (as long as the communication flows 635 through the path they are located on). So, summarizing, the shim6 636 protocol does not provide data packet protection from on-path 637 attackers. 639 However, the shim6 protocol does provide several security techniques. 640 The goals of these security measures is to protect the shim6 641 signalling protocol in order to prevent enabling new attacks through 642 the adoption of the shim6 protocol. In particular, the usage of the 643 HBA/CGA technique, prevents on-path and off-path attackers to 644 introduce new locators in the locator set of a shim6 context, 645 preventing redirection attacks. Moreover, the usage of probes before 646 using a locator as a destination address prevents flooding attacks 647 from off-path attackers. 649 In addition, the usage of a 4-way handshake for establishing the 650 shim6 context protects against DoS attacks, so hosts implementing the 651 shim6 protocol should not be more vulnerable to DoS attacks than 652 regular IPv6 hosts. 654 Finally, other shim6 signalling messages contain the context tag, 655 meaning that only attackers that know the context tag can forge them. 656 This means that only on-path attackers can generate false shim6 657 signalling packets for an established context. The impact of this 658 attacks would be limited since they wouldn't be able to add 659 additional locators to the locator set (because of the HBA/CGA 660 protection). In general the possible attacks have similar effects to 661 the ones that an on-path attacker can launch on any regular IPv6 662 communication. The residual threats are described in the Security 663 Considerations of the shim6 protocol specification 664 [I-D.ietf-shim6-proto]. 666 6.1. Privacy Considerations 668 The shim6 protocol is designed to provide some basic privacy 669 features. In particular, HBAs are generated in such a way, that the 670 different addresses assigned to a host cannot be trivially linked 671 together as belonging to the same host, since there is nothing in 672 common in the addresses themselves. Similar features are provided 673 when the CGA protection is used. This means that it is not trivial 674 to determine that a set of addresses is assigned to a single shim6 675 host. 677 However, the shim6 protocol does exchange the locator set in clear 678 text and it also uses a fixed context tag when using different 679 locators in a given context. This implies that an attacker that can 680 observe the shim6 context establishment exchange or that can see 681 different payload packets exchanged through different locators, but 682 with the same context tag can determine the set of addresses assigned 683 to a host. However this requires that the attacker is located along 684 the path and that he can capture the shim6 signalling packets. A 685 more in depth analysis of the privacy of the shim6 protocol can be 686 found in [I-D.bagnulo-shim6-privacy]. 688 7. Change History 690 This section should be removed prior to publication. 692 The list of Normative References to this document includes internet 693 drafts; publication of those documents on the standards track is a 694 prerequisite for the publication of this document, as-is. 696 draft-ietf-shim6-applicability-02: Removed Section about shim6 and 697 MIP RO; Added Section on shim6 and HIP. Completed the security 698 considerations section-. Added example of web client downloading 699 web contents through multiple short TCP connections. Added text 700 about other limiations of v4 support, inclusing increased address 701 consumtion and NAt traversal. Added text about no cooperation 702 between ISPs needed. Added text about how to not create shim6 703 contexts when using SCTP 704 draft-ietf-shim6-applicability-01: Added text for section 2 705 (Application scenarios), section 3 (About Address Configuration), 706 section 4 (Resulting shim6 capabilities) and section 5 707 (Interactions with other protocols). 708 draft-ietf-shim6-applicability-00: First draft, largely incomplete, 709 submitted to facilitate comments on general structure and 710 approach. 712 8. Contributors 714 The anlysis on the interaction between the shim6 protocol and the 715 other protocols presented in this note benefited from the advice of 716 various people including Tom Henderson, Erik Nordmark, Hesham 717 Soliman, Vijay Devarpalli, John Loughney and Dave Thaler. 719 9. Acknowledgements 721 Joe Abley's work was supported in part by the US National Science 722 Foundation (research grant SCI-0427144) and DNS-OARC. 724 Marcelo Bagnulo worked on this document while visiting Ericsson 725 Research Laboratory Nomadiclab. 727 Shinta Sugimoto reviewed this document and provided comments and 728 text. 730 Iljitsch van Beijnum, Brian Carpenter, Sam Xia reviewed this document 731 and provided comments. 733 10. References 735 10.1. Normative References 737 [I-D.ietf-shim6-failure-detection] 738 Arkko, J. and I. Beijnum, "Failure Detection and Locator 739 Pair Exploration Protocol for IPv6 Multihoming", 740 draft-ietf-shim6-failure-detection-06 (work in progress), 741 September 2006. 743 [I-D.ietf-shim6-hba] 744 Bagnulo, M., "Hash Based Addresses (HBA)", 745 draft-ietf-shim6-hba-02 (work in progress), October 2006. 747 [I-D.ietf-shim6-proto] 748 Bagnulo, M. and E. Nordmark, "Level 3 multihoming shim 749 protocol", draft-ietf-shim6-proto-05 (work in progress), 750 May 2006. 752 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 753 Discovery for IP Version 6 (IPv6)", RFC 2461, 754 December 1998. 756 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 757 Autoconfiguration", RFC 2462, December 1998. 759 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 760 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 761 Zhang, L., and V. Paxson, "Stream Control Transmission 762 Protocol", RFC 2960, October 2000. 764 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 765 and M. Carney, "Dynamic Host Configuration Protocol for 766 IPv6 (DHCPv6)", RFC 3315, July 2003. 768 [RFC3484] Draves, R., "Default Address Selection for Internet 769 Protocol version 6 (IPv6)", RFC 3484, February 2003. 771 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 772 (IPv6) Addressing Architecture", RFC 3513, April 2003. 774 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 775 in IPv6", RFC 3775, June 2004. 777 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 778 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 779 RFC 3963, January 2005. 781 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 782 Neighbor Discovery (SEND)", RFC 3971, March 2005. 784 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 785 RFC 3972, March 2005. 787 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 788 (HIP) Architecture", RFC 4423, May 2006. 790 10.2. Informative References 792 [I-D.bagnulo-ipv6-rfc3484-update] 793 Bagnulo, M., "Updating RFC 3484 for multihoming support", 794 draft-bagnulo-ipv6-rfc3484-update-00 (work in progress), 795 December 2005. 797 [I-D.bagnulo-shim6-privacy] 798 Bagnulo, M., "Privacy Analysis for the SHIM6 protocol", 799 draft-bagnulo-shim6-privacy-00 (work in progress), 800 February 2006. 802 [I-D.nikander-esp-beet-mode] 803 Melen, J. and P. Nikander, "A Bound End-to-End Tunnel 804 (BEET) mode for ESP", draft-nikander-esp-beet-mode-06 805 (work in progress), August 2006. 807 [I-D.nordmark-shim6-esd] 808 Nordmark, E., "Extended Shim6 Design for ID/loc split and 809 Traffic Engineering", draft-nordmark-shim6-esd-00 (work in 810 progress), February 2006. 812 [I-D.sugimoto-multihome-shim-api] 813 Komu, M., "Socket Application Program Interface (API) for 814 Multihoming Shim", draft-sugimoto-multihome-shim-api-00 815 (work in progress), June 2006. 817 [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the 818 Internet", RFC 3221, December 2001. 820 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 821 Multihoming Architectures", RFC 3582, August 2003. 823 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 824 Gill, "IPv4 Multihoming Practices and Limitations", 825 RFC 4116, July 2005. 827 Authors' Addresses 829 Joe Abley 830 Afilias Canada, Inc. 831 Suite 204 832 4141 Yonge Street 833 Toronto, Ontario M2P 2A8 834 Canada 836 Phone: +1 416 673 4176 837 Email: jabley@ca.afilias.info 838 URI: http://afilias.info/ 840 Marcelo Bagnulo 841 Universidad Carlos III de Madrid 842 Av. Universidad 30 843 Leganes, Madrid 28911 844 Spain 846 Phone: +34 91 6248814 847 Email: marcelo@it.uc3m.es 848 URI: http://www.it.uc3m.es/ 850 Full Copyright Statement 852 Copyright (C) The Internet Society (2006). 854 This document is subject to the rights, licenses and restrictions 855 contained in BCP 78, and except as set forth therein, the authors 856 retain all their rights. 858 This document and the information contained herein are provided on an 859 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 860 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 861 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 862 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 863 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 864 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 866 Intellectual Property 868 The IETF takes no position regarding the validity or scope of any 869 Intellectual Property Rights or other rights that might be claimed to 870 pertain to the implementation or use of the technology described in 871 this document or the extent to which any license under such rights 872 might or might not be available; nor does it represent that it has 873 made any independent effort to identify any such rights. Information 874 on the procedures with respect to rights in RFC documents can be 875 found in BCP 78 and BCP 79. 877 Copies of IPR disclosures made to the IETF Secretariat and any 878 assurances of licenses to be made available, or the result of an 879 attempt made to obtain a general license or permission for the use of 880 such proprietary rights by implementers or users of this 881 specification can be obtained from the IETF on-line IPR repository at 882 http://www.ietf.org/ipr. 884 The IETF invites any interested party to bring to its attention any 885 copyrights, patents or patent applications, or other proprietary 886 rights that may cover technology that may be required to implement 887 this standard. Please address the information to the IETF at 888 ietf-ipr@ietf.org. 890 Acknowledgment 892 Funding for the RFC Editor function is provided by the IETF 893 Administrative Support Activity (IASA).