idnits 2.17.1 draft-ietf-shim6-applicability-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 30, 2009) is 5260 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 179 -- Looks like a reference, but probably isn't: '2' on line 180 ** 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) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-09) exists of draft-ietf-csi-dhcpv6-cga-ps-00 == Outdated reference: A later version (-17) exists of draft-ietf-shim6-multihome-shim-api-10 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: June 3, 2010 A. Garcia-Martinez 6 UC3M 7 November 30, 2009 9 Applicability Statement for the Level 3 Multihoming Shim Protocol 10 (Shim6) 11 draft-ietf-shim6-applicability-04 13 Abstract 15 This document discusses the applicability of the Shim6 IPv6 protocol 16 and associated support protocols and mechanisms to provide site 17 multihoming capabilities in IPv6. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on June 3, 2010. 42 Copyright Notice 44 Copyright (c) 2009 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 3 73 3. Address Configuration . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Protocol Version (IPv4 vs. IPv6) . . . . . . . . . . . . . 5 75 3.2. Prefix Lengths . . . . . . . . . . . . . . . . . . . . . . 5 76 3.3. Address Generation . . . . . . . . . . . . . . . . . . . . 6 77 3.4. Use of CGA vs. HBA . . . . . . . . . . . . . . . . . . . . 6 78 4. Shim6 and Ingress Filtering . . . . . . . . . . . . . . . . . 7 79 5. Shim6 Capabilities . . . . . . . . . . . . . . . . . . . . . . 8 80 5.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 8 81 5.1.1. Establishing Communications After an Outage . . . . . 8 82 5.1.2. Short-Lived Communications . . . . . . . . . . . . . . 8 83 5.1.3. Long-Lived Communications . . . . . . . . . . . . . . 9 84 5.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 9 85 5.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 9 86 6. Application Considerations . . . . . . . . . . . . . . . . . . 10 87 7. Interaction with Other Protocols . . . . . . . . . . . . . . . 11 88 7.1. Shim6 and Mobile IPv6 . . . . . . . . . . . . . . . . . . 11 89 7.1.1. Multihomed Home Network . . . . . . . . . . . . . . . 11 90 7.1.2. Shim6 Between the HA and the MN . . . . . . . . . . . 14 91 7.2. Shim6 and SeND . . . . . . . . . . . . . . . . . . . . . . 14 92 7.3. Shim6 and SCTP . . . . . . . . . . . . . . . . . . . . . . 15 93 7.4. Shim6 and NEMO . . . . . . . . . . . . . . . . . . . . . . 15 94 7.5. Shim6 and HIP . . . . . . . . . . . . . . . . . . . . . . 16 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 17 97 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction 106 Site multihoming is an arrangement by which a site may use multiple 107 paths to the rest of the Internet to provide better reliability for 108 traffic passing in and out of the site than would be possible with a 109 single path. Some of the motivations for operators to multi-home 110 their network are described in [RFC3582]. 112 In IPv4, site multihoming is achieved by injecting into introducing 113 the global Internet routing system (sometimes referred to as the 114 Default-Free Zone, or DFZ) the additional state required to allow 115 session resilience over re-homing events [RFC4116]. There is concern 116 that this approach will not scale [RFC3221], [RFC4984]. 118 In IPv6, site multihoming in the style of IPv4 is not generally 119 available to end sites due to a strict policy of route aggregation in 120 the DFZ. Site multihoming for sites without PI addresses is achieved 121 by assigning multiple addresses to each host, one or more from each 122 provider. This multihoming approach provides no transport-layer 123 stability across re-homing events. 125 Shim6 provides layer-3 support for making re-homing events 126 transparent to the transport layer by means of a shim approach. 127 State information relating to the multihoming of two endpoints 128 exchanging unicast traffic is retained on the endpoints themselves, 129 rather than in the network. Communications between Shim6-capable 130 hosts and Shim6-incapable hosts proceed as normal, but without the 131 benefit of transport-layer stability. The Shim6 approach is thought 132 to have better scaling properties with respect to the state held in 133 the DFZ than the IPv4 approach. 135 This note describes the applicability of the Level 3 multihoming 136 (hereafter Shim6) protocol defined in [RFC5533] and the failure 137 detection mechanisms defined in [RFC5534]. 139 The terminology used in this document, including terms like locator, 140 and ULID, is defined in [RFC5533]. 142 2. Deployment Scenarios 144 The goal of the Shim6 protocol is to support locator agility in 145 established communications: different layer-3 endpoint addresses may 146 be used to exchange packets belonging to the same transport-layer 147 session, all the time presenting a consistent identifier pair to 148 upper-layer protocols. 150 In order to be useful, the Shim6 protocol requires that at least one 151 of the peers has more than one address which could be used on the 152 wire (as locators). In the event of communications failure between 153 an active pair of addresses, the Shim6 protocol will attempt to 154 reestablish communication by trying different combinations of 155 locators. 157 While other multi-addressing scenarios are not precluded, the 158 scenario in which the Shim6 protocol is expected to operate is that 159 of a multihomed site which is connected to multiple transit 160 providers, and which receives an IPv6 prefix from each of them. This 161 configuration is intended to provide protection for the end-site in 162 the event of a failure in some subset of the available transit 163 providers, without requiring the end-site to acquire provider- 164 independent (PI) address space or requiring any particular 165 cooperation between the transit providers. 167 ,------------------------------------. ,----------------. 168 | Rest of the Internet +-------+ Remote Host R | 169 `--+-----------+------------------+--' `----------------' 170 | | | LR[1] ... LR[m] 171 ,---+----. ,---+----. ,----+---. 172 | ISP[1] | | ISP[2] | ...... | ISP[n] | 173 `---+----' `---+----' `----+---' 174 | | | 175 ,---+-----------+------------------+---. 176 | Multi-Homed Site S assigned | 177 | prefixes P[1], P[2], ..., P[n] | 178 | | 179 | ,--------. L[1] = P[1]:iid[1], | 180 | | Host H | L[2] = P[2]:iid[2], ... | 181 | `--------' L[n] = P[n]:iid[n] | 182 `--------------------------------------' 184 Figure 1 186 In the scenario illustrated in Figure 1 host H communicates with some 187 remote host R. Each of the addresses L[i] configured on host H in the 188 multihomed site S can be reached through provider ISP[i] only, since 189 ISP[i] is solely responsible for advertising a covering prefix for 190 P[i] to the rest of the Internet. 192 The use of locator L[i] on H hence causes inbound traffic towards H 193 to be routed through ISP[i]. Changing the locator from L[i] to L[j] 194 will have the effect of re-routing inbound traffic to H from ISP[i] 195 to ISP[j]. This is the central mechanism by which the Shim6 protocol 196 aims to provide multihoming functionality: by changing locators, host 197 H can change the upstream ISP used to route inbound packets towards 198 itself. Regarding to the outbound traffic to H, the path taken in 199 this case depends on both the actual locator LR[j] chosen by R, and 200 the administrative exit selection policy of site S. 202 The Shim6 protocol has other potential applications beyond site 203 multihoming. For example, since Shim6 is a host-based protocol, it 204 can also be used to support host multihoming. In this case, a 205 failure in communication between a multihomed host and some other 206 remote host might be repaired by selecting a locator associated with 207 a different interface. 209 3. Address Configuration 211 3.1. Protocol Version (IPv4 vs. IPv6) 213 The Shim6 protocol is defined only for IPv6. However, there is no 214 fundamental reason why a Shim6-like approach could not support IPv4 215 addresses as locators, either to provide multihoming support to IPv4- 216 numbered sites, or as part of an IPv4/IPv6 transition strategy. Some 217 extensions to the Shim6 protocol for supporting IPv4 locators have 218 been proposed in [I-D.nordmark-shim6-esd]. 220 The Shim6 protocol, as specified for IPv6, incorporates cryptographic 221 elements in the construction of locators (see [RFC3972], [RFC5535]). 222 Since IPv4 addresses are insufficiently large to contain addresses 223 constructed in this fashion, direct implementation of Shim6 as 224 specified for IPv6 for use with IPv4 addresses might require protocol 225 modifications. 227 In addition, there are other factors to take into account when 228 considering the support of IPv4 addresses, in particular IPv4 229 locators. Using multiple IPv4 addresses in a single host in order to 230 support Shim6 style of multihoming would result in an increased IPv4 231 address consumption, which with the current rate of IPv4 addresses 232 would be problematic. Besides, in order to be useful, Shim6 IPv4 233 support would require NAT traversal mechanisms which are not defined 234 yet and that would imply additional complexity (as any other NAT 235 traversal mechanism). 237 3.2. Prefix Lengths 239 The Shim6 protocol does not assume that all the prefixes assigned to 240 the multihomed site have the same prefix length. 242 However, the use of CGA [RFC3972] and HBA [RFC5535] involve encoding 243 information in the lower 64 bits of the locators. This imposes the 244 requirement on address assignment to Shim6-capable hosts that all 245 interface addresses should be able to accommodate 64-bit interface 246 identifiers. It should be noted that this is imposed by RFC4291 247 [RFC4291] 249 3.3. Address Generation 251 The security of the Shim6 protocol is based on the use of CGA and HBA 252 addresses. 254 CGA and HBA generation process can use the information provided by 255 the stateless auto-configuration mechanism defined in [RFC4862] with 256 the additional considerations presented in [RFC3972] and [RFC5535]. 258 Stateful address auto-configuration using DHCP [RFC3315] is not 259 currently supported, because there is no defined mechanism to convey 260 the CGA Parameter Data Structure and other relevant information from 261 the DHCP server to the host. The definition of such mechanism seems 262 to be quite straightforward in the case of the HBA, since only the 263 CGA Parameter Data Structure needs to be delivered from the DHCP 264 server to the Shim6 host, and this data structure does not contain 265 any secret information. In the case of CGAs, the difficulty is 266 increased, since private key information should be exchanged as well 267 as the CGA Parameter Data Structure. However, with appropriate 268 extensions a DHCP server could inform to a host about the SEC value 269 to use when generating an address, or DHCP could even be used by the 270 host to delegate to the server the CPU-intensive task of computing a 271 Modifier for a given combination 272 [I-D.ietf-csi-dhcpv6-cga-ps]. 274 3.4. Use of CGA vs. HBA 276 The choice between CGA and HBA is a trade-off between flexibility and 277 performance. 279 The use of HBA is more efficient in the sense that addresses require 280 less computation than CGA, involving only hash operations for both 281 the generation and the verification of locator sets. However, the 282 locators of an HBA set are determined during the generation process, 283 and cannot be subsequently changed; the addition of new locators to 284 that initial set is not supported, except by re-generation of the 285 entire set which will in turn cause all addresses to change. 287 The use of CGA is more computationally expensive, involving public 288 key cryptography in the verification of locator sets. However, CGAs 289 are more flexible in the sense that they support the dynamic 290 modification of locator sets. 292 Therefore, CGAs are well suited to support dynamic environments such 293 as mobile hosts, where the locator set must be changed frequently. 295 HBAs are better suited for sites where the prefix set remains 296 relatively stable. 298 It should be noted that, since HBAs are defined as a CGA extension, 299 it is possible to generate hybrid HBA/CGA structures that incorporate 300 the strengths of both: i.e. that a single address can be used as an 301 HBA, enabling computationally-cheap validation amongst a fixed set of 302 addresses, and also as a CGA, enabling dynamic manipulation of the 303 locator set. For additional details, see [RFC5535]. 305 4. Shim6 and Ingress Filtering 307 Ingress filtering [RFC2827] prevents address spoofing by dropping 308 packets which come from customer networks with source addresses not 309 belonging to the prefix assigned to them. The problem of deploying 310 ingress filters with multihomed customers is discussed in [RFC3704], 311 in particular considering the case in which non-PI addresses are used 312 by customer networks. This is the case for IPv6 hosts in multihomed 313 networks with PA, and also for a Shim6 host in a multihomed network. 314 Note that this is also the case for other solutions supporting 315 multihoming, such as SCTP [RFC4960], HIP [RFC4423], etc. 317 [RFC3704] proposes that non-PI addresses should ensure that each 318 packet should be delivered to the provider related with the prefix of 319 its source address. To deliver packets to the appropriate outgoing 320 ISP, forwarding decisions must consider source addresses, in addition 321 to usual destination-based forwarding. Tunneling may be used in the 322 customer network to reduce the number of routers in which forwarding 323 have to take source address into account. 325 For hosts attached directly to networks of different providers, a 326 host solution to ensure that packets are forwarded to the appropriate 327 interface according to its source address must be provided. This 328 problem is under discussion in the Multiple Interfaces (MIF) IETF 329 Working Group. 331 Shim6 has no means to enforce neither host nor network forwarding for 332 a given local locator. If any notification is received from the 333 router dropping the packets with legitimate source addresses as a 334 result of ingress filtering, the affected locator could be associated 335 to a low preference (or not being used at all). Note that even if 336 such notification is not received, or not processed by the Shim6 337 layer, defective ingress filtering configuration will be treated as a 338 communication failure, and Shim6 re-homing would finally select a 339 working path in which packets are not filtered, if this path exists. 341 5. Shim6 Capabilities 343 5.1. Fault Tolerance 345 5.1.1. Establishing Communications After an Outage 347 If a host within a multihomed site attempts to establish a 348 communication with a remote host and selects a locator which 349 corresponds to a failed transit path, bidirectional communication 350 between the two hosts will not succeed. In order to establish a new 351 communication, the initiating host must try different combinations of 352 (source, destination) locator pairs until it finds a pair that works. 353 The mechanism for this default address selection is described in 354 [RFC3484]. A commentary on this mechanism in the context of 355 multihomed environments can be found in 356 [I-D.bagnulo-ipv6-rfc3484-update]. 358 Since a Shim6 context is normally only established between two hosts 359 after initial communication has been set up, there is no opportunity 360 for Shim6 to participate in the discovery of a suitable, initial 361 (source, destination) locator pair. The same consideration holds for 362 referrals, as it is described in Section 6. 364 5.1.2. Short-Lived Communications 366 The Shim6 context establishment operation requires a 4-way packet 367 exchange, and involves some overhead on the participating hosts in 368 memory and CPU. 370 For short-lived communications between two hosts, the benefit of 371 establishing a Shim6 context might not exceed the cost, perhaps 372 because the protocols concerned are fault tolerant and can arrange 373 their own recovery (e.g. DNS) or because the frequency of re-homing 374 events is sufficiently low that the probability of such a failure 375 occurring during a short-lived exchange is not considered 376 significant. 378 It is anticipated that the exchange of Shim6 context will provide 379 most benefit for exchanges between hosts which are long-lived. For 380 this reason the default behaviour of Shim6-capable hosts is expected 381 to employ deferred context-establishment. This default behaviour 382 will be able to be overridden by applications which prefer immediate 383 context establishment regardless of transaction longevity. 385 It must be noted that all the above considerations refer to the 386 lifetime of the interaction between the peers and not about the 387 lifetime of a particular connection (e.g. TCP connection). In other 388 words, the Shim6 context is established between ULID pairs and it 389 affects all the communication between these ULIDs. So, two nodes 390 with multiple short-lived communications using the same ULID pair 391 would benefit as much from the Shim6 features as two nodes having a 392 single long-lived communication. One example of such scenario would 393 be a web client software downloading web contents from a server over 394 multiple TCP connections. Each TCP connection is short-lived, but 395 the communication/contact between the two ULID could be long-lived. 397 5.1.3. Long-Lived Communications 399 As discussed in Section 5.1.2, hosts engaged in long-lived 400 communications will suffer lower proportional overhead, and greater 401 probability of benefit than those performing brief transactions. 403 Deferred context setup ensures that session establishment time will 404 not be increased by the use of Shim6. 406 5.2. Load Balancing 408 The Shim6 protocol does not support load balancing within a single 409 context: all packets associated with a particular context are 410 exchanged using a single locator pair per direction, with the 411 exception of forked contexts, which are created upon explicit 412 requests from the upper-layer protocol. 414 It may be possible to extend the Shim6 protocol to use multiple 415 locator pairs in a single context, but the impact of such an 416 extension on upper-layer protocols (e.g. on TCP congestion control) 417 should be considered carefully. 419 When many contexts are considered together in aggregation, e.g. on a 420 single host which participates in many simultaneous contexts or in a 421 site full of hosts, some degree of load sharing should occur 422 naturally due to the selection of different locator pairs in each 423 context. However, there is no mechanism defined to ensure that this 424 natural load sharing is arranged to provide a statistical balance 425 between transit providers. 427 5.3. Traffic Engineering 429 The Shim6 protocol provides some lightweight traffic engineering 430 capabilities in the form of the Locator Preferences option, which 431 allows a host to inform a remote host of local preferences for 432 locator selection. 434 This mechanism is only available after a Shim6 context has been 435 established, and it is a host-based capability rather than a site- 436 based capability. There is no defined mechanism which would allow 437 use of the Locator Preferences option amongst a site full of hosts to 438 be managed centrally. 440 6. Application Considerations 442 Shim6 provides multihoming support without forcing changes in the 443 applications running on the host. The fact that an address has been 444 generated according to the CGA or HBA specification does not require 445 any specific action from the application, e.g. it can obtain remote 446 CGA or HBA addresses as a result of a getaddrinfo() call to trigger a 447 DNS Request. The storage of CGA or HBA addresses in DNS does not 448 require also any modification of this protocol, since they are 449 recorded using AAAA records. Moreover, neither the ULID/locator 450 management [RFC5533] nor the failure detection and recovery [RFC5534] 451 functions require application awareness. 453 However, a specific API [I-D.ietf-shim6-multihome-shim-api] is being 454 developed for those applications which might require additional 455 capabilities in ULID/locator management, such as the locator pair in 456 use for a given context, or the set of local or remote locators 457 available for it. This API can also be used to disable Shim6 458 operation when required. 460 It is worth to note that callbacks can benefit naturally from Shim6 461 support. In a callback, an application in B retrieves IP_A, the IP 462 address of a peer A, and B uses IP_A to establish a new communication 463 with A. As long as the address exchanged, IP_A is the ULID for the 464 initial communication between A and B, and B uses the same address as 465 in the initial communication, and this initial communication is alive 466 (or the context has not been deleted), the new communication could 467 use the locators exchanged by Shim6 for the first communication. In 468 this case, communication could proceed even if the ULID of A is not 469 reachable. 471 However, Shim6 does not provide specific protection to current 472 applications when they use referrals. A referral is the exchange of 473 the IP address IP_A of a party A by party B to party C, so that party 474 C could use IP_A to communicate with party A 475 [I-D.ietf-multi6-app-refer]. In a normal case, the ULID IP_A would 476 be the only information sent by B to C as referral. But if IP_A is 477 no longer valid as locator in A, C could have trouble in establishing 478 a communication with A. Increased failure protection for referrals 479 could be obtained if B exchanged the whole list of alternative 480 locators of A, although in this case the application protocol should 481 be modified. Note that B could send to C the current locator of A, 482 instead of the ULID of A, as a way of using the most recent 483 reachability information about A. While in this case no modification 484 of the application protocol is required, some concerns arise: host A 485 may not accept one of its locator as ULID for initiating a 486 communication, and if CGA are used, the locator may not be a CGA so a 487 Shim6 context among A and C could not be created. 489 7. Interaction with Other Protocols 491 7.1. Shim6 and Mobile IPv6 493 We next consider some scenarios in which the Shim6 protocol and the 494 MIPv6 protocol [RFC3775] might be used simultaneously. 496 7.1.1. Multihomed Home Network 498 In this case, the Home Network of the Mobile Node (MN) is multihomed. 499 This implies the availability of multiple Home Network prefixes, 500 resulting on multiple HoAs for each MN. Since the MN is a node 501 within a multihomed site, it seems reasonable to expect that the MN 502 should be able to benefit from the multihoming capabilities provided 503 by the Shim6 protocol. Moreover, the MN needs to be able to obtain 504 the multihoming benefits even when it is roaming away from the Home 505 Network: if the MN is away from the Home Network while the Home 506 Network suffers a failure in a transit path, the MN should be able to 507 continue communicating using alternate paths to reach the Home 508 Network. 510 The resulting scenario is the following: 512 +------------------------------------+ 513 | Internet | 514 +------------------------------------+ 515 | | 516 +----+ +----+ 517 |ISP1| |ISP2| 518 +----+ +----+ 519 | | 520 +------------------------------------+ 521 | Multihomed Home Network | 522 | Prefixes: P1 and P2 | 523 | | 524 | Home Agent | 525 | // | 526 +------------------//----------------+ 527 // 528 // 529 +-----+ 530 | MN | HoA1, HoA2 531 +-----+ 533 Figure 2 535 So, in this configuration, the Shim6 protocol is used to provide 536 multiple communication paths to all the nodes within the multihomed 537 sites (including the mobile nodes) and the MIPv6 protocol is used to 538 support mobility of the mobile nodes of the multihomed site. 540 The proposed protocol architecture would be the following: 542 +--------------+ 543 | Application | 544 +--------------+ 545 | Transport | 546 +--------------+ 547 | IP | 548 | +----------+ | 549 | | IPSec | | 550 | +----------+<--ULIDs 551 | | Shim6 | | 552 | +----------+<--HoAs 553 | | MIPv6 | | 554 | +----------+<--CoAs 555 | | 556 +--------------+ 558 Figure 3 560 In this architecture, the upper layer protocols and IPSec would use 561 ULIDs of the Shim6 protocol. Only the HoAs will be presented by the 562 upper layers to the Shim6 layer as potential ULIDs. Two Shim6 563 entities will exchange their own available HoAs as locators. 564 Therefore, Shim6 provides failover between different HoAs and allows 565 preserving established communications when an outage affects the path 566 through the ISP that has delegated the HoA used for initiating the 567 communication (similarly to the case of a host within a multihomed 568 site). The CoAs are not presented to the Shim6 layer and are not 569 included in the local locator set in this case. The CoAs are managed 570 by the MIPv6 layer, which binds each HoA to a CoA. 572 So, in this case, the upper layer protocols select a ULID pair for 573 the communication. The Shim6 protocol translates the ULID pair to an 574 alternative locator in case that is needed. Both the ULIDs and the 575 alternative locators are HoAs. Next, the MIPv6 layer maps the 576 selected HoA to the corresponding CoA, which is the actual address 577 included in the wire. 579 The Shim6 context is established between the MN and the CN, and it 580 would allow the communication to use all the available HoAs to 581 provide fault tolerance. The MIPv6 protocol is used between the MN 582 and the HA in the case of the bidirectional tunnel mode, and between 583 the MN and the CN in case of the RO (Route Optimization) mode. 585 7.1.2. Shim6 Between the HA and the MN 587 Another scenario where a Shim6-MIPv6 interaction may be useful is the 588 case where a Shim6 context is established between the MN and the HA 589 in order to provide fault tolerance capabilities to the bidirectional 590 tunnel between them. 592 Consider the case where the HA has multiple addresses (whether 593 because the Home Network is multihomed or because the HA has multiple 594 interfaces) and/or the MN has multiple addresses (whether because the 595 visited network is multihomed or because the MN has multiple 596 interfaces). In this case, if a failure affects the address pair 597 that is being used to run the tunnel between the MN and HA, 598 additional mechanisms need to be used to preserve the communication. 600 One possibility would be to use MIPv6 capabilities, by simply 601 changing the CoA used as the tunnel endpoint. However, MIPv6 lacks 602 of failure detection mechanisms that would allow the MN and/or the HA 603 to detect the failure and trigger the usage of an alternative 604 address. Shim6 provides such failure detection protocol, so one 605 possibility would be re-using the failure detection function from the 606 Shim6 failure detection protocol in MIPv6. In this case, the Shim6 607 protocol wouldn't be used to create Shim6 context and provide fault 608 tolerance, but just its failure detection functionality would be re- 609 used. 611 The other possibility would be to use the Shim6 protocol to create a 612 Shim6 context between the HA and the MN so that the Shim6 detects any 613 failure and re-homes the communication in a transparent fashion to 614 MIPv6. In this case, the Shim6 protocol would be associated to the 615 tunnel interface. 617 7.2. Shim6 and SeND 619 Secure Neighbor Discovery (SeND) [RFC3971] uses CGAs to prove address 620 ownership for Neighbor Discovery [RFC4861]. The Shim6 protocol can 621 use either CGAs or HBAs to protect locator sets included in Shim6 622 contexts. It is expected that some hosts will need to participate in 623 both SeND and Shim6 simultaneously. 625 In the case that both the SeND and Shim6 protocols are using the CGA 626 technique to generate addresses, then there is no conflict: the host 627 will generate addresses for both purposes as CGAs, and since it will 628 be in control of the associated private key, the same CGA can be used 629 for the different protocols. 631 In the case that a Shim6-capable host is using HBAs to protect its 632 locator sets, the host will need to generate hybrid HBA/CGA addresses 633 as defined in [RFC5535] and discussed briefly in Section 3.4. In 634 this case, the CGA Parameter Data Structure containing a valid public 635 key and the Multi-Prefix extension are included as inputs to the hash 636 function. 638 7.3. Shim6 and SCTP 640 The SCTP [RFC4960] protocol provides a reliable, stream-based 641 communications channel between two hosts which provides a superset of 642 the capabilities of TCP. One of the notable features of SCTP is that 643 it allows the exchange of endpoint addresses between hosts, and is 644 able to recover from the failure of a particular endpoint pair in a 645 manner which is conceptually similar to locator selection in Shim6. 647 SCTP is a transport-layer protocol, higher in the protocol stack than 648 Shim6, and hence there is no fundamental incompatibility which would 649 prevent a Shim6-capable host from communicating using SCTP. 651 However, since SCTP and Shim6 both aim to exchange addressing 652 information between hosts in order to meet the same generic goal, it 653 is possible that their simultaneous use might result in unexpected 654 behaviour, e.g. lead to race conditions. 656 The capabilities of SCTP with respect to path maintenance of a 657 reliable, connection-oriented stream protocol are more extensive than 658 the more general layer-3 locator agility provided by Shim6. 659 Therefore, It is recommended that Shim6 is not used for SCTP 660 sessions, and that path maintenance is provided solely by SCTP. 661 There are at least two ways to enforce this behaviour. One option 662 would be to make the stack, and in particular the Shim6 sublayer, 663 aware of SCTP sockets and in this case refrain from creating a Shim6 664 context. The other option is that the upper layer, SCTP in this 665 case, informs using a Shim6 capable API like the one proposed in 666 [I-D.ietf-shim6-multihome-shim-api] that no Shim6 context must be 667 created for this particular communication. 669 7.4. Shim6 and NEMO 671 The NEMO [RFC3963] protocol extensions to MIPv6 allow a Mobile 672 Network to communicate through a bidirectional tunnel via a Mobile 673 Router (MR) to a NEMO-compliant Home Agent (HA) located in a Home 674 Network. 676 If either or both of the MR or HA are multihomed, then a Shim6 677 context established preserves the integrity of the bidirectional 678 tunnel between them in the event that a transit failure occurs in the 679 connecting path. 681 Once the tunnel between MR and HA is established, hosts within the 682 Mobile Network which are Shim6-capable can establish contexts with 683 remote hosts in order to receive the same multihoming benefits as any 684 host located within the Home Network. 686 7.5. Shim6 and HIP 688 Shim6 and the Host Identity Protocol ( HIP [RFC4423]) are 689 architecturally similar in the sense that both solutions allow two 690 hosts to use different locators to support communications between 691 stable ULIDs. The signaling exchange to establish the demultiplexing 692 context on the hosts is very similar for both protocols. However, 693 there are a few key differences. First, Shim6 avoids defining a new 694 namespace for ULIDs, preferring instead to use a routable locator as 695 a ULID, while HIP uses public keys and hashes thereof as ULIDs. The 696 use of a routable locator as ULID better supports deferred context 697 establishment, application callbacks, and application referrals, and 698 avoids management and resolution costs of a new namespace, but 699 requires additional security mechanisms to securely bind the ULID 700 with the locators. Second, Shim6 uses an explicit context header on 701 data packets for which the ULIDs differ from the locators in use 702 (this header is only needed after a failure/rehoming event occurs), 703 while HIP compresses this context tag into the ESP SPI field of a 704 BEET-mode security association BEET [I-D.nikander-esp-beet-mode]. 705 Third, HIP as presently defined requires the use of public-key 706 operations in its signaling exchange and ESP encryption in the data 707 plane, while the use of Shim6 requires neither (if only HBA addresses 708 are used). HIP by default provides data protection, while this is a 709 non goal for Shim6. 711 The Shim6 working group was chartered to provide a solution to a 712 specific problem, multihoming, which minimizes deployment disruption, 713 while HIP is considered more of an experimental approach intended to 714 solve several more general problems (mobility, multihoming and loss 715 of end-to-end addressing transparency) through an explicit 716 identifier/locator split. Communicating hosts that are willing and 717 interested to run HIP (perhaps extended with Shim6's failure 718 detection protocol) likely have no reason to also run Shim6. In this 719 sense, HIP may be viewed as a possible long-term evolution or 720 extension of the Shim6 architecture, or one possible implementation 721 of the extended Shim6 design ESD [I-D.nordmark-shim6-esd]. 723 8. Security Considerations 725 This section considers the applicability of the Shim6 protocol from a 726 security perspective, i.e. which security features can expect 727 applications and users of the Shim6 protocol. 729 First of all, it should be noted that the Shim6 protocol is not a 730 security protocol, like for instance HIP. This means that as opposed 731 to HIP, it is an explicit non goal of the Shim6 protocol to provide 732 enhanced security for the communications that use the Shim6 protocol. 733 The goal of the Shim6 protocol design in terms of security is not to 734 introduce new vulnerabilities that were not present in the current 735 non-Shim6 enabled communications. In particular, it is an explicit 736 non goal of the Shim6 protocol security to provide protection from 737 on-path attackers. On-path attackers are able to sniff and spoof 738 packets in the current Internet, and they are able to do the same in 739 Shim6 communications (as long as the communication flows through the 740 path they are located on). So, summarizing, the Shim6 protocol does 741 not provide data packet protection from on-path attackers. 743 However, the Shim6 protocol does use several security techniques. 744 The goal of these security measures is to protect the Shim6 signaling 745 protocol from new attacks resulting from the adoption of the Shim6 746 protocol. In particular, the use of HBA/CGA prevents on-path and 747 off-path attackers to introduce new locators in the locator set of a 748 Shim6 context, preventing redirection attacks [RFC4218]. Moreover, 749 the usage of probes before re-homing to a different locator as a 750 destination address prevents flooding attacks from off-path 751 attackers. 753 In addition, the usage of a 4-way handshake for establishing the 754 Shim6 context protects against DoS attacks, so hosts implementing the 755 Shim6 protocol should not be more vulnerable to DoS attacks than 756 regular IPv6 hosts. 758 Finally, many Shim6 signaling messages contain a Context Tag, meaning 759 that only attackers that know the Context Tag can forge them. As a 760 consequence, only on-path attackers can generate false Shim6 761 signaling packets for an established context. The impact of these 762 attacks would be limited since they would not be able to add 763 additional locators to the locator set (because of the HBA/CGA 764 protection). In general the possible attacks have similar effects to 765 the ones that an on-path attacker can launch on any regular IPv6 766 communication. The residual threats are described in the Security 767 Considerations of the Shim6 protocol specification [RFC5533]. 769 8.1. Privacy Considerations 771 The Shim6 protocol is designed to provide some basic privacy 772 features. In particular, HBAs are generated in such a way, that the 773 different addresses assigned to a host cannot be trivially linked 774 together as belonging to the same host, since there is nothing in 775 common in the addresses themselves. Similar features are provided 776 when the CGA protection is used. This means that it is not trivial 777 to determine that a set of addresses is assigned to a single Shim6 778 host. 780 However, the Shim6 protocol does exchange the locator set in clear 781 text and it also uses a fixed Context Tag when using different 782 locators in a given context. This implies that an attacker observing 783 the Shim6 context establishment exchange or seeing different payload 784 packets exchanged through different locators, but with the same 785 Context Tag, can determine the set of addresses assigned to a host. 786 However, this requires that the attacker is located along the path 787 and that it can capture the Shim6 signaling packets. A more in depth 788 analysis of the privacy of the Shim6 protocol can be found in 789 [I-D.bagnulo-shim6-privacy]. 791 9. Contributors 793 The analysis on the interaction between the Shim6 protocol and the 794 other protocols presented in this note benefited from the advice of 795 various people including Tom Henderson, Erik Nordmark, Hesham 796 Soliman, Vijay Devarpalli, John Loughney and Dave Thaler. 798 10. Acknowledgements 800 Joe Abley's work was supported in part by the US National Science 801 Foundation (research grant SCI-0427144) and DNS-OARC. 803 Marcelo Bagnulo worked on this document while visiting Ericsson 804 Research Laboratory Nomadiclab. 806 Shinta Sugimoto reviewed this document and provided comments and 807 text. 809 Iljitsch van Beijnum, Brian Carpenter, Sam Xia reviewed this document 810 and provided comments. 812 11. References 814 11.1. Normative References 816 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 817 Defeating Denial of Service Attacks which employ IP Source 818 Address Spoofing", BCP 38, RFC 2827, May 2000. 820 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 821 and M. Carney, "Dynamic Host Configuration Protocol for 822 IPv6 (DHCPv6)", RFC 3315, July 2003. 824 [RFC3484] Draves, R., "Default Address Selection for Internet 825 Protocol version 6 (IPv6)", RFC 3484, February 2003. 827 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 828 Networks", BCP 84, RFC 3704, March 2004. 830 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 831 in IPv6", RFC 3775, June 2004. 833 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 834 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 835 RFC 3963, January 2005. 837 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 838 Neighbor Discovery (SEND)", RFC 3971, March 2005. 840 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 841 RFC 3972, March 2005. 843 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 844 Architecture", RFC 4291, February 2006. 846 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 847 (HIP) Architecture", RFC 4423, May 2006. 849 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 850 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 851 September 2007. 853 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 854 Address Autoconfiguration", RFC 4862, September 2007. 856 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 857 RFC 4960, September 2007. 859 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 860 Workshop on Routing and Addressing", RFC 4984, 861 September 2007. 863 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 864 Shim Protocol for IPv6", RFC 5533, June 2009. 866 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 867 Locator Pair Exploration Protocol for IPv6 Multihoming", 868 RFC 5534, June 2009. 870 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 871 June 2009. 873 11.2. Informative References 875 [I-D.bagnulo-ipv6-rfc3484-update] 876 Bagnulo, M., "Updating RFC 3484 for multihoming support", 877 draft-bagnulo-ipv6-rfc3484-update-00 (work in progress), 878 December 2005. 880 [I-D.bagnulo-shim6-privacy] 881 Bagnulo, M., "Privacy Analysis for the SHIM6 protocol", 882 draft-bagnulo-shim6-privacy-01 (work in progress), 883 October 2006. 885 [I-D.ietf-csi-dhcpv6-cga-ps] 886 Jiang, S., Shen, S., and T. Chown, "DHCPv6 and CGA 887 Interaction: Problem Statement", 888 draft-ietf-csi-dhcpv6-cga-ps-00 (work in progress), 889 October 2009. 891 [I-D.ietf-multi6-app-refer] 892 Nordmark, E., "Multi6 Application Referral Issues", 893 draft-ietf-multi6-app-refer-00 (work in progress), 894 January 2005. 896 [I-D.ietf-shim6-multihome-shim-api] 897 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 898 "Socket Application Program Interface (API) for 899 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-10 900 (work in progress), October 2009. 902 [I-D.nikander-esp-beet-mode] 903 Nikander, P. and J. Melen, "A Bound End-to-End Tunnel 904 (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 905 (work in progress), August 2008. 907 [I-D.nordmark-shim6-esd] 908 Nordmark, E., "Extended Shim6 Design for ID/loc split and 909 Traffic Engineering", draft-nordmark-shim6-esd-01 (work in 910 progress), February 2008. 912 [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the 913 Internet", RFC 3221, December 2001. 915 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 916 Multihoming Architectures", RFC 3582, August 2003. 918 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 919 Gill, "IPv4 Multihoming Practices and Limitations", 920 RFC 4116, July 2005. 922 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 923 Multihoming Solutions", RFC 4218, October 2005. 925 Authors' Addresses 927 Joe Abley 928 Afilias Canada, Inc. 929 Suite 204 930 4141 Yonge Street 931 Toronto, Ontario M2P 2A8 932 Canada 934 Phone: +1 416 673 4176 935 Email: jabley@ca.afilias.info 936 URI: http://afilias.info/ 938 Marcelo Bagnulo 939 U. Carlos III de Madrid 940 Av. Universidad 30 941 Leganes, Madrid 28911 942 Spain 944 Phone: +34 91 6248814 945 Email: marcelo@it.uc3m.es 946 URI: http://www.it.uc3m.es/ 948 Alberto Garcia Martinez 949 U. Carlos III de Madrid 950 Av. Universidad 30 951 Leganes, Madrid 28911 952 Spain 954 Phone: +34 91 6248782 955 Email: alberto@it.uc3m.es 956 URI: http://www.it.uc3m.es/