doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc8047.txt b/doc/rfc/rfc8047.txt
new file mode 100644
index 0000000..cbe0b73
--- /dev/null
+++ b/doc/rfc/rfc8047.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                 T. Henderson, Ed.
+Request for Comments: 8047                      University of Washington
+Category: Standards Track                                        C. Vogt
+ISSN: 2070-1721                                              Independent
+                                                                J. Arkko
+                                                                Ericsson
+                                                           February 2017
+
+
+            Host Multihoming with the Host Identity Protocol
+
+Abstract
+
+   This document defines host multihoming extensions to the Host
+   Identity Protocol (HIP), by leveraging protocol components defined
+   for host mobility.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   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/rfc8047.
+
+Copyright Notice
+
+   Copyright (c) 2017 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.
+
+
+
+
+
+
+Henderson, et al.            Standards Track                    [Page 1]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+Table of Contents
+
+   1.  Introduction and Scope  . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology and Conventions . . . . . . . . . . . . . . . . .   4
+   3.  Protocol Model  . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
+     4.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   5
+     4.2.  Usage Scenarios . . . . . . . . . . . . . . . . . . . . .   6
+       4.2.1.  Multiple Addresses  . . . . . . . . . . . . . . . . .   6
+       4.2.2.  Multiple Security Associations  . . . . . . . . . . .   6
+       4.2.3.  Host Multihoming for Fault Tolerance  . . . . . . . .   7
+       4.2.4.  Host Multihoming for Load Balancing . . . . . . . . .   9
+       4.2.5.  Site Multihoming  . . . . . . . . . . . . . . . . . .  10
+       4.2.6.  Dual-Host Multihoming . . . . . . . . . . . . . . . .  10
+       4.2.7.  Combined Mobility and Multihoming . . . . . . . . . .  11
+       4.2.8.  Initiating the Protocol in R1, I2, or R2  . . . . . .  11
+       4.2.9.  Using LOCATOR_SETs across Addressing Realms . . . . .  13
+     4.3.  Interaction with Security Associations  . . . . . . . . .  13
+   5.  Processing Rules  . . . . . . . . . . . . . . . . . . . . . .  14
+     5.1.  Sending LOCATOR_SETs  . . . . . . . . . . . . . . . . . .  14
+     5.2.  Handling Received LOCATOR_SETs  . . . . . . . . . . . . .  16
+     5.3.  Verifying Address Reachability  . . . . . . . . . . . . .  18
+     5.4.  Changing the Preferred Locator  . . . . . . . . . . . . .  18
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  21
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  21
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  22
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Henderson, et al.            Standards Track                    [Page 2]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+1.  Introduction and Scope
+
+   The Host Identity Protocol (HIP) [RFC7401] supports an architecture
+   that decouples the transport layer (TCP, UDP, etc.) from the
+   internetworking layer (IPv4 and IPv6) by using public/private key
+   pairs, instead of IP addresses, as host identities.  When a host uses
+   HIP, the overlying protocol sublayers (e.g., transport-layer sockets
+   and Encapsulating Security Payload (ESP) Security Associations (SAs))
+   are instead bound to representations of these host identities, and
+   the IP addresses are only used for packet forwarding.  However, each
+   host must also know at least one IP address at which its peers are
+   reachable.  Initially, these IP addresses are the ones used during
+   the HIP base exchange.
+
+   One consequence of such a decoupling is that new solutions to
+   network-layer mobility and host multihoming are possible.  Basic host
+   mobility is defined in [RFC8046] and covers the case in which a host
+   has a single address and changes its network point of attachment
+   while desiring to preserve the HIP-enabled security association.
+   Host multihoming is somewhat of a dual case to host mobility, in
+   that, a host may simultaneously have more than one network point of
+   attachment.  There are potentially many variations of host
+   multihoming possible.  [RFC8046] specifies the format of the HIP
+   parameter (LOCATOR_SET parameter) used to convey IP addressing
+   information between peers, the procedures for sending and processing
+   this parameter to enable basic host mobility, and procedures for an
+   address verification mechanism.  The scope of this document
+   encompasses messaging and elements of procedure for some basic host
+   multihoming scenarios of interest.
+
+   Another variation of multihoming that has been heavily studied is
+   site multihoming.  Solutions for host multihoming in multihomed IPv6
+   networks have been specified by the IETF shim6 working group.  The
+   Shim6 protocol [RFC5533] bears many architectural similarities to
+   HIP, but there are differences in the security model and in the
+   protocol.
+
+   While HIP can potentially be used with transports other than the ESP
+   transport format [RFC7402], this document largely assumes the use of
+   ESP and leaves other transport formats for further study.
+
+   Finally, making underlying IP multihoming transparent to the
+   transport layer has implications on the proper response of transport
+   congestion control, path MTU selection, and Quality of Service (QoS).
+   Transport-layer mobility triggers, and the proper transport response
+   to a HIP multihoming address change, are outside the scope of this
+   document.
+
+
+
+
+Henderson, et al.            Standards Track                    [Page 3]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   This specification relies on implementing Sections 4 ("LOCATOR_SET
+   Parameter Format") and 5 ("Processing Rules") of [RFC8046] as a
+   starting point for this implementation.
+
+2.  Terminology and Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+   The following terms used in this document are defined in [RFC8046]:
+   LOCATOR_SET, Locator, locator, Address, preferred locator, and
+   Credit-Based Authorization.
+
+3.  Protocol Model
+
+   The protocol model for HIP support of host multihoming extends the
+   model for host mobility described in Section 3 of [RFC8046].  This
+   section only highlights the differences.
+
+   In host multihoming, a host has multiple locators simultaneously
+   rather than sequentially, as in the case of mobility.  By using the
+   LOCATOR_SET parameter defined in [RFC8046], a host can inform its
+   peers of additional (multiple) locators at which it can be reached.
+   When multiple locators are available and announced to the peer, a
+   host can designate a particular locator as a "preferred" locator,
+   meaning that the host prefers that its peer send packets to the
+   designated address before trying an alternative address.  Although
+   this document defines a basic mechanism for multihoming, it does not
+   define all possible policies and procedures, such as which locators
+   to choose when more than one is available, the operation of
+   simultaneous mobility and multihoming, source address selection
+   policies (beyond those specified in [RFC6724]), and the implications
+   of multihoming on transport protocols.
+
+4.  Protocol Overview
+
+   In this section, we briefly introduce a number of usage scenarios for
+   HIP multihoming.  These scenarios assume that HIP is being used with
+   the ESP transport [RFC7402], although other scenarios may be defined
+   in the future.  To understand these usage scenarios, the reader
+   should be at least minimally familiar with the HIP protocol
+   specification [RFC7401], the use of the ESP transport format
+   [RFC7402], and the HIP mobility specification [RFC8046].  However,
+   for the (relatively) uninitiated reader, it is most important to keep
+   in mind that in HIP, the actual payload traffic is protected with
+   ESP, and that the ESP Security Parameter Index (SPI) acts as an index
+   to the right host-to-host context.
+
+
+
+Henderson, et al.            Standards Track                    [Page 4]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+4.1.  Background
+
+   The multihoming scenarios can be explained in contrast to the
+   non-multihoming case described in the base protocol specification
+   [RFC7401].  We review the pertinent details here.  In the base
+   specification, when used with the ESP transport format, the HIP base
+   exchange will set up a single SA in each direction.  The IP addresses
+   associated with the SAs are the same as those used to convey the HIP
+   packets.  For data traffic, a security policy database (SPD) and
+   security association database (SAD) will likely exist, following the
+   IPsec architecture.  One distinction between HIP and IPsec, however,
+   is that the host IDs, and not the IP addresses, are conceptually used
+   as selectors in the SPD.  In the outbound direction, as a result of
+   SPD processing, when an outbound SA is selected, the correct IP
+   destination address for the peer must also be assigned.  Therefore,
+   outbound SAs are conceptually associated with the peer IP address
+   that must be used as the destination IP address below the HIP layer.
+   In the inbound direction, the IP addresses may be used as selectors
+   in the SAD to look up the SA, but they are not strictly required; the
+   ESP SPI may be used alone.  To summarize, in the non-multihoming
+   case, there is only one source IP address, one destination IP
+   address, one inbound SA, and one outbound SA.
+
+   The HIP readdressing protocol [RFC8046] is an asymmetric protocol in
+   which a mobile or multihomed host informs a peer host about changes
+   of IP addresses on affected SPIs.  IP address and ESP SPI information
+   is carried in Locator fields in a HIP parameter called a LOCATOR_SET.
+   The HIP mobility specification [RFC8046] describes how the
+   LOCATOR_SET is carried in a HIP UPDATE packet.
+
+   To summarize the mobility elements of procedure, as background for
+   multihoming, the basic idea of host mobility is to communicate a
+   local IP address change to the peer when active HIP-maintained SAs
+   are in use.  To do so, the IP address must be conveyed, any
+   association between the IP address and an inbound SA (via the SPI
+   index) may be conveyed, and protection against flooding attacks must
+   be ensured.  The association of an IP address with an SPI is
+   performed by a Locator Type of "1", which is a concatenation of an
+   ESP SPI with an IP address.
+
+   An address verification method is specified in [RFC8046].  It is
+   expected that addresses learned in multihoming scenarios also are
+   subject to the same verification rules.  At times, the scenarios
+   describe addresses as being in either an ACTIVE, VERIFIED, or
+   DEPRECATED state.  From the perspective of a host, newly learned
+   addresses of the peer must be verified before put into active
+
+
+
+
+
+Henderson, et al.            Standards Track                    [Page 5]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   service, and addresses removed by the peer are put into a deprecated
+   state.  Under limited conditions described in [RFC8046], an
+   UNVERIFIED address may be used.
+
+   With this background, we next describe an additional protocol to
+   facilitate scenarios in which one or both hosts have multiple IP
+   addresses available.  Increasingly, this is the common case with
+   network-connected hosts on the Internet.
+
+4.2.  Usage Scenarios
+
+4.2.1.  Multiple Addresses
+
+   Hosts may have multiple IP addresses within different address
+   families (IPv4 and IPv6) and scopes available to support HIP
+   messaging and HIP-enabled SAs.  The multiple addresses may be on a
+   single network interface or multiple network interfaces.  It is
+   outside of the scope of this document to specify how a host decides
+   which of possibly multiple addresses may be used to support a HIP
+   association.  Some IP addresses may be held back from usage due to
+   privacy, security, or cost considerations.
+
+   When multiple IP addresses are shared with a peer, the procedures
+   described in the HIP mobility specification [RFC8046] allow for a
+   host to set a preferred locator ("P") bit, requesting that one of the
+   multiple addresses be preferred for control- or data-plane traffic.
+   It is also permitted to leave the preferred bit unset for all
+   addresses, allowing the peer to make address selection decisions.
+
+   Hosts that use link-local addresses as source addresses in their HIP
+   handshakes may not be reachable by a mobile peer.  Such hosts SHOULD
+   provide a globally routable address either in the initial handshake
+   or via the LOCATOR_SET parameter.
+
+   To support mobility, as described in the HIP mobility specification
+   [RFC8046], the LOCATOR_SET may be sent in a HIP UPDATE packet.  To
+   support multihoming, the LOCATOR_SET may also be sent in R1, I2, or
+   R2 packets defined in the HIP protocol specification [RFC7401].  The
+   reason to consider sending LOCATOR_SET parameters in base exchange
+   packets is to convey all usable addresses for fault-tolerance or
+   load-balancing considerations.
+
+4.2.2.  Multiple Security Associations
+
+   When multiple addresses are available between peer hosts, a question
+   that arises is whether to use one or multiple SAs.  The intent of
+   this specification is to support different use cases but to leave the
+   policy decision to the hosts.
+
+
+
+Henderson, et al.            Standards Track                    [Page 6]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   When one host has n addresses and the other host has m addresses, it
+   is possible to set up as many as (n * m) SAs in each direction.  In
+   such a case, every combination of source and destination IP addresses
+   would have a unique SA, and the possibility of the reordering of
+   datagrams on each SA will be lessened (ESP SAs may have an anti-
+   replay window [RFC4303] sensitive to reordering).  However, the
+   downside to creating a mesh of SAs is the signaling overhead required
+   (for exchanging UPDATE messages conveying ESP_INFO parameters) and
+   the state maintenance required in the SPD/SAD.
+
+   For load balancing, when multiple paths are to be used in parallel,
+   it may make sense to create different SAs for different paths.  In
+   this use case, while a full mesh of 2 * (n * m) SAs may not be
+   required, it may be beneficial to create one SA pair per load-
+   balanced path to avoid anti-replay window issues.
+
+   For fault tolerance, it is more likely that a single SA and multiple
+   IP addresses associated with that SA can be used, and the alternative
+   addresses can be used only upon failure detection of the addresses in
+   use.  Techniques for path failure detection are outside the scope of
+   this specification.  An implementation may use ICMP interactions,
+   reachability checks, or other means to detect the failure of a
+   locator.
+
+   In summary, whether and how a host decides to leverage additional
+   addresses in a load-balancing or fault-tolerant manner is outside the
+   scope of the specification (although the academic literature on
+   multipath TCP schedulers may provide guidance on how to design such a
+   policy).  However, in general, this document recommends that for
+   fault tolerance, it is likely sufficient to use a single SA pair for
+   all addresses, and for load balancing, to support a different SA pair
+   for all active paths being balanced across.
+
+4.2.3.  Host Multihoming for Fault Tolerance
+
+   A (mobile or stationary) host may have more than one interface or
+   global address.  The host may choose to notify the peer host of the
+   additional interface or address by using the LOCATOR_SET parameter.
+   The LOCATOR_SET parameter may be included in an I2, R1, or R2 packet,
+   or it may be conveyed, after the base exchange completes in an UPDATE
+   packet.
+
+   When more than one locator is provided to the peer host, the host MAY
+   indicate which locator is preferred (the locator on which the host
+   prefers to receive traffic).  By default, the address that a host
+   uses in the base exchange is its preferred locator (for the address
+
+
+
+
+
+Henderson, et al.            Standards Track                    [Page 7]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   family and address scope in use during the base exchange) until
+   indicated otherwise.  It may be the case that the host does not
+   express any preferred locators.
+
+   In the multihoming case, the sender may also have multiple valid
+   locators from which to source traffic.  In practice, a HIP
+   association in a multihoming configuration may have both a preferred
+   peer locator and a preferred local locator.  The host should try to
+   use the peer's preferred locator unless policy or other circumstances
+   prevent such usage.  A preferred local locator may be overridden if
+   source address selection rules on the destination address (peer's
+   preferred locator) suggest the use of a different source address.
+
+   Although the protocol may allow for configurations in which there is
+   an asymmetric number of SAs between the hosts (e.g., one host has two
+   interfaces and two inbound SAs, while the peer has one interface and
+   one inbound SA), it is suggested that inbound and outbound SAs be
+   created pairwise between hosts.  When an ESP_INFO arrives to rekey a
+   particular outbound SA, the corresponding inbound SA should also be
+   rekeyed at that time.  Section 4.3 discusses the interaction between
+   addresses and security associations in more detail.
+
+   Consider the case of two hosts, one single-homed and one multihomed.
+   The multihomed host may decide to inform the single-homed host about
+   its other address(es).  It may choose to do so as follows.
+
+   If the multihomed host wishes to convey the additional address(es)
+   for fault tolerance, it should include all of its addresses in
+   Locator fields, indicating the Traffic Type, Locator Type, and
+   whether the locator is a preferred locator.  If it wishes to bind any
+   particular address to an existing SPI, it may do so by using a
+   Locator Type of "1" as specified in the HIP mobility specification
+   [RFC8046].  It does not need to rekey the existing SA or request
+   additional SAs at this time.
+
+   Figure 1 illustrates this scenario.  Note that the conventions for
+   message parameter notations in figures (use of parentheses and
+   brackets) is defined in Section 2.2 of [RFC7401].
+
+     Multihomed Host                     Peer Host
+
+              UPDATE(LOCATOR_SET, SEQ)
+        ----------------------------------->
+              UPDATE(ACK)
+        <-----------------------------------
+
+                   Figure 1: Basic Multihoming Scenario
+
+
+
+
+Henderson, et al.            Standards Track                    [Page 8]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   In this scenario, the peer host associates the multiple addresses
+   with the SA pair between it and the multihomed host.  It may also
+   undergo address verification procedures to transition the addresses
+   to ACTIVE state.  For inbound data traffic, it may choose to use the
+   addresses along with the SPI as selectors.  For outbound data
+   traffic, it must choose among the available addresses of the
+   multihomed host, considering the state of address verification
+   [RFC8046] of each address, and also considering available information
+   about whether an address is in a working state.
+
+4.2.4.  Host Multihoming for Load Balancing
+
+   A multihomed host may decide to set up new SA pairs corresponding to
+   new addresses, for the purpose of load balancing.  The decision to
+   load balance and the mechanism for splitting load across multiple SAs
+   is out of scope of this document.  The scenario can be supported by
+   sending the LOCATOR_SET parameter with one or more ESP_INFO
+   parameters to initiate new ESP SAs.  To do this, the multihomed host
+   sends a LOCATOR_SET with an ESP_INFO, indicating the request for a
+   new SA by setting the OLD SPI value to zero and the NEW SPI value to
+   the newly created incoming SPI.  A Locator Type of "1" is used to
+   associate the new address with the new SPI.  The LOCATOR_SET
+   parameter also contains a second Type "1" Locator, that of the
+   original address and SPI.  To simplify parameter processing and avoid
+   explicit protocol extensions to remove locators, each LOCATOR_SET
+   parameter MUST list all locators in use on a connection (a complete
+   listing of inbound locators and SPIs for the host).  The multihomed
+   host waits for a corresponding ESP_INFO (new outbound SA) from the
+   peer and an ACK of its own UPDATE.  As in the mobility case, the peer
+   host must perform an address verification before actively using the
+   new address.
+
+   Figure 2 illustrates this scenario.
+
+     Multihomed Host                     Peer Host
+
+              UPDATE(ESP_INFO, LOCATOR_SET, SEQ, [DIFFIE_HELLMAN])
+        ----------------------------------->
+              UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
+        <-----------------------------------
+              UPDATE(ACK, ECHO_RESPONSE)
+        ----------------------------------->
+
+               Figure 2: Host Multihoming for Load Balancing
+
+   In multihoming scenarios, it is important that hosts receiving
+   UPDATEs associate them correctly with the destination address used in
+   the packet carrying the UPDATE.  When processing inbound LOCATOR_SETs
+
+
+
+Henderson, et al.            Standards Track                    [Page 9]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   that establish new security associations on an interface with
+   multiple addresses, a host uses the destination address of the UPDATE
+   containing the LOCATOR_SET as the local address to which the
+   LOCATOR_SET plus ESP_INFO is targeted.  This is because hosts may
+   send UPDATEs with the same (locator) IP address to different peer
+   addresses -- this has the effect of creating multiple inbound SAs
+   implicitly affiliated with different peer source addresses.
+
+4.2.5.  Site Multihoming
+
+   A host may have an interface that has multiple globally routable IP
+   addresses.  Such a situation may be a result of the site having
+   multiple upper Internet Service Providers, or just because the site
+   provides all hosts with both IPv4 and IPv6 addresses.  The host
+   should stay reachable at all or any subset of the currently available
+   global routable addresses, independent of how they are provided.
+
+   This case is handled the same as if there were different IP
+   addresses, described above in Sections 4.2.3 and 4.2.4.  Note that a
+   single interface may have addresses corresponding to site multihoming
+   while the host itself may also have multiple network interfaces.
+
+   Note that a host may be multihomed and mobile simultaneously, and
+   that a multihomed host may want to protect the location of some of
+   its interfaces while revealing the real IP address of some others.
+
+   This document does not present additional site multihoming extensions
+   to HIP; such extensions are for further study.
+
+4.2.6.  Dual-Host Multihoming
+
+   Consider the case in which both hosts are multihomed and would like
+   to notify the peer of an additional address after the base exchange
+   completes.  It may be the case that both hosts choose to simply
+   announce the second address in a LOCATOR_SET parameter using an
+   UPDATE message exchange.  It may also be the case that one or both
+   hosts decide to ask for new SA pairs to be created using the newly
+   announced address.  In the case that both hosts request this, the
+   result will be a full mesh of SAs as depicted in Figure 3.  In such a
+   scenario, consider that host1, which used address addr1a in the base
+   exchange to set up SPI1a and SPI2a, wants to add address addr1b.  It
+   would send an UPDATE with LOCATOR_SET (containing the address addr1b)
+   to host2, using destination address addr2a, and a new ESP_INFO, and a
+   new set of SPIs would be added between hosts 1 and 2 (call them SPI1b
+   and SPI2b; not shown in the figure).  Next, consider host2 deciding
+   to add addr2b to the relationship.  Host2 must select one of host1's
+   addresses towards which to initiate an UPDATE.  It may choose to
+   initiate an UPDATE to addr1a, addr1b, or both.  If it chooses to send
+
+
+
+Henderson, et al.            Standards Track                   [Page 10]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   to both, then a full mesh (four SA pairs) of SAs would exist between
+   the two hosts.  This is the most general case; the protocol is
+   flexible enough to accommodate this choice.
+
+              -<- SPI1a --                         -- SPI2a ->-
+      host1 <              > addr1a <---> addr2a <              > host2
+              ->- SPI2a --                         -- SPI1a -<-
+
+                             addr1b <---> addr2a  (second SA pair)
+                             addr1a <---> addr2b  (third SA pair)
+                             addr1b <---> addr2b  (fourth SA pair)
+
+    Figure 3: Dual-Multihoming Case in which Each Host Uses LOCATOR_SET
+                          to Add a Second Address
+
+4.2.7.  Combined Mobility and Multihoming
+
+   Mobile hosts may be simultaneously mobile and multihomed, i.e., have
+   multiple mobile interfaces.  Furthermore, if the interfaces use
+   different access technologies, it is fairly likely that one of the
+   interfaces may appear stable (retain its current IP address) while
+   some others may experience mobility (undergo IP address change).
+
+   The use of LOCATOR_SET plus ESP_INFO should be flexible enough to
+   handle most such scenarios, although more complicated scenarios have
+   not been studied so far.
+
+4.2.8.  Initiating the Protocol in R1, I2, or R2
+
+   A Responder host MAY include a LOCATOR_SET parameter in the R1 packet
+   that it sends to the Initiator.  This parameter MUST be protected by
+   the R1 signature.  If the R1 packet contains LOCATOR_SET parameters
+   with a new preferred locator, the Initiator SHOULD directly set the
+   new preferred locator to status ACTIVE without performing address
+   verification first, and it MUST send the I2 packet to the new
+   preferred locator.  The I1 destination address and the new preferred
+   locator may be identical.  All new non-preferred locators must still
+   undergo address verification once the base exchange completes.  It is
+   also possible for the host to send the LOCATOR_SET without any
+   preferred bits set, in which case the exchange will continue as
+   normal and the newly learned addresses will be in an UNVERIFIED state
+   at the initiator.
+
+
+
+
+
+
+
+
+
+Henderson, et al.            Standards Track                   [Page 11]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+            Initiator                                Responder
+
+                              R1 with LOCATOR_SET
+                  <-----------------------------------
+   record additional addresses
+   change Responder address
+                     I2 sent to newly indicated preferred address
+                  ----------------------------------->
+                                                     (process normally)
+                                  R2
+                  <-----------------------------------
+   (process normally, later verification of non-preferred locators)
+
+                   Figure 4: LOCATOR_SET Inclusion in R1
+
+   An Initiator MAY include one or more LOCATOR_SET parameters in the I2
+   packet, independent of whether or not there was a LOCATOR_SET
+   parameter in the R1.  These parameters MUST be protected by the I2
+   signature.  Even if the I2 packet contains LOCATOR_SET parameters,
+   the Responder MUST still send the R2 packet to the source address of
+   the I2.  The new preferred locator, if set, SHOULD be identical to
+   the I2 source address.  If the I2 packet contains LOCATOR_SET
+   parameters, all new locators must undergo address verification as
+   usual, and the ESP traffic that subsequently follows should use the
+   preferred locator.
+
+            Initiator                                Responder
+
+                             I2 with LOCATOR_SET
+                  ----------------------------------->
+                                                     (process normally)
+                                             record additional addresses
+                       R2 sent to source address of I2
+                  <-----------------------------------
+   (process normally)
+
+                   Figure 5: LOCATOR_SET Inclusion in I2
+
+   The I1 and I2 may be arriving from different source addresses if the
+   LOCATOR_SET parameter is present in R1.  In this case,
+   implementations simultaneously using multiple pre-created R1s,
+   indexed by Initiator IP addresses, may inadvertently fail the puzzle
+   solution of I2 packets due to a perceived puzzle mismatch.  See, for
+   instance, the example in Appendix A of [RFC7401].  As a solution, the
+   Responder's puzzle indexing mechanism must be flexible enough to
+   accommodate the situation when R1 includes a LOCATOR_SET parameter.
+
+
+
+
+
+Henderson, et al.            Standards Track                   [Page 12]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   Finally, the R2 may be used to carry the LOCATOR_SET parameter.  In
+   this case, the LOCATOR_SET is covered by the HIP_MAC_2 and
+   HIP_SIGNATURE.  Including LOCATOR_SET in R2 as opposed to R1 may have
+   some advantages when a host prefers not to divulge additional
+   locators until after the I2 is successfully processed.
+
+   When the LOCATOR_SET parameter is sent in an UPDATE packet, the
+   receiver will respond with an UPDATE acknowledgment.  When the
+   LOCATOR_SET parameter is sent in an R1, I2, or R2 packet, the base
+   exchange retransmission mechanism will confirm its successful
+   delivery.
+
+4.2.9.  Using LOCATOR_SETs across Addressing Realms
+
+   It is possible for HIP associations to use these mechanisms to
+   migrate their HIP associations and security associations from
+   addresses in the IPv4 addressing realm to IPv6, or vice versa.  It
+   may be possible for a state to arise in which both hosts are only
+   using locators in different addressing realms, but in such a case,
+   some type of mechanism for interworking between the different realms
+   must be employed; such techniques are outside the scope of the
+   present text.
+
+4.3.  Interaction with Security Associations
+
+   A host may establish any number of security associations (or SPIs)
+   with a peer.  The main purpose of having multiple SPIs with a peer is
+   to group the addresses into collections that are likely to experience
+   fate sharing, or to perform load balancing.
+
+   A basic property of HIP SAs is that the inbound IP address is not
+   used to look up the incoming SA.  However, the use of different
+   source and destination addresses typically leads to different paths,
+   with different latencies in the network, and if packets were to
+   arrive via an arbitrary destination IP address (or path) for a given
+   SPI, the reordering due to different latencies may cause some packets
+   to fall outside of the ESP anti-replay window.  For this reason, HIP
+   provides a mechanism to affiliate destination addresses with inbound
+   SPIs, when there is a concern that anti-replay windows might be
+   violated.  In this sense, we can say that a given inbound SPI has an
+   "affinity" for certain inbound IP addresses, and this affinity is
+   communicated to the peer host.  Each physical interface SHOULD have a
+   separate SA, unless the ESP anti-replay window is extended or
+   disabled.
+
+   Moreover, even when the destination addresses used for a particular
+   SPI are held constant, the use of different source interfaces may
+   also cause packets to fall outside of the ESP anti-replay window,
+
+
+
+Henderson, et al.            Standards Track                   [Page 13]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   since the path traversed is often affected by the source address or
+   interface used.  A host has no way to influence the source interface
+   on which a peer sends its packets on a given SPI.  A host SHOULD
+   consistently use the same source interface and address when sending
+   to a particular destination IP address and SPI.  For this reason, a
+   host may find it useful to change its SPI or at least reset its ESP
+   anti-replay window when the peer host readdresses.
+
+5.  Processing Rules
+
+   Basic processing rules for the LOCATOR_SET parameter are specified in
+   [RFC8046].  This document focuses on multihoming-specific rules.
+
+5.1.  Sending LOCATOR_SETs
+
+   The decision of when to send a LOCATOR_SET, and which addresses to
+   include, is a local policy issue.  [RFC8046] recommends that a host
+   "send a LOCATOR_SET whenever it recognizes a change of its IP
+   addresses in use on an active HIP association and [when it] assumes
+   that the change is going to last at least for a few seconds."  It is
+   possible to delay the exposure of additional locators to the peer,
+   and to send data from previously unannounced locators, as might arise
+   in certain mobility or multihoming situations.
+
+   When a host decides to inform its peers about changes in its IP
+   addresses, it has to decide how to group the various addresses with
+   SPIs.  If hosts are deployed in an operational environment in which
+   HIP-aware NATs and firewalls (that may perform parameter inspection)
+   exist, and different such devices may exist on different paths, hosts
+   may take that knowledge into consideration about how addresses are
+   grouped, and may send the same LOCATOR_SET in separate UPDATEs on the
+   different paths.  However, more detailed guidelines about how to
+   operate in the presence of such HIP-aware NATs and firewalls are a
+   topic for further study.  Since each SPI is associated with a
+   different security association, the grouping policy may also be based
+   on ESP anti-replay protection considerations.  In the typical case,
+   simply basing the grouping on actual kernel-level physical and
+   logical interfaces may be the best policy.  The grouping policy is
+   outside of the scope of this document.
+
+   Locators corresponding to tunnel interfaces (e.g., IPsec tunnel
+   interfaces or Mobile IP home addresses) or other virtual interfaces
+   MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid
+   announcing such locators as preferred locators if more direct paths
+   may be obtained by instead preferring locators from non-tunneling
+   interfaces if such locators provide a more direct path to the HIP
+   peer.
+
+
+
+
+Henderson, et al.            Standards Track                   [Page 14]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   [RFC8046] specifies that hosts MUST NOT announce broadcast or
+   multicast addresses in LOCATOR_SETs.  Link-local addresses MAY be
+   announced to peers that are known to be neighbors on the same link,
+   such as when the IP destination address of a peer is also link local.
+   The announcement of link-local addresses in this case is a policy
+   decision; link-local addresses used as preferred locators will create
+   reachability problems when the host moves to another link.  In any
+   case, link-local addresses MUST NOT be announced to a peer unless
+   that peer is known to be on the same link.
+
+   Once the host has decided on the groups and assignment of addresses
+   to the SPIs, it creates a LOCATOR_SET parameter that serves as a
+   complete representation of the addresses and associated SPIs intended
+   for active use.  We now describe a few cases introduced in Section 4.
+   We assume that the Traffic Type for each locator is set to "0" (other
+   values for Traffic Type may be specified in documents that separate
+   the HIP control plane from data-plane traffic).  Other mobility and
+   multihoming cases are possible but are left for further
+   experimentation.
+
+   1.  Host multihoming (addition of an address).  We only describe the
+       simple case of adding an additional address to a (previously)
+       single-homed, non-mobile host.  The host MAY choose to simply
+       announce this address to the peer, for fault tolerance.  To do
+       this, the multihomed host creates a LOCATOR_SET parameter
+       including the existing address and SPI as a Type "1" Locator, and
+       the new address as a Type "0" Locator.  The host sends this in an
+       UPDATE message with the SEQ parameter, which is acknowledged by
+       the peer.
+
+   2.  The host MAY set up a new SA pair between this new address and an
+       address of the peer host.  To do this, the multihomed host
+       creates a new inbound SA and creates a new SPI.  For the outgoing
+       UPDATE message, it inserts an ESP_INFO parameter with an OLD SPI
+       field of "0", a NEW SPI field corresponding to the new SPI, and a
+       KEYMAT Index as selected by local policy.  The host adds to the
+       UPDATE message a LOCATOR_SET with two Type "1" Locators: the
+       original address and SPI active on the association, and the new
+       address and new SPI being added (with the SPI matching the NEW
+       SPI contained in the ESP_INFO).  The preferred bit SHOULD be set
+       depending on the policy to tell the peer host which of the two
+       locators is preferred.  The UPDATE also contains a SEQ parameter
+       and optionally a DIFFIE_HELLMAN parameter and follows rekeying
+       procedures with respect to this new address.  The UPDATE message
+       SHOULD be sent to the peer's preferred address with a source
+       address corresponding to the new locator.
+
+
+
+
+
+Henderson, et al.            Standards Track                   [Page 15]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   The sending of multiple LOCATOR_SETs is unsupported.  Note that the
+   inclusion of LOCATOR_SET in an R1 packet requires the use of Type "0"
+   Locators since no SAs are set up at that point.
+
+5.2.  Handling Received LOCATOR_SETs
+
+   A host SHOULD be prepared to receive a LOCATOR_SET parameter in the
+   following HIP packets: R1, I2, R2, and UPDATE.
+
+   This document describes sending both ESP_INFO and LOCATOR_SET
+   parameters in an UPDATE.  The ESP_INFO parameter is included when
+   there is a need to rekey or key a new SPI and can otherwise be
+   included for the possible benefit of HIP-aware middleboxes.  The
+   LOCATOR_SET parameter contains a complete map of the locators that
+   the host wishes to make or keep active for the HIP association.
+
+   In general, the processing of a LOCATOR_SET depends upon the packet
+   type in which it is included.  Here, we describe only the case in
+   which ESP_INFO is present and a single LOCATOR_SET and ESP_INFO are
+   sent in an UPDATE message; other cases are for further study.  The
+   steps below cover each of the cases described in Section 5.1.
+
+   The processing of ESP_INFO and LOCATOR_SET parameters is intended to
+   be modular and support future generalization to the inclusion of
+   multiple ESP_INFO and/or multiple LOCATOR_SET parameters.  A host
+   SHOULD first process the ESP_INFO before the LOCATOR_SET, since the
+   ESP_INFO may contain a new SPI value mapped to an existing SPI, while
+   a Type "1" Locator will only contain a reference to the new SPI.
+
+   When a host receives a validated HIP UPDATE with a LOCATOR_SET and
+   ESP_INFO parameter, it processes the ESP_INFO as follows.  The
+   ESP_INFO parameter indicates whether an SA is being rekeyed, created,
+   deprecated, or just identified for the benefit of middleboxes.  The
+   host examines the OLD SPI and NEW SPI values in the ESP_INFO
+   parameter:
+
+   1.  (no rekeying) If the OLD SPI is equal to the NEW SPI and both
+       correspond to an existing SPI, the ESP_INFO is gratuitous
+       (provided for middleboxes), and no rekeying is necessary.
+
+   2.  (rekeying) If the OLD SPI indicates an existing SPI and the NEW
+       SPI is a different non-zero value, the existing SA is being
+       rekeyed and the host follows HIP ESP rekeying procedures by
+       creating a new outbound SA with an SPI corresponding to the NEW
+       SPI, with no addresses bound to this SPI.  Note that locators in
+       the LOCATOR_SET parameter will reference this new SPI instead of
+       the old SPI.
+
+
+
+
+Henderson, et al.            Standards Track                   [Page 16]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   3.  (new SA) If the OLD SPI value is zero and the NEW SPI is a new
+       non-zero value, then a new SA is being requested by the peer.
+       This case is also treated like a rekeying event; the receiving
+       host must create a new SA and respond with an UPDATE ACK.
+
+   4.  (deprecating the SA) If the OLD SPI indicates an existing SPI and
+       the NEW SPI is zero, the SA is being deprecated and all locators
+       uniquely bound to the SPI are put into the DEPRECATED state.
+
+   If none of the above cases apply, a protocol error has occurred and
+   the processing of the UPDATE is stopped.
+
+   Next, the locators in the LOCATOR_SET parameter are processed.  For
+   each locator listed in the LOCATOR_SET parameter, check that the
+   address therein is a legal unicast or anycast address.  That is, the
+   address MUST NOT be a broadcast or multicast address.  Note that some
+   implementations MAY accept addresses that indicate the local host,
+   since it may be allowed that the host runs HIP with itself.
+
+   For each Type "1" address listed in the LOCATOR_SET parameter, the
+   host checks whether the address is already bound to the SPI
+   indicated.  If the address is already bound, its lifetime is updated.
+   If the status of the address is DEPRECATED, the status is changed to
+   UNVERIFIED.  If the address is not already bound, the address is
+   added, and its status is set to UNVERIFIED.  If there exist remaining
+   addresses corresponding to the SPI that were NOT listed in the
+   LOCATOR_SET parameter, the host sets the status of such addresses to
+   DEPRECATED.
+
+   For each Type "0" address listed in the LOCATOR_SET parameter, if the
+   status of the address is DEPRECATED, or the address was not
+   previously known, the status is changed to UNVERIFIED.  The host MAY
+   choose to associate this address with one or more SAs.  The
+   association with different SAs is a local policy decision, unless the
+   peer has indicated that the address is preferred, in which case the
+   address should be put into use on an SA that is prioritized in the
+   security policy database.
+
+   As a result, at the end of processing, the addresses listed in the
+   LOCATOR_SET parameter have a state of either UNVERIFIED or ACTIVE,
+   and any old addresses on the old SA not listed in the LOCATOR_SET
+   parameter have a state of DEPRECATED.
+
+   Once the host has processed the locators, if the LOCATOR_SET
+   parameter contains a new preferred locator, the host SHOULD initiate
+   a change of the preferred locator.  This requires that the host first
+   verifies reachability of the associated address and only then changes
+   the preferred locator; see Section 5.4.
+
+
+
+Henderson, et al.            Standards Track                   [Page 17]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   If a host receives a locator with an unsupported Locator Type, and
+   when such a locator is also declared to be the preferred locator for
+   the peer, the host SHOULD send a NOTIFY error with a Notify Message
+   Type of LOCATOR_TYPE_UNSUPPORTED, with the Notification Data field
+   containing the locator(s) that the receiver failed to process.
+   Otherwise, a host MAY send a NOTIFY error if a (non-preferred)
+   locator with an unsupported Locator Type is received in a LOCATOR_SET
+   parameter.
+
+5.3.  Verifying Address Reachability
+
+   Address verification is defined in [RFC8046].
+
+   When address verification is in progress for a new preferred locator,
+   the host SHOULD select a different locator listed as ACTIVE, if one
+   such locator is available, to continue communications until address
+   verification completes.  Alternatively, the host MAY use the new
+   preferred locator while in UNVERIFIED status to the extent Credit-
+   Based Authorization permits.  Credit-Based Authorization is explained
+   in [RFC8046].  Once address verification succeeds, the status of the
+   new preferred locator changes to ACTIVE.
+
+5.4.  Changing the Preferred Locator
+
+   A host MAY want to change the preferred outgoing locator for
+   different reasons, e.g., because traffic information or ICMP error
+   messages indicate that the currently used preferred address may have
+   become unreachable.  Another reason may be due to receiving a
+   LOCATOR_SET parameter that has the preferred bit set.
+
+   To change the preferred locator, the host initiates the following
+   procedure:
+
+   1.  If the new preferred locator has ACTIVE status, the preferred
+       locator is changed and the procedure succeeds.
+
+   2.  If the new preferred locator has UNVERIFIED status, the host
+       starts to verify its reachability.  The host SHOULD use a
+       different locator listed as ACTIVE until address verification
+       completes if one such locator is available.  Alternatively, the
+       host MAY use the new preferred locator, even though in UNVERIFIED
+       status, to the extent Credit-Based Authorization permits.  Once
+       address verification succeeds, the status of the new preferred
+       locator changes to ACTIVE, and its use is no longer governed by
+       Credit-Based Authorization.
+
+
+
+
+
+
+Henderson, et al.            Standards Track                   [Page 18]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   3.  If the peer host has not indicated a preference for any address,
+       then the host picks one of the peer's ACTIVE addresses randomly
+       or according to policy.  This case may arise if, for example,
+       ICMP error messages that deprecate the preferred locator arrive,
+       but the peer has not yet indicated a new preferred locator.
+
+   4.  If the new preferred locator has DEPRECATED status and there is
+       at least one non-deprecated address, the host selects one of the
+       non-deprecated addresses as a new preferred locator and
+       continues.  If the selected address is UNVERIFIED, the address
+       verification procedure described above will apply.
+
+6.  Security Considerations
+
+   This document extends the scope of host mobility solutions defined in
+   [RFC8046] to also include host multihoming, and as a result, many of
+   the same security considerations for mobility also pertain to
+   multihoming.  In particular, [RFC8046] describes how HIP host
+   mobility is resistant to different types of impersonation attacks and
+   denial-of-service (DoS) attacks.
+
+   The security considerations for this document are similar to those of
+   [RFC8046] because the strong authentication capabilities for mobility
+   also carry over to end-host multihoming.  [RFC4218] provides a threat
+   analysis for IPv6 multihoming, and the remainder of this section
+   first describes how HIP host multihoming addresses those previously
+   described threats, and then it discusses some additional security
+   considerations.
+
+   The high-level threats discussed in [RFC4218] involve redirection
+   attacks for the purposes of packet recording, data manipulation, and
+   availability.  There are a few types of attackers to consider:
+   on-path attackers, off-path attackers, and malicious hosts.
+
+   [RFC4218] also makes the comment that in identifier/locator split
+   solutions such as HIP, application security mechanisms should be tied
+   to the identifier, not the locator, and attacks on the identifier
+   mechanism and on the mechanism binding locators to the identifier are
+   of concern.  This document does not consider the former issue
+   (application-layer security bindings) to be within scope.  The latter
+   issue (locator bindings to identifier) is directly addressed by the
+   cryptographic protections of the HIP protocol, in that locators
+   associated to an identifier are listed in HIP packets that are signed
+   using the identifier key.
+
+   Section 3.1 of [RFC4218] lists several classes of security
+   configurations in use in the Internet.  HIP maps to the fourth
+   (strong identifier) and fifth ("leap-of-faith") categories, the
+
+
+
+Henderson, et al.            Standards Track                   [Page 19]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   latter being associated with the optional opportunistic mode of HIP
+   operation.  The remainder of Section 3 describes existing security
+   problems in the Internet and comments that the goal of a multihoming
+   solution is not to solve them specifically but rather not to make any
+   of them worse.  HIP multihoming should not increase the severity of
+   the identified risks.  One concern for both HIP mobility and
+   multihoming is the susceptibility of the mechanisms to misuse
+   flooding-based redirections due to a malicious host.  The mechanisms
+   described in [RFC8046] for address verification are important in this
+   regard.
+
+   Regarding the new types of threats introduced by multihoming
+   (Section 4 of [RFC4218]), HIP multihoming should not introduce new
+   concerns.  Classic and premeditated redirection are prevented by the
+   strong authentication in HIP messages.  Third-party DoS attacks are
+   prevented by the address verification mechanism.  Replay attacks can
+   be avoided via use of replay protection in ESP SAs.  In addition,
+   accepting packets from unknown locators is protected by either the
+   strong authentication in the HIP control packets or by the ESP-based
+   encryption in use for data packets.
+
+   The HIP mechanisms are designed to limit the ability to introduce DoS
+   on the mechanisms themselves (Section 7 of [RFC4218]).  Care is taken
+   in the HIP base exchange to avoid creating state or performing much
+   work before hosts can authenticate one another.  A malicious host
+   involved in HIP multihoming with another host might attempt to misuse
+   the mechanisms for multihoming by, for instance, increasing the state
+   required or inducing a resource limitation attack by sending too many
+   candidate locators to the peer host.  Therefore, implementations
+   supporting the multihoming extensions should consider avoiding
+   accepting large numbers of peer locators and rate limiting any UPDATE
+   messages being exchanged.
+
+   The exposure of a host's IP addresses through HIP mobility and
+   multihoming extensions may raise the following privacy concern.  The
+   administrator of a host may be trying to hide its location in some
+   context through the use of a VPN or other virtual interfaces.
+   Similar privacy issues also arise in other frameworks such as WebRTC
+   and are not specific to HIP.  Implementations SHOULD provide a
+   mechanism to allow the host administrator to block the exposure of
+   selected addresses or address ranges.
+
+   Finally, some implementations of VPN tunneling have experienced
+   instances of 'leakage' of flows that were intended to have been
+   protected by a security tunnel but are instead sent in the clear,
+   perhaps because some of the addresses used fall outside of the range
+   of addresses configured for the tunnel in the security policy or
+   association database.  Implementors are advised to take steps to
+
+
+
+Henderson, et al.            Standards Track                   [Page 20]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+   ensure that the usage of multiple addresses between hosts does not
+   cause accidental leakage of some data session traffic outside of the
+   ESP-protected envelope.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
+              "Default Address Selection for Internet Protocol Version 6
+              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
+              <http://www.rfc-editor.org/info/rfc6724>.
+
+   [RFC7401]  Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
+              Henderson, "Host Identity Protocol Version 2 (HIPv2)",
+              RFC 7401, DOI 10.17487/RFC7401, April 2015,
+              <http://www.rfc-editor.org/info/rfc7401>.
+
+   [RFC7402]  Jokela, P., Moskowitz, R., and J. Melen, "Using the
+              Encapsulating Security Payload (ESP) Transport Format with
+              the Host Identity Protocol (HIP)", RFC 7402,
+              DOI 10.17487/RFC7402, April 2015,
+              <http://www.rfc-editor.org/info/rfc7402>.
+
+   [RFC8046]  Henderson, T., Ed., Vogt, C., and J. Arkko, "Host Mobility
+              with the Host Identity Protocol", RFC 8046,
+              DOI 10.17487/RFC8046, February 2017,
+              <http://www.rfc-editor.org/info/rfc8046>.
+
+7.2.  Informative References
+
+   [RFC4218]  Nordmark, E. and T. Li, "Threats Relating to IPv6
+              Multihoming Solutions", RFC 4218, DOI 10.17487/RFC4218,
+              October 2005, <http://www.rfc-editor.org/info/rfc4218>.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, DOI 10.17487/RFC4303, December 2005,
+              <http://www.rfc-editor.org/info/rfc4303>.
+
+   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
+              Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
+              June 2009, <http://www.rfc-editor.org/info/rfc5533>.
+
+
+
+
+Henderson, et al.            Standards Track                   [Page 21]
+
+RFC 8047                     HIP Multihoming               February 2017
+
+
+Acknowledgments
+
+   This document contains content that was originally included in RFC
+   5206.  Pekka Nikander and Jari Arkko originated RFC 5206, and
+   Christian Vogt and Thomas Henderson (editor) later joined as
+   coauthors.  Also in RFC 5206, Greg Perkins contributed the initial
+   draft of the security section, and Petri Jokela was a coauthor of the
+   initial individual submission.
+
+   The authors thank Miika Komu, Mika Kousa, Jeff Ahrenholz, and Jan
+   Melen for many improvements to the document.  Concepts from a paper
+   on host multihoming across address families, by Samu Varjonen, Miika
+   Komu, and Andrei Gurtov, contributed to this revised specification.
+
+Authors' Addresses
+
+   Thomas R. Henderson (editor)
+   University of Washington
+   Campus Box 352500
+   Seattle, WA
+   United States of America
+
+   Email: tomhend@u.washington.edu
+
+
+   Christian Vogt
+   Independent
+   3473 North First Street
+   San Jose, CA  95134
+   United States of America
+
+   Email: mail@christianvogt.net
+
+
+   Jari Arkko
+   Ericsson
+   Jorvas,  FIN-02420
+   Finland
+
+   Phone: +358 40 5079256
+   Email: jari.arkko@piuha.net
+
+
+
+
+
+
+
+
+
+
+Henderson, et al.            Standards Track                   [Page 22]
+