idnits 2.17.1 draft-ietf-shim6-applicability-05.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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 15, 2010) is 5176 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 180 -- Looks like a reference, but probably isn't: '2' on line 181 ** 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 (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-08 == Outdated reference: A later version (-09) exists of draft-ietf-csi-dhcpv6-cga-ps-01 == Outdated reference: A later version (-17) exists of draft-ietf-shim6-multihome-shim-api-12 Summary: 6 errors (**), 0 flaws (~~), 4 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: August 19, 2010 A. Garcia-Martinez 6 UC3M 7 February 15, 2010 9 Applicability Statement for the Level 3 Multihoming Shim Protocol 10 (Shim6) 11 draft-ietf-shim6-applicability-05 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 August 19, 2010. 42 Copyright Notice 44 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . 9 80 5.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 9 81 5.1.1. Establishing Communications After an Outage . . . . . 9 82 5.1.2. Short-Lived Communications . . . . . . . . . . . . . . 9 83 5.1.3. Long-Lived Communications . . . . . . . . . . . . . . 10 84 5.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 10 85 5.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 10 86 6. Application Considerations . . . . . . . . . . . . . . . . . . 11 87 7. Interaction with Other Protocols . . . . . . . . . . . . . . . 12 88 7.1. Shim6 and Mobile IPv6 . . . . . . . . . . . . . . . . . . 12 89 7.1.1. Multihomed Home Network . . . . . . . . . . . . . . . 12 90 7.1.2. Shim6 Between the HA and the MN . . . . . . . . . . . 15 91 7.2. Shim6 and SeND . . . . . . . . . . . . . . . . . . . . . . 15 92 7.3. Shim6 and SCTP . . . . . . . . . . . . . . . . . . . . . . 16 93 7.4. Shim6 and NEMO . . . . . . . . . . . . . . . . . . . . . . 16 94 7.5. Shim6 and HIP . . . . . . . . . . . . . . . . . . . . . . 17 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 96 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 19 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 98 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 100 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 102 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 105 1. Introduction 107 Site multihoming is an arrangement by which a site may use multiple 108 paths to the rest of the Internet to provide better reliability for 109 traffic passing in and out of the site than would be possible with a 110 single path. Some of the motivations for operators to multi-home 111 their network are described in [RFC3582]. 113 In IPv4, site multihoming is achieved by injecting into the global 114 Internet routing system (sometimes referred to as the Default-Free 115 Zone, or DFZ) the additional state required to allow session 116 resilience over re-homing events [RFC4116]. There is concern that 117 this approach will not scale [RFC3221], [RFC4984]. 119 In IPv6, site multihoming in the style of IPv4 is not generally 120 available to end sites due to a strict policy of route aggregation in 121 the DFZ. Site multihoming for sites without provider-independent 122 (PI) addresses is achieved by assigning multiple addresses to each 123 host, one or more from each provider. This multihoming approach 124 provides no transport-layer stability across re-homing events. 126 Shim6 provides layer-3 support for making re-homing events 127 transparent to the transport layer by means of a shim approach. 128 State information relating to the multihoming of two endpoints 129 exchanging unicast traffic is retained on the endpoints themselves, 130 rather than in the network. Communications between Shim6-capable 131 hosts and Shim6-incapable hosts proceed as normal, but without the 132 benefit of transport-layer stability. The Shim6 approach is thought 133 to have better scaling properties with respect to the state held in 134 the DFZ than the IPv4 approach. 136 This note describes the applicability of the Level 3 multihoming 137 (hereafter Shim6) protocol defined in [RFC5533] and the failure 138 detection mechanisms defined in [RFC5534]. 140 The terminology used in this document, including terms like locator, 141 and ULID, is defined in [RFC5533]. 143 2. Deployment Scenarios 145 The goal of the Shim6 protocol is to support locator agility in 146 established communications: different layer-3 endpoint addresses may 147 be used to exchange packets belonging to the same transport-layer 148 session, all the time presenting a consistent identifier pair to 149 upper-layer protocols. 151 In order to be useful, the Shim6 protocol requires that at least one 152 of the peers has more than one address which could be used on the 153 wire (as locators). In the event of communications failure between 154 an active pair of addresses, the Shim6 protocol will attempt to 155 reestablish communication by trying different combinations of 156 locators. 158 While other multi-addressing scenarios are not precluded, the 159 scenario in which the Shim6 protocol is expected to operate is that 160 of a multihomed site which is connected to multiple transit 161 providers, and which receives an IPv6 prefix from each of them. This 162 configuration is intended to provide protection for the end-site in 163 the event of a failure in some subset of the available transit 164 providers, without requiring the end-site to acquire PI address space 165 or requiring any particular cooperation between the transit 166 providers. 168 ,------------------------------------. ,----------------. 169 | Rest of the Internet +-------+ Remote Host R | 170 `--+-----------+------------------+--' `----------------' 171 | | | LR[1] ... LR[m] 172 ,---+----. ,---+----. ,----+---. 173 | ISP[1] | | ISP[2] | ...... | ISP[n] | 174 `---+----' `---+----' `----+---' 175 | | | 176 ,---+-----------+------------------+---. 177 | Multi-Homed Site S assigned | 178 | prefixes P[1], P[2], ..., P[n] | 179 | | 180 | ,--------. L[1] = P[1]:iid[1], | 181 | | Host H | L[2] = P[2]:iid[2], ... | 182 | `--------' L[n] = P[n]:iid[n] | 183 `--------------------------------------' 185 Figure 1 187 In the scenario illustrated in Figure 1 host H communicates with some 188 remote host R. Each of the addresses L[i] configured on host H in the 189 multihomed site S can be reached through provider ISP[i] only, since 190 ISP[i] is solely responsible for advertising a covering prefix for 191 P[i] to the rest of the Internet. 193 The use of locator L[i] on H hence causes inbound traffic towards H 194 to be routed through ISP[i]. Changing the locator from L[i] to L[j] 195 will have the effect of re-routing inbound traffic to H from ISP[i] 196 to ISP[j]. This is the central mechanism by which the Shim6 protocol 197 aims to provide multihoming functionality: by changing locators, host 198 H can change the upstream ISP used to route inbound packets towards 199 itself. Regarding to the outbound traffic to H, the path taken in 200 this case depends on both the actual locator LR[j] chosen by R, and 201 the administrative exit selection policy of site S. 203 The Shim6 protocol has other potential applications beyond site 204 multihoming. For example, since Shim6 is a host-based protocol, it 205 can also be used to support host multihoming. In this case, a 206 failure in communication between a multihomed host and some other 207 remote host might be repaired by selecting a locator associated with 208 a different interface. 210 3. Address Configuration 212 3.1. Protocol Version (IPv4 vs. IPv6) 214 The Shim6 protocol is defined only for IPv6. However, there is no 215 fundamental reason why a Shim6-like approach could not support IPv4 216 addresses as locators, either to provide multihoming support to IPv4- 217 numbered sites, or as part of an IPv4/IPv6 transition strategy. Some 218 extensions to the Shim6 protocol for supporting IPv4 locators have 219 been proposed in [I-D.nordmark-shim6-esd]. 221 The Shim6 protocol, as specified for IPv6, incorporates cryptographic 222 elements in the construction of locators (see [RFC3972], [RFC5535]). 223 Since IPv4 addresses are insufficiently large to contain addresses 224 constructed in this fashion, direct implementation of Shim6 as 225 specified for IPv6 for use with IPv4 addresses might require protocol 226 modifications. 228 In addition, there are other factors to take into account when 229 considering the support of IPv4 addresses, in particular IPv4 230 locators. Using multiple IPv4 addresses in a single host in order to 231 support Shim6 style of multihoming would result in an increased IPv4 232 address consumption, which with the current rate of IPv4 addresses 233 would be problematic. Besides, Shim6 may suffer additional problems 234 if locators become translated on the wire. Address translation is 235 more likely to involve IPv4 addresses. IPv4 addressed can be 236 translated to other IPv4 addresses (for example, private IPv4 address 237 into public IPv4 address and vice versa) or to/from IPv6 addresses 238 (for example, as defined by NAT64 239 [I-D.ietf-behave-v6v4-xlate-stateful]). When address translation 240 occurs, a locator exchanged by Shim6 could be different to the 241 address needed to reach the corresponding host, either because the 242 translated version of the locator exchanged by Shim6 is not known or 243 because the translation state does not exist any more in the 244 translator device. Supporting these scenarios would require NAT 245 traversal mechanisms which are not defined yet and which would imply 246 additional complexity (as any other NAT traversal mechanism). 248 3.2. Prefix Lengths 250 The Shim6 protocol does not assume that all the prefixes assigned to 251 the multihomed site have the same prefix length. 253 However, the use of CGA [RFC3972] and HBA [RFC5535] involve encoding 254 information in the lower 64 bits of the locators. This imposes the 255 requirement on address assignment to Shim6-capable hosts that all 256 interface addresses should be able to accommodate 64-bit interface 257 identifiers. It should be noted that this is imposed by RFC4291 258 [RFC4291] 260 3.3. Address Generation 262 The security of the Shim6 protocol is based on the use of CGA and HBA 263 addresses. 265 CGA and HBA generation process can use the information provided by 266 the stateless auto-configuration mechanism defined in [RFC4862] with 267 the additional considerations presented in [RFC3972] and [RFC5535]. 269 Stateful address auto-configuration using DHCP [RFC3315] is not 270 currently supported, because there is no defined mechanism to convey 271 the CGA Parameter Data Structure and other relevant information from 272 the DHCP server to the host. The definition of such mechanism seems 273 to be quite straightforward in the case of the HBA, since only the 274 CGA Parameter Data Structure needs to be delivered from the DHCP 275 server to the Shim6 host, and this data structure does not contain 276 any secret information. In the case of CGAs, the difficulty is 277 increased, since private key information should be exchanged as well 278 as the CGA Parameter Data Structure. However, with appropriate 279 extensions a DHCP server could inform to a host about the SEC value 280 to use when generating an address, or DHCP could even be used by the 281 host to delegate to the server the CPU-intensive task of computing a 282 Modifier for a given combination 283 [I-D.ietf-csi-dhcpv6-cga-ps]. 285 3.4. Use of CGA vs. HBA 287 The choice between CGA and HBA is a trade-off between flexibility and 288 performance. 290 The use of HBA is more efficient in the sense that addresses require 291 less computation than CGA, involving only hash operations for both 292 the generation and the verification of locator sets. However, the 293 locators of an HBA set are determined during the generation process, 294 and cannot be subsequently changed; the addition of new locators to 295 that initial set is not supported, except by re-generation of the 296 entire set which will in turn cause all addresses to change. 298 The use of CGA is more computationally expensive, involving public 299 key cryptography in the verification of locator sets. However, CGAs 300 are more flexible in the sense that they support the dynamic 301 modification of locator sets. 303 Therefore, CGAs are well suited to support dynamic environments such 304 as mobile hosts, where the locator set must be changed frequently. 305 HBAs are better suited for sites where the prefix set remains 306 relatively stable. 308 It should be noted that, since HBAs are defined as a CGA extension, 309 it is possible to generate hybrid HBA/CGA structures that incorporate 310 the strengths of both: i.e. that a single address can be used as an 311 HBA, enabling computationally-cheap validation amongst a fixed set of 312 addresses, and also as a CGA, enabling dynamic manipulation of the 313 locator set. For additional details, see [RFC5535]. 315 4. Shim6 and Ingress Filtering 317 Ingress filtering [RFC2827] prevents address spoofing by dropping 318 packets which come from customer networks with source addresses not 319 belonging to the prefix assigned to them. The problem of deploying 320 ingress filters with multihomed customers is discussed in [RFC3704], 321 in particular considering the case in which non-PI addresses are used 322 by customer networks. This is the case for IPv6 hosts in multihomed 323 networks with PA, and also for a Shim6 host in a multihomed network. 324 Note that this is also the case for other solutions supporting 325 multihoming, such as SCTP [RFC4960], HIP [RFC4423], etc. 327 One solution to this problem is to make the providers aware of the 328 alternative prefixes that can be used by a multihomed site, so that 329 ingress filtering would not be applied to packets with source 330 addresses belonging to these prefixes. This may be possible in some 331 cases, but it cannot be assumed as the general case. 333 [RFC3704] proposes that non-PI addresses should ensure that each 334 packet is delivered to the provider related with the prefix of its 335 source address. To deliver packets to the appropriate outgoing ISP, 336 some routers of the site must consider source addresses in their 337 forwarding decisions, in addition to the usual destination-based 338 forwarding. These routers maintain as many parallel routing tables 339 as valid source prefixes are, and choose a route that is a function 340 of both the source and the destination address. The way these 341 routing tables are populated is out of the scope of this document. 343 As proposed in [I-D.huitema-multi6-hosts], it is required for site 344 exit routers (at least) to be part of a single connected source based 345 routing domain: 347 Multiple site exits 348 | | | | 349 -----+-----+-----+-----+----- 350 ( ) 351 ( Source based routing domain ) 352 ( ) 353 ----+----+----+----+----+---- 354 ( ) 355 ( Generic routing domain ) 356 ( ) 357 ----------------------------- 359 Figure 2 361 In this way, packets arriving to this connected source based routing 362 domain would be delivered to the appropriate exit router. 364 Some particular cases of this generic deployment scenario are: 366 - a single exit router, in which the router chooses the exit provider 367 according to the source address of the packet to be forwarded 369 - a site in which all routers perform source address based forwarding 371 - a site in which only site-exit routers perform source address based 372 forwarding, and these site-exit routers are connected through point- 373 to-point tunnels, so that packets can be tunneled to the appropriate 374 exit router according to its source address 376 For hosts attached directly to networks of different providers, a 377 host solution to ensure that packets are forwarded to the appropriate 378 interface according to its source address must be provided. This 379 problem is under discussion in the Multiple Interfaces (MIF) IETF 380 Working Group. 382 Shim6 has no means to enforce neither host nor network forwarding for 383 a given locator to be used as source address. If any notification is 384 received from the router dropping the packets with legitimate source 385 addresses as a result of ingress filtering, the affected locator 386 could be associated to a low preference (or not being used at all). 387 But even if such notification is not received, or not processed by 388 the Shim6 layer, defective ingress filtering configuration will be 389 treated as a communication failure, and Shim6 re-homing would finally 390 select a working path in which packets are not filtered, if this path 391 exists. Note that this behavior results from the powerful end-to-end 392 resilience properties exhibited by REAP. 394 5. Shim6 Capabilities 396 5.1. Fault Tolerance 398 5.1.1. Establishing Communications After an Outage 400 If a host within a multihomed site attempts to establish a 401 communication with a remote host and selects a locator which 402 corresponds to a failed transit path, bidirectional communication 403 between the two hosts will not succeed. In order to establish a new 404 communication, the initiating host must try different combinations of 405 (source, destination) locator pairs until it finds a pair that works. 406 The mechanism for this default address selection is described in 407 [RFC3484]. A commentary on this mechanism in the context of 408 multihomed environments can be found in 409 [I-D.bagnulo-ipv6-rfc3484-update]. 411 Since a Shim6 context is normally only established between two hosts 412 after initial communication has been set up, there is no opportunity 413 for Shim6 to participate in the discovery of a suitable, initial 414 (source, destination) locator pair. The same consideration holds for 415 referrals, as it is described in Section 6. 417 5.1.2. Short-Lived Communications 419 The Shim6 context establishment operation requires a 4-way packet 420 exchange, and involves some overhead on the participating hosts in 421 memory and CPU. 423 For short-lived communications between two hosts, the benefit of 424 establishing a Shim6 context might not exceed the cost, perhaps 425 because the protocols concerned are fault tolerant and can arrange 426 their own recovery (e.g. DNS) or because the frequency of re-homing 427 events is sufficiently low that the probability of such a failure 428 occurring during a short-lived exchange is not considered 429 significant. 431 It is anticipated that the exchange of Shim6 context will provide 432 most benefit for exchanges between hosts which are long-lived. For 433 this reason the default behaviour of Shim6-capable hosts is expected 434 to employ deferred context-establishment. This default behaviour 435 will be able to be overridden by applications which prefer immediate 436 context establishment regardless of transaction longevity. 438 It must be noted that all the above considerations refer to the 439 lifetime of the interaction between the peers and not about the 440 lifetime of a particular connection (e.g. TCP connection). In other 441 words, the Shim6 context is established between ULID pairs and it 442 affects all the communication between these ULIDs. So, two nodes 443 with multiple short-lived communications using the same ULID pair 444 would benefit as much from the Shim6 features as two nodes having a 445 single long-lived communication. One example of such scenario would 446 be a web client software downloading web contents from a server over 447 multiple TCP connections. Each TCP connection is short-lived, but 448 the communication/contact between the two ULID could be long-lived. 450 5.1.3. Long-Lived Communications 452 As discussed in Section 5.1.2, hosts engaged in long-lived 453 communications will suffer lower proportional overhead, and greater 454 probability of benefit than those performing brief transactions. 456 Deferred context setup ensures that session establishment time will 457 not be increased by the use of Shim6. 459 5.2. Load Balancing 461 The Shim6 protocol does not support load balancing within a single 462 context: all packets associated with a particular context are 463 exchanged using a single locator pair per direction, with the 464 exception of forked contexts, which are created upon explicit 465 requests from the upper-layer protocol. 467 It may be possible to extend the Shim6 protocol to use multiple 468 locator pairs in a single context, but the impact of such an 469 extension on upper-layer protocols (e.g. on TCP congestion control) 470 should be considered carefully. 472 When many contexts are considered together in aggregation, e.g. on a 473 single host which participates in many simultaneous contexts or in a 474 site full of hosts, some degree of load sharing should occur 475 naturally due to the selection of different locator pairs in each 476 context. However, there is no mechanism defined to ensure that this 477 natural load sharing is arranged to provide a statistical balance 478 between transit providers. 480 5.3. Traffic Engineering 482 The Shim6 protocol provides some lightweight traffic engineering 483 capabilities in the form of the Locator Preferences option, which 484 allows a host to inform a remote host of local preferences for 485 locator selection. 487 This mechanism is only available after a Shim6 context has been 488 established, and it is a host-based capability rather than a site- 489 based capability. There is no defined mechanism which would allow 490 use of the Locator Preferences option amongst a site full of hosts to 491 be managed centrally. 493 6. Application Considerations 495 Shim6 provides multihoming support without forcing changes in the 496 applications running on the host. The fact that an address has been 497 generated according to the CGA or HBA specification does not require 498 any specific action from the application, e.g. it can obtain remote 499 CGA or HBA addresses as a result of a getaddrinfo() call to trigger a 500 DNS Request. The storage of CGA or HBA addresses in DNS does not 501 require also any modification of this protocol, since they are 502 recorded using AAAA records. Moreover, neither the ULID/locator 503 management [RFC5533] nor the failure detection and recovery [RFC5534] 504 functions require application awareness. 506 However, a specific API [I-D.ietf-shim6-multihome-shim-api] is being 507 developed for those applications which might require additional 508 capabilities in ULID/locator management, such as the locator pair in 509 use for a given context, or the set of local or remote locators 510 available for it. This API can also be used to disable Shim6 511 operation when required. 513 It is worth to note that callbacks can benefit naturally from Shim6 514 support. In a callback, an application in B retrieves IP_A, the IP 515 address of a peer A, and B uses IP_A to establish a new communication 516 with A. As long as the address exchanged, IP_A is the ULID for the 517 initial communication between A and B, and B uses the same address as 518 in the initial communication, and this initial communication is alive 519 (or the context has not been deleted), the new communication could 520 use the locators exchanged by Shim6 for the first communication. In 521 this case, communication could proceed even if the ULID of A is not 522 reachable. 524 However, Shim6 does not provide specific protection to current 525 applications when they use referrals. A referral is the exchange of 526 the IP address IP_A of a party A by party B to party C, so that party 527 C could use IP_A to communicate with party A 528 [I-D.ietf-multi6-app-refer]. In a normal case, the ULID IP_A would 529 be the only information sent by B to C as referral. But if IP_A is 530 no longer valid as locator in A, C could have trouble in establishing 531 a communication with A. Increased failure protection for referrals 532 could be obtained if B exchanged the whole list of alternative 533 locators of A, although in this case the application protocol should 534 be modified. Note that B could send to C the current locator of A, 535 instead of the ULID of A, as a way of using the most recent 536 reachability information about A. While in this case no modification 537 of the application protocol is required, some concerns arise: host A 538 may not accept one of its locator as ULID for initiating a 539 communication, and if CGA are used, the locator may not be a CGA so a 540 Shim6 context among A and C could not be created. 542 7. Interaction with Other Protocols 544 7.1. Shim6 and Mobile IPv6 546 We next consider some scenarios in which the Shim6 protocol and the 547 MIPv6 protocol [RFC3775] might be used simultaneously. 549 7.1.1. Multihomed Home Network 551 In this case, the Home Network of the Mobile Node (MN) is multihomed. 552 This implies the availability of multiple Home Network prefixes, 553 resulting on multiple HoAs for each MN. Since the MN is a node 554 within a multihomed site, it seems reasonable to expect that the MN 555 should be able to benefit from the multihoming capabilities provided 556 by the Shim6 protocol. Moreover, the MN needs to be able to obtain 557 the multihoming benefits even when it is roaming away from the Home 558 Network: if the MN is away from the Home Network while the Home 559 Network suffers a failure in a transit path, the MN should be able to 560 continue communicating using alternate paths to reach the Home 561 Network. 563 The resulting scenario is the following: 565 +------------------------------------+ 566 | Internet | 567 +------------------------------------+ 568 | | 569 +----+ +----+ 570 |ISP1| |ISP2| 571 +----+ +----+ 572 | | 573 +------------------------------------+ 574 | Multihomed Home Network | 575 | Prefixes: P1 and P2 | 576 | | 577 | Home Agent | 578 | // | 579 +------------------//----------------+ 580 // 581 // 582 +-----+ 583 | MN | HoA1, HoA2 584 +-----+ 586 Figure 3 588 So, in this configuration, the Shim6 protocol is used to provide 589 multiple communication paths to all the nodes within the multihomed 590 sites (including the mobile nodes) and the MIPv6 protocol is used to 591 support mobility of the mobile nodes of the multihomed site. 593 The proposed protocol architecture would be the following: 595 +--------------+ 596 | Application | 597 +--------------+ 598 | Transport | 599 +--------------+ 600 | IP | 601 | +----------+ | 602 | | IPSec | | 603 | +----------+<--ULIDs 604 | | Shim6 | | 605 | +----------+<--HoAs 606 | | MIPv6 | | 607 | +----------+<--CoAs 608 | | 609 +--------------+ 611 Figure 4 613 In this architecture, the upper layer protocols and IPSec would use 614 ULIDs of the Shim6 protocol. Only the HoAs will be presented by the 615 upper layers to the Shim6 layer as potential ULIDs. Two Shim6 616 entities will exchange their own available HoAs as locators. 617 Therefore, Shim6 provides failover between different HoAs and allows 618 preserving established communications when an outage affects the path 619 through the ISP that has delegated the HoA used for initiating the 620 communication (similarly to the case of a host within a multihomed 621 site). The CoAs are not presented to the Shim6 layer and are not 622 included in the local locator set in this case. The CoAs are managed 623 by the MIPv6 layer, which binds each HoA to a CoA. 625 So, in this case, the upper layer protocols select a ULID pair for 626 the communication. The Shim6 protocol translates the ULID pair to an 627 alternative locator in case that is needed. Both the ULIDs and the 628 alternative locators are HoAs. Next, the MIPv6 layer maps the 629 selected HoA to the corresponding CoA, which is the actual address 630 included in the wire. 632 The Shim6 context is established between the MN and the CN, and it 633 would allow the communication to use all the available HoAs to 634 provide fault tolerance. The MIPv6 protocol is used between the MN 635 and the HA in the case of the bidirectional tunnel mode, and between 636 the MN and the CN in case of the RO (Route Optimization) mode. 638 7.1.2. Shim6 Between the HA and the MN 640 Another scenario where a Shim6-MIPv6 interaction may be useful is the 641 case where a Shim6 context is established between the MN and the HA 642 in order to provide fault tolerance capabilities to the bidirectional 643 tunnel between them. 645 Consider the case where the HA has multiple addresses (whether 646 because the Home Network is multihomed or because the HA has multiple 647 interfaces) and/or the MN has multiple addresses (whether because the 648 visited network is multihomed or because the MN has multiple 649 interfaces). In this case, if a failure affects the address pair 650 that is being used to run the tunnel between the MN and HA, 651 additional mechanisms need to be used to preserve the communication. 653 One possibility would be to use MIPv6 capabilities, by simply 654 changing the CoA used as the tunnel endpoint. However, MIPv6 lacks 655 of failure detection mechanisms that would allow the MN and/or the HA 656 to detect the failure and trigger the usage of an alternative 657 address. Shim6 provides such failure detection protocol, so one 658 possibility would be re-using the failure detection function from the 659 Shim6 failure detection protocol in MIPv6. In this case, the Shim6 660 protocol wouldn't be used to create Shim6 context and provide fault 661 tolerance, but just its failure detection functionality would be re- 662 used. 664 The other possibility would be to use the Shim6 protocol to create a 665 Shim6 context between the HA and the MN so that the Shim6 detects any 666 failure and re-homes the communication in a transparent fashion to 667 MIPv6. In this case, the Shim6 protocol would be associated to the 668 tunnel interface. 670 7.2. Shim6 and SeND 672 Secure Neighbor Discovery (SeND) [RFC3971] uses CGAs to prove address 673 ownership for Neighbor Discovery [RFC4861]. The Shim6 protocol can 674 use either CGAs or HBAs to protect locator sets included in Shim6 675 contexts. It is expected that some hosts will need to participate in 676 both SeND and Shim6 simultaneously. 678 In the case that both the SeND and Shim6 protocols are using the CGA 679 technique to generate addresses, then there is no conflict: the host 680 will generate addresses for both purposes as CGAs, and since it will 681 be in control of the associated private key, the same CGA can be used 682 for the different protocols. 684 In the case that a Shim6-capable host is using HBAs to protect its 685 locator sets, the host will need to generate hybrid HBA/CGA addresses 686 as defined in [RFC5535] and discussed briefly in Section 3.4. In 687 this case, the CGA Parameter Data Structure containing a valid public 688 key and the Multi-Prefix extension are included as inputs to the hash 689 function. 691 7.3. Shim6 and SCTP 693 The SCTP [RFC4960] protocol provides a reliable, stream-based 694 communications channel between two hosts which provides a superset of 695 the capabilities of TCP. One of the notable features of SCTP is that 696 it allows the exchange of endpoint addresses between hosts, and is 697 able to recover from the failure of a particular endpoint pair in a 698 manner which is conceptually similar to locator selection in Shim6. 700 SCTP is a transport-layer protocol, higher in the protocol stack than 701 Shim6, and hence there is no fundamental incompatibility which would 702 prevent a Shim6-capable host from communicating using SCTP. 704 However, since SCTP and Shim6 both aim to exchange addressing 705 information between hosts in order to meet the same generic goal, it 706 is possible that their simultaneous use might result in unexpected 707 behaviour, e.g. lead to race conditions. 709 The capabilities of SCTP with respect to path maintenance of a 710 reliable, connection-oriented stream protocol are more extensive than 711 the more general layer-3 locator agility provided by Shim6. 712 Therefore, It is recommended that Shim6 is not used for SCTP 713 sessions, and that path maintenance is provided solely by SCTP. 714 There are at least two ways to enforce this behaviour. One option 715 would be to make the stack, and in particular the Shim6 sublayer, 716 aware of SCTP sockets and in this case refrain from creating a Shim6 717 context. The other option is that the upper layer, SCTP in this 718 case, informs using a Shim6 capable API like the one proposed in 719 [I-D.ietf-shim6-multihome-shim-api] that no Shim6 context must be 720 created for this particular communication. 722 Note that the issues described here for SCTP may also arise for a 723 multipath TCP solution. 725 7.4. Shim6 and NEMO 727 The NEMO [RFC3963] protocol extensions to MIPv6 allow a Mobile 728 Network to communicate through a bidirectional tunnel via a Mobile 729 Router (MR) to a NEMO-compliant Home Agent (HA) located in a Home 730 Network. 732 If either or both of the MR or HA are multihomed, then a Shim6 733 context established preserves the integrity of the bidirectional 734 tunnel between them in the event that a transit failure occurs in the 735 connecting path. 737 Once the tunnel between MR and HA is established, hosts within the 738 Mobile Network which are Shim6-capable can establish contexts with 739 remote hosts in order to receive the same multihoming benefits as any 740 host located within the Home Network. 742 7.5. Shim6 and HIP 744 Shim6 and the Host Identity Protocol ( HIP [RFC4423]) are 745 architecturally similar in the sense that both solutions allow two 746 hosts to use different locators to support communications between 747 stable ULIDs. The signaling exchange to establish the demultiplexing 748 context on the hosts is very similar for both protocols. However, 749 there are a few key differences. First, Shim6 avoids defining a new 750 namespace for ULIDs, preferring instead to use a routable locator as 751 a ULID, while HIP uses public keys and hashes thereof as ULIDs. The 752 use of a routable locator as ULID better supports deferred context 753 establishment, application callbacks, and application referrals, and 754 avoids management and resolution costs of a new namespace, but 755 requires additional security mechanisms to securely bind the ULID 756 with the locators. Second, Shim6 uses an explicit context header on 757 data packets for which the ULIDs differ from the locators in use 758 (this header is only needed after a failure/rehoming event occurs), 759 while HIP compresses this context tag into the ESP SPI field of a 760 BEET-mode security association BEET [I-D.nikander-esp-beet-mode]. 761 Third, HIP as presently defined requires the use of public-key 762 operations in its signaling exchange and ESP encryption in the data 763 plane, while the use of Shim6 requires neither (if only HBA addresses 764 are used). HIP by default provides data protection, while this is a 765 non goal for Shim6. 767 The Shim6 working group was chartered to provide a solution to a 768 specific problem, multihoming, which minimizes deployment disruption, 769 while HIP is considered more of an experimental approach intended to 770 solve several more general problems (mobility, multihoming and loss 771 of end-to-end addressing transparency) through an explicit 772 identifier/locator split. Communicating hosts that are willing and 773 interested to run HIP (perhaps extended with Shim6's failure 774 detection protocol) likely have no reason to also run Shim6. In this 775 sense, HIP may be viewed as a possible long-term evolution or 776 extension of the Shim6 architecture, or one possible implementation 777 of the extended Shim6 design ESD [I-D.nordmark-shim6-esd]. 779 8. Security Considerations 781 This section considers the applicability of the Shim6 protocol from a 782 security perspective, i.e. which security features can expect 783 applications and users of the Shim6 protocol. 785 First of all, it should be noted that the Shim6 protocol is not a 786 security protocol, like for instance HIP. This means that as opposed 787 to HIP, it is an explicit non goal of the Shim6 protocol to provide 788 enhanced security for the communications that use the Shim6 protocol. 789 The goal of the Shim6 protocol design in terms of security is not to 790 introduce new vulnerabilities that were not present in the current 791 non-Shim6 enabled communications. In particular, it is an explicit 792 non goal of the Shim6 protocol security to provide protection from 793 on-path attackers. On-path attackers are able to sniff and spoof 794 packets in the current Internet, and they are able to do the same in 795 Shim6 communications (as long as the communication flows through the 796 path they are located on). So, summarizing, the Shim6 protocol does 797 not provide data packet protection from on-path attackers. 799 However, the Shim6 protocol does use several security techniques. 800 The goal of these security measures is to protect the Shim6 signaling 801 protocol from new attacks resulting from the adoption of the Shim6 802 protocol. In particular, the use of HBA/CGA prevents on-path and 803 off-path attackers to introduce new locators in the locator set of a 804 Shim6 context, preventing redirection attacks [RFC4218]. Moreover, 805 the usage of probes before re-homing to a different locator as a 806 destination address prevents flooding attacks from off-path 807 attackers. 809 In addition, the usage of a 4-way handshake for establishing the 810 Shim6 context protects against DoS attacks, so hosts implementing the 811 Shim6 protocol should not be more vulnerable to DoS attacks than 812 regular IPv6 hosts. 814 Finally, many Shim6 signaling messages contain a Context Tag, meaning 815 that only attackers that know the Context Tag can forge them. As a 816 consequence, only on-path attackers can generate false Shim6 817 signaling packets for an established context. The impact of these 818 attacks would be limited since they would not be able to add 819 additional locators to the locator set (because of the HBA/CGA 820 protection). In general the possible attacks have similar effects to 821 the ones that an on-path attacker can launch on any regular IPv6 822 communication. The residual threats are described in the Security 823 Considerations of the Shim6 protocol specification [RFC5533]. 825 8.1. Privacy Considerations 827 The Shim6 protocol is designed to provide some basic privacy 828 features. In particular, HBAs are generated in such a way, that the 829 different addresses assigned to a host cannot be trivially linked 830 together as belonging to the same host, since there is nothing in 831 common in the addresses themselves. Similar features are provided 832 when the CGA protection is used. This means that it is not trivial 833 to determine that a set of addresses is assigned to a single Shim6 834 host. 836 However, the Shim6 protocol does exchange the locator set in clear 837 text and it also uses a fixed Context Tag when using different 838 locators in a given context. This implies that an attacker observing 839 the Shim6 context establishment exchange or seeing different payload 840 packets exchanged through different locators, but with the same 841 Context Tag, can determine the set of addresses assigned to a host. 842 However, this requires that the attacker is located along the path 843 and that it can capture the Shim6 signaling packets. A more in depth 844 analysis of the privacy of the Shim6 protocol can be found in 845 [I-D.bagnulo-shim6-privacy]. 847 9. IANA Considerations 849 This document has no actions for IANA. 851 10. Contributors 853 The analysis on the interaction between the Shim6 protocol and the 854 other protocols presented in this note benefited from the advice of 855 various people including Tom Henderson, Erik Nordmark, Hesham 856 Soliman, Vijay Devarpalli, John Loughney and Dave Thaler. 858 11. Acknowledgements 860 Joe Abley's work was supported in part by the US National Science 861 Foundation (research grant SCI-0427144) and DNS-OARC. 863 Marcelo Bagnulo worked on this document while visiting Ericsson 864 Research Laboratory Nomadiclab. 866 Shinta Sugimoto reviewed this document and provided comments and 867 text. 869 Iljitsch van Beijnum, Brian Carpenter, Sam Xia reviewed this document 870 and provided comments. 872 12. References 874 12.1. Normative References 876 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 877 Defeating Denial of Service Attacks which employ IP Source 878 Address Spoofing", BCP 38, RFC 2827, May 2000. 880 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 881 and M. Carney, "Dynamic Host Configuration Protocol for 882 IPv6 (DHCPv6)", RFC 3315, July 2003. 884 [RFC3484] Draves, R., "Default Address Selection for Internet 885 Protocol version 6 (IPv6)", RFC 3484, February 2003. 887 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 888 Networks", BCP 84, RFC 3704, March 2004. 890 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 891 in IPv6", RFC 3775, June 2004. 893 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 894 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 895 RFC 3963, January 2005. 897 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 898 Neighbor Discovery (SEND)", RFC 3971, March 2005. 900 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 901 RFC 3972, March 2005. 903 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 904 Architecture", RFC 4291, February 2006. 906 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 907 (HIP) Architecture", RFC 4423, May 2006. 909 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 910 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 911 September 2007. 913 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 914 Address Autoconfiguration", RFC 4862, September 2007. 916 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 917 RFC 4960, September 2007. 919 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 920 Workshop on Routing and Addressing", RFC 4984, 921 September 2007. 923 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 924 Shim Protocol for IPv6", RFC 5533, June 2009. 926 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 927 Locator Pair Exploration Protocol for IPv6 Multihoming", 928 RFC 5534, June 2009. 930 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 931 June 2009. 933 12.2. Informative References 935 [I-D.bagnulo-ipv6-rfc3484-update] 936 Bagnulo, M., "Updating RFC 3484 for multihoming support", 937 draft-bagnulo-ipv6-rfc3484-update-00 (work in progress), 938 December 2005. 940 [I-D.bagnulo-shim6-privacy] 941 Bagnulo, M., "Privacy Analysis for the SHIM6 protocol", 942 draft-bagnulo-shim6-privacy-01 (work in progress), 943 October 2006. 945 [I-D.huitema-multi6-hosts] 946 Huitema, C. and R. Draves, "Host-Centric IPv6 947 Multihoming", draft-huitema-multi6-hosts-03 (work in 948 progress), February 2004. 950 [I-D.ietf-behave-v6v4-xlate-stateful] 951 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 952 NAT64: Network Address and Protocol Translation from IPv6 953 Clients to IPv4 Servers", 954 draft-ietf-behave-v6v4-xlate-stateful-08 (work in 955 progress), January 2010. 957 [I-D.ietf-csi-dhcpv6-cga-ps] 958 Jiang, S., Shen, S., and T. Chown, "DHCPv6 and CGA 959 Interaction: Problem Statement", 960 draft-ietf-csi-dhcpv6-cga-ps-01 (work in progress), 961 December 2009. 963 [I-D.ietf-multi6-app-refer] 964 Nordmark, E., "Multi6 Application Referral Issues", 965 draft-ietf-multi6-app-refer-00 (work in progress), 966 January 2005. 968 [I-D.ietf-shim6-multihome-shim-api] 969 Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 970 "Socket Application Program Interface (API) for 971 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-12 972 (work in progress), January 2010. 974 [I-D.nikander-esp-beet-mode] 975 Nikander, P. and J. Melen, "A Bound End-to-End Tunnel 976 (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 977 (work in progress), August 2008. 979 [I-D.nordmark-shim6-esd] 980 Nordmark, E., "Extended Shim6 Design for ID/loc split and 981 Traffic Engineering", draft-nordmark-shim6-esd-01 (work in 982 progress), February 2008. 984 [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the 985 Internet", RFC 3221, December 2001. 987 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 988 Multihoming Architectures", RFC 3582, August 2003. 990 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 991 Gill, "IPv4 Multihoming Practices and Limitations", 992 RFC 4116, July 2005. 994 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 995 Multihoming Solutions", RFC 4218, October 2005. 997 Authors' Addresses 999 Joe Abley 1000 Afilias Canada, Inc. 1001 Suite 204 1002 4141 Yonge Street 1003 Toronto, Ontario M2P 2A8 1004 Canada 1006 Phone: +1 416 673 4176 1007 Email: jabley@ca.afilias.info 1008 URI: http://afilias.info/ 1009 Marcelo Bagnulo 1010 U. Carlos III de Madrid 1011 Av. Universidad 30 1012 Leganes, Madrid 28911 1013 Spain 1015 Phone: +34 91 6248814 1016 Email: marcelo@it.uc3m.es 1017 URI: http://www.it.uc3m.es/ 1019 Alberto Garcia Martinez 1020 U. Carlos III de Madrid 1021 Av. Universidad 30 1022 Leganes, Madrid 28911 1023 Spain 1025 Phone: +34 91 6248782 1026 Email: alberto@it.uc3m.es 1027 URI: http://www.it.uc3m.es/