idnits 2.17.1 draft-garcia-shim6-applicability-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (March 28, 2012) is 4404 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 448 -- Looks like a reference, but probably isn't: '2' on line 187 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-03 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission J. Abley 3 Internet-Draft ICANN 4 Intended status: Informational M. Bagnulo 5 Expires: September 29, 2012 A. Garcia-Martinez 6 UC3M 7 March 28, 2012 9 Considerations on the Application of the Level 3 Multihoming Shim 10 Protocol (Shim6) 11 draft-garcia-shim6-applicability-05 13 Abstract 15 This document discusses some considerations on the applicability of 16 the Shim6 IPv6 protocol and associated support protocols and 17 mechanisms to provide site multihoming capabilities in IPv6. 19 Status of this Memo 21 This Internet-Draft is submitted 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). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 29, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 4 55 3. Addresses and Shim6 . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Protocol Version (IPv4 vs. IPv6) . . . . . . . . . . . . . 6 57 3.2. Prefix Lengths . . . . . . . . . . . . . . . . . . . . . . 7 58 3.3. Address Generation and Configuration . . . . . . . . . . . 7 59 3.4. Use of CGA vs. HBA . . . . . . . . . . . . . . . . . . . . 8 60 4. Shim6 in Multihomed Nodes . . . . . . . . . . . . . . . . . . 8 61 5. Shim6 Capabilities . . . . . . . . . . . . . . . . . . . . . . 10 62 5.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 10 63 5.1.1. Establishing Communications After an Outage . . . . . 10 64 5.1.2. Short-Lived and Long-Lived Communications . . . . . . 11 65 5.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 11 66 5.3. Traffic Engineering . . . . . . . . . . . . . . . . . . . 12 67 6. Application Considerations . . . . . . . . . . . . . . . . . . 12 68 7. Interaction with Other Protocols and Mechanisms . . . . . . . 13 69 7.1. Shim6 and Mobile IPv6 . . . . . . . . . . . . . . . . . . 14 70 7.1.1. Multihomed Home Network . . . . . . . . . . . . . . . 14 71 7.1.2. Shim6 Between the HA and the MN . . . . . . . . . . . 16 72 7.2. Shim6 and SEND . . . . . . . . . . . . . . . . . . . . . . 16 73 7.3. Shim6, SCTP and MPTCP . . . . . . . . . . . . . . . . . . 17 74 7.4. Shim6 and NEMO . . . . . . . . . . . . . . . . . . . . . . 18 75 7.5. Shim6 and HIP . . . . . . . . . . . . . . . . . . . . . . 18 76 7.6. Shim6 and Firewalls . . . . . . . . . . . . . . . . . . . 19 77 7.7. Shim6 and NPTv6 . . . . . . . . . . . . . . . . . . . . . 20 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 79 8.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 24 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 81 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 85 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 88 1. Introduction 90 Site multihoming is an arrangement by which a site may use multiple 91 paths to the rest of the Internet to provide better reliability for 92 traffic passing in and out of the site than would be possible with a 93 single path. Some of the motivations for operators to multi-home 94 their network are described in [RFC3582]. 96 In IPv4, site multihoming is achieved by injecting into the global 97 Internet routing system (sometimes referred to as the Default-Free 98 Zone, or DFZ) the additional state required to allow session 99 resilience over re-homing events [RFC4116]. There is concern that 100 this approach will not scale [RFC3221], [RFC4984]. 102 Site multihoming in IPv6 can be achieved as in IPv4, thus facing 103 similar scalability concerns. However, the large address space of 104 IPv6 enables a different solution for site multihoming in IPv6: to 105 assign multiple addresses to each host, one or more from each 106 provider. Deploying site multihoming in this way does not impact in 107 the routing system, so such a site multihoming strategy may be 108 extended to a large number of sites, and may be applied to small 109 sites which would not be eligible for site multihoming based on the 110 injection of routes to PI (Provider Independent) prefixes. A 111 drawback of this multihoming approach is that it does not provide 112 transport-layer stability across re-homing events. 114 Shim6 provides layer-3 support for making re-homing events 115 transparent to the transport layer by means of a shim approach. Once 116 a Shim6 session has been established, the failure detection mechanism 117 defined for Shim6 allows finding new valid locator combinations in 118 case of failure, and using these locators to continue the 119 communication. However, Shim6 does not provide failure protection to 120 the communication establishment, so if a host within a multihomed 121 site attempts to establish a communication with a remote host and 122 selects an address which corresponds to a failed transit path, the 123 communication will fail. State information relating to the 124 multihoming of two endpoints exchanging unicast traffic is retained 125 on the endpoints themselves, rather than in the network. 126 Communications between Shim6-capable hosts and Shim6-incapable hosts 127 proceed as normal, but without the benefit of transport-layer 128 stability. The Shim6 approach is thought to have better scaling 129 properties with respect to the state held in the DFZ than the PI 130 approach. In order to successfully deploy Shim6 in a multihomed 131 site, additional mechanisms may be required to solve issues such as 132 selecting the source address appropriate to the destination and to 133 the outgoing provider, or to allow the network manager to perform 134 traffic engineering. Such problems are not specific to Shim6, but 135 are relevant to the hosts of any site which is connected to multiple 136 transit providers, and which receives an IPv6 prefix from each of the 137 providers [RFC5220]. Some of these mechanisms are not defined today. 138 However, note that once a Shim6 session has been established, Shim6 139 reduces the impact of these problems, because if a working path 140 exists, Shim6 will find it. 142 This note describes the applicability of the Level 3 multihoming 143 (hereafter Shim6) protocol defined in [RFC5533] and the failure 144 detection mechanisms defined in [RFC5534]. 146 The terminology used in this document, including terms like locator, 147 and ULID (Upper-Layer Identifier), is defined in [RFC5533]. 149 2. Deployment Scenarios 151 The goal of the Shim6 protocol is to support locator agility in 152 established communications: different layer-3 endpoint addresses may 153 be used to exchange packets belonging to the same transport-layer 154 session, all the time presenting a consistent identifier pair to 155 upper-layer protocols. 157 In order to be useful, the Shim6 protocol requires that at least one 158 of the peers has more than one address which could be used on the 159 wire (as locators). In the event of communications failure between 160 an active pair of addresses, the Shim6 protocol attempts to 161 reestablish communication by trying different combinations of 162 locators. 164 While other multi-addressing scenarios are not precluded, the 165 scenario in which the Shim6 protocol is expected to operate is that 166 of a multihomed site which is connected to multiple transit 167 providers, and which receives an IPv6 prefix from each of them. This 168 configuration is intended to provide protection for the end-site in 169 the event of a failure in some subset of the available transit 170 providers, without requiring the end-site to acquire PI address space 171 or requiring any particular cooperation between the transit 172 providers. 174 ,------------------------------------. ,----------------. 175 | Rest of the Internet +-------+ Remote Host R | 176 `--+-----------+------------------+--' `----------------' 177 | | | LR[1] ... LR[m] 178 ,---+----. ,---+----. ,----+---. 179 | ISP[1] | | ISP[2] | ...... | ISP[n] | 180 `---+----' `---+----' `----+---' 181 | | | 182 ,---+-----------+------------------+---. 183 | Multi-Homed Site S assigned | 184 | prefixes P[1], P[2], ..., P[n] | 185 | | 186 | ,--------. L[1] = P[1]:iid[1], | 187 | | Host H | L[2] = P[2]:iid[2], ... | 188 | `--------' L[n] = P[n]:iid[n] | 189 `--------------------------------------' 191 Figure 1 193 In the scenario illustrated in Figure 1 host H communicates with some 194 remote host R. Each of the addresses L[i] configured on host H in the 195 multihomed site S can be reached through provider ISP[i] only, since 196 ISP[i] is solely responsible for advertising a covering prefix for 197 P[i] to the rest of the Internet. 199 The use of locator L[i] on H hence causes inbound traffic towards H 200 to be routed through ISP[i]. Changing the locator from L[i] to L[j] 201 will have the effect of re-routing inbound traffic to H from ISP[i] 202 to ISP[j]. This is the central mechanism by which the Shim6 protocol 203 aims to provide multihoming functionality: by changing locators, host 204 H can change the upstream ISP used to route inbound packets towards 205 itself. Regarding the outbound traffic to H, the path taken in this 206 case depends on both the actual locator LR[j] used for R, and the 207 administrative exit selection policy of site S. As discussed in 208 Section 4, the site should deliver outgoing packets having a source 209 address derived from the prefix of ISP[i] to that particular 210 provider, in order to prevent those packets to be filtered due to 211 Ingress Filtering [RFC2827] being applied by the providers. It is 212 worth noting that in an scenario such as the one depicted in 213 Figure 1, the paths followed by inbound and outbound traffic are 214 determined to a large extent by the locators in use for the 215 communication. This is not a particular issue of Shim6, but it is 216 common to any deployment in which hosts are configured with addresses 217 received from different providers. Traffic Engineering in such sites 218 will likely involve proper configuration of address selection 219 policies in the hosts, by means of mechanisms such as the ones 220 discussed in Section 4. 222 The Shim6 protocol has other potential applications beyond site 223 multihoming. For example, since Shim6 is a host-based protocol, it 224 can also be used to support host multihoming. In this case, a 225 failure in communication between a multihomed host and some other 226 remote host might be repaired by selecting a locator associated with 227 a different interface. 229 To allow nodes to benefit from the capabilities provided by Shim6 230 (discussed in Section 5) such as fault tolerance, nodes should be 231 configured to initiate a Shim6 session with any peer node if they 232 have multiple locators to use. Note that this configuration can be 233 performed transparently to the applications, in the sense that 234 applications do not need to be aware of the Shim6 functionality 235 provided by the node; iin particular, nodes are not forced to use the 236 Shim6 API [RFC6316] to benefit from Shim6. The Shim6 session should 237 be created after the two nodes have been communicating for some time, 238 i.e. using the deferred context establishment facility provided by 239 Shim6. Otherwise, the cost of the Shim6 4-way handshake used for 240 establishing the session may exceed the benefits provided for short- 241 lived communications (see Section 5.1.2). More advanced node 242 configuration may involved configuring different delays for 243 initiating the session for different applications, for example, based 244 on a per-port configuration. Nodes being able to use a single 245 locator for the communication should not initiate the creation of a 246 Shim6 context, but should participate if other node initiates it. 247 Note that Shim6-aware applications can overrid this behavior by means 248 of the Shim6 API [RFC6316]. 250 3. Addresses and Shim6 252 3.1. Protocol Version (IPv4 vs. IPv6) 254 The Shim6 protocol is defined only for IPv6. While some Shim6-like 255 approaches have been suggested to support IPv4 addresses as locator 256 [I-D.nordmark-shim6-esd], at this time it is not clear if such 257 extensions are feasible. 259 The Shim6 protocol, as specified for IPv6, incorporates cryptographic 260 elements in the construction of locators (see [RFC3972], [RFC5535]). 261 Since IPv4 addresses are insufficiently large to contain addresses 262 constructed in this fashion, direct implementation of Shim6 as 263 specified for IPv6 for use with IPv4 addresses is not possible. 265 In addition, there are other factors to take into account when 266 considering the support of IPv4 addresses, in particular IPv4 267 locators. Using multiple IPv4 addresses in a single host in order to 268 support Shim6 style of multihoming would result in an increased IPv4 269 address consumption, which would be problematic considering the 270 current situation in which IPv4 address space has been exhausted. 271 Besides, Shim6 may experience additional problems if locators become 272 translated on the wire. Address translation is more likely to 273 involve IPv4 addresses. IPv4 addresses can be translated to other 274 IPv4 addresses (for example, private IPv4 address into public IPv4 275 address and vice versa) or to/from IPv6 addresses (for example, as 276 defined by NAT64 [RFC6146]). When address translation occurs, a 277 locator exchanged by Shim6 could be different from the address needed 278 to reach the corresponding host, either because the translated 279 version of the locator exchanged by Shim6 is not known or because the 280 translation state does not exist any more in the translator device. 281 Besides, the translated locators will not be verifiable with the 282 current CGA (Cryptographically Generated Address) and HBA (Hash-Based 283 Address) verification mechanisms, which protect the locators as seen 284 by the node for which they are configured. 286 3.2. Prefix Lengths 288 The Shim6 protocol does not assume that all the prefixes assigned to 289 the multihomed site have the same prefix length. 291 However, the use of CGA [RFC3972] and HBA [RFC5535] involve encoding 292 information in the lower 64 bits of the locators. This imposes the 293 requirement on address assignment to Shim6-capable hosts that all 294 interface addresses should be able to accommodate 64-bit interface 295 identifiers. It should be noted that this is imposed by RFC4291 296 [RFC4291]. 298 3.3. Address Generation and Configuration 300 The security of the Shim6 protocol is based on the use of CGA and HBA 301 addresses. 303 CGA and HBA generation process can use the information provided by 304 the stateless auto-configuration mechanism defined in [RFC4862] with 305 the additional considerations presented in [RFC3972] and [RFC5535]. 307 Stateful address auto-configuration using DHCP [RFC3315] is not 308 currently supported, because there is no defined mechanism to convey 309 the CGA Parameter Data Structure and other relevant information from 310 the DHCP server to the host. An analysis of the possible 311 interactions between DHCPv6 and CGA can be found in 312 [I-D.ietf-csi-dhcpv6-cga-ps]. 314 3.4. Use of CGA vs. HBA 316 The choice between CGA and HBA is a trade-off between flexibility and 317 performance. 319 The use of HBA is more efficient in the sense that addresses require 320 less computation than CGA, involving only hash operations for both 321 the generation and the verification of locator sets. However, the 322 locators of an HBA set are determined during the generation process, 323 and cannot be subsequently changed; the addition of new locators to 324 that initial set is not supported. Therefore, a node using an HBA as 325 ULID for a Shim6 session can only use the locators associated to that 326 HBA for the considered Shim6 session. If the node wants to use a new 327 set of locators, it has to generate a new HBA including the prefixes 328 of the new locators (which will result with very high probability in 329 different addresses to those of the previous set). New sessions 330 initiated with a ULID belonging to the new HBA address set could use 331 the new locators. 333 The use of CGA is more computationally expensive, involving public 334 key cryptography in the verification of locator sets. However, CGAs 335 are more flexible in the sense that they support the dynamic 336 modification of locator sets. 338 Therefore, CGAs are well suited to support dynamic environments such 339 as mobile hosts, where the locator set must be changed frequently. 340 HBAs are better suited for sites where the prefix set remains 341 relatively stable. 343 It should be noted that, since HBAs are defined as a CGA extension, 344 it is possible to generate a address that incorporates the strengths 345 of both HBA and CGA: i.e. that a single address can be used as an 346 HBA, enabling computationally-cheap validation amongst a fixed set of 347 addresses, and also as a CGA, enabling dynamic manipulation of the 348 locator set. For additional details, see [RFC5535]. 350 4. Shim6 in Multihomed Nodes 352 Shim6 multihomed nodes are likely to experience problems related to 353 the attachment to different provision domains. Note that these 354 problems are not specific to Shim6. [RFC6418] discusses the problems 355 associated with nodes with multiple interfaces, which may involve 356 difficulties in 357 o managing the configuration associated with different providers 358 o finding the appropriate DNS server to resolve a query and to match 359 DNS answers to providers 361 o routing the packets to the right provider 362 o selecting the source address appropriate to the destination and to 363 the outgoing provider 364 o performing session management appropriately 366 Some of these problems may also arise in single-interface hosts 367 connected to multiple networks, for example in configurations in 368 which a customer network receives multiple Provider Aggregatable 369 prefixes. These problems are relevant to other solutions supporting 370 multihoming such as SCTP (Stream Control Transmission Protocol 371 [RFC4960]), MPTCP (Multipath TCP [RFC6182]) or HIP (Host Identity 372 Protocol [RFC4423]. Note also that single-homed nodes implementing 373 Shim6 to improve communications with other nodes having multiple 374 addresses will not experience these problems. 376 The compatibility of Shim6 with configurations or mechanisms 377 developed to solve any multihoming problem has to be carefully 378 considered in a case-by-case basis. However, the interaction of 379 Shim6 with some of the solutions discussed in 380 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] is commented in the 381 next paragraphs. 383 In order to configure source and destination address selection, tools 384 such as DHCPv6 can be used to disseminate a [RFC3484] policy table to 385 a host [I-D.ietf-6man-addr-select-opt]. The impact to Shim6 of a 386 solution which disseminates the policy table to the hosts is the 387 following: Shim6 selects the ULID pair to use in a communication 388 according to the mechanism described in [RFC3484]. In case different 389 locator pairs need to be explored, nodes also use the rules defined 390 by [RFC3484] to identify valid pairs, and to establish an order among 391 them, as described in [RFC5534]. 393 When a locator has been selected by a host to be used as source 394 address for a Shim6 session, Shim6 has no means to enforce an 395 appropriate path for that source address neither in the host nor in 396 the network. For IPv6 nodes, the next hop router to use for a given 397 set of destinations can be configured through Extensions to Router 398 Advertisements through Default Router Preference and More-Specific 399 Routes [RFC4191], the use of a DHCPv6 option, or the use of a routing 400 protocol. It is also possible to rely on routers considering source 401 addresses in their forwarding decisions in addition to the usual 402 destination-based forwarding. All these solutions are compatible 403 with Shim6 operation. Note that an improper matching of source 404 address and egress provider may result in packets being dropped if 405 the provider performs Ingress Filtering [RFC2827], i.e. dropping 406 packets which come from customer networks with source addresses not 407 belonging to the prefix assigned to them, to prevent address 408 spoofing. 410 For some particular configurations, i.e. for a walled-garden or 411 closed service, the node may need to identify the most appropriate 412 DNS server to resolve a particular query. For an analysis of this 413 problem, the reader is referred to 414 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]. 416 Finally, it is worth to note that Shim6 is built to handle 417 communication problems, so it may recover from the misconfiguration 418 (or lack) of some of the mechanisms used to handle the aforementioned 419 problems. For example, if any notification is received from the 420 router dropping the packets with legitimate source addresses as a 421 result of ingress filtering, the affected locator could be associated 422 with a low preference (or not be used at all). But even if such 423 notification is not received, or not processed by the Shim6 layer, 424 defective source address or next-hop selection will be treated as a 425 communication failure, and Shim6 re-homing could finally select a 426 working path in which packets are not filtered, if this path exists. 427 This behavior results from the powerful end-to-end resilience 428 properties exhibited by the REAchability Protocol (REAP) [RFC5534]. 430 5. Shim6 Capabilities 432 5.1. Fault Tolerance 434 5.1.1. Establishing Communications After an Outage 436 If a host within a multihomed site attempts to establish a 437 communication with a remote host and selects a locator which 438 corresponds to a failed transit path, bidirectional communication 439 between the two hosts will not succeed. In order to establish a new 440 communication, the initiating host must try different combinations of 441 (source, destination) locator pairs until it finds a pair that works. 442 The mechanism for this default address selection is described in 443 [RFC3484]. As a result of the use of this mechanism, some failures 444 may not be recovered even if a valid alternative path exists between 445 two communicating hosts. For example, assuming a failure in ISP[1] 446 (see Figure 1), and host H initiating a communication with host R, 447 the source address selection algorithm described in [RFC3484] may 448 result in the selection of the source address corresponding to ISP[1] 449 for every destination address being tried by the application. 450 However, note that if R is the node initiating the communication, it 451 will find a valid path provided that the application at R tries every 452 available address for H. 454 Since a Shim6 context is normally established between two hosts only 455 after initial communication has been set up, there is no opportunity 456 for Shim6 to participate in the discovery of a suitable, initial 457 (source, destination) locator pair. The same consideration holds for 458 referrals, as it is described in Section 6. 460 5.1.2. Short-Lived and Long-Lived Communications 462 The Shim6 context establishment operation requires a 4-way packet 463 exchange, and involves some overhead on the participating hosts in 464 memory and CPU. 466 For short-lived communications between two hosts, the benefit of 467 establishing a Shim6 context might not exceed the cost, perhaps 468 because the protocols concerned are fault tolerant and can arrange 469 their own recovery (e.g. DNS) or because the frequency of re-homing 470 events is sufficiently low that the probability of such a failure 471 occurring during a short-lived exchange is not considered 472 significant. 474 It is anticipated that the exchange of Shim6 context will provide 475 most benefit for exchanges between hosts which are long-lived. For 476 this reason the default behavior of Shim6-capable hosts is expected 477 to employ deferred context-establishment. Deferred context setup 478 ensures that session establishment time will not be increased by the 479 use of Shim6. This default behavior will be able to be overridden by 480 applications which prefer immediate context establishment regardless 481 of transaction longevity, by using [RFC6316]. 483 It must be noted that all the above considerations refer to the 484 lifetime of the interaction between the peers and not about the 485 lifetime of a particular connection (e.g. TCP connection). In other 486 words, the Shim6 context is established between ULID pairs and it 487 affects all the communication between these ULIDs. So, two nodes 488 with multiple short-lived communications using the same ULID pair 489 would benefit as much from the Shim6 features as two nodes having a 490 single long-lived communication. One example of such scenario would 491 be a web client software downloading web contents from a server over 492 multiple TCP connections. Each TCP connection is short-lived, but 493 the communication/contact between the two ULID could be long-lived. 495 5.2. Load Balancing 497 The Shim6 protocol does not support load balancing within a single 498 context: all packets associated with a particular context are 499 exchanged using a single locator pair per direction, with the 500 exception of forked contexts, which are created upon explicit 501 requests from the upper-layer protocol. 503 It may be possible to extend the Shim6 protocol to use multiple 504 locator pairs in a single context, but the impact of such an 505 extension on upper-layer protocols (e.g. on TCP congestion control) 506 should be considered carefully. 508 When many contexts are considered together in aggregation, e.g. on a 509 single host which participates in many simultaneous contexts or in a 510 site full of hosts, some degree of load sharing should occur 511 naturally due to the selection of different locator pairs in each 512 context. However, there is no mechanism defined to ensure that this 513 natural load sharing is arranged to provide a statistical balance 514 between transit providers. 516 It is worth to note that the use of transport-layer solutions 517 enhanced with mechanisms to allow the use of multiple paths for a 518 transport session are more amenable for achieving load-balancing. 519 One such solution is MPTCP [RFC6182]. 521 5.3. Traffic Engineering 523 For sites with prefixes obtained from different providers, the paths 524 followed by inbound and outbound traffic are determined to a large 525 extent by the locators selected for each communication. This is not 526 a particular issue of Shim6, but it is common to any deployment in 527 which hosts are configured with addresses received from different 528 providers. Traffic Engineering in such sites will likely involve 529 proper configuration of the address selection policies defined by 530 [RFC3484]. 532 Besides, the Shim6 protocol provides some lightweight traffic 533 engineering capabilities in the form of the Locator Preferences 534 option, which allows a host to inform a remote host of local 535 preferences for locator selection. In this way, the host can 536 influence in the incoming path for the communication. This mechanism 537 is only available after a Shim6 context has been established, and it 538 is a host-based capability rather than a site-based capability. 539 There is no defined mechanism which would allow use of the Locator 540 Preferences option amongst a site full of hosts to be managed 541 centrally by the administrator of the site. 543 6. Application Considerations 545 Shim6 provides multihoming support without forcing changes in the 546 applications running on the host. The fact that an address has been 547 generated according to the CGA or HBA specification does not require 548 any specific action from the application, e.g. it can obtain remote 549 CGA or HBA addresses as a result of a getaddrinfo() call to trigger a 550 DNS Request. The storage of CGA or HBA addresses in DNS does not 551 require any modification to this protocol, since they are recorded 552 using AAAA records. Moreover, neither the ULID/locator management 553 [RFC5533] nor the failure detection and recovery [RFC5534] functions 554 require application awareness. 556 However, a specific API [RFC6316] has been developed for those 557 applications which might require additional capabilities in ULID/ 558 locator management, such as the locator pair in use for a given 559 context, or the set of local or remote locators available for it. 560 This API can also be used to disable Shim6 operation when required. 562 It is worth noting that callbacks can benefit naturally from Shim6 563 support. In a callback, an application in B retrieves IP_A, the IP 564 address of a peer A, and B uses IP_A to establish a new communication 565 with A. As long as the address exchanged, IP_A, is the ULID for the 566 initial communication between A and B, and B uses the same address as 567 in the initial communication, and this initial communication is alive 568 (or the context has not been deleted), the new communication could 569 use the locators exchanged by Shim6 for the first communication. In 570 this case, communication could proceed even if the ULID of A is not 571 reachable. 573 However, Shim6 does not provide specific protection to current 574 applications when they use referrals. A referral is the exchange of 575 the IP address IP_A of a party A by party B to party C, so that party 576 C could use IP_A to communicate with party A. In a normal case, the 577 ULID IP_A would be the only information sent by B to C as referral. 578 But if IP_A is no longer valid as locator in A, C could have trouble 579 in establishing a communication with A. Increased failure protection 580 for referrals could be obtained if B exchanged the whole list of 581 alternative locators of A, although in this case the application 582 protocol should be modified. Note that B could send to C the current 583 locator of A, instead of the ULID of A, as a way of using the most 584 recent reachability information about A. While in this case no 585 modification of the application protocol is required, some concerns 586 arise: host A may not accept one of its locator as ULID for 587 initiating a communication, and if CGA are used, the locator may not 588 be a CGA so a Shim6 context among A and C could not be created. 590 7. Interaction with Other Protocols and Mechanisms 592 In this section we discuss the interaction between Shim6 and other 593 protocols and mechanisms. Before starting the discussion, it is 594 worth noting that at the time of this writing there is a lack of 595 experience with the combination of Shim6 and these protocols and 596 mechanisms. Therefore, the conclusions stated should be reviewed as 597 real experience is gained in the use of Shim6. 599 7.1. Shim6 and Mobile IPv6 601 We next consider some scenarios in which the Shim6 protocol and the 602 MIPv6 protocol [RFC6275] might be used simultaneously. 604 7.1.1. Multihomed Home Network 606 In this case, the Home Network of the Mobile Node (MN) is multihomed. 607 This implies the availability of multiple Home Network prefixes, 608 resulting on multiple Home Addresses (HoAs) for each MN. Since the 609 MN is a node within a multihomed site, it seems reasonable to expect 610 that the MN should be able to benefit from the multihoming 611 capabilities provided by the Shim6 protocol. Moreover, the MN needs 612 to be able to obtain the multihoming benefits even when it is roaming 613 away from the Home Network: if the MN is away from the Home Network 614 while the Home Network suffers a failure in a transit path, the MN 615 should be able to continue communicating using alternate paths to 616 reach the Home Network. 618 The resulting scenario is the following: 620 +------------------------------------+ 621 | Internet | 622 +------------------------------------+ 623 | | 624 +----+ +----+ 625 |ISP1| |ISP2| 626 +----+ +----+ 627 | | 628 +------------------------------------+ 629 | Multihomed Home Network | 630 | Prefixes: P1 and P2 | 631 | | 632 | Home Agent | 633 | // | 634 +------------------//----------------+ 635 // 636 // 637 +-----+ 638 | MN | HoA1, HoA2 639 +-----+ 641 Figure 2 643 So, in this configuration, the Shim6 protocol is used to provide 644 multiple communication paths to all the nodes within the multihomed 645 sites (including the mobile nodes) and the MIPv6 protocol is used to 646 support mobility of the mobile nodes of the multihomed site. 648 The proposed protocol architecture would be the following: 650 +--------------+ 651 | Application | 652 +--------------+ 653 | Transport | 654 +--------------+ 655 | IP | 656 | +----------+ | 657 | | IPSec | | 658 | +----------+<--ULIDs 659 | | Shim6 | | 660 | +----------+<--HoAs 661 | | MIPv6 | | 662 | +----------+<--CoAs 663 | | 664 +--------------+ 666 Figure 3 668 In this architecture, the upper layer protocols and IPSec would use 669 ULIDs of the Shim6 protocol (see section 16.1 in [RFC5533] for more 670 detail on the interaction between Shim6 and IPsec). Only the HoAs 671 will be presented by the upper layers to the Shim6 layer as potential 672 ULIDs. Two Shim6 entities will exchange their own available HoAs as 673 locators. Therefore, Shim6 provides failover between different HoAs 674 and allows preserving established communications when an outage 675 affects the path through the ISP that has delegated the HoA used for 676 initiating the communication (similarly to the case of a host within 677 a multihomed site). The Care-of Addresses (CoAs) are not presented 678 to the Shim6 layer and are not included in the local locator set in 679 this case. The CoAs are managed by the MIPv6 layer, which binds each 680 HoA to a CoA. For example, if a single CoA, CoA1, is available for 681 the MN in the foreign link to which it is attached, every HoA should 682 have a bind to CoA1. 684 So, in this case, the upper layer protocols select a ULID pair for 685 the communication. The Shim6 protocol translates the ULID pair to an 686 alternative locator in case that is needed. Both the ULIDs and the 687 alternative locators are HoAs. Next, the MIPv6 layer maps the 688 selected HoA to the corresponding CoA, which is the actual address 689 included in the wire. 691 The Shim6 context is established between the MN and the Correspondent 692 Node (CN), and it would allow the communication to use all the 693 available HoAs to provide fault tolerance. The MIPv6 protocol is 694 used between the MN and the HA in the case of the bidirectional 695 tunnel mode, and between the MN and the CN in case of the RO (Route 696 Optimization) mode. 698 7.1.2. Shim6 Between the HA and the MN 700 Another scenario where a Shim6-MIPv6 interaction may be useful is the 701 case where a Shim6 context is established between the MN and the HA 702 in order to provide fault tolerance capabilities to the bidirectional 703 tunnel between them. 705 Consider the case where the HA has multiple addresses (whether 706 because the Home Network is multihomed or because the HA has multiple 707 interfaces) and/or the MN has multiple addresses (whether because the 708 visited network is multihomed or because the MN has multiple 709 interfaces). In this case, if a failure affects the address pair 710 that is being used to run the tunnel between the MN and HA, 711 additional mechanisms need to be used to preserve the communication. 713 One possibility would be to use MIPv6 capabilities, by simply 714 changing the CoA used as the tunnel endpoint. However, MIPv6 lacks 715 of failure detection mechanisms that would allow the MN and/or the HA 716 to detect the failure and trigger the usage of an alternative 717 address. Shim6 provides such failure detection protocol, so one 718 possibility would be re-using the failure detection function from the 719 Shim6 failure detection protocol in MIPv6. In this case, the Shim6 720 protocol wouldn't be used to create Shim6 context and provide fault 721 tolerance, but just its failure detection functionality would be re- 722 used. 724 The other possibility would be to use the Shim6 protocol to create a 725 Shim6 context between the HA and the MN so that the Shim6 detects any 726 failure and re-homes the communication in a transparent fashion to 727 MIPv6. In this case, the Shim6 protocol would be associated with the 728 tunnel interface. 730 7.2. Shim6 and SEND 732 Secure Neighbor Discovery (SEND) [RFC3971] uses CGAs to prove address 733 ownership for Neighbor Discovery [RFC4861]. The Shim6 protocol can 734 use either CGAs or HBAs to protect locator sets included in Shim6 735 contexts. It is expected that some hosts will need to participate in 736 both SEND and Shim6 simultaneously. 738 In the case that both the SEND and Shim6 protocols are using the CGA 739 technique to generate addresses, then there is no conflict: the host 740 will generate addresses for both purposes as CGAs, and since it will 741 be in control of the associated private key, the same CGA can be used 742 for the different protocols. 744 In the case that a Shim6-capable host is using HBAs to protect its 745 locator sets, the host will need to generate an address which is both 746 a valid CGA and a valid HBA, as defined in [RFC5535]. In this case, 747 the CGA Parameter Data Structure containing a valid public key and 748 the Multi-Prefix extension are included as inputs to the hash 749 function. 751 7.3. Shim6, SCTP and MPTCP 753 Both the SCTP [RFC4960] and MPTCP [RFC6182] protocols provide a 754 reliable, stream-based communications channel between two hosts which 755 provides a superset of the capabilities of TCP. One notable feature 756 of these two protocols is that they allow the exchange of endpoint 757 addresses between hosts, in order to recover from the failure of a 758 particular endpoint pair, or to benefit from multipath communication 759 in the MPTCP case, in a manner which is conceptually similar to 760 locator selection in Shim6. 762 SCTP and MPTCP are transport-layer protocols, higher in the protocol 763 stack than Shim6, and hence there is no fundamental incompatibility 764 which would prevent a Shim6-capable host from communicating using 765 SCTP or MPTCP. 767 However, since either SCTP or MPTCP, and Shim6 aim to exchange 768 addressing information between hosts in order to meet the same 769 generic goal, it is possible that their simultaneous use might result 770 in unexpected behavior, e.g. lead to race conditions. 772 The capabilities of these transport protocols with respect to path 773 maintenance of a reliable, connection-oriented stream protocol are 774 more extensive than the more general layer-3 locator agility provided 775 by Shim6. Therefore, it is recommended that Shim6 is not used for 776 SCTP or MPTCP sessions, and that path maintenance is provided solely 777 by SCTP or MPTCP. There are at least two ways to enforce this 778 behavior. One option would be to make the stack, and in particular 779 the Shim6 sublayer, aware of the use of SCTP or MPTCP and in this 780 case refrain from creating a Shim6 context. The other option is that 781 the upper transport layer, informs using a Shim6-capable API like the 782 one proposed in [RFC6316] that no Shim6 context must be created for 783 this particular communication. 785 In general, the issues described here may also arise for protocols 786 which handle different addresses for two communicating nodes at a 787 higher level than the network-layer to improve reliability, 788 performance, congestion control, etc. 790 7.4. Shim6 and NEMO 792 The NEMO [RFC3963] protocol extensions to MIPv6 allow a Mobile 793 Network to communicate through a bidirectional tunnel via a Mobile 794 Router (MR) to a NEMO-compliant Home Agent (HA) located in a Home 795 Network. 797 If either or both of the MR or HA are multihomed, then a Shim6 798 context established preserves the integrity of the bidirectional 799 tunnel between them in the event that a transit failure occurs in the 800 connecting path. 802 Once the tunnel between MR and HA is established, hosts within the 803 Mobile Network which are Shim6-capable can establish contexts with 804 remote hosts in order to receive the same multihoming benefits as any 805 host located within the Home Network. 807 7.5. Shim6 and HIP 809 Shim6 and the Host Identity Protocol (HIP [RFC4423]) are 810 architecturally similar in the sense that both solutions allow two 811 hosts to use different locators to support communications between 812 stable ULIDs. The signaling exchange to establish the demultiplexing 813 context on the hosts is very similar for both protocols. However, 814 there are a few key differences. First, Shim6 avoids defining a new 815 namespace for ULIDs, preferring instead to use a routable locator as 816 a ULID, while HIP uses public keys and hashes thereof as ULIDs. The 817 use of a routable locator as ULID better supports deferred context 818 establishment, application callbacks, and application referrals, and 819 avoids management and resolution costs of a new namespace, but 820 requires additional security mechanisms to securely bind the ULID 821 with the locators. Second, Shim6 uses an explicit context header on 822 data packets for which the ULIDs differ from the locators in use 823 (this header is only needed after a failure/rehoming event occurs), 824 while HIP may compress this context-tag function into the ESP SPI 825 field [RFC5201]. Third, HIP as presently defined requires the use of 826 public-key operations in its signaling exchange and ESP encryption in 827 the data plane, while the use of Shim6 requires neither (if only HBA 828 addresses are used). HIP by default provides data protection, while 829 this is a non-goal for Shim6. 831 Shim6 aimed to provide a solution to a specific problem, multihoming, 832 which minimizes deployment disruption, while HIP is considered more 833 of an experimental approach intended to solve several more general 834 problems (mobility, multihoming and loss of end-to-end addressing 835 transparency) through an explicit identifier/locator split. 837 Communicating hosts that are willing and interested to run HIP 838 (perhaps extended with Shim6's failure detection protocol) likely 839 have no reason to also run Shim6. In this sense, HIP may be viewed 840 as a possible long-term evolution or extension of the Shim6 841 architecture, or one possible implementation of the Extended Shim6 842 Design (ESD [I-D.nordmark-shim6-esd]). 844 7.6. Shim6 and Firewalls 846 The ability of Shim6 to divert the communication to different paths 847 may be affected by certain firewall configurations. For example, 848 consider a deployment in which one of the peers of a Shim6 session is 849 protected by a firewall (i.e. all the paths to the locators of that 850 peer traverse the firewall). The firewall implements the Simple 851 Security model [RFC4864], in which incoming packets are checked 852 against a state resulting from outgoing traffic, either associated 853 with the locator of the internal node ('endpoint independent 854 filtering') or to both the locators of the internal and external 855 nodes ('address dependent filtering' or 'address and port dependent 856 filtering'). If the external node changes the locator associated 857 with the internal node, the packet will be discarded by the firewall. 858 In addition, if the firewall implements 'address dependent filtering' 859 or 'address and port dependent filtering', any change by the external 860 node in the locator used to identify itself will also result in the 861 packet being discarded by the firewall. 863 This issue could be mitigated by making the firewalls aware of the 864 different locators which could be associated with a given 865 communication. If the firewall is implemented in the communication 866 node itself, the firewall could inspect the Shim6 control packet 867 exchange to obtain this information, or the Shim6 software module 868 could explicitly inform the firewall software module. For firewalls 869 located outside the node, the Shim6 control packet exchange can be 870 used to associate the alternate locators to the communication state, 871 although it may not work for topologies in which both directions for 872 the communication do not traverse the firewall, or in which the 873 firewall is not traversed after a locator change. The detail of any 874 of such mechanisms is out of the scope of this document. 876 However, note that a failure in using the alternative locators does 877 not impact in the communication between the nodes as long as the path 878 between them defined by the initial locator pair remains available. 879 In this case, data packets flow between the communicating nodes as 880 for any non-Shim6 communication. 882 7.7. Shim6 and NPTv6 884 Address translation techniques such as Network Prefix Translation 885 (NPTv6, [RFC6296]) may be used until workable solutions to avoid 886 renumbering or facilitate multihoming are developed [RFC5902]. We 887 now consider the impact of NPTv6 in Shim6 operation. Some of the 888 considerations stated in this section may also be applicable to other 889 types of IPv6 NAT. 891 The main purpose of Shim6 is to provide locator agility below 892 transport protocols. To prevent the risk of redirection attacks by 893 abusing on the locator exchange facilities provided by Shim6, the 894 protocol is built upon the cryptographic properties of CGA and HBA 895 addresses. When a CGA address of a node is used as the local ULID, 896 the locators configured in the node can be signed with the private 897 key associated with the CGA. A peer receiving a Shim6 message 898 performs a hash of the CGA Parameter Data Structure information 899 received, including a public key, to assure that this key is bound to 900 the CGA address, and then checks the signature protecting the 901 locators. When an HBA address of a node is used as the local ULID, 902 the HBA address securely chains the ULID and other locators of the 903 node by means of a hash. For both the CGA and the HBA, the locators 904 can be exchanged at the four-way handshake used to establish the 905 Shim6 context, or once the context has been established by means of 906 an Update Request message. 908 When a node behind an NPTv6 communicates, the NAT device translates 909 the address assigned to this internal node to an address of its 910 address pool. This operation results in a mismatch between the 911 address seen by external hosts and the address configured in the 912 internal node, which is the locator that would be conveyed in a Shim6 913 locator exchange and is also the address for which the security 914 defined in the CGA and HBA specifications are provided. Then, the 915 validation processes performed by an external node may prevent the 916 creation of the Shim6 context, or may allow the context to be created 917 but render the alternative locator of the internal host unusable. 919 However, note that the failure in creating a Shim6 context, or in 920 using the alternative locators, does not impact in the communication 921 between the nodes as long as the path between them defined by the 922 initial locator pair remains available. Data packets flow between 923 the communicating nodes as for any non-Shim6 communication. Not 924 creating the Shim6 context or not being able to convey the local 925 locators to the peer node affect to the added value provided by 926 Shim6, i.e. to the ability of preserving the communication in case 927 any of the locators fail. Therefore, using Shim6 with NPTv6 does not 928 provide less functionality than using IPv6 in the same scenario. 930 We now illustrate some cases that may occur when combining Shim6 and 931 NPTv6. The following discussion does not aim to be exhaustive in the 932 cases that may arise, but just aims to provide some examples of 933 possible situations. We assume a scenario in which host A is located 934 behind a NPTv6 device for its locator IP_A1, but it is connected to 935 the public IPv6 internet for its locator IP_A2. Once translated, 936 locator IP_A1 appears to external nodes as IP_T. Node A communicates 937 with node B, with public addresses IP_B1 and IP_B2. 939 +-----+ 940 | A | 941 +-----+ 942 IP_A1 | | IP_A2 943 | | 944 | +-----+ 945 | | 946 +--------+ | 947 | NPTv6 | | 948 +--------+ | 949 IP_T | | 950 | | 951 +--------------------------+ 952 | Internet | 953 +--------------------------+ 954 | | 955 IP_B1 | | IP_B2 956 +-----+ 957 | B | 958 +-----+ 960 Figure 4 962 We first discuss some issues related with the four-way handshake used 963 to establish the Shim6 context. When the locator information is 964 included in the Shim6 exchange, either in the I2 or R2 messages, the 965 receiver is required to validate the ULID of the peer node by 966 performing the CGA or HBA address validation procedure. In case the 967 validation fails, the message containing the information is silently 968 discarded. In the scenario depicted in Figure 4, some of the cases 969 which may occur are: 970 o Node A initiates the exchange, with IP_B1 as destination address 971 and IP_A1 as source address, which is a CGA. Node A includes 972 IP_A2 as an alternative locator in the I2 message. Node B sees 973 IP_T as the ULID for A, so when it validates the CGA with the 974 information contained in I2, the validation fails because the CGA 975 Parameter Data Structure contains information bound to IP_A1. 976 Therefore, B silently discards the received I2 message. Without 977 receiving a valid I2 message, B does not create the Shim6 context. 978 Without receiving the R2 message, A does not create either the 979 Shim6 context. However, data communication can proceed as long as 980 the path between IP_A1 and IP_B1 is valid. A similar case occur 981 if IP_A1 and IP_A2 form a HBA, instead of using CGAs for securing 982 the communication. 983 o Node A initiates the exchange with IP_B1 as destination address 984 and IP_A2, its public address, as source address, which is a CGA. 985 Node A includes IP_A1 as an alternative locator in the I2 message. 986 In this case, B can successfully validate IP_A2 as a CGA. 987 Regarding to the validation of IP_A1 as an alternative locator for 988 A, the Shim6 specification [RFC5533] indicates that it should 989 perform this check when the I2 message is received, but it may 990 perform it later on, provided that the check is performed before 991 using it as a locator. In case the validation is performed when 992 I2 is received, the I2 message would be silently discarded, with 993 the same result as for the previous case. In case the validation 994 is performed later, the Shim6 context would be established in both 995 nodes A and B, but B could not send to IP_A1, and packets sent by 996 A from IP_A1 will not be received by B. Note that in this case 997 both IP_B1 and IP_B2 could be used by A and B, as long as the 998 locator for A is IP_A2, so limited locator agility may be 999 achieved. 1000 o Node B initiates the exchange with IP_B1 as source address, and 1001 IP_A2 as destination address, which is a CGA. This case is 1002 similar to the previous one, although it is the R2 message sent by 1003 A the one that cannot be validated. While A can create a context 1004 with B, B cannot do the same for A. Data communication using IP_B1 1005 and IP_A2 can proceed. However, A may try to use IP_B2 as 1006 alternative locator but the data packets sent, carrying the Shim6 1007 Extension Header, will not be associated by B to any established 1008 context, so they will be discarded. The same occurs for packets 1009 sent by A with IP_A1 as source address. 1011 We can also consider the case in which node A do not exchange its own 1012 locators in the Shim6 establishment exchange. For example, a Shim6 1013 context can be established between CGA IP_A2, and IP_B1. B can 1014 convey locator IP_B2 in the four-way handshake without, and 1015 validation will be correctly done by A. Later on, A may send an 1016 Update Request message to inform B about its locator IP_A1. 1017 Validation for this message will fail in B, and B will send a Shim6 1018 Error message to A. Neither A nor B will use IP_A1 as locator. 1019 However, in IP_A2, IP_B1 and IP_B2 can still be used as valid 1020 locators for the communication. 1022 Finally, note that modification of the Shim6 control packets by the 1023 NPTv6 would not be able to generate a valid signature, in case a CGA 1024 is being used, or a Parameter Data Structure binding the translated 1025 locator to the other locators of a node, in case a HBA is being used. 1026 Therefore, the same failure cases described before would remain. 1028 8. Security Considerations 1030 This section considers the applicability of the Shim6 protocol from a 1031 security perspective, i.e. which security features can be expected by 1032 applications and users of the Shim6 protocol. 1034 First of all, it should be noted that the Shim6 protocol is not a 1035 security protocol, unlike for instance HIP. This means that as 1036 opposed to HIP, it is an explicit non-goal of the Shim6 protocol to 1037 provide enhanced security for the communications that use the Shim6 1038 protocol. The goal of the Shim6 protocol design in terms of security 1039 is not to introduce new vulnerabilities that were not present in the 1040 current non-Shim6 enabled communications. In particular, it is an 1041 explicit non-goal of the Shim6 protocol security to provide 1042 protection from on-path attackers. On-path attackers are able to 1043 sniff and spoof packets in the current Internet, and they are able to 1044 do the same in Shim6 communications (as long as the communication 1045 flows through the path they are located on). So, summarizing, the 1046 Shim6 protocol does not provide data packet protection from on-path 1047 attackers. 1049 However, the Shim6 protocol does use several security techniques. 1050 The goal of these security measures is to protect the Shim6 signaling 1051 protocol from new attacks resulting from the adoption of the Shim6 1052 protocol. In particular, the use of HBA/CGA prevents on-path and 1053 off-path attackers injecting new locators into the locator set of a 1054 Shim6 context, thus preventing redirection attacks [RFC4218]. 1055 Moreover, the usage of probes before re-homing to a different locator 1056 as a destination address prevents flooding attacks from off-path 1057 attackers. Note that for nodes using CGA addresses, security depends 1058 on the secure handling of the private key associated with the 1059 signature and validation of locators. In particular, any address 1060 configuration method must assure that the private key remains secret, 1061 as discussed in Section 3.3. 1063 In addition, the usage of a 4-way handshake for establishing the 1064 Shim6 context protects against DoS attacks, so hosts implementing the 1065 Shim6 protocol should not be more vulnerable to DoS attacks than 1066 regular IPv6 hosts. 1068 Finally, many Shim6 signaling messages contain a Context Tag, meaning 1069 that only attackers that know the Context Tag can forge them. As a 1070 consequence, only on-path attackers can generate false Shim6 1071 signaling packets for an established context. The impact of these 1072 attacks would be limited since they would not be able to add 1073 additional locators to the locator set (because of the HBA/CGA 1074 protection). In general the possible attacks have similar effects to 1075 the ones that an on-path attacker can launch on any regular IPv6 1076 communication. The residual threats are described in the Security 1077 Considerations of the Shim6 protocol specification [RFC5533]. 1079 8.1. Privacy Considerations 1081 The Shim6 protocol is designed to provide some basic privacy 1082 features. In particular, HBAs are generated in such a way, that the 1083 different addresses assigned to a host cannot be trivially linked 1084 together as belonging to the same host, since there is nothing in 1085 common in the addresses themselves. Similar features are provided 1086 when the CGA protection is used. This means that it is not trivial 1087 to determine that a set of addresses is assigned to a single Shim6 1088 host. 1090 However, the Shim6 protocol does exchange the locator set in clear 1091 text and it also uses a fixed Context Tag when using different 1092 locators in a given context. This implies that an attacker observing 1093 the Shim6 context establishment exchange or seeing different payload 1094 packets exchanged through different locators, but with the same 1095 Context Tag, can determine the set of addresses assigned to a host. 1096 However, this requires that the attacker is located along the path 1097 and that it can capture the Shim6 signaling packets. 1099 9. IANA Considerations 1101 This document has no actions for IANA. 1103 10. Contributors 1105 The analysis on the interaction between the Shim6 protocol and the 1106 other protocols presented in this note benefited from the advice of 1107 various people including Tom Henderson, Erik Nordmark, Hesham 1108 Soliman, Vijay Devarpalli, John Loughney and Dave Thaler. 1110 11. Acknowledgements 1112 Joe Abley's work was supported in part by the US National Science 1113 Foundation (research grant SCI-0427144) and DNS-OARC. 1115 Marcelo Bagnulo worked on this document while visiting Ericsson 1116 Research Laboratory Nomadiclab. 1118 Alberto Garcia-Martinez was supported in part by the eeCONTET project 1119 (TEC2011-29688-C02-02, granted by the Spanish Science and Innovation 1120 Ministry). 1122 Shinta Sugimoto reviewed this document and provided comments and 1123 text. 1125 Brian Carpenter, Jari Arkko, Joel Halpern, Iljitsch van Beijnum, Sam 1126 Xia, Carsten Bormann, Dan Wing, Stephen Farrell and Stewart Bryant 1127 reviewed this document and provided comments. 1129 12. References 1131 12.1. Normative References 1133 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1134 Defeating Denial of Service Attacks which employ IP Source 1135 Address Spoofing", BCP 38, RFC 2827, May 2000. 1137 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1138 and M. Carney, "Dynamic Host Configuration Protocol for 1139 IPv6 (DHCPv6)", RFC 3315, July 2003. 1141 [RFC3484] Draves, R., "Default Address Selection for Internet 1142 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1144 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1145 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1146 RFC 3963, January 2005. 1148 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1149 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1151 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1152 RFC 3972, March 2005. 1154 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1155 Architecture", RFC 4291, February 2006. 1157 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1158 (HIP) Architecture", RFC 4423, May 2006. 1160 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1161 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1162 September 2007. 1164 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1165 Address Autoconfiguration", RFC 4862, September 2007. 1167 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1168 RFC 4960, September 2007. 1170 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1171 "Host Identity Protocol", RFC 5201, April 2008. 1173 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1174 Shim Protocol for IPv6", RFC 5533, June 2009. 1176 [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and 1177 Locator Pair Exploration Protocol for IPv6 Multihoming", 1178 RFC 5534, June 2009. 1180 [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, 1181 June 2009. 1183 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1184 NAT64: Network Address and Protocol Translation from IPv6 1185 Clients to IPv4 Servers", RFC 6146, April 2011. 1187 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 1188 Iyengar, "Architectural Guidelines for Multipath TCP 1189 Development", RFC 6182, March 2011. 1191 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1192 in IPv6", RFC 6275, July 2011. 1194 [RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, 1195 "Sockets Application Program Interface (API) for 1196 Multihoming Shim", RFC 6316, July 2011. 1198 12.2. Informative References 1200 [I-D.ietf-6man-addr-select-opt] 1201 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 1202 "Distributing Address Selection Policy using DHCPv6", 1203 draft-ietf-6man-addr-select-opt-03 (work in progress), 1204 February 2012. 1206 [I-D.ietf-csi-dhcpv6-cga-ps] 1207 Jiang, S. and S. Shen, "Analysis of Possible DHCPv6 and 1208 CGA Interactions", draft-ietf-csi-dhcpv6-cga-ps-09 (work 1209 in progress), March 2012. 1211 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 1212 Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. 1214 Wing, "IPv6 Multihoming without Network Address 1215 Translation", 1216 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work 1217 in progress), February 2012. 1219 [I-D.nordmark-shim6-esd] 1220 Nordmark, E., "Extended Shim6 Design for ID/loc split and 1221 Traffic Engineering", draft-nordmark-shim6-esd-01 (work in 1222 progress), February 2008. 1224 [RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the 1225 Internet", RFC 3221, December 2001. 1227 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 1228 Multihoming Architectures", RFC 3582, August 2003. 1230 [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. 1231 Gill, "IPv4 Multihoming Practices and Limitations", 1232 RFC 4116, July 2005. 1234 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1235 More-Specific Routes", RFC 4191, November 2005. 1237 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 1238 Multihoming Solutions", RFC 4218, October 2005. 1240 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 1241 E. Klein, "Local Network Protection for IPv6", RFC 4864, 1242 May 2007. 1244 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 1245 Workshop on Routing and Addressing", RFC 4984, 1246 September 2007. 1248 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 1249 "Problem Statement for Default Address Selection in Multi- 1250 Prefix Environments: Operational Issues of RFC 3484 1251 Default Rules", RFC 5220, July 2008. 1253 [RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on 1254 IPv6 Network Address Translation", RFC 5902, July 2010. 1256 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1257 Translation", RFC 6296, June 2011. 1259 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 1260 Provisioning Domains Problem Statement", RFC 6418, 1261 November 2011. 1263 Authors' Addresses 1265 Joe Abley 1266 ICANN 1267 4676 Admiralty Way, Suite 330 1268 Marina del Rey, CA 90292 1269 USA 1271 Phone: +1 519 670 9327 1272 Email: joe.abley@icann.org 1274 Marcelo Bagnulo 1275 U. Carlos III de Madrid 1276 Av. Universidad 30 1277 Leganes, Madrid 28911 1278 Spain 1280 Phone: +34 91 6248814 1281 Email: marcelo@it.uc3m.es 1282 URI: http://www.it.uc3m.es/ 1284 Alberto Garcia-Martinez 1285 U. Carlos III de Madrid 1286 Av. Universidad 30 1287 Leganes, Madrid 28911 1288 Spain 1290 Phone: +34 91 6248782 1291 Email: alberto@it.uc3m.es 1292 URI: http://www.it.uc3m.es/