GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6629

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6629.txt · Last modified: 2012/06/11 22:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki