summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5648.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5648.txt')
-rw-r--r--doc/rfc/rfc5648.txt2019
1 files changed, 2019 insertions, 0 deletions
diff --git a/doc/rfc/rfc5648.txt b/doc/rfc/rfc5648.txt
new file mode 100644
index 0000000..eb9a2db
--- /dev/null
+++ b/doc/rfc/rfc5648.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group R. Wakikawa, Ed.
+Request for Comments: 5648 Toyota ITC
+Category: Standards Track V. Devarapalli
+ Wichorus
+ G. Tsirtsis
+ Qualcomm
+ T. Ernst
+ INRIA
+ K. Nagami
+ INTEC NetCore
+ October 2009
+
+
+ Multiple Care-of Addresses Registration
+
+Abstract
+
+ According to the current Mobile IPv6 specification, a mobile node may
+ have several care-of addresses but only one, called the primary
+ care-of address, can be registered with its home agent and the
+ correspondent nodes. However, for matters of cost, bandwidth, delay,
+ etc, it is useful for the mobile node to get Internet access through
+ multiple accesses simultaneously, in which case the mobile node would
+ be configured with multiple active IPv6 care-of addresses. This
+ document proposes extensions to the Mobile IPv6 protocol to register
+ and use multiple care-of addresses. The extensions proposed in this
+ document can be used by mobile routers using the NEMO (Network
+ Mobility) Basic Support protocol as well.
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright and License Notice
+
+ Copyright (c) 2009 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
+
+
+
+Wakikawa, et al. Standards Track [Page 1]
+
+RFC 5648 MCoA October 2009
+
+
+ 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 BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. Protocol Overview ...............................................4
+ 4. Mobile IPv6 Extensions .........................................10
+ 4.1. Binding Cache Structure and Binding Update List ...........10
+ 4.2. Binding Update Message ....................................10
+ 4.3. Binding Identifier Mobility Option ........................11
+ 4.4. New Status Values for Binding Acknowledgement .............13
+ 5. Mobile Node Operation ..........................................14
+ 5.1. Management of Care-of Address(es) and Binding
+ Identifier(s) .............................................14
+ 5.2. Binding Registration ......................................15
+ 5.3. Bulk Registration .........................................16
+ 5.4. Binding De-Registration ...................................16
+ 5.5. Returning Home with Complete Binding
+ De-Registration: Using a Single Interface .................17
+ 5.5.1. Using Only the Interface Attached to the
+ Home Link ..........................................17
+ 5.5.2. Using Only the Interface Attached to the
+ Visited Link .......................................17
+ 5.6. Returning Home: Simultaneous Home and Visited Link
+ Operation .................................................18
+ 5.6.1. Problems of Simultaneous Home and Foreign
+ Attachments ........................................18
+ 5.6.2. Overview and Approach ..............................18
+ 5.6.3. Home Binding Support ...............................19
+ 5.6.4. Sending Packets from the Home Link .................20
+ 5.6.5. Leaving from the Home Link .........................20
+ 5.7. Receiving Binding Acknowledgement .........................21
+ 5.8. Receiving Binding Refresh Request .........................22
+ 5.9. Bootstrapping .............................................22
+ 6. Home Agent and Correspondent Node Operation ....................22
+ 6.1. Searching Binding Cache with Binding Identifier ...........22
+ 6.2. Processing Binding Update .................................23
+ 6.3. Sending a Binding Acknowledgement for Home Link
+ Registration ..............................................25
+ 6.4. Sending Binding Refresh Request ...........................27
+ 6.5. Receiving Packets from Mobile Node ........................27
+ 7. Network Mobility Applicability .................................27
+ 8. DSMIPv6 Applicability ..........................................27
+ 8.1. IPv4 Care-of Address Registration .........................28
+ 8.2. IPv4 Home Address Management ..............................29
+
+
+
+Wakikawa, et al. Standards Track [Page 2]
+
+RFC 5648 MCoA October 2009
+
+
+ 9. IPsec and IKEv2 Interaction ....................................30
+ 9.1. Use of Care-of Address in the IKEv2 Exchange ..............31
+ 9.2. Transport Mode IPsec-Protected Messages ...................31
+ 9.3. Tunnel Mode IPsec-Protected Messages ......................31
+ 9.3.1. Tunneled Home Test Init and Home Test Messages .....31
+ 9.3.2. Tunneled Payload Traffic ...........................32
+ 10. Security Considerations .......................................33
+ 11. IANA Considerations ...........................................34
+ 12. Acknowledgements ..............................................35
+ 13. References ....................................................35
+ 13.1. Normative References .....................................35
+ 13.2. Informative References ...................................35
+
+1. Introduction
+
+ A mobile node may use various types of network interfaces to obtain
+ durable and wide area network connectivity. This has increasingly
+ become true with mobile nodes having multiple interfaces, such as
+ 802.2, 802.11, 802.16, cellular radios, etc. The motivations for and
+ benefits of using multiple points of attachment are discussed in
+ [MOTIVATION]. When a mobile node with multiple interfaces uses
+ Mobile IPv6 [RFC3775] for mobility management, it cannot use its
+ multiple interfaces to send and receive packets while taking
+ advantage of session continuity provided by Mobile IPv6. This is
+ because Mobile IPv6 allows the mobile node to bind only one care-of
+ address at a time with its home address. See [MIP6ANALYSIS] for a
+ further analysis of using multiple interfaces and addresses with
+ Mobile IPv6.
+
+ This document proposes extensions to Mobile IPv6 to allow a mobile
+ node to register multiple care-of addresses for a home address and
+ create multiple binding cache entries. A new Binding Identification
+ (BID) number is created for each binding the mobile node wants to
+ create and is sent in the Binding Update. The home agent that
+ receives this Binding Update creates a separate binding for each BID.
+ The BID information is stored in the corresponding binding cache
+ entry. The BID information can now be used to identify individual
+ bindings. The same extensions can also be used in Binding Updates
+ sent to the correspondent nodes.
+
+2. Terminology
+
+ 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 [RFC2119].
+
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 3]
+
+RFC 5648 MCoA October 2009
+
+
+ Terms used in this document are defined in [RFC3775], [RFC3753], and
+ [RFC4885]. In addition to or as a replacement of these, the
+ following terms are defined or redefined:
+
+ Binding Identification Number (BID)
+
+ The BID is an identification number used to distinguish multiple
+ bindings registered by the mobile node. Assignment of distinct
+ BIDs allows a mobile node to register multiple binding cache
+ entries for a given home address. BIDs assigned to the same home
+ address must not be duplicated at the same time. The value zero
+ is reserved for future extensions. Each BID is generated and
+ managed by a mobile node. The BID is stored in the Binding Update
+ List and is sent by the mobile node in the Binding Update. A
+ mobile node may change the value of a BID at any time according to
+ its administrative policy -- for instance, to protect its privacy.
+ An implementation must carefully assign the BID so as to keep
+ using the same BID for the same binding even when the status of
+ the binding is changed. More details can be found in Section 5.1.
+
+ Binding Identifier Mobility Option
+
+ The Binding Identifier mobility option is used to carry the BID
+ information.
+
+ Bulk Registration
+
+ A mobile node can register multiple bindings at once by sending a
+ single Binding Update. A mobile node can also replace some or all
+ of the bindings available at the home agent with the new bindings
+ by using the bulk registration. Bulk registration is supported
+ only for home registration (i.e., with the home agent) as
+ explained in Section 5.3. A mobile node must not perform the bulk
+ registration mechanism described in this specification with a
+ correspondent node.
+
+3. Protocol Overview
+
+ A new extension called the Binding Identification number (BID) is
+ introduced to distinguish between multiple bindings pertaining to the
+ same home address. If a mobile node configures several IPv6 global
+ addresses on one or more of its interfaces, it can register these
+ addresses with its home agent as care-of addresses. If the mobile
+ node wants to register multiple bindings, it MUST generate a BID for
+ each care-of address and store the BID in the Binding Update List. A
+ mobile node can manipulate each binding independently by using the
+ BIDs. The mobile node then registers its care-of addresses by
+ sending a Binding Update with a Binding Identifier mobility option.
+
+
+
+Wakikawa, et al. Standards Track [Page 4]
+
+RFC 5648 MCoA October 2009
+
+
+ The BID is included in the Binding Identifier mobility option. After
+ receiving the Binding Update with a Binding Identifier mobility
+ option, the home agent MUST copy the BID from the Binding Identifier
+ mobility option to the corresponding field in the binding cache
+ entry. If there is an existing binding cache entry for the mobile
+ node, and if the BID in the Binding Update does not match the one
+ with the existing entry, the home agent MUST create a new binding
+ cache entry for the new care-of address and BID. The mobile node can
+ either register multiple care-of addresses at once in a single
+ Binding Update or independently in individual Binding Updates.
+
+ If the mobile host wishes to register its binding with a
+ correspondent node, it must perform return routability operations as
+ described in [RFC3775]. This includes managing a Care-of Keygen
+ token per care-of address and exchanging Care-of Test Init and Care-
+ of Test messages with the correspondent node for each care-of
+ address. The mobile node MAY use the same BID that it used with the
+ home agent for a particular care-of address. For protocol
+ simplicity, bulk registration to correspondent nodes is not supported
+ in this document. This is because the return routability mechanism
+ introduced in [RFC3775] cannot be easily extended to verify multiple
+ care-of addresses stored in a single Binding Update.
+
+ Figure 1 illustrates the configuration where the mobile node obtains
+ multiple care-of addresses at foreign links. The mobile node can
+ utilize all the care-of addresses. In Figure 1, the home address of
+ the mobile node (MN) is 2001:db8::EUI. The mobile node has 3
+ different interfaces and possibly acquires care-of addresses 1-3
+ (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2, and BID3 to
+ each care-of address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 5]
+
+RFC 5648 MCoA October 2009
+
+
+ +----+
+ | CN |
+ +--+-+
+ |
+ +---+------+ +----+
+ +------+ Internet |----------+ HA |
+ | +----+---+-+ +--+-+
+ CoA2| | | | Home Link
+ +--+--+ | | ------+------
+ | MN +--------+ |
+ +--+--+ CoA1 |
+ CoA3| |
+ +---------------+
+
+ Binding Cache Database:
+ home agent's binding (Proxy neighbor advertisement is active)
+ binding [2001:db8::EUI BID1 care-of address1]
+ binding [2001:db8::EUI BID2 care-of address2]
+ binding [2001:db8::EUI BID3 care-of address3]
+ correspondent node's binding
+ binding [2001:db8::EUI BID1 care-of address1]
+ binding [2001:db8::EUI BID2 care-of address2]
+ binding [2001:db8::EUI BID3 care-of address3]
+
+ Figure 1: Multiple Care-of Addresses Registration
+
+ If the mobile node decides to act as a regular mobile node compliant
+ with [RFC3775], it sends a Binding Update without any Binding
+ Identifier mobility options. The receiver of the Binding Update
+ deletes all the bindings registered with a BID and registers only a
+ single binding for the mobile node. Note that the mobile node can
+ continue using the BID even if it has only a single binding that is
+ active.
+
+ Binding cache lookup is done based on the home address and BID
+ information if a BID is available. This is different from RFC 3775,
+ where only the home address is used for binding cache lookup.
+ Binding cache lookup is operated for either protocol signaling or
+ data packets. For protocol signaling such as a Binding Update, BID
+ should be always carried by a BID sub-option in a protocol signaling.
+ Therefore, a correspondent binding cache that matches the specified
+ BID MUST be found from the binding cache database. On the other
+ hand, for the data packets, no BID information is carried in a
+ packet. The binding cache lookup may involve policy or flow filters
+ to retrieve a correspondent BID per packet in cases where some policy
+ or flow filters are used to direct a certain packet or flow to a
+ particular care-of address. However, the binding cache lookup using
+ policy or flow filters is out of scope for this document. If no such
+
+
+
+Wakikawa, et al. Standards Track [Page 6]
+
+RFC 5648 MCoA October 2009
+
+
+ mechanism is available and no BID is found for a packet, a node
+ SHOULD use the binding that was last verified by receiving data
+ packets or signaling from the mobile node. In case the binding cache
+ lookup for data packets, using the combination of home address and
+ BID, does not return a valid binding cache entry, the home agent
+ SHOULD perform the lookup based on only the home address as described
+ in [RFC3775].
+
+ In any case, to avoid problems with upper-layer protocols and TCP in
+ particular, a single packet flow as identified by the 5-tuple SHOULD
+ only be sent to a single care-of address at a time.
+
+ The mobile node may return to the home link through one of its
+ interfaces. There are two options possible for the mobile node when
+ it returns home. Sections 5.5.1 and 5.6 describe the returning-home
+ procedures in more detail.
+
+ 1. The mobile node uses only the interface with which it attaches to
+ the home link and takes back full ownership of its HoA (home
+ address) on the home link. This is illustrated in Figure 2. It
+ de-registers all bindings with the home agent related to all
+ care-of addresses. The interfaces still attached to the visited
+ link(s) are no longer going to be receiving any encapsulated
+ traffic from the home agent. On the other hand, the mobile node
+ can continue communicating with the correspondent nodes from the
+ other interfaces attached to foreign links by using route
+ optimization. Even if the mobile node is attached to the home
+ link, it can still send Binding Updates for other active care-of
+ addresses (CoA1 and CoA2) to correspondent nodes. Since the
+ correspondent node has bindings, packets are routed from and to
+ each care-of address directly.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 7]
+
+RFC 5648 MCoA October 2009
+
+
+ +----+
+ | CN |
+ +--+-+
+ |
+ +---+------+ +----+
+ +------+ Internet |----------+ HA |
+ | +----+-----+ +--+-+
+ CoA2| | | Home Link
+ +--+--+ | --+---+------
+ | MN +--------+ |
+ +--+--+ CoA1 |
+ | |
+ +---------------------------+
+
+ Binding Cache Database:
+ home agent's binding
+ none
+ correspondent node's binding
+ binding [2001:db8::EUI BID1 care-of address1]
+ binding [2001:db8::EUI BID2 care-of address2]
+
+ Figure 2: Using Only an Interface Attached to the Home Link
+
+ 2. The mobile node may simultaneously use both the interface
+ attached to the home link and the interfaces still attached to
+ the visited link(s) as shown in Figure 3. There are two possible
+ topologies, depending on whether or not the home agent is the
+ only router on the home link. The operation of Neighbor
+ Discovery [RFC4861] is different in the two topologies. More
+ details can be found in Section 5.6. The home agent and the
+ correspondent node have the binding entries listed in Figure 3 in
+ their binding cache database in both topologies. The home agent
+ also knows that the mobile node is attached to the home link.
+ All the traffic from the Internet is intercepted by the home
+ agent first and routed to either the interface attached to the
+ home link or to one of the foreign links. How the home agent
+ decides to route a particular flow to the interface attached to
+ the home link or foreign link is out of scope for this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 8]
+
+RFC 5648 MCoA October 2009
+
+
+ Topology-a)
+ +----+
+ | CN |
+ +--+-+
+ |
+ +---+------+ +----+
+ +------+ Internet |----------+ HA |
+ | +----+-----+ +--+-+
+ CoA2| | | Home Link
+ +--+--+ | --+---+------
+ | MN +--------+ |
+ +--+--+ CoA1 |
+ | |
+ +---------------------------+
+
+
+ Topology-b)
+ +----+
+ | CN |
+ +--+-+
+ |
+ +---+------+ Router +----+
+ +------+ Internet |-------R | HA |
+ | +----+-----+ | +--+-+
+ CoA2| | | | Home Link
+ +--+--+ | --+-+-------+------
+ | MN +--------+ |
+ +--+--+ CoA1 |
+ | |
+ +---------------------------+
+
+ Binding Cache Database:
+ home agent's binding
+ binding [2001:db8::EUI BID1 care-of address1]
+ binding [2001:db8::EUI BID2 care-of address2]
+ correspondent node's binding
+ binding [2001:db8::EUI BID1 care-of address1]
+ binding [2001:db8::EUI BID2 care-of address2]
+
+ Figure 3: Simultaneous Home and Visited Link Operation
+
+ This specification keeps backwards compatibility with [RFC3775]. If
+ a receiver (either home agent or correspondent node) does not support
+ this specification, it does not understand the Binding Identifier
+ mobility option. The receiver skips the unknown mobility option
+ (i.e., the Binding Identifier mobility option) and processes the
+ Binding Update as defined in [RFC3775]. In order to keep backwards
+ compatibility with [RFC3775], when a mobile node sends a Binding
+
+
+
+Wakikawa, et al. Standards Track [Page 9]
+
+RFC 5648 MCoA October 2009
+
+
+ Update message with extensions described in this document, the
+ receiver needs to reflect the Binding Identifier mobility option in
+ the Binding Acknowledgement. If the mobile node finds no Binding
+ Identifier mobility options in the received Binding Acknowledgement,
+ it assumes the other end node does not support this specification.
+ In such case, the mobile node needs to fall back to the legacy
+ [RFC3775]-compliant mobile node. If it is the home registration, the
+ mobile node MAY try to discover another home agent that supports the
+ Binding Identifier mobility option for the home registration.
+
+4. Mobile IPv6 Extensions
+
+ This section summarizes the extensions to Mobile IPv6 that are
+ necessary to manage multiple bindings.
+
+4.1. Binding Cache Structure and Binding Update List
+
+ The BID is required to be stored in the binding cache and Binding
+ Update List structure.
+
+ The sequence number value MUST be shared among all the Binding Update
+ List entries related to Binding Updates sent to a particular home
+ agent or correspondent node. Whenever a mobile node sends either an
+ individual or a bulk Binding Update, the sequence number is
+ incremented. When a home agent receives an individual Binding
+ Update, it should update the sequence number for all the bindings for
+ a particular mobile node, with the sequence number in the received
+ Binding Update.
+
+4.2. Binding Update Message
+
+ This specification extends the Binding Update message with a new
+ flag. The flag is shown and described below.
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Sequence # |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ . .
+ . Mobility options .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4: Binding Update Message
+
+
+
+
+Wakikawa, et al. Standards Track [Page 10]
+
+RFC 5648 MCoA October 2009
+
+
+ Overwrite (O) flag
+
+ When this flag is set, all the binding cache entries for a mobile
+ node are replaced by new entries registering with this Binding
+ Update message. This flag is only used when the BID mobility
+ option is carried with the Binding Update.
+
+ Reserved
+
+ 6-bit Reserved field.
+
+4.3. Binding Identifier Mobility Option
+
+ The Binding Identifier mobility option is included in the Binding
+ Update, Binding Acknowledgement, Binding Refresh Request, and Care-of
+ Test Init and Care-of Test messages. The Binding Identifier mobility
+ option has an alignment requirement of 2n if the Care-of Address
+ field is not present. Otherwise, it has the alignment requirement of
+ 8n + 2.
+
+ 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Type = 35 | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Binding ID (BID) | Status |H| Reserved |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
+ + +
+ : IPv4 or IPv6 care-of address (CoA) :
+ + +
+ +---------------------------------------------------------------+
+
+ Figure 5: BID Mobility Option
+
+ Type
+
+ Type value for Binding Identifier is 35.
+
+ Length
+
+ 8-bit unsigned integer. Length of the option, in octets,
+ excluding the Type and Length fields. It MUST be set to either 4,
+ 8, or 20 depending on the Care-of Address field. When the care-of
+ address is not carried by this option, the length value MUST be
+ set to 4. If the IPv4 care-of address is stored in the Care-of
+ Address field, the length MUST be 8. Otherwise, the length value
+ MUST be set to 20 for IPv6 care-of addresses.
+
+
+
+
+Wakikawa, et al. Standards Track [Page 11]
+
+RFC 5648 MCoA October 2009
+
+
+ Binding ID (BID)
+
+ The BID that is assigned to the binding indicated by the care-of
+ address in the Binding Update or the Binding Identifier mobility
+ option. The BID is a 16-bit unsigned integer. The value of zero
+ is reserved and SHOULD NOT be used.
+
+ Status
+
+ The Status field is an 8-bit unsigned integer. When the Binding
+ Identifier mobility option is included in a Binding
+ Acknowledgement, this field overwrites the Status field in the
+ Binding Acknowledgement only for this BID. If this field is set
+ to zero, the receiver ignores this field and uses the registration
+ status stored in the Binding Acknowledgement message. The
+ receiver MUST ignore this field if the Binding Identifier mobility
+ option is not carried within either the Binding Acknowledgement or
+ the Care-of Test messages. The possible status codes are the same
+ as the status codes of the Binding Acknowledgement. This Status
+ field is also used to carry error information related to the
+ care-of address test in the Care-of Test message.
+
+ Simultaneous Home and Foreign Binding (H) flag
+
+ This flag indicates that the mobile node registers multiple
+ bindings to the home agent while it is attached to the home link.
+ This flag is valid only for a Binding Update sent to the home
+ agent.
+
+ Reserved
+
+ 7-bit Reserved field. The value MUST be initialized to zero by
+ the sender, and SHOULD be ignored by the receiver.
+
+ Care-of Address
+
+ If a Binding Identifier mobility option is included in a Binding
+ Update for the home registration, either IPv4 or IPv6 care-of
+ addresses for the corresponding BID can be stored in this field.
+ For the binding registration to correspondent nodes (i.e., route
+ optimization), only IPv6 care-of addresses can be stored in this
+ field. If no address is specified in this field, the length of
+ this field MUST be zero (i.e., not appear in the option). If the
+ option is included in any messages other than a Binding Update,
+ the length of this field MUST also be zero.
+
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 12]
+
+RFC 5648 MCoA October 2009
+
+
+4.4. New Status Values for Binding Acknowledgement
+
+ New status values for the Status field in a Binding Acknowledgement
+ are defined for handling the multiple care-of addresses registration:
+
+ MCOA NOTCOMPLETE (4)
+
+ In bulk registration, not all the Binding Identifier mobility
+ options were successfully registered. Some of them were rejected.
+ The error status value of the failed mobility option is
+ individually stored in the Status field of the Binding Identifier
+ mobility option.
+
+ MCOA RETURNHOME WO/NDP (5)
+
+ When a mobile node returns home, it MUST NOT use the Neighbor
+ Discovery Protocol (NDP) for the home address on the home link.
+ This is explained in more detail in Section 5.6.
+
+ MCOA MALFORMED (164)
+
+ Registration failed because the Binding Identifier mobility option
+ was not formatted correctly. This value is used in the following
+ cases:
+
+ * when the wrong length value is specified (neither 4, 8, nor 20)
+ in the Length field of the Binding Identifier mobility option.
+
+ * when a unicast routable address is not specified in the Care-of
+ Address field of the Binding Identifier mobility option.
+
+ * when a care-of address does not appear in the Care-of Address
+ field of the Binding Identifier mobility option stored in an
+ IPsec Encapsulating Security Payload (ESP)-protected Binding
+ Update.
+
+ MCOA NON-MCOA BINDING EXISTS (165)
+
+ Indicates that a bootstrapping multiple care-of addresses
+ registration was performed without the 'O' flag set.
+
+ MCOA UNKOWN COA (167)
+
+ Indicates that a Binding Identifier mobility option did not
+ include a Care-of Address field and that the receiver has no
+ record for the Binding ID indicated in the same option.
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 13]
+
+RFC 5648 MCoA October 2009
+
+
+ MCOA PROHIBITED (166)
+
+ Implies that the multiple care-of addresses registration is
+ administratively prohibited.
+
+ MCOA BULK REGISTRATION PROHIBITED (168)
+
+ Bulk binding registration is either not permitted or not
+ supported. Note that the bulk registration is an optional
+ procedure and might not be available on a home agent.
+
+ MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
+
+ Simultaneous home and foreign attachment is neither supported nor
+ permitted.
+
+5. Mobile Node Operation
+
+5.1. Management of Care-of Address(es) and Binding Identifier(s)
+
+ There are two cases when a mobile node might acquire several care-of
+ addresses. A mixture of the two cases is also possible. Note that a
+ mobile node can use BID regardless of the number of interfaces and
+ care-of addresses. Whether or not a mobile node uses BID is
+ determined by a local configuration.
+
+ 1. A mobile node is using several physical network interfaces and
+ acquires a care-of address on each of its interfaces.
+
+ 2. A mobile node uses a single physical network interface but
+ receives advertisements for multiple prefixes on the link to
+ which the interface is attached. This will result in the mobile
+ node configuring several global addresses on the interface from
+ each of the announced prefixes.
+
+ The difference between the above two cases is only in the number of
+ physical network interfaces and is therefore irrelevant in this
+ document. What is of significance is the fact that the mobile node
+ has several addresses it can use as care-of addresses.
+
+ A mobile node assigns a BID to each care-of address when it wants to
+ register them simultaneously with its home address. The BID MUST be
+ unique for a given home address. The value is an integer between 1
+ and 65535. A zero value SHOULD NOT be used as a BID. If a mobile
+ node has only one care-of address, the assignment of a BID is not
+ needed until it has multiple care-of addresses with which to
+ register, at which time all of the care-of addresses MUST be mapped
+ to BIDs.
+
+
+
+Wakikawa, et al. Standards Track [Page 14]
+
+RFC 5648 MCoA October 2009
+
+
+ When a mobile node registers a given BID for the first time, it MUST
+ include the Care-of Address field in the Binding Identifier mobility
+ option. For any subsequent registrations that either re-register or
+ de-register the same BID, the MN need not include the Care-of Address
+ field in the Binding Identifier mobility option.
+
+5.2. Binding Registration
+
+ For the multiple care-of addresses registration, the mobile node MUST
+ include a Binding Identifier mobility option(s) in the Binding Update
+ as shown in Figure 6.
+
+ When IPsec ESP is used for protecting the Binding Update, a care-of
+ address MUST be carried in an alternate Care-of Address mobility
+ option as described in [RFC4877]. However, in this specification,
+ the care-of address MUST be carried in the Care-of Address field of
+ the Binding Identifier mobility option. In order to save bits of the
+ Binding Update, the alternate Care-of Address option MUST NOT be
+ included.
+
+ For binding registration to a correspondent node, the mobile node
+ MUST have both active Home and Care-of Keygen tokens for Kbm (binding
+ management key; see Section 5.2.5 of [RFC3775]) before sending the
+ Binding Update. The care-of Keygen tokens MUST be maintained for
+ each care-of address that the mobile node wants to register to the
+ correspondent node. The Binding Update to the correspondent node is
+ protected by the Binding Authorization Data mobility option that is
+ placed after the Binding Identifier mobility option.
+
+ IPv6 header (src=Care-of Address, dst=Home Agent Address)
+ IPv6 Home Address Option
+ ESP Header*
+ Mobility header
+ Binding Update
+ Mobility Options
+ Binding Identifier mobility option
+ Binding Authorization mobility option+
+ (*) if necessary, for home registration
+ (+) if necessary, for route optimization
+
+ Figure 6: Binding Update for Binding Registration
+
+ If the mobile node wants to replace existing registered bindings on
+ the home agent with the single binding in the sent Binding Update, it
+ sets the 'O' flag. If the 'O' flag is not set, then the binding will
+ be added to existing bindings in the home agent. The single binding
+ will be registered with the assigned BID. Section 6.2 describes this
+ registration procedure in detail.
+
+
+
+Wakikawa, et al. Standards Track [Page 15]
+
+RFC 5648 MCoA October 2009
+
+
+5.3. Bulk Registration
+
+ Bulk registration is an optimization for binding multiple care-of
+ addresses to a home address using a single Binding Update. This is
+ very useful if the mobile node, for instance, does not want to send a
+ lot of signaling messages through an interface where the bandwidth is
+ scarce. This document specifies bulk registration only for the
+ mobile node's home registration. A mobile node performing bulk
+ registration with a correspondent node is out of scope.
+
+ To use bulk registration, the mobile node includes a Binding
+ Identifier mobility option for each BID it wants to register in the
+ same Binding Update message. As with single registrations (see
+ Section 5.1), the Care-of Address field is included for each BID
+ registered for the first time. This is shown in Figure 7. The rest
+ of the fields and options in the Binding Update (such as Lifetime,
+ Sequence Number, and the flags in the Binding Update) are common
+ across all care-of addresses.
+
+ IPv6 header (src=Care-of Address, dst=Home Agent Address)
+ IPv6 Home Address Option
+ ESP Header
+ Mobility header
+ Binding Update
+ Mobility Options
+ Binding Identifier1 (including Care-of Address)
+ Binding Identifier2 (including Care-of Address)
+ Binding Identifier3 (no Care-of Address)
+ Binding IdentifierN (no Care-of Address)
+
+ :
+
+ Figure 7: Binding Update for Bulk Registration
+
+ As with regular registrations, if the mobile node wants to replace
+ existing registered bindings on the home agent with the multiple
+ bindings in the sent Binding Update, it sets the 'O' flag in the
+ Binding Update; otherwise, the bindings are added to the existing
+ bindings in the home agent.
+
+5.4. Binding De-Registration
+
+ When a mobile node decides to delete all the bindings for its home
+ address, it sends a regular de-registration Binding Update with
+ lifetime set to zero as defined in [RFC3775]. The Binding Identifier
+ mobility option is not required.
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 16]
+
+RFC 5648 MCoA October 2009
+
+
+ If a mobile node wants to delete a particular binding(s) from its
+ home agent and correspondent nodes, the mobile node sends a Binding
+ Update with lifetime set to zero and includes a Binding Identifier
+ mobility option(s) with the BID(s) it wants to de-register. The
+ receiver will remove only the care-of address(es) that match(es) the
+ specified BID(s). Since de-registration attempts to remove a BID
+ that already exists, the Care-of Address field in each Binding
+ Identifier option can be omitted by the sender as defined in Section
+ 5.1.
+
+5.5. Returning Home with Complete Binding De-Registration: Using a
+ Single Interface
+
+ The mobile node may return to the home link by attaching to the home
+ link through one of its interfaces. When the mobile node wants to
+ return home, it should be configured with information on what
+ interface it needs to use.
+
+5.5.1. Using Only the Interface Attached to the Home Link
+
+ The mobile node returns home and de-registers all the bindings it has
+ with the home agent, as shown in Figure 2 and as defined in
+ [RFC3775]. After the de-registration step, all the packets routed by
+ the home agent are only forwarded to the interface attached to the
+ home link, even if there are other active interfaces attached to the
+ visited link(s). While the mobile node de-registers all the bindings
+ from the home agent, it may continue registering, to the
+ correspondent node, bindings for interfaces attached to visited links
+ as shown in Figure 2.
+
+5.5.2. Using Only the Interface Attached to the Visited Link
+
+ The mobile node returns home physically but shuts down the interface
+ attached to the home link. As a result, a mobile node does not
+ return home even though it attaches to the home link by one of the
+ interfaces. Before shutting down the interface, any binding for the
+ care-of address previously associated with the interface should be
+ deleted as defined in Section 5.4.
+
+ In this scenario, despite the fact that the mobile node is connected
+ to its home link, all of its traffic is sent and received via the
+ home agent and its foreign links.
+
+
+
+
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 17]
+
+RFC 5648 MCoA October 2009
+
+
+5.6. Returning Home: Simultaneous Home and Visited Link Operation
+
+5.6.1. Problems of Simultaneous Home and Foreign Attachments
+
+ The mobile node returns home and continues using all the interfaces
+ attached to both foreign and home links as shown in Figure 3.
+
+ In [RFC3775], the home agent intercepts packets meant for the mobile
+ node using proxy Neighbor Discovery [RFC4861] while the mobile node
+ is away from the home link. When the mobile node returns home, the
+ home agent deletes the binding cache and stops proxying for the home
+ address so that a mobile node can configure its home address on the
+ interface attached to the home link. In this specification, a mobile
+ node may return home and configure the home address on the interface
+ attached to the home link, but still use the interfaces attached to
+ the foreign links. In this case, a possible conflict arises when
+ both the home agent and the mobile node try to defend the home
+ address. If the home agent stops proxying for the home address, the
+ packets are always routed to the interface attached to the home link
+ and are never routed to the interfaces attached to the visited links.
+ Deployments making use of multiple care-of addresses are required to
+ avoid configuration conflict between the home agent and the mobile
+ node, while still allowing the simultaneous use of home and foreign
+ links. The following describes the mechanism for achieving this.
+
+5.6.2. Overview and Approach
+
+ The home agent MUST intercept all the packets meant for the mobile
+ node, whether or not the mobile node is attached to the home link,
+ and decide whether to send the traffic directly to the home address
+ on the link or tunnel to the care-of address.
+
+ Two scenarios are illustrated in Figure 3, depending on whether or
+ not the home agent is the only router at the home link. The
+ difference is on who defends the home address by (Proxy) Neighbor
+ Discovery on the home link.
+
+ 1. Mobile node defends the home address by the regular Neighbor
+ Discovery protocol (illustrated as topology-a in Figure 3). The
+ home agent is the only router on the home link. Therefore, the
+ home agent is capable of intercepting packets without relying on
+ the proxy Neighbor Discovery protocol, and the mobile node can
+ manage the neighbor cache entry of the home address on the home
+ link as a regular IPv6 node. However, there is one limitation of
+ this scenario. If a correspondent node is located at the home
+ link, the home agent may not intercept the packets destined to
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 18]
+
+RFC 5648 MCoA October 2009
+
+
+ the mobile node. These packets are routed only via the home
+ link, but this is the most optimal path for the mobile node to
+ communicate with nodes on the home link.
+
+ 2. If there are routers other than the home agent on the home link,
+ then it cannot be guaranteed that all packets meant for the
+ mobile node are routed to the home agent. In this case, the
+ mobile node MUST NOT operate the Neighbor Discovery protocol for
+ the home address on the home link. This allows the home agent to
+ keep using proxy Neighbor Discovery, and thus it keeps receiving
+ all the packets sent to the mobile node's home address. If the
+ home agent, according to its local policy, needs to deliver
+ packets to the mobile node over the home link, an issue arises
+ with respect to how the home agent discovers the mobile node's
+ link local address. This specification uses the Mobility Header
+ Link-Layer Address option defined in [RFC5568] in order to carry
+ the mobile node's link-layer address in the Binding Update.
+ Likewise, the mobile node would also know the link-layer address
+ of the default router address to send packets from the home link
+ without Neighbor Discovery. The link-layer address is used to
+ transmit packets from and to the mobile node on the home link.
+ The packets are transmitted without the Neighbor Discovery
+ protocol by constructing the link-layer header manually. This
+ operation is similar to Mobile IPv6 [RFC3775] when a mobile node
+ sends a de-registration Binding Update to the home agent's link-
+ layer address in the operation for returning home.
+
+5.6.3. Home Binding Support
+
+ When the home binding is used, the mobile node MUST send a
+ registering Binding Update with a Binding Identifier mobility option
+ with the 'H' flag set. The lifetime MUST be set to a non-zero
+ lifetime of the home binding, and the Care-of Address field MUST be
+ set to the home address. The mobile node registers only one home
+ binding at a time, even if it attaches to the home link by multiple
+ interfaces.
+
+ The mobile node SHOULD include the Mobility Header Link-Layer Address
+ option [RFC5568] to notify the mobile node's link-layer address to
+ the home agent, too. The option code of the Mobility Header Link-
+ Layer Address option MUST be set to '2' (link-layer address of the
+ mobile node). This link-layer address is required for the home agent
+ to send the Binding Acknowledgement and to forward the mobile node's
+ packet.
+
+ According to [RFC3775], the mobile node MUST start responding to
+ Neighbor Solicitation for its home address right after it sends the
+ de-registration Binding Update to the home agent. However, in this
+
+
+
+Wakikawa, et al. Standards Track [Page 19]
+
+RFC 5648 MCoA October 2009
+
+
+ specification, the mobile node MUST NOT respond to Neighbor
+ Solicitation before receiving a Binding Acknowledgement, since the
+ home agent may continue proxying for the home address. If the mobile
+ node receives [MCOA RETURNHOME WO/NDP (5)] status value in the
+ received Binding Acknowledgment, it MUST NOT respond to Neighbor
+ Solicitation even after the Binding Acknowledgement.
+
+ The management of the home binding is the same as the binding
+ management described in this specification. The home binding can be
+ included in a bulk binding registration (Section 5.3). The MN SHOULD
+ refresh the lifetime of the home binding by sending appropriate
+ Binding Updates as with any other binding.
+
+5.6.4. Sending Packets from the Home Link
+
+ o When the mobile node receives the Binding Acknowledgement with the
+ status value 'Binding Update Accepted' and the BID option, it can
+ configure its home address to the interface attached to the home
+ link and start operating Neighbor Discovery for the home address
+ on the home link. Packets can be transmitted from and to the
+ mobile node as if the mobile node were a regular IPv6 node.
+
+ o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in
+ the Binding Acknowledgement, it MUST NOT operate Neighbor
+ Discovery for the home address. When the mobile node sends
+ packets from the interface attached to the home link, it MUST
+ learn the link-layer address of the next hop (i.e., default router
+ of the mobile node). A mobile node learns the default router's
+ link-layer address from a Source Link-Layer Address option in
+ Router Advertisements. The mobile node sends packets directly to
+ the default router's link-layer address. This is done by
+ constructing the packet to include a link-layer header with the
+ learned link-layer address of the default router. The home agent
+ also forwards the packet to the mobile node on the home link by
+ using the mobile node's link-layer address. The link-layer
+ address SHOULD be cached when the home agent receives the
+ de-registration Binding Update message. Note that the default
+ router MUST NOT cache the mobile node's link-layer address in the
+ neighbor cache when it forwards the packet from the mobile node to
+ the home agent.
+
+5.6.5. Leaving from the Home Link
+
+ When the mobile node detaches from the home link, it SHOULD
+ immediately send a Binding Update for one of the active care-of
+ addresses with the 'H' flag unset. When the 'H' flag of the BID
+ option is unset in any Binding Update, the home agent stops
+ forwarding the mobile node's packets to the home link.
+
+
+
+Wakikawa, et al. Standards Track [Page 20]
+
+RFC 5648 MCoA October 2009
+
+
+5.7. Receiving Binding Acknowledgement
+
+ The verification of a Binding Acknowledgement is the same as Mobile
+ IPv6 (Section 11.7.3 of [RFC3775]). The operation for sending a
+ Binding Acknowledgement is described in Section 6.2.
+
+ If a mobile node includes a Binding Identifier mobility option in a
+ Binding Update with the 'A' flag set, a Binding Acknowledgement
+ SHOULD carry a Binding Identifier mobility option. According to
+ [RFC3775], the receiver of the Binding Update ignores unknown
+ mobility options and processes the Binding Update without the unknown
+ mobility option. Therefore, if no such mobility option is included
+ in the Binding Acknowledgement in response to a Binding Update for a
+ multiple care-of addresses registration, this indicates that the
+ originating node of the Binding Acknowledgement does not support
+ processing the Binding Identifier mobility option regardless of
+ status value. In such case, the receiver of the Binding Update may
+ create a regular binding. The mobile node then SHOULD no longer
+ attempt a multiple care-of addresses registration with that node. If
+ this occurs with home registration, the mobile node MAY attempt to
+ discover another home agent that supports the Binding Identifier
+ mobility option for the home registration.
+
+ If a Binding Identifier mobility option is present in the received
+ Binding Acknowledgement, the mobile node checks the Status field in
+ the option. If the status value in the Binding Identifier mobility
+ option is zero, the mobile node uses the value in the Status field of
+ the Binding Acknowledgement. Otherwise, it uses the value in the
+ Status field of the Binding Identifier mobility option.
+
+ If the status code is greater than or equal to 128, the mobile node
+ starts relevant operations according to the error code. Otherwise,
+ the mobile node assumes that the originator (home agent or
+ correspondent node) successfully registered the binding information
+ and BID for the mobile node.
+
+ o If the status value is [MCOA PROHIBITED], the mobile node MUST
+ stop registering multiple bindings with the node that sent the
+ Binding Acknowledgement.
+
+ o If the status value is [MCOA BULK REGISTRATION PROHIBITED], the
+ mobile node needs to stop using bulk registrations with the node
+ that sent the Binding Acknowledgement. It should assume that none
+ of the attempted registrations were successful.
+
+ o If [MCOA MALFORMED] is specified, it indicates that the Binding
+ Identifier mobility option is formatted wrong, presumably due to a
+ programming error or major packet corruption.
+
+
+
+Wakikawa, et al. Standards Track [Page 21]
+
+RFC 5648 MCoA October 2009
+
+
+ o If [MCOA NON-MCOA BINDING EXISTS] is specified, it means that
+ there is a non-MCoA binding entry in the receiver. The mobile
+ node MUST set 'O' flag so that all the registered bindings are
+ replaced by an MCoA registration as described in Section 5.9.
+
+ o If [MCOA UNKNOWN COA] is specified, it means that the mobile node
+ sent a Binding Identifier mobility option without a Care-of
+ Address field, but the receiver could not find an entry for the
+ BID indicated. If the mobile node is trying to de-register a BID,
+ it need not do anything further. If the mobile node is trying to
+ refresh a binding, it SHOULD send a Binding Identifier mobility
+ option including the Care-of Address field.
+
+5.8. Receiving Binding Refresh Request
+
+ The verification of a Binding Refresh Request is the same as in
+ Mobile IPv6 (Section 11.7.4 of [RFC3775]). The operation of sending
+ a Binding Refresh Request is described in Section 6.4.
+
+ If a mobile node receives a Binding Refresh Request with a Binding
+ Identifier mobility option, it indicates that the node sending the
+ Binding Refresh Request message is requesting that the mobile node
+ send a new Binding Update for the BID. The mobile node SHOULD then
+ send a Binding Update at least for the respective binding, as
+ described in Sections 5.2 and 5.3.
+
+5.9. Bootstrapping
+
+ When a mobile node bootstraps and registers multiple bindings for the
+ first time, it MUST set the 'O' flag in the Binding Update message.
+ If old bindings still exist at the home agent, the mobile node has no
+ knowledge of which bindings still exist at the home agent. This
+ scenario happens when a mobile node reboots and loses state regarding
+ the registrations. If the 'O' flag is set, all the bindings are
+ replaced by the new binding(s).
+
+6. Home Agent and Correspondent Node Operation
+
+6.1. Searching Binding Cache with Binding Identifier
+
+ If either a correspondent node or a home agent has multiple bindings
+ for a mobile node in their binding cache database, it can use any of
+ the bindings to communicate with the mobile node. This section
+ explains how to retrieve the desired binding for the binding
+ management. This document does not provide any mechanism to select
+ the suitable binding for forwarding data packets.
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 22]
+
+RFC 5648 MCoA October 2009
+
+
+ A node that is either a correspondent node or a home agent SHOULD use
+ both the home address and the BID as the search key of the binding
+ cache if it knows the corresponding BID (for example, when processing
+ signaling messages). In the example below, if a node searches the
+ binding with the home address and BID2, it gets binding2 for this
+ mobile node.
+
+ binding1 [2001:db8::EUI, care-of address1, BID1]
+ binding2 [2001:db8::EUI, care-of address2, BID2]
+ binding3 [2001:db8::EUI, care-of address3, BID3]
+
+ Figure 8: Searching the Binding Cache
+
+ The node learns the BID when it receives a Binding Identifier
+ mobility option. At that time, the node MUST look up its binding
+ cache database with the home address and the BID retrieved from the
+ Binding Update. If the node does not know the BID, it searches for a
+ binding with only the home address. In such a case, the first
+ matched binding is found. If the node does not desire to use
+ multiple bindings for a mobile node, it can simply ignore the BID.
+
+6.2. Processing Binding Update
+
+ If a Binding Update does not contain a Binding Identifier mobility
+ option, its processing is the same as in [RFC3775]. If the receiver
+ already has multiple bindings for the home address, it MUST replace
+ all the existing bindings with the received binding. If the
+ [RFC3775] Binding Update is for de-registration, the receiver MUST
+ delete all existing bindings from its binding cache.
+
+ If the Binding Update contains Binding Identifier mobility option(s),
+ it is first validated according to Section 9.5.1 of [RFC3775]. Then
+ the receiver processes the Binding Identifier mobility option(s) as
+ described in the following steps.
+
+ o The length value is examined. The length value MUST be either 4,
+ 8, or 20 depending on the Care-of Address field. If the length is
+ incorrect, the receiver MUST reject the Binding Update and return
+ the status value set to [MCOA MALFORMED].
+
+ o When the length value is either 8 or 20, the care-of address MUST
+ be present in the Binding Identifier mobility option. If the
+ unicast routable address [RFC3775] is not present in the Care-of
+ Address field, the receiver MUST reject the Binding Identifier
+ mobility option and return the status value set to [MCOA
+ MALFORMED].
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 23]
+
+RFC 5648 MCoA October 2009
+
+
+ o When multiple Binding Identifier mobility options are present in
+ the Binding Update, it is treated as bulk registration. If the
+ receiving node is a correspondent node, it MUST reject the Binding
+ Update and return the status value set to [MCOA BULK REGISTRATION
+ PROHIBITED] in the binding Acknowledgement.
+
+ o If the Lifetime field in the Binding Update is set to zero, the
+ receiving node deletes the binding entry that corresponds to the
+ BID in the Binding Identifier mobility option. If the receiving
+ node does not have an appropriate binding for the BID, it MUST
+ reject the Binding Update and send a Binding Acknowledgement with
+ status set to 133 [not home agent for this mobile node].
+
+ o If the 'O' flag is set in the de-registering Binding Update, it is
+ ignored. If the 'H' flag is set, the home agent stores a home
+ address in the Care-of Address field of the binding cache entry.
+ The home agent MUST follow the descriptions described in Section
+ 5.6.
+
+ o If the Lifetime field is not set to zero, the receiving node
+ registers a binding with the specified BID as a mobile node's
+ binding. The care-of address is obtained from the Binding Update
+ packet as follows:
+
+ * If the length value of the Binding Identifier mobility option
+ is 20, the care-of address is the IPv6 address copied from the
+ Care-of Address field in the Binding Identifier mobility
+ option.
+
+ * When the length value is 8, the address MUST be the IPv4 valid
+ address. How to obtain an IPv4 care-of address is described in
+ Section 8.
+
+ * When the length value is 4 and the Binding Identifier is
+ present in the binding cache, the receiving node MUST update
+ the associated binding entry. Otherwise, the receiving node
+ MUST reject that Binding Identifier mobility option and send a
+ Binding Acknowledgement with the status for that Binding
+ Identifier mobility option set to [MCOA UNKNOWN].
+
+ o Once the care-of address(es) have been retrieved from the Binding
+ Update, the receiving nodes create new binding(s).
+
+ * If the 'O' flag is set in the Binding Update, the receiving
+ node removes all the existing bindings and registers the
+ received binding(s).
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 24]
+
+RFC 5648 MCoA October 2009
+
+
+ * If the 'O' flag is unset in the Binding Update and the receiver
+ has a regular binding that does not have a BID for the mobile
+ node, it must not process the Binding Update. The receiver
+ should send a Binding Acknowledgement with status set to [MCOA
+ NON-MCOA BINDING EXISTS].
+
+ * If the receiver already has a binding with the same BID but
+ different care-of address, it MUST update the binding and
+ respond with a Binding Acknowledgement with status set to 0
+ [Binding Update accepted].
+
+ * If the receiver does not have a binding entry for the BID, it
+ registers a new binding for the BID and responds with a Binding
+ Acknowledgement with status set to 0 [Binding Update accepted].
+
+ If all the above operations are successfully completed and the 'A'
+ flag is set in the Binding Update, a Binding Acknowledgement
+ containing the Binding Identifier mobility options MUST be sent to
+ the mobile node. Whenever a Binding Acknowledgement is sent, all the
+ Binding Identifier mobility options stored in the Binding Update MUST
+ be copied to the Binding Acknowledgement except the Status field.
+ The Care-of Address field in each Binding Identifier mobility option,
+ however, MAY be omitted, because the mobile node can match a
+ corresponding Binding Update List entry using the BID.
+
+ When a correspondent node sends a Binding Acknowledgement, the status
+ value MUST always be stored in the Status field of the Binding
+ Acknowledgement and the Status field of the Binding Identifier
+ mobility option MUST always be set to zero.
+
+ When the home agent sends a Binding Acknowledgement, the status value
+ can be stored in the Status field of either a Binding Acknowledgement
+ or a Binding Identifier mobility option. If the status value is
+ specific to one of the bindings in the bulk registration, the status
+ value MUST be stored in the Status field in the corresponding Binding
+ Identifier mobility option. In this case, the Status field of the
+ Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so that
+ the receiver can examine the Status field of each Binding Identifier
+ mobility option for further operations. Otherwise, the Status field
+ of the Binding Identifier mobility option MUST be set to zero and the
+ home agent Status field of the Binding Acknowledgement is used.
+
+6.3. Sending a Binding Acknowledgement for Home Link Registration
+
+ The operations described in this section are related to returning
+ home with simultaneous use of home and foreign links.
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 25]
+
+RFC 5648 MCoA October 2009
+
+
+ o When the home agent sends the Binding Acknowledgement after
+ successfully processing the home binding registration, it MUST set
+ the status value to either 0 [Binding Update Accepted] or [MCOA
+ RETURNHOME WO/NDP (5)] in the Status field of the Binding
+ Acknowledgment, depending on home agent configuration at the home
+ link. The new values are:
+
+ * Binding Update Accepted (0): The Neighbor Discovery protocol is
+ permitted for the home address at the home link. This is the
+ regular returning home operation of [RFC3775].
+
+ * MCOA RETURNHOME WO/NDP (5): The Neighbor Discovery protocol is
+ prohibited for the home address at the home link.
+
+ The respective Binding Identifier mobility options need to be
+ included in the Binding Acknowledgement.
+
+ o If the Binding Update is rejected, the appropriate error value
+ MUST be set in the Status field. In this case, the home agent
+ operation is the same as in [RFC3775].
+
+ o Only if the home agent is the only router in the home link MAY it
+ turn off Neighbor Discovery for the requested home address and
+ respond with the [Binding Update Accepted] status value to the
+ mobile node. Since the mobile node will not reply to Neighbor
+ Solicitation for the home address before receiving the Binding
+ Acknowledgement, the home agent SHOULD use the link-layer address
+ carried by the Mobility Header Link-Layer Address option [RFC5568]
+ in the received Binding Update. After the completion of the home
+ binding registration, the mobile node starts regular Neighbor
+ Discovery operations for the home address on the home link. The
+ neighbor cache entry for the home address is created by the
+ regular exchange of Neighbor Solicitation and Neighbor
+ Advertisement.
+
+ o If the home agent is not the only router in the home link, the
+ home agent returns [MCOA RETURNHOME WO/NDP] value in the Status
+ field of the Binding Identifier mobility option. The home agent
+ learns the mobile node's link-layer address by receiving the
+ Mobility Header Link-Layer Address option carried by the Binding
+ Update. It stores the link-layer address as a neighbor cache
+ entry for the mobile node so that it can send the packets to the
+ mobile node's link-layer address.
+
+ o Note that the use of proxy Neighbor Discovery is an easier way to
+ intercept the mobile nodes' packets instead of IP routing in some
+ deployment scenarios. Therefore, even if a home agent is the only
+
+
+
+
+Wakikawa, et al. Standards Track [Page 26]
+
+RFC 5648 MCoA October 2009
+
+
+ router, it is an implementation and operational choice whether the
+ home agent returns [Binding Update Accepted] or [MCOA RETURNHOME
+ WO/NDP].
+
+ o If the BID option is not included in the Binding Acknowledgement,
+ the home agent might not recognize the home registration. The
+ home agent might have processed the home registration Binding
+ Update as a regular de-registration, as described in [RFC3775],
+ and deleted all the registered binding cache entries for the
+ mobile node. Thus, the mobile node SHOULD stop using the
+ interface attached to the foreign link and use only the interface
+ attached to the home link.
+
+6.4. Sending Binding Refresh Request
+
+ When a node (home agent or correspondent node) sends a Binding
+ Refresh Request for a particular binding created with the BID, the
+ node SHOULD include the Binding Identifier mobility option in the
+ Binding Refresh Request. The node MAY include multiple Binding
+ Identifier mobility options if there are multiple bindings that need
+ to be refreshed.
+
+6.5. Receiving Packets from Mobile Node
+
+ When a node receives packets with a Home Address destination option
+ from a mobile node, it MUST check that the care-of address that
+ appears in the Source Address field of the IPv6 header is equal to
+ one of the care-of addresses in the binding cache entry. If no
+ binding is found, the packets MUST be discarded. The node MUST also
+ send a Binding Error message as specified in [RFC3775]. This
+ verification MUST NOT be done for a Binding Update.
+
+7. Network Mobility Applicability
+
+ The binding management mechanisms are the same for a mobile host that
+ uses Mobile IPv6 and for a mobile router that is using the NEMO Basic
+ Support protocol [RFC3963]. Therefore, the extensions described in
+ this document can also be used to support a mobile router with
+ multiple care-of addresses. [RFC4980] contains an analysis of NEMO
+ multihoming.
+
+8. DSMIPv6 Applicability
+
+ Dual Stack Mobile IPv6 (DSMIPv6) [RFC5555] extends Mobile IPv6 to
+ register an IPv4 care-of address instead of the IPv6 care-of address
+ when the mobile node is attached to an IPv4-only access network. It
+ also allows the mobile node to acquire an IPv4 home address in
+
+
+
+
+Wakikawa, et al. Standards Track [Page 27]
+
+RFC 5648 MCoA October 2009
+
+
+ addition to an IPv6 home address for use with IPv4-only correspondent
+ nodes. This section describes how the multiple care-of addresses
+ registration works with IPv4 care-of and home addresses.
+
+8.1. IPv4 Care-of Address Registration
+
+ The mobile node can use the extensions described in the document to
+ register multiple care-of addresses, even if some of the care-of
+ addresses are IPv4 addresses.
+
+ Bulk registration MUST NOT be used for the initial binding
+ registration from an IPv4 care-of address. This is because the
+ Binding Update and Binding Acknowledgement exchange is used to detect
+ NAT on the path between the mobile node and the home agent. So the
+ mobile node needs to check for a NAT between each IPv4 care-of
+ address and the home agent.
+
+ The Binding Update MUST be sent to the IPv4 home agent address by
+ using UDP and IPv4 headers as shown in Figure 9. It is similar to
+ [RFC5555] except that the IPv4 care-of address option MUST NOT be
+ used when the BID mobility option is used.
+
+ IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
+ UDP Header
+ IPv6 header (src=V6HoA, dst=HAADDR)
+ ESP Header
+ Mobility header
+ -Binding Update
+ Mobility Options
+ - Binding Identifier (IPv4 CoA)
+ *V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [RFC5555]
+
+ Figure 9: Initial Binding Update for IPv4 Care-of Address
+
+ If a NAT is not detected, the mobile node can update the IPv4 care-of
+ address by using bulk registration. The mobile node can register the
+ IPv4 care-of address along with other IPv4 and IPv6 care-of
+ addresses. Figure 10 shows the Binding Update format when the mobile
+ node sends a Binding Update from one of its IPv6 care-of addresses.
+ If the mobile node sends a Binding Update from an IPv4 care-of
+ address, it MUST follow the format described in Figure 9. Note that
+ the IPv4 care-of address must be registered by a non-bulk binding
+ registration whenever it is changed.
+
+ As shown in Figure 9, the IPv4 care-of address will appear in the
+ Binding Identifier mobility option. The IPv4 Care-of Address
+ mobility option defined in [RFC5555] MUST always be omitted. The
+ receiver of the Binding Update message for an IPv4 care-of address
+
+
+
+Wakikawa, et al. Standards Track [Page 28]
+
+RFC 5648 MCoA October 2009
+
+
+ MUST treat the IPv4 address stored in the Binding Identifier mobility
+ option as the one in the IPv4 Care-of Address mobility option of
+ [RFC5555]. If the IPv4 address in the Binding Identifier mobility
+ option is different from one in the Source Address field in the IPv4
+ header of the Binding Update (i.e., V4ADDR in Figure 9), the source
+ address is used as an IPv4 care-of address. Otherwise, the IPv4
+ address in the Binding Identifier mobility option is used as an IPv4
+ care-of address.
+
+ IPv6 header (src=Care-of Address, dst=Home Agent Address)
+ IPv6 Home Address Option
+ ESP Header
+ Mobility header
+ -Binding Update
+ Mobility Options
+ - Binding Identifier (IPv6/v4 CoA)
+ - Binding Identifier (IPv6/v4 CoA)
+ - ...
+
+ Figure 10: Binding Bulk Registration for an IPv4 Care-of Address
+
+ When the home agent returns a Binding Acknowledgement for the IPv4
+ care-of address registration, it SHOULD NOT use the IPv4 Address
+ Acknowledgement mobility option and SHOULD use only the Binding
+ Identifier mobility option. The registration status for the IPv4
+ care-of address is stored in the Status field of the Binding
+ Identifier mobility option. However, if the home agent needs to
+ store the status value specially defined for the IPv4 Address
+ Acknowledgement mobility option, it MUST store the status value in
+ the IPv4 Address Acknowledgement mobility option and MUST NOT store
+ it in the Binding Identifier mobility option. In such case, the home
+ agent MUST include both the IPv4 Address Acknowledgement mobility
+ option and the Binding Identifier mobility option.
+
+8.2. IPv4 Home Address Management
+
+ When the mobile node wants to configure an IPv4 home address in
+ addition to the IPv6 home address, it can request one using the IPv4
+ Home Address option in the Binding Update. If the home agent accepts
+ the Binding Update, the mobile node can now register multiple care-of
+ addresses for the IPv4 home address in addition to the IPv6 home
+ address. The mobile node MUST always use the IPv4 Home Address
+ mobility option for any purposes of the IPv4 home address management.
+ The same set of care-of addresses will be registered for both IPv6
+ and IPv4 home addresses. The mobile node cannot bind a different set
+ of care-of addresses to each home address.
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 29]
+
+RFC 5648 MCoA October 2009
+
+
+ According to [RFC5555], the home agent includes the IPv4 Address
+ Acknowledgement option in the Binding Acknowledgement only if the
+ mobile node had requested an IPv4 home address in the corresponding
+ Binding Update. The IPv4 Address Acknowledgement option MUST be
+ present before any Binding Identifier mobility option. The Status
+ field of the IPv4 Address Acknowledgement option contains only the
+ error code defined in Section 3.2.1 of [RFC5555]. The home agent
+ MUST always include the IPv4 Address Acknowledgement mobility option
+ in the Binding Acknowledgement for the IPv4 home address
+ registration.
+
+9. IPsec and IKEv2 Interaction
+
+ Mobile IPv6 [RFC3775] and the NEMO protocol [RFC3963] require the use
+ of IPsec to protect signaling messages, including Binding Updates,
+ Binding Acknowledgements, and return routability messages. IPsec may
+ also be used to protect all tunneled data traffic. The Mobile IPv6-
+ IKEv2 specification [RFC4877] specifies how IKEv2 can be used to set
+ up the required IPsec security associations. The following
+ assumptions were made in [RFC3775], [RFC3963], and [RFC4877] with
+ respect to the use of IKEv2 and IPsec.
+
+ o There is only one primary care-of address per mobile node.
+
+ o The primary care-of address is stored in the IPsec database for
+ tunnel encapsulation and decapsulation.
+
+ o When the home agent receives a packet from the mobile node, the
+ source address is verified against the care-of address in the
+ corresponding binding cache entry. If the packet is a reverse-
+ tunneled packet from the mobile node, the care-of address check is
+ done against the source address on the outer IPv6 header. The
+ reverse-tunneled packet could either be a tunneled Home Test Init
+ message or tunneled data traffic to the correspondent node.
+
+ o The mobile node runs IKEv2 (or IKEv1) with the home agent using
+ the care-of address. The IKE SA is based on the care-of address
+ of the mobile node.
+
+ The above assumptions may not be valid when multiple care-of
+ addresses are used by the mobile node. In the following sections,
+ the main issues with the use of multiple care-of addresses with IPsec
+ are addressed.
+
+
+
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 30]
+
+RFC 5648 MCoA October 2009
+
+
+9.1. Use of Care-of Address in the IKEv2 Exchange
+
+ For each home address for which the mobile node sets up security
+ associations with the home agent, the mobile node must pick one
+ care-of address and use that as the source address for all IKEv2
+ messages exchanged to create and maintain the IPsec security
+ associations associated with the home address. The resultant IKEv2
+ security association is created based on this care-of address.
+
+ If the mobile node needs to change the care-of address, it just sends
+ a Binding Update with the care-of address it wants to use, with the
+ corresponding Binding Identifier mobility option, and with the 'K'
+ bit set. This will force the home agent to update the IKEv2 security
+ association to use the new care-of address. If the 'K' bit is not
+ supported on the mobile node or the home agent, the mobile node MUST
+ re-establish the IKEv2 security association with the new care-of
+ address. This will also result in new IPsec security associations
+ being set up for the home address.
+
+9.2. Transport Mode IPsec-Protected Messages
+
+ For Mobile IPv6 signaling message protected using IPsec in transport
+ mode, the use of a particular care-of address among multiple care-of
+ addresses does not matter for IPsec processing.
+
+ The home agent processes Mobile Prefix Discovery messages with the
+ same rules of data packets described in Section 6.5.
+
+9.3. Tunnel Mode IPsec-Protected Messages
+
+ The use of IPsec in tunnel mode with multiple care-of addresses
+ introduces a few issues that require changes to how the mobile node
+ and the home agent send and receive tunneled traffic. The route
+ optimization mechanism described in [RFC3775] mandates the use of
+ IPsec protection in tunnel mode for the Home Test Init and Home Test
+ messages. The mobile node and the home agent may also choose to
+ protect all reverse-tunneled payload traffic with IPsec in tunnel
+ mode. The following sections address multiple care-of address
+ support for these two types of messages.
+
+9.3.1. Tunneled Home Test Init and Home Test Messages
+
+ The mobile node MAY use the same care-of address for all Home Test
+ Init messages sent reverse tunneled through the home agent. The
+ mobile node may use the same care-of address irrespective of which
+ correspondent node the Home Test Init message is being to. RFC 3775
+ requires the home agent to verify that the mobile node is using the
+ care-of address that is in the binding cache entry when it receives a
+
+
+
+Wakikawa, et al. Standards Track [Page 31]
+
+RFC 5648 MCoA October 2009
+
+
+ reverse-tunneled Home Test Init message. If a different address is
+ used as the source address, the message is silently dropped by the
+ home agent. This document requires the home agent implementation to
+ decapsulate and forward the Home Test Init message as long as the
+ source address is one of the care-of addresses in the binding cache
+ entry for the mobile node.
+
+ When the home agent tunnels a Home Test message to the mobile node,
+ the care-of address used in the outer IPv6 header is not relevant to
+ the Home Test message. So regular IPsec tunnel encapsulation with
+ the care-of address known to the IPsec implementation on the home
+ agent is sufficient.
+
+9.3.2. Tunneled Payload Traffic
+
+ When the mobile node sends and receives multiple traffic flows
+ protected by IPsec to different care-of addresses, the use of the
+ correct care-of address for each flow becomes important. Support for
+ this requires the following two considerations on the home agent.
+
+ o When the home agent receives a reverse-tunneled payload message
+ protected by IPsec in tunnel mode, the source address used in the
+ outer IPv6 header is irrelevant to IPsec, since the tunnel mode
+ security association is based on the addresses in the inner IPv6
+ header. Therefore, the same IPsec security association can be
+ used for payload traffic tunneled from any of the care-of
+ addresses. Note that the care-of address used in the reverse-
+ tunneled traffic can be different from the care-of address used as
+ the source address in the IKEv2 exchange. However, this does not
+ cause an issue due to the above-mentioned reason.
+
+ o For tunneled IPsec traffic from the home agent to the mobile node,
+ the IPsec implementation on the home agent will not be aware of
+ which care-of address to use when performing IPsec tunnel
+ encapsulation. The Mobile IP stack on the home agent, based on
+ the binding cache entries created by the mobile node, knows to
+ which care-of address the packet belonging to a particular flow
+ needs to be tunneled. The destination address for the outer IP
+ header must either be conveyed dynamically per packet to the IPsec
+ stack when it performs the encapsulation or the Mobile IPv6 stack
+ must get access to the packet after IPsec processing is done and
+ modify the destination address. The first option requires changes
+ to the IPsec implementation. In the second option, there is a
+ need for special processing in the forwarding function to replace
+ the destination address on the outer header with the correct
+ care-of address. The exact technique to achieve the above is
+ implementation specific.
+
+
+
+
+Wakikawa, et al. Standards Track [Page 32]
+
+RFC 5648 MCoA October 2009
+
+
+10. Security Considerations
+
+ The security considerations for securing the Binding Update and
+ Binding Acknowledgement messages with multiple care-of addresses are
+ very similar to the security considerations for securing the Binding
+ Update and Binding Acknowledgement. Please see [RFC3775] for more
+ information. The Binding Update and Binding Acknowledgement messages
+ with multiple care-of addresses are securely exchanged as described
+ in [RFC3775], [RFC4877], and Section 9 of this document. Additional
+ security considerations are described below.
+
+ With simultaneous binding support, it is possible for a malicious
+ mobile node to successfully bind a number of victims' addresses as
+ valid care-of addresses for the mobile node with its home agent.
+ Once these addresses have been bound, the malicious mobile node can
+ perform a re-direction attack by instructing the home agent (e.g.,
+ setting filtering rules to direct a large file transfer) to tunnel
+ packets to the victims' addresses. Such risk is highlighted in
+ [MIP6ANALYSIS]. These attacks are possible because the care-of
+ addresses sent by the mobile node in the Binding Update messages are
+ not verified by the home agent, i.e., the home agent does not check
+ if the mobile node is at the care-of address at which it claims to
+ be. The security model for Mobile IPv6 assumes that there is a trust
+ relationship between the mobile node and its home agent. Any
+ malicious attack by the mobile node is traceable by the home agent.
+ This acts as a deterrent for the mobile node to launch such attacks.
+
+ Although such a risk exists in Mobile IPv6, the risk level is
+ increased when simultaneous multiple care-of address bindings are
+ performed. In Mobile IPv6, a mobile node can only have a single
+ care-of address binding per home address at a given time. However,
+ for simultaneous multiple care-of address bindings, a mobile node can
+ have more than one care-of address binding per home address at a
+ given time. This implies that a mobile node using simultaneous
+ binding support can effectively bind more than a single victim's
+ address. Another difference is the degree of risk involved. In the
+ single care-of address binding case, once the re-direction attack is
+ initiated, a malicious mobile node would be unable to use its home
+ address for communications (such as to receive control packets
+ pertaining to the file transfer). However, in the simultaneous
+ binding support case, a malicious mobile node could bind a valid
+ care-of address in addition to multiple victims addresses. This
+ valid care-of address could then be used by the malicious mobile node
+ to set up flow filtering rules at its home agent, thereby controlling
+ and/or launching new re-direction attacks.
+
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 33]
+
+RFC 5648 MCoA October 2009
+
+
+ Thus, in view of such risks, it is advisable for a home agent to
+ employ some form of care-of address verification mechanism before
+ using the care-of addresses as a valid routing path to a mobile node.
+ These mechanisms are out of scope for this document.
+
+ In the binding registration of Mobile IPv6, a care-of address is
+ always verified by its reachability by a home agent. This
+ reachability test may decrease the above risks. However, when bulk
+ registration is used, a home agent cannot verify reachability of
+ care-of addresses carried in a Binding Identifier mobility option.
+ Therefore, the home agent can choose to reject bulk registration by
+ using [MCOA BULK REGISTRATION PROHIBITED] in a Binding
+ Acknowledgement. Alternatively, when a mobile node first registers a
+ care-of address, it uses the individual Binding Updates for the first
+ appeared care-of address. During the initial binding registration, a
+ home agent can verify the address reachability for that given care-of
+ address. After that, the mobile node uses bulk registration to
+ refresh the care-of address.
+
+11. IANA Considerations
+
+ The following Extension Types have been assigned by IANA:
+
+ o Binding Identifier mobility option type: (35) has been assigned
+ from the same space as the mobility option in [RFC3775].
+
+ o New Successful Status of Binding Acknowledgement: These status
+ codes have been assigned from the same space as the Binding
+ Acknowledgement status codes in [RFC3775].
+
+ * MCOA NOTCOMPLETE (4)
+
+ * MCOA RETURNHOME WO/NDP (5)
+
+ o New Unsuccessful Status of Binding Acknowledgement: These status
+ codes have also been assigned from the same space as the Binding
+ Acknowledgement status codes in [RFC3775].
+
+ * MCOA MALFORMED (164)
+
+ * MCOA NON-MCOA BINDING EXISTS (165)
+
+ * MCOA PROHIBITED (166)
+
+ * MCOA UNKNOWN COA (167)
+
+ * MCOA BULK REGISTRATION PROHIBITED (168)
+
+
+
+
+Wakikawa, et al. Standards Track [Page 34]
+
+RFC 5648 MCoA October 2009
+
+
+ * MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (169)
+
+12. Acknowledgements
+
+ Ryuji Wakikawa and Thierry Ernst are grateful to Keio University for
+ its initial support on this specification at the time when they were
+ working there. In addition, the authors would like to thank Masafumi
+ Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Martti Kuparinen,
+ Romain Kuntz, Benjamin Lim, Heikki Mahkonen, Nicolas Montavont, and
+ Chan-Wah Ng for their discussions and inputs. Thanks to Susumu
+ Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke
+ Uehara, Masafumi Watari, and Jun Murai for earlier work on this
+ subject.
+
+13. References
+
+13.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+ "Neighbor Discovery for IP version 6 (IPv6)", RFC
+ 4861, September 2007.
+
+ [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
+ Support in IPv6", RFC 3775, June 2004.
+
+ [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation
+ with IKEv2 and the Revised IPsec Architecture", RFC
+ 4877, April 2007.
+
+ [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
+ Thubert, "Network Mobility (NEMO) Basic Support
+ Protocol", RFC 3963, January 2005.
+
+ [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack
+ Hosts and Routers", RFC 5555, June 2009.
+
+ [RFC5568] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC
+ 5568, July 2009.
+
+13.2. Informative References
+
+ [MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K.
+ Kuladinithi, "Motivations and Scenarios for Using
+ Multiple Interfaces and Global Addresses", Work in
+ Progress, May 2008.
+
+
+
+Wakikawa, et al. Standards Track [Page 35]
+
+RFC 5648 MCoA October 2009
+
+
+ [RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis
+ of Multihoming in Network Mobility Support", RFC 4980,
+ October 2007.
+
+ [MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
+ Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
+ Work in Progress, May 2008.
+
+ [RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related
+ Terminology", RFC 3753, June 2004.
+
+ [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support
+ Terminology", RFC 4885, July 2007.
+
+Authors' Addresses
+
+ Ryuji Wakikawa (Editor)
+ TOYOTA InfoTechnology Center Co., Ltd.
+
+ EMail: ryuji.wakikawa@gmail.com (ryuji@jp.toyota-itc.com)
+
+
+ Vijay Devarapalli
+ Wichorus
+
+ EMail: vijay@wichorus.com
+
+
+ George Tsirtsis
+ Qualcomm
+
+ EMail: Tsirtsis@gmail.com
+
+
+ Thierry Ernst
+ INRIA
+
+ EMail: thierry.ernst@inria.fr
+
+
+ Kenichi Nagami
+ INTEC NetCore Inc.
+
+ EMail: nagami@inetcore.com
+
+
+
+
+
+
+
+Wakikawa, et al. Standards Track [Page 36]
+