doc: Add RFC documents

1 files changed, 1571 insertions, 0 deletions

diff --git a/doc/rfc/rfc6629.txt b/doc/rfc/rfc6629.txt
new file mode 100644
index 0000000..047e980
--- /dev/null
+++ b/doc/rfc/rfc6629.txt
@@ -0,0 +1,1571 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Abley
+Request for Comments: 6629                                         ICANN
+Category: Informational                                       M. Bagnulo
+ISSN: 2070-1721                                       A. Garcia-Martinez
+                                                                    UC3M
+                                                               June 2012
+
+
+                Considerations on the Application of the
+           Level 3 Multihoming Shim Protocol for IPv6 (Shim6)
+
+Abstract
+
+   This document discusses some considerations on the applicability of
+   the level 3 multihoming Shim protocol for IPv6 (Shim6)
+   and associated support protocols and mechanisms to provide site
+   multihoming capabilities in IPv6.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any
+   errata, and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6629.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Abley, et al.                 Informational                     [Page 1]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Deployment Scenarios ............................................4
+   3. Addresses and Shim6 .............................................6
+      3.1. Protocol Version (IPv4 vs. IPv6) ...........................6
+      3.2. Prefix Lengths .............................................7
+      3.3. Address Generation and Configuration .......................7
+      3.4. Use of CGA vs. HBA .........................................7
+   4. Shim6 in Multihomed Nodes .......................................8
+   5. Shim6 Capabilities .............................................10
+      5.1. Fault Tolerance ...........................................10
+           5.1.1. Establishing Communications After an Outage ........10
+           5.1.2. Short-Lived and Long-Lived Communications ..........11
+      5.2. Load Balancing ............................................11
+      5.3. Traffic Engineering .......................................12
+   6. Application Considerations .....................................12
+   7. Interaction with Other Protocols and Mechanisms ................13
+      7.1. Shim6 and Mobile IPv6 .....................................13
+           7.1.1. Multihomed Home Network ............................14
+           7.1.2. Shim6 Between the HA and the MN ....................16
+      7.2. Shim6 and SEND ............................................16
+      7.3. Shim6, SCTP and MPTCP .....................................17
+      7.4. Shim6 and NEMO ............................................18
+      7.5. Shim6 and HIP .............................................18
+      7.6. Shim6 and Firewalls .......................................19
+      7.7. Shim6 and NPTv6 ...........................................20
+   8. Security Considerations ........................................23
+      8.1. Privacy Considerations ....................................24
+   9. Contributors ...................................................24
+   10. Acknowledgements ..............................................24
+   11. References ....................................................25
+      11.1. Normative References .....................................25
+      11.2. Informative References ...................................26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley, et al.                 Informational                     [Page 2]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+1.  Introduction
+
+   Site multihoming is an arrangement by which a site may use multiple
+   paths to the rest of the Internet to provide better reliability for
+   traffic passing in and out of the site than would be possible with a
+   single path.  Some of the motivations for operators to multihome
+   their network are described in [RFC3582].
+
+   In IPv4, site multihoming is achieved by injecting the additional
+   state required to allow session resilience over re-homing events
+   [RFC4116] into the global Internet routing system (sometimes referred
+   to as the Default-Free Zone, or DFZ).  There is concern that this
+   approach will not scale [RFC3221] [RFC4984].
+
+   Site multihoming in IPv6 can be achieved as in IPv4, thus facing
+   similar scalability concerns.  However, IPv6's large address space
+   enables a different solution for site multihoming in IPv6: to assign
+   multiple addresses to each host, one or more from each provider.
+   Deploying site multihoming in this way does not impact the routing
+   system.  So such a site multihoming strategy may be extended to a
+   large number of sites, and may be applied to small sites that would
+   not be eligible for site multihoming based on the injection of routes
+   to Provider Independent (PI) prefixes.  A drawback of this
+   multihoming approach is that it does not provide transport-layer
+   stability across re-homing events.
+
+   Shim6 provides layer-3 support for making re-homing events
+   transparent to the transport layer by means of a shim approach.  Once
+   a Shim6 session has been established, the failure detection mechanism
+   defined for Shim6 allows finding new, valid locator combinations in
+   case of failure and using these locators to continue the
+   communication.  However, Shim6 does not provide failure protection to
+   the communication establishment, so if a host within a multihomed
+   site attempts to establish a communication with a remote host and
+   selects an address that corresponds to a failed transit path, the
+   communication will fail.  State information relating to the
+   multihoming of two endpoints exchanging unicast traffic is retained
+   on the endpoints themselves, rather than in the network.
+   Communications between Shim6-capable hosts and Shim6-incapable hosts
+   proceed as normal, but without the benefit of transport-layer
+   stability.  The Shim6 approach is thought to have better scaling
+   properties with respect to the state held in the DFZ than the PI
+   approach.  In order to successfully deploy Shim6 in a multihomed
+   site, additional mechanisms may be required to solve issues, such as
+   selecting the source address appropriate to the destination and to
+   the outgoing provider, or to allow the network manager to perform
+   traffic engineering.  Such problems are not specific to Shim6, but
+   are relevant to the hosts of any site that is connected to multiple
+
+
+
+Abley, et al.                 Informational                     [Page 3]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   transit providers, and that receives an IPv6 prefix from each of the
+   providers [RFC5220].  Some of these mechanisms are not defined today.
+   However, note that once a Shim6 session has been established, Shim6
+   reduces the impact of these problems, because if a working path
+   exists, Shim6 will find it.
+
+   This note describes the applicability of the Level 3 multihoming
+   (hereafter Shim6) protocol defined in [RFC5533] and the failure
+   detection mechanisms defined in [RFC5534].
+
+   The terminology used in this document, including terms like locator
+   and Upper-Layer Identifier (ULID), is defined in [RFC5533].
+
+2.  Deployment Scenarios
+
+   The goal of the Shim6 protocol is to support locator agility in
+   established communications; different layer-3 endpoint addresses may
+   be used to exchange packets belonging to the same transport-layer
+   session, all the time presenting a consistent identifier pair to
+   upper-layer protocols.
+
+   In order to be useful, the Shim6 protocol requires that at least one
+   of the peers have more than one address that could be used on the
+   wire (as locators).  In the event of communications failure between
+   an active pair of addresses, the Shim6 protocol attempts to
+   reestablish communication by trying different combinations of
+   locators.
+
+   While other multi-addressing scenarios are not precluded, the
+   scenario in which the Shim6 protocol is expected to operate is that
+   of a multihomed site that is connected to multiple transit providers,
+   and that receives an IPv6 prefix from each of them.  This
+   configuration is intended to provide protection for the end-site in
+   the event of a failure in some subset of the available transit
+   providers, without requiring the end-site to acquire PI address space
+   or requiring any particular cooperation between the transit
+   providers.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley, et al.                 Informational                     [Page 4]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+    ,------------------------------------.       ,----------------.
+    |        Rest of the Internet        +-------+ Remote Host R  |
+    `--+-----------+------------------+--'       `----------------'
+       |           |                  |            LR[1] ... LR[m]
+   ,---+----.  ,---+----.        ,----+---.
+   | ISP[1] |  | ISP[2] | ...... | ISP[n] |
+   `---+----'  `---+----'        `----+---'
+       |           |                  |
+   ,---+-----------+------------------+---.
+   |   Multi-Homed Site S assigned        |
+   |   prefixes P[1], P[2], ..., P[n]     |
+   |                                      |
+   |  ,--------. L[1] = P[1]:iid[1],      |
+   |  | Host H | L[2] = P[2]:iid[2], ...  |
+   |  `--------' L[n] = P[n]:iid[n]       |
+   `--------------------------------------'
+
+                                 Figure 1
+
+   In the scenario illustrated in Figure 1, host H communicates with
+   some remote host R.  Each of the addresses L[i] configured on host H
+   in the multihomed site S can be reached through provider ISP[i] only,
+   since ISP[i] is solely responsible for advertising a covering prefix
+   for P[i] to the rest of the Internet.
+
+   The use of locator L[i] on H hence causes inbound traffic towards H
+   to be routed through ISP[i].  Changing the locator from L[i] to L[j]
+   will have the effect of re-routing inbound traffic to H from ISP[i]
+   to ISP[j].  This is the central mechanism by which the Shim6 protocol
+   aims to provide multihoming functionality: by changing locators, host
+   H can change the upstream ISP used to route inbound packets towards
+   itself.  Regarding the outbound traffic to H, the path taken in this
+   case depends on both the actual locator LR[j] used for R, and the
+   administrative exit selection policy of site S.  As discussed in
+   Section 4, the site should deliver outgoing packets that have a
+   source address derived from the prefix of ISP[i] to that particular
+   provider, in order to prevent those packets from being filtered due
+   to ingress filtering [RFC2827] being applied by the providers.  It is
+   worth noting that in a scenario such as the one depicted in Figure 1,
+   the paths followed by inbound and outbound traffic are determined, to
+   a large extent, by the locators in use for the communication.  This
+   is not a particular issue of Shim6, but it is common to any
+   deployment in which hosts are configured with addresses received from
+   different providers.  Traffic Engineering in such sites will likely
+   involve proper configuration of address selection policies in the
+   hosts, by means of mechanisms such as the ones discussed in Section
+   4.
+
+
+
+
+Abley, et al.                 Informational                     [Page 5]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   The Shim6 protocol has other potential applications beyond site
+   multihoming.  For example, since Shim6 is a host-based protocol, it
+   can also be used to support host multihoming.  In this case, a
+   failure in communication between a multihomed host and some other
+   remote host might be repaired by selecting a locator associated with
+   a different interface.
+
+   To allow nodes to benefit from the capabilities provided by Shim6,
+   (discussed in Section 5) such as fault tolerance, nodes should be
+   configured to initiate a Shim6 session with any peer node if they
+   have multiple locators to use.  Note that this configuration can be
+   performed transparently to the applications, in the sense that
+   applications do not need to be aware of the Shim6 functionality
+   provided by the node; in particular, nodes are not forced to use the
+   Shim6 API [RFC6316] to benefit from Shim6.  The Shim6 session should
+   be created after the two nodes have been communicating for some time,
+   i.e., using the deferred context establishment facility provided by
+   Shim6.  Otherwise, the cost of the Shim6 4-way handshake used for
+   establishing the session may exceed the benefits provided for short-
+   lived communications (see Section 5.1.2).  More advanced node
+   configuration may involve configuring different delays for initiating
+   the session for different applications, for example, based on a per-
+   port configuration.  Nodes being able to use a single locator for the
+   communication should not initiate the creation of a Shim6 context,
+   but should participate if another node initiates it.  Note that
+   Shim6-aware applications can override this behavior by means of the
+   Shim6 API [RFC6316].
+
+3.  Addresses and Shim6
+
+3.1.  Protocol Version (IPv4 vs. IPv6)
+
+   The Shim6 protocol is defined only for IPv6.  While some Shim6-like
+   approaches have been suggested to support IPv4 addresses as a locator
+   [SHIM6-ESD], it is not clear if such extensions are feasible.
+
+   The Shim6 protocol, as specified for IPv6, incorporates cryptographic
+   elements in the construction of locators (see [RFC3972] and
+   [RFC5535]).  Since IPv4 addresses are insufficiently large to contain
+   addresses constructed in this fashion, direct use of Shim6 with IPv4
+   addresses is not possible.
+
+   In addition, there are other factors to take into account when
+   considering the support of IPv4 addresses, in particular, IPv4
+   locators.  Using multiple IPv4 addresses in a single host in order to
+   support the Shim6 style of multihoming would result in an increased
+   IPv4 address consumption, which would be problematic considering that
+   the IPv4 address space has been exhausted.  Besides, Shim6 may
+
+
+
+Abley, et al.                 Informational                     [Page 6]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   experience additional problems if locators become translated on the
+   wire.  Address translation is more likely to involve IPv4 addresses.
+   IPv4 addresses can be translated to other IPv4 addresses (for
+   example, a private IPv4 address into a public IPv4 address and vice
+   versa) or to/from IPv6 addresses (for example, as defined by NAT64
+   [RFC6146]).  When address translation occurs, a locator exchanged by
+   Shim6 could be different from the address needed to reach the
+   corresponding host, either because the translated version of the
+   locator exchanged by Shim6 is not known or because the translation
+   state no longer exists in the translator device.  Besides, the
+   translated locators will not be verifiable with the current
+   Cryptographically Generated Address (CGA) and Hash-Based Address
+   (HBA) verification mechanisms, which protect the locators as seen by
+   the node for which they are configured.
+
+3.2.  Prefix Lengths
+
+   The Shim6 protocol does not assume that all the prefixes assigned to
+   the multihomed site have the same prefix length.
+
+   However, the use of CGA [RFC3972] and HBA [RFC5535] involves encoding
+   information in the lower 64 bits of the locators.  This imposes the
+   requirement that all interface addresses should be able to
+   accommodate 64-bit interface identifiers on Shim6-capable hosts.
+   Note that this is imposed by RFC 4291 [RFC4291].
+
+3.3.  Address Generation and Configuration
+
+   The security of the Shim6 protocol is based on the use of CGA and HBA
+   addresses.
+
+   The CGA and HBA generation process can use the information provided
+   by the stateless auto-configuration mechanism defined in [RFC4862]
+   with the additional considerations presented in [RFC3972] and
+   [RFC5535].
+
+   Stateful address auto-configuration using DHCP [RFC3315] is not
+   currently supported, because there is no defined mechanism to convey
+   the CGA Parameter Data Structure and other relevant information from
+   the DHCP server to the host.  An analysis of the possible
+   interactions between DHCPv6 and CGA can be found in [DHCPv6-CGA].
+
+3.4.  Use of CGA vs. HBA
+
+   The choice between CGA and HBA is a trade-off between flexibility and
+   performance.
+
+
+
+
+
+Abley, et al.                 Informational                     [Page 7]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   The use of HBA is more efficient in the sense that addresses require
+   less computation than CGA, involving only hash operations for both
+   the generation and the verification of locator sets.  However, the
+   locators of an HBA set are determined during the generation process
+   and cannot be subsequently changed; the addition of new locators to
+   that initial set is not supported.  Therefore, a node using an HBA as
+   a ULID for a Shim6 session can only use the locators associated to
+   that HBA for the considered Shim6 session.  If the node wants to use
+   a new set of locators, it has to generate a new HBA including the
+   prefixes of the new locators (which will result with very high
+   probability in different addresses to those of the previous set).
+   New sessions initiated with a ULID belonging to the new HBA address
+   set could use the new locators.
+
+   The use of CGA is more computationally expensive, involving public-
+   key cryptography in the verification of locator sets.  However, CGAs
+   are more flexible in the sense that they support the dynamic
+   modification of locator sets.
+
+   Therefore, CGAs are well suited to support dynamic environments such
+   as mobile hosts, where the locator set must be changed frequently.
+   HBAs are better suited for sites where the prefix set remains
+   relatively stable.
+
+   It should be noted that since HBAs are defined as a CGA extension, it
+   is possible to generate an address that incorporates the strengths of
+   both HBA and CGA, i.e., that a single address can be used as an HBA,
+   enabling computationally-cheap validation amongst a fixed set of
+   addresses, and also as a CGA, enabling dynamic manipulation of the
+   locator set.  For additional details, see [RFC5535].
+
+4.  Shim6 in Multihomed Nodes
+
+   Shim6 multihomed nodes are likely to experience problems related to
+   the attachment to different provision domains.  Note that these
+   problems are not specific to Shim6.  [RFC6418] discusses the problems
+   associated with nodes with multiple interfaces, which may involve
+   difficulties in
+
+   o  managing the configuration associated with different providers.
+
+   o  finding the appropriate DNS server to resolve a query and to match
+      DNS answers to providers.
+
+   o  routing the packets to the right provider.
+
+   o  selecting the source address appropriate to the destination and to
+      the outgoing provider.
+
+
+
+Abley, et al.                 Informational                     [Page 8]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   o  performing session management appropriately.
+
+   Some of these problems may also arise in single-interface hosts
+   connected to multiple networks, for example, in configurations in
+   which a customer network receives multiple Provider Aggregatable
+   prefixes.  These problems are relevant to other solutions supporting
+   multihoming, such as Stream Control Transmission Protocol (SCTP)
+   [RFC4960], Multipath TCP (MPTCP) [RFC6182], or Host Identity Protocol
+   (HIP) [RFC4423].  Note also that single-homed nodes implementing
+   Shim6 to improve communications with other nodes having multiple
+   addresses will not experience these problems.
+
+   The compatibility of Shim6 with configurations or mechanisms
+   developed to solve any multihoming problem has to be carefully
+   considered on a case-by-case basis.  However, the interaction of
+   Shim6 with some of the solutions discussed in [IPv6NAT] is commented
+   on in the next paragraphs.
+
+   In order to configure source and destination address selection, tools
+   such as DHCPv6 can be used to disseminate an [RFC3484] policy table
+   to a host [6MAN].  The impact to Shim6 using this solution, which
+   disseminates the policy table to the hosts, is the following: Shim6
+   selects the ULID pair to use in communication according to the
+   mechanism described in [RFC3484].  In case different locator pairs
+   need to be explored, nodes also use the rules defined by [RFC3484] to
+   identify valid pairs, and to establish an order among them, as
+   described in [RFC5534].
+
+   When a locator has been selected by a host to be used as the source
+   address for a Shim6 session, Shim6 has no means to enforce an
+   appropriate path for that source address in either the host or the
+   network.  For IPv6 nodes, the next-hop router to use for a given set
+   of destinations can be configured through Extensions to Router
+   Advertisements, through Default Router Preference and More-Specific
+   Routes [RFC4191], the use of a DHCPv6 option, or the use of a routing
+   protocol.  It is also possible to rely on routers that consider
+   source addresses in their forwarding decisions in addition to the
+   usual destination-based forwarding.  All these solutions are
+   compatible with Shim6 operation.  Note that an improper matching of
+   source address and egress provider may result in packets being
+   dropped if the provider performs ingress filtering [RFC2827], i.e.,
+   dropping packets that come from customer networks with source
+   addresses not belonging to the prefix assigned to them to prevent
+   address spoofing.
+
+
+
+
+
+
+
+Abley, et al.                 Informational                     [Page 9]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   For some particular configurations, i.e., for a walled-garden or
+   closed service, the node may need to identify the most appropriate
+   DNS server to resolve a particular query.  For an analysis of this
+   problem, the reader is referred to [IPv6NAT].
+
+   Finally, note that Shim6 is built to handle communication problems,
+   so it may recover from the misconfiguration (or lack) of some of the
+   mechanisms used to handle the aforementioned problems.  For example,
+   if any notification is received from the router dropping the packets
+   with legitimate source addresses as a result of ingress filtering,
+   the affected locator could be associated with a low preference (or
+   not be used at all).  But even if such a notification is not
+   received, or not processed by the Shim6 layer, the defective source
+   address or next-hop selection will be treated as a communication
+   failure.  Therefore, Shim6 re-homing could finally select a working
+   path in which packets are not filtered, if this path exists.  This
+   behavior results from the powerful end-to-end resilience properties
+   exhibited by the REAchability Protocol (REAP) [RFC5534].
+
+5.  Shim6 Capabilities
+
+5.1.  Fault Tolerance
+
+5.1.1.  Establishing Communications After an Outage
+
+   If a host within a multihomed site attempts to establish a
+   communication with a remote host and selects a locator that
+   corresponds to a failed transit path, bidirectional communication
+   between the two hosts will not succeed.  In order to establish a new
+   communication, the initiating host must try different combinations of
+   (source, destination) locator pairs until it finds a pair that works.
+   The mechanism for this default address selection is described in
+   [RFC3484].  As a result of the use of this mechanism, some failures
+   may not be recovered, even if a valid alternative path exists between
+   two communicating hosts.  For example, assuming a failure in ISP[1]
+   (see Figure 1), and host H initiating a communication with host R,
+   the source address selection algorithm described in [RFC3484] may
+   result in the selection of the source address corresponding to ISP[1]
+   for every destination address being tried by the application.
+   However, note that if R is the node initiating the communication, it
+   will find a valid path provided that the application at R tries every
+   available address for H.
+
+   Since a Shim6 context is normally established between two hosts only
+   after initial communication has been set up, there is no opportunity
+   for Shim6 to participate in the discovery of a suitable, initial
+   (source, destination) locator pair.  The same consideration holds for
+   referrals, as described in Section 6.
+
+
+
+Abley, et al.                 Informational                    [Page 10]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+5.1.2.  Short-Lived and Long-Lived Communications
+
+   The Shim6 context establishment operation requires a 4-way packet
+   exchange, and involves some overhead on the participating hosts in
+   memory and CPU.
+
+   For short-lived communications between two hosts, the benefit of
+   establishing a Shim6 context might not exceed the cost, perhaps
+   because the protocols concerned are fault tolerant and can arrange
+   their own recovery (e.g., DNS) or because the frequency of re-homing
+   events is sufficiently low that the probability of such a failure
+   occurring during a short-lived exchange is not considered
+   significant.
+
+   It is anticipated that the exchange of Shim6 context will provide the
+   most benefit for exchanges between hosts that are long-lived.  For
+   this reason, the default behavior of Shim6-capable hosts is expected
+   to employ deferred context-establishment.  Deferred context setup
+   ensures that session-establishment time will not be increased by the
+   use of Shim6.  This default behavior can be overridden by
+   applications that prefer immediate context establishment, regardless
+   of transaction longevity, by using [RFC6316].
+
+   Note that all the above considerations refer to the lifetime of the
+   interaction between the peers, and not the lifetime of a particular
+   connection (e.g., TCP connection).  In other words, the Shim6 context
+   is established between ULID pairs and it affects all the
+   communication between these ULIDs.  So, two nodes with multiple
+   short-lived communications using the same ULID pair would benefit as
+   much from the Shim6 features as two nodes having a single long-lived
+   communication.  One example of such a scenario would be a web-client
+   software downloading web content from a server over multiple TCP
+   connections.  Each TCP connection is short-lived, but the
+   communication/contact between the two ULID could be long-lived.
+
+5.2.  Load Balancing
+
+   The Shim6 protocol does not support load balancing within a single
+   context: all packets associated with a particular context are
+   exchanged using a single locator pair per direction, with the
+   exception of forked contexts, which are created upon explicit
+   requests from the upper-layer protocol.
+
+   It may be possible to extend the Shim6 protocol to use multiple
+   locator pairs in a single context, but the impact of such an
+   extension on upper-layer protocols (e.g., on TCP congestion control)
+   should be considered carefully.
+
+
+
+
+Abley, et al.                 Informational                    [Page 11]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   When many contexts are considered together in aggregation, e.g., on a
+   single host that participates in many simultaneous contexts or in a
+   site full of hosts, some degree of load sharing should occur
+   naturally due to the selection of different locator pairs in each
+   context.  However, there is no mechanism defined to ensure that this
+   natural load sharing is arranged to provide a statistical balance
+   between transit providers.
+
+   Note that the use of transport-layer solutions enhanced with
+   mechanisms to allow the use of multiple paths for a transport session
+   are more amenable for achieving load-balancing.  One such solution is
+   MPTCP [RFC6182].
+
+5.3.  Traffic Engineering
+
+   For sites with prefixes obtained from different providers, the paths
+   followed by inbound and outbound traffic are determined to a large
+   extent by the locators selected for each communication.  This is not
+   a particular issue of Shim6, but it is common to any deployment in
+   which hosts are configured with addresses received from different
+   providers.  Traffic engineering in such sites will likely involve
+   proper configuration of the address selection policies defined by
+   [RFC3484].
+
+   The Shim6 protocol provides some lightweight traffic engineering
+   capabilities in the form of the Locator Preferences option, which
+   allows a host to inform a remote host of local preferences for
+   locator selection.  In this way, the host can influence the incoming
+   path for the communication.  This mechanism is only available after a
+   Shim6 context has been established, and it is a host-based capability
+   rather than a site-based capability.  There is no defined mechanism
+   that would allow use of the Locator Preferences option amongst a site
+   full of hosts to be managed centrally by the administrator of the
+   site.
+
+6.  Application Considerations
+
+   Shim6 provides multihoming support without forcing changes in the
+   applications running on the host.  The fact that an address has been
+   generated according to the CGA or HBA specification does not require
+   any specific action from the application, e.g., it can obtain remote
+   CGA or HBA addresses as a result of a getaddrinfo() call to trigger a
+   DNS Request.  The storage of CGA or HBA addresses in DNS does not
+   require any modification to this protocol, since they are recorded
+   using AAAA records.  Moreover, neither the ULID/locator management
+   [RFC5533] nor the failure detection and recovery [RFC5534] functions
+   require application awareness.
+
+
+
+
+Abley, et al.                 Informational                    [Page 12]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   However, a specific API [RFC6316] has been developed for those
+   applications that might require additional capabilities in ULID/
+   locator management, such as the locator pair in use for a given
+   context, or the set of local or remote locators available for it.
+   This API can also be used to disable Shim6 operation when required.
+
+   It is worth noting that callbacks can benefit naturally from Shim6
+   support.  In a callback, an application in B retrieves IP_A, the IP
+   address of a peer A, and B uses IP_A to establish a new communication
+   with A.  As long as the address exchanged, IP_A, is the ULID for the
+   initial communication between A and B, and B uses the same address as
+   in the initial communication, and this initial communication is alive
+   (or the context has not been deleted), the new communication could
+   use the locators exchanged by Shim6 for the first communication.  In
+   this case, communication could proceed even if the ULID of A is not
+   reachable.
+
+   However, Shim6 does not provide specific protection to current
+   applications when they use referrals.  A referral is the exchange of
+   the IP address IP_A of a party A by party B to party C, so that party
+   C could use IP_A to communicate with party A.  In a normal case, the
+   ULID IP_A would be the only information sent by B to C as a referral.
+   But if IP_A is no longer valid as the locator in A, C could have
+   trouble establishing a communication with A.  Increased failure
+   protection for referrals could be obtained if B exchanged the whole
+   list of alternative locators of A; although, in this case the
+   application protocol should be modified.  Note that B could send to C
+   the current locator of A, instead of the ULID of A, as a way of using
+   the most recent reachability information about A.  While in this case
+   no modification of the application protocol is required, some
+   concerns arise: host A may not accept one of its locators as ULID for
+   initiating a communication, and if a CGA are used, the locator may
+   not be a CGA so a Shim6 context among A and C could not be created.
+
+7.  Interaction with Other Protocols and Mechanisms
+
+   In this section we discuss the interaction between Shim6 and other
+   protocols and mechanisms.  Before starting the discussion, it is
+   worth noting that at the time of this writing, there is a lack of
+   experience with the combination of Shim6 and these protocols and
+   mechanisms.  Therefore, the conclusions stated should be reviewed as
+   real experience is gained in the use of Shim6.
+
+7.1.  Shim6 and Mobile IPv6
+
+   Here, we consider some scenarios in which the Shim6 protocol and the
+   Mobile IPv6 (MIPv6) protocol [RFC6275] might be used simultaneously.
+
+
+
+
+Abley, et al.                 Informational                    [Page 13]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+7.1.1.  Multihomed Home Network
+
+   In this case, the Home Network of the Mobile Node (MN) is multihomed.
+   This implies the availability of multiple Home Network prefixes,
+   resulting in multiple Home Addresses (HoAs) for each MN.  Since the
+   MN is a node within a multihomed site, it seems reasonable to expect
+   that the MN should be able to benefit from the multihoming
+   capabilities provided by the Shim6 protocol.  Moreover, the MN needs
+   to be able to obtain the multihoming benefits, even when it is
+   roaming away from the Home Network: if the MN is away from the Home
+   Network while the Home Network suffers a failure in a transit path,
+   the MN should be able to continue communicating using alternate paths
+   to reach the Home Network.
+
+   The resulting scenario is the following:
+
+       +------------------------------------+
+       |               Internet             |
+       +------------------------------------+
+          |                   |
+        +----+              +----+
+        |ISP1|              |ISP2|
+        +----+              +----+
+          |                   |
+       +------------------------------------+
+       |   Multihomed Home Network          |
+       |   Prefixes: P1 and P2              |
+       |                                    |
+       |                   Home Agent       |
+       |                   //               |
+       +------------------//----------------+
+                         //
+                        //
+                      +-----+
+                      | MN  | HoA1, HoA2
+                      +-----+
+
+                      Figure 2
+
+   So, in this configuration, the Shim6 protocol is used to provide
+   multiple communication paths to all the nodes within the multihomed
+   sites (including the mobile nodes), and the MIPv6 protocol is used to
+   support mobility of the multihomed site's mobile nodes.
+
+
+
+
+
+
+
+
+Abley, et al.                 Informational                    [Page 14]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   The proposed protocol architecture would be the following:
+
+      +--------------+
+      |  Application |
+      +--------------+
+      |  Transport   |
+      +--------------+
+      |      IP      |
+      | +----------+ |
+      | |  IPSec   | |
+      | +----------+<--ULIDs
+      | | Shim6    | |
+      | +----------+<--HoAs
+      | | MIPv6    | |
+      | +----------+<--CoAs
+      |              |
+      +--------------+
+          Figure 3
+
+   In this architecture, the upper-layer protocols and IPSec would use
+   ULIDs of the Shim6 protocol (see Section 16.1 in [RFC5533] for more
+   detail on the interaction between Shim6 and IPsec).  Only the HoAs
+   will be presented by the upper layers to the Shim6 layer as potential
+   ULIDs.  Two Shim6 entities will exchange their own available HoAs as
+   locators.  Therefore, Shim6 provides failover between different HoAs
+   and allows preservation of established communications when an outage
+   affects the path through the ISP that has delegated the HoA used for
+   initiating the communication (similar to the case of a host within a
+   multihomed site).  The Care-of Addresses (CoAs) are not presented to
+   the Shim6 layer and are not included in the local locator set in this
+   case.  The CoAs are managed by the MIPv6 layer, which binds each HoA
+   to a CoA.  For example, if a single CoA, CoA1, is available for the
+   MN in the foreign link to which it is attached, every HoA should have
+   a bind to CoA1.
+
+   So, in this case, the upper-layer protocols select a ULID pair for
+   the communication.  The Shim6 protocol translates the ULID pair to an
+   alternative locator in case that is needed.  Both the ULIDs and the
+   alternative locators are HoAs.  Next, the MIPv6 layer maps the
+   selected HoA to the corresponding CoA, which is the actual address
+   included in the wire.
+
+   The Shim6 context is established between the MN and the Correspondent
+   Node (CN), and it would allow the communication to use all the
+   available HoAs to provide fault tolerance.  The MIPv6 protocol is
+   used between the MN and the Home Agent (HA) in the case of the
+   bidirectional tunnel mode, and between the MN and the CN in case of
+   the Route Optimization (RO) mode.
+
+
+
+Abley, et al.                 Informational                    [Page 15]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+7.1.2.  Shim6 between the HA and the MN
+
+   Another scenario where a Shim6-MIPv6 interaction may be useful is the
+   case where a Shim6 context is established between the MN and the HA
+   in order to provide fault tolerance capabilities to the bidirectional
+   tunnel between them.
+
+   Consider the case where the HA has multiple addresses (whether
+   because the Home Network is multihomed or because the HA has multiple
+   interfaces) and/or the MN has multiple addresses (whether because the
+   visited network is multihomed or because the MN has multiple
+   interfaces).  In this case, if a failure affects the address pair
+   that is being used to run the tunnel between the MN and HA,
+   additional mechanisms need to be used to preserve the communication.
+
+   One possibility would be to use MIPv6 capabilities, by simply
+   changing the CoA used as the tunnel endpoint.  However, MIPv6 lacks
+   the failure detection mechanisms that would allow the MN and/or the
+   HA to detect the failure and trigger the usage of an alternative
+   address.  Shim6 provides such a failure detection protocol, so one
+   possibility would be re-using the failure detection function from the
+   Shim6 failure detection protocol in MIPv6.  In this case, the Shim6
+   protocol wouldn't be used to create Shim6 context and provide fault
+   tolerance, but just its failure detection functionality would be
+   re-used.
+
+   The other possibility would be to use the Shim6 protocol to create a
+   Shim6 context between the HA and the MN, so that the Shim6 detects
+   any failure and re-homes the communication in a transparent fashion
+   to MIPv6.  In this case, the Shim6 protocol would be associated with
+   the tunnel interface.
+
+7.2.  Shim6 and SEND
+
+   Secure Neighbor Discovery (SEND) [RFC3971] uses CGAs to prove address
+   ownership for Neighbor Discovery [RFC4861].  The Shim6 protocol can
+   use either CGAs or HBAs to protect locator sets included in Shim6
+   contexts.  It is expected that some hosts will need to participate in
+   both SEND and Shim6 simultaneously.
+
+   In the case that both the SEND and Shim6 protocols are using the CGA
+   technique to generate addresses, there is no conflict; the host will
+   generate addresses for both purposes as CGAs, and since it will be in
+   control of the associated private key, the same CGA can be used for
+   the different protocols.
+
+
+
+
+
+
+Abley, et al.                 Informational                    [Page 16]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   In the case that a Shim6-capable host is using HBAs to protect its
+   locator sets, the host will need to generate an address that is both
+   a valid CGA and a valid HBA, as defined in [RFC5535].  In this case,
+   the CGA Parameter Data Structure containing a valid public key and
+   the Multi-Prefix extension are included as inputs to the hash
+   function.
+
+7.3.  Shim6, SCTP, and MPTCP
+
+   Both the SCTP [RFC4960] and MPTCP [RFC6182] protocols provide a
+   reliable, stream-based communications channel between two hosts that
+   provides a superset of the capabilities of TCP.  One notable feature
+   of these two protocols is that they allow the exchange of endpoint
+   addresses between hosts in order to recover from the failure of a
+   particular endpoint pair, or to benefit from multipath communication
+   in the MPTCP case, in a manner that is conceptually similar to
+   locator selection in Shim6.
+
+   SCTP and MPTCP are transport-layer protocols, higher in the protocol
+   stack than Shim6; hence, there is no fundamental incompatibility that
+   would prevent a Shim6-capable host from communicating using SCTP or
+   MPTCP.
+
+   However, since either SCTP or MPTCP, and Shim6 aim to exchange
+   addressing information between hosts in order to meet the same
+   generic goal, it is possible that their simultaneous use might result
+   in unexpected behavior, e.g., lead to race conditions.
+
+   The capabilities of these transport protocols with respect to path
+   maintenance of a reliable, connection-oriented stream protocol are
+   more extensive than the more general layer-3 locator agility provided
+   by Shim6.  Therefore, it is recommended that Shim6 not be used for
+   SCTP or MPTCP sessions, and that path maintenance be provided solely
+   by SCTP or MPTCP.  There are at least two ways to enforce this
+   behavior.  One option is to make the stack, and in particular the
+   Shim6 sublayer, aware of the use of SCTP or MPTCP, and in this case
+   refrain from creating a Shim6 context.  The other option is that the
+   upper transport layer indicates, using a Shim6-capable API like the
+   one proposed in [RFC6316], that no Shim6 context must be created for
+   this particular communication.
+
+   In general, the issues described here may also arise for protocols
+   that handle different addresses for two communicating nodes at a
+   higher level than the network layer to improve reliability,
+   performance, congestion control, etc.
+
+
+
+
+
+
+Abley, et al.                 Informational                    [Page 17]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+7.4.  Shim6 and NEMO
+
+   The Network Mobility (NEMO) [RFC3963] protocol extensions to MIPv6
+   allow a Mobile Network to communicate through a bidirectional tunnel
+   via a Mobile Router (MR) to a NEMO-compliant HA located in a Home
+   Network.
+
+   If either or both the MR or HA are multihomed, then an established
+   Shim6 context preserves the integrity of the bidirectional tunnel
+   between them in the event that a transit failure occurs in the
+   connecting path.
+
+   Once the tunnel between MR and HA is established, hosts within the
+   Mobile Network that are Shim6-capable can establish contexts with
+   remote hosts in order to receive the same multihoming benefits as any
+   host located within the Home Network.
+
+7.5.  Shim6 and HIP
+
+   Shim6 and HIP [RFC4423] are architecturally similar in the sense that
+   both solutions allow two hosts to use different locators to support
+   communications between stable ULIDs.  The signaling exchange to
+   establish the demultiplexing context on the hosts is very similar for
+   both protocols.  However, there are a few key differences.  First,
+   Shim6 avoids defining a new namespace for ULIDs, preferring instead
+   to use a routable locator as a ULID, while HIP uses public keys and
+   hashes thereof as ULIDs.  The use of a routable locator as the ULID
+   better supports deferred context establishment, application
+   callbacks, and application referrals, and avoids management and
+   resolution costs of a new namespace, but requires additional security
+   mechanisms to securely bind the ULID with the locators.  Second,
+   Shim6 uses an explicit context header on data packets for which the
+   ULIDs differ from the locators in use (this header is only needed
+   after a failure/re-homing event occurs), while HIP may compress this
+   context-tag function into the Encapsulating Security Payload (ESP)
+   Security Parameter Index (SPI) field [RFC5201].  Third, HIP as
+   presently defined requires the use of public-key operations in its
+   signaling exchange and ESP encryption in the data plane, while the
+   use of Shim6 requires neither (if only HBA addresses are used).  By
+   default, HIP provides data protection, while this is a non-goal for
+   Shim6.
+
+   Shim6 aimed to provide a solution to a specific problem, multihoming,
+   which minimizes deployment disruption, while HIP is considered more
+   of an experimental approach intended to solve several more general
+   problems (mobility, multihoming, and loss of end-to-end addressing
+   transparency) through an explicit identifier/locator split.
+
+
+
+
+Abley, et al.                 Informational                    [Page 18]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   Communicating hosts that are willing to run HIP (perhaps extended
+   with Shim6's failure detection protocol) likely have no reason to
+   also run Shim6.  In this sense, HIP may be viewed as a possible long-
+   term evolution or extension of the Shim6 architecture, or one
+   possible implementation of the Extended Shim6 Design (ESD)
+   [SHIM6-ESD].
+
+7.6.  Shim6 and Firewalls
+
+   The ability of Shim6 to divert the communication to different paths
+   may be affected by certain firewall configurations.  For example,
+   consider a deployment in which one of the peers of a Shim6 session is
+   protected by a firewall (i.e., all the paths to the locators of that
+   peer traverse the firewall).  The firewall implements the Simple
+   Security model [RFC4864], in which incoming packets are checked
+   against a state resulting from outgoing traffic, either associated
+   with the locator of the internal node ('endpoint independent
+   filtering') or to both the locators of the internal and external
+   nodes ('address dependent filtering' or 'address and port dependent
+   filtering').  If the external node changes the locator associated
+   with the internal node, the packet will be discarded by the firewall.
+   In addition, if the firewall implements 'address dependent filtering'
+   or 'address and port dependent filtering', any change by the external
+   node in the locator used to identify itself will also result in the
+   packet being discarded by the firewall.
+
+   This issue could be mitigated by making the firewalls aware of the
+   different locators that could be associated with a given
+   communication.  If the firewall is implemented in the communication
+   node itself, the firewall could inspect the Shim6 control packet
+   exchange to obtain this information, or the Shim6 software module
+   could explicitly inform the firewall software module.  For firewalls
+   located outside the node, the Shim6 control packet exchange can be
+   used to associate the alternate locators to the communication state,
+   although it may not work for topologies in which both directions for
+   the communication do not traverse the firewall, or in which the
+   firewall is not traversed after a locator change.  The detail of any
+   of such mechanisms is out of the scope of this document.
+
+   However, note that a failure in using the alternative locators does
+   not impact the communication between the nodes as long as the path
+   between them defined by the initial locator pair remains available.
+   In this case, data packets flow between the communicating nodes as
+   for any non-Shim6 communication.
+
+
+
+
+
+
+
+Abley, et al.                 Informational                    [Page 19]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+7.7.  Shim6 and NPTv6
+
+   Address translation techniques such as Network Prefix Translation
+   (NPTv6) [RFC6296] may be used until workable solutions to avoid
+   renumbering or facilitate multihoming are developed [RFC5902].  We
+   now consider the impact of NPTv6 in Shim6 operation.  Some of the
+   considerations stated in this section may also be applicable to other
+   types of IPv6 NAT.
+
+   The main purpose of Shim6 is to provide locator agility below
+   transport protocols.  To prevent the risk of redirection attacks by
+   abusing the locator exchange facilities provided by Shim6, the
+   protocol is built upon the cryptographic properties of CGA and HBA
+   addresses.  When the CGA address of a node is used as the local ULID,
+   the locators configured in the node can be signed with the private
+   key associated with the CGA.  A peer receiving a Shim6 message
+   performs a hash of the CGA Parameter Data Structure information
+   received, including a public key, to assure that this key is bound to
+   the CGA address, and then checks the signature protecting the
+   locators.  When an HBA address of a node is used as the local ULID,
+   the HBA address securely chains the ULID and other locators of the
+   node by means of a hash.  For both the CGA and the HBA, the locators
+   can be exchanged at the four-way handshake used to establish the
+   Shim6 context, or once the context has been established by means of
+   an Update Request message.
+
+   When a node behind an NPTv6 communicates, the NAT device translates
+   the address assigned to this internal node to an address of its
+   address pool.  This operation results in a mismatch between the
+   address seen by external hosts and the address configured in the
+   internal node, which is the locator that would be conveyed in a Shim6
+   locator exchange and is also the address for which the security
+   defined in the CGA and HBA specifications are provided.  Then, the
+   validation processes performed by an external node may prevent the
+   creation of the Shim6 context, or may allow the context to be created
+   but render the alternative locator of the internal host unusable.
+
+   However, note that the failure in creating a Shim6 context, or in
+   using the alternative locators, does not impact the communication
+   between the nodes as long as the path between them defined by the
+   initial locator pair remains available.  Data packets flow between
+   the communicating nodes as for any non-Shim6 communication.  Not
+   creating the Shim6 context, or not being able to convey the local
+   locators to the peer node, affect the added value provided by Shim6,
+   i.e., the ability to preserve the communication in case any of the
+   locators fail.  Therefore, using Shim6 with NPTv6 does not provide
+   less functionality than using IPv6 in the same scenario.
+
+
+
+
+Abley, et al.                 Informational                    [Page 20]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   We now illustrate some cases that may occur when combining Shim6 and
+   NPTv6.  The following discussion does not aim to be exhaustive in the
+   cases that may arise, but just aims to provide some examples of
+   possible situations.  We assume a scenario in which host A is located
+   behind a NPTv6 device for its locator IP_A1, but it is connected to
+   the public IPv6 Internet for its locator IP_A2.  Once translated,
+   locator IP_A1 appears to external nodes as IP_T.  Node A communicates
+   with node B, with public addresses IP_B1 and IP_B2.
+
+                   +-----+
+                   |  A  |
+                   +-----+
+              IP_A1 |  | IP_A2
+                    |  |
+                    |  +-----+
+                    |        |
+                +--------+   |
+                | NPTv6  |   |
+                +--------+   |
+               IP_T |        |
+                    |        |
+           +--------------------------+
+           |         Internet         |
+           +--------------------------+
+                     |  |
+               IP_B1 |  | IP_B2
+                   +-----+
+                   |  B  |
+                   +-----+
+
+                   Figure 4
+
+   We first discuss some issues related with the four-way handshake used
+   to establish the Shim6 context.  When the locator information is
+   included in the Shim6 exchange, either in the I2 or R2 messages, the
+   receiver is required to validate the ULID of the peer node by
+   performing the CGA or HBA address validation procedure.  In case the
+   validation fails, the message containing the information is silently
+   discarded.  In the scenario depicted in Figure 4, some of the cases
+   that may occur are:
+
+   o  Node A initiates the exchange, with IP_B1 as the destination
+      address and IP_A1 as the source address, which is a CGA.  Node A
+      includes IP_A2 as an alternative locator in the I2 message.  Node
+      B sees IP_T as the ULID for A, so when it validates the CGA with
+      the information contained in I2, the validation fails because the
+      CGA Parameter Data Structure contains information bound to IP_A1.
+      Therefore, B silently discards the received I2 message.  Without
+
+
+
+Abley, et al.                 Informational                    [Page 21]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+      receiving a valid I2 message, B does not create the Shim6 context.
+      Without receiving the R2 message, A also does not create the Shim6
+      context.  However, data communication can proceed as long as the
+      path between IP_A1 and IP_B1 is valid.  A similar case occurs if
+      IP_A1 and IP_A2 form an HBA, instead of using CGAs for securing
+      the communication.
+
+   o  Node A initiates the exchange with IP_B1 as the destination
+      address and IP_A2 (its public address) as the source address,
+      which is a CGA.  Node A includes IP_A1 as an alternative locator
+      in the I2 message.  In this case, B can successfully validate
+      IP_A2 as a CGA.  Regarding the validation of IP_A1 as an
+      alternative locator for A, the Shim6 specification [RFC5533]
+      indicates that it should perform this check when the I2 message is
+      received, but it may perform it later on, provided that the check
+      is performed before using it as a locator.  In case the validation
+      is performed when I2 is received, the I2 message would be silently
+      discarded, with the same result as for the previous case.  In case
+      the validation is performed later, the Shim6 context would be
+      established in both nodes A and B, but B could not send to IP_A1,
+      and packets sent by A from IP_A1 will not be received by B.  Note
+      that in this case both IP_B1 and IP_B2 could be used by A and B,
+      as long as the locator for A is IP_A2, so limited locator agility
+      may be achieved.
+
+   o  Node B initiates the exchange with IP_B1 as the source address,
+      and IP_A2 as the destination address, which is a CGA.  This case
+      is similar to the previous one, although it is the R2 message sent
+      by A that cannot be validated.  While A can create a context with
+      B, B cannot do the same for A.  Data communication using IP_B1 and
+      IP_A2 can proceed.  However, A may try to use IP_B2 as an
+      alternative locator, but the data packets sent carrying the Shim6
+      Extension Header will not be associated by B to any established
+      context, so they will be discarded.  The same occurs for packets
+      sent by A with IP_A1 as the source address.
+
+   We can also consider the case in which node A does not exchange its
+   own locators in the Shim6 establishment exchange.  For example, a
+   Shim6 context can be established between CGA IP_A2 and IP_B1.  B can
+   convey locator IP_B2 in the four-way handshake, and validation will
+   be correctly done by A.  Later on, A may send an Update Request
+   message to inform B about its locator IP_A1.  Validation for this
+   message will fail in B, and B will send a Shim6 Error message to A.
+   Neither A nor B will use IP_A1 as a locator.  However, IP_A2, IP_B1,
+   and IP_B2 can still be used as valid locators for the communication.
+
+
+
+
+
+
+Abley, et al.                 Informational                    [Page 22]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   Finally, note that modification of the Shim6 control packets by the
+   NPTv6 would not be able to generate a valid signature when a CGA is
+   being used or a Parameter Data Structure binding the translated
+   locator to the other locators of a node when an HBA is being used.
+   Therefore, the same failure cases described before would remain.
+
+8.  Security Considerations
+
+   This section considers the applicability of the Shim6 protocol from a
+   security perspective, i.e., which security features can be expected
+   by applications and users of the Shim6 protocol.
+
+   First of all, it should be noted that the Shim6 protocol is not a
+   security protocol, unlike HIP, for instance.  This means that, as
+   opposed to HIP, it is an explicit non-goal of the Shim6 protocol to
+   provide enhanced security for the communications that use the Shim6
+   protocol.  The goal of the Shim6 protocol design, in terms of
+   security, is not to introduce new vulnerabilities that were not
+   present in the current non-Shim6 enabled communications.  In
+   particular, it is an explicit non-goal of Shim6 protocol security to
+   provide protection from on-path attackers.  On-path attackers are
+   able to sniff and spoof packets in the current Internet, and they are
+   able to do the same in Shim6 communications (as long as the
+   communication flows through the path on which they are located).
+   Summarizing, the Shim6 protocol does not provide data packet
+   protection from on-path attackers.
+
+   However, the Shim6 protocol does use several security techniques.
+   The goal of these security measures is to protect the Shim6 signaling
+   protocol from new attacks resulting from the adoption of the Shim6
+   protocol.  In particular, the use of HBA/CGA prevents on-path and
+   off-path attackers from injecting new locators into the locator set
+   of a Shim6 context, thus preventing redirection attacks [RFC4218].
+   Moreover, the usage of probes before re-homing to a different locator
+   as a destination address prevents flooding attacks from off-path
+   attackers.  Note that for nodes using CGA addresses, security depends
+   on the secure handling of the private key associated with the
+   signature and validation of locators.  In particular, any address
+   configuration method must assure that the private key remains secret,
+   as discussed in Section 3.3.
+
+   In addition, the usage of a 4-way handshake for establishing the
+   Shim6 context protects against DoS attacks, so hosts implementing the
+   Shim6 protocol should not be more vulnerable to DoS attacks than
+   regular IPv6 hosts.
+
+   Finally, many Shim6 signaling messages contain a Context Tag, meaning
+   that only attackers that know the Context Tag can forge them.  As a
+
+
+
+Abley, et al.                 Informational                    [Page 23]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   consequence, only on-path attackers can generate false Shim6
+   signaling packets for an established context.  The impact of these
+   attacks would be limited since they would not be able to add
+   additional locators to the locator set (because of the HBA/CGA
+   protection).  In general, the possible attacks have similar effects
+   to the ones that an on-path attacker can launch on any regular IPv6
+   communication.  The residual threats are described in the Security
+   Considerations of the Shim6 protocol specification [RFC5533].
+
+8.1.  Privacy Considerations
+
+   The Shim6 protocol is designed to provide some basic privacy
+   features.  In particular, HBAs are generated in such a way that the
+   different addresses assigned to a host cannot be trivially linked
+   together as belonging to the same host, since there is nothing in
+   common in the addresses themselves.  Similar features are provided
+   when the CGA protection is used.  This means that it is not trivial
+   to determine that a set of addresses is assigned to a single Shim6
+   host.
+
+   However, the Shim6 protocol does exchange the locator set in clear
+   text, and it also uses a fixed Context Tag when using different
+   locators in a given context.  This implies that an attacker observing
+   the Shim6 context establishment exchange or seeing different payload
+   packets exchanged through different locators, but with the same
+   Context Tag, can determine the set of addresses assigned to a host.
+   However, this requires that the attacker be located along the path
+   and can capture the Shim6 signaling packets.
+
+9.  Contributors
+
+   The analysis on the interaction between the Shim6 protocol and the
+   other protocols presented in this note benefited from the advice of
+   various people including Tom Henderson, Erik Nordmark, Hesham
+   Soliman, Vijay Devarpalli, John Loughney, and Dave Thaler.
+
+10.  Acknowledgements
+
+   Joe Abley's work was supported, in part, by the US National Science
+   Foundation (research grant SCI-0427144) and DNS-OARC.
+
+   Marcelo Bagnulo worked on this document while visiting Ericsson
+   Research Laboratory Nomadiclab.
+
+   Alberto Garcia-Martinez was supported, in part, by the eeCONTET
+   project (TEC2011-29688-C02-02, granted by the Spanish Science and
+   Innovation Ministry).
+
+
+
+
+Abley, et al.                 Informational                    [Page 24]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   Shinta Sugimoto reviewed this document and provided comments and
+   text.
+
+   Brian Carpenter, Jari Arkko, Joel Halpern, Iljitsch van Beijnum, Sam
+   Xia, Carsten Bormann, Dan Wing, Stephen Farrell, and Stewart Bryant
+   reviewed this document and provided comments.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2827]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
+                Defeating Denial of Service Attacks which employ IP
+                Source Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+   [RFC3315]    Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+                C., and M. Carney, "Dynamic Host Configuration Protocol
+                for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3484]    Draves, R., "Default Address Selection for Internet
+                Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [RFC3963]    Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
+                Thubert, "Network Mobility (NEMO) Basic Support
+                Protocol", RFC 3963, January 2005.
+
+   [RFC3971]    Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+                "SEcure Neighbor Discovery (SEND)", RFC 3971, March
+                2005.
+
+   [RFC3972]    Aura, T., "Cryptographically Generated Addresses (CGA)",
+                RFC 3972, March 2005.
+
+   [RFC4291]    Hinden, R. and S. Deering, "IP Version 6 Addressing
+                Architecture", RFC 4291, February 2006.
+
+   [RFC4423]    Moskowitz, R. and P. Nikander, "Host Identity Protocol
+                (HIP) Architecture", RFC 4423, May 2006.
+
+   [RFC4861]    Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+                "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+                September 2007.
+
+   [RFC4862]    Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+                Address Autoconfiguration", RFC 4862, September 2007.
+
+   [RFC4960]    Stewart, R., Ed., "Stream Control Transmission
+                Protocol", RFC 4960, September 2007.
+
+
+
+Abley, et al.                 Informational                    [Page 25]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   [RFC5201]    Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
+                Henderson, "Host Identity Protocol", RFC 5201, April
+                2008.
+
+   [RFC5533]    Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
+                Shim Protocol for IPv6", RFC 5533, June 2009.
+
+   [RFC5534]    Arkko, J. and I. van Beijnum, "Failure Detection and
+                Locator Pair Exploration Protocol for IPv6 Multihoming",
+                RFC 5534, June 2009.
+
+   [RFC5535]    Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
+                June 2009.
+
+   [RFC6146]    Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+                NAT64: Network Address and Protocol Translation from
+                IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
+
+   [RFC6182]    Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
+                Iyengar, "Architectural Guidelines for Multipath TCP
+                Development", RFC 6182, March 2011.
+
+   [RFC6275]    Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
+                Support in IPv6", RFC 6275, July 2011.
+
+   [RFC6316]    Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Ed.,
+                "Sockets Application Program Interface (API) for
+                Multihoming Shim", RFC 6316, July 2011.
+
+11.2.  Informative References
+
+   [6MAN]       Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
+                "Distributing Address Selection Policy using DHCPv6",
+                Work in Progress, February 2012.
+
+   [DHCPv6-CGA] Jiang, S. and S. Shen, "Analysis of Possible DHCPv6 and
+                CGA Interactions", Work in Progress, March 2012.
+
+   [IPv6NAT]    Matsushima, S., Okimoto, T., Troan, O., Miles, D., and
+                D.  Wing, "IPv6 Multihoming without Network Address
+                Translation", Work in Progress, February 2012.
+
+   [RFC3221]    Huston, G., "Commentary on Inter-Domain Routing in the
+                Internet", RFC 3221, December 2001.
+
+   [RFC3582]    Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
+                Multihoming Architectures", RFC 3582, August 2003.
+
+
+
+
+Abley, et al.                 Informational                    [Page 26]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+   [RFC4116]    Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
+                Gill, "IPv4 Multihoming Practices and Limitations", RFC
+                4116, July 2005.
+
+   [RFC4191]    Draves, R. and D. Thaler, "Default Router Preferences
+                and More-Specific Routes", RFC 4191, November 2005.
+
+   [RFC4218]    Nordmark, E. and T. Li, "Threats Relating to IPv6
+                Multihoming Solutions", RFC 4218, October 2005.
+
+   [RFC4864]    Van de Velde, G., Hain, T., Droms, R., Carpenter, B.,
+                and E. Klein, "Local Network Protection for IPv6", RFC
+                4864, May 2007.
+
+   [RFC4984]    Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed.,
+                "Report from the IAB Workshop on Routing and
+                Addressing", RFC 4984, September 2007.
+
+   [RFC5220]    Matsumoto, A., Fujisaki, T., Hiromi, R., and K.
+                Kanayama, "Problem Statement for Default Address
+                Selection in Multi-Prefix Environments: Operational
+                Issues of RFC 3484 Default Rules", RFC 5220, July 2008.
+
+   [RFC5902]    Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
+                IPv6 Network Address Translation", RFC 5902, July 2010.
+
+   [RFC6296]    Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
+                Translation", RFC 6296, June 2011.
+
+   [RFC6418]    Blanchet, M. and P. Seite, "Multiple Interfaces and
+                Provisioning Domains Problem Statement", RFC 6418,
+                November 2011.
+
+   [SHIM6-ESD]  Nordmark, E., "Extended Shim6 Design for ID/loc split
+                and Traffic Engineering", Work in Progress, February
+                2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley, et al.                 Informational                    [Page 27]
+
+RFC 6629           Shim6 Applicability Considerations          June 2012
+
+
+Authors' Addresses
+
+   Joe Abley
+   ICANN
+   12025 Waterfront Drive
+   Suite 300
+   Los Angeles, CA 90094
+   USA
+
+   Phone: +1 519 670 9327
+   EMail: joe.abley@icann.org
+
+
+   Marcelo Bagnulo
+   U. Carlos III de Madrid
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   Spain
+
+   Phone: +34 91 6248814
+   EMail: marcelo@it.uc3m.es
+   URI:   http://www.it.uc3m.es/
+
+
+   Alberto Garcia-Martinez
+   U. Carlos III de Madrid
+   Av. Universidad 30
+   Leganes, Madrid  28911
+   Spain
+
+   Phone: +34 91 6248782
+   EMail: alberto@it.uc3m.es
+   URI:   http://www.it.uc3m.es/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abley, et al.                 Informational                    [Page 28]
+