Monami6 Working Group R. Wakikawa (Editor) Internet-Draft Keio University Intended status: Standards Track T. Ernst Expires: July 31, 2008 INRIA K. Nagami INTEC NetCore V. Devarapalli Azaire Networks January 28, 2008 Multiple Care-of Addresses Registration draft-ietf-monami6-multiplecoa-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 31, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Wakikawa (Editor), et al. Expires July 31, 2008 [Page 1] Internet-Draft MCoA January 2008 Abstract According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, termed 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 access media simultaneously, in which case multiple active IPv6 care-of addresses would be assigned to the mobile node. We thus propose Mobile IPv6 extensions designed to register multiple care-of addresses bound to a single Home Address instead of the sole primary care-of address. For doing so, a new identification number must be carried in each binding for the receiver to distinguish between the bindings corresponding to the same Home Address. Those extensions are targeted to NEMO (Network Mobility) Basic Support as well as to Mobile IPv6. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 2] Internet-Draft MCoA January 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 9 4.1. Binding Cache Structure and Binding Update List . . . . . 9 4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 9 4.2.1. Binding Identifier Mobility Option . . . . . . . . . . 9 4.3. New Status Values for Binding Acknowledgment . . . . . . . 11 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 13 5.1. Management of Care-of Addresses and Binding Identifier . . 13 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 13 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 14 5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 15 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 16 5.6.1. Using only Interface attached to the Home Link . . . . 16 5.6.2. Using only Interface attached to the Visited Link . . 16 5.6.3. Simultaneous Home and Visited Link Operation . . . . . 17 5.7. Receiving Binding Acknowledgment . . . . . . . . . . . . . 19 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 20 5.9. Sending Packets to Home Agent . . . . . . . . . . . . . . 20 5.10. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 21 6. Home Agent and Correspondent Node Operation . . . . . . . . . 22 6.1. Searching Binding Cache with Binding Identifier . . . . . 22 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 22 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 23 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 25 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 26 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 27 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 28 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 28 8.2. IPv4 HoA Management . . . . . . . . . . . . . . . . . . . 29 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 30 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 30 9.2. Transport Mode IPsec protected messages . . . . . . . . . 31 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 31 9.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 31 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 32 Wakikawa (Editor), et al. Expires July 31, 2008 [Page 3] Internet-Draft MCoA January 2008 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13.1. Normative References . . . . . . . . . . . . . . . . . . . 35 13.2. Informative References . . . . . . . . . . . . . . . . . . 36 Appendix A. Example Configurations . . . . . . . . . . . . . . . 37 Appendix B. Changes From Previous Versions . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . . . 44 Wakikawa (Editor), et al. Expires July 31, 2008 [Page 4] Internet-Draft MCoA January 2008 1. Introduction A mobile node may use various types of network interfaces to obtain durable and wide area network connectivity. The assumed scenarios and motivations for multiple points of attachment, and benefits for doing it are discussed at large in [ID-MOTIVATION]. IPv6 [RFC-2460] conceptually allows a node to have several addresses on a given interface. Consequently, Mobile IPv6 [RFC-3775] has mechanisms to manage multiple ``Home Addresses'' based on home agent's managed prefixes such as mobile prefix solicitation and mobile prefix advertisement. But assigning a single Home Address to a node is more advantageous than assigning multiple Home Addresses because applications do not need to be aware of the multiplicity of Home Addresses. If multiple home addresses are available, applications must reset the connection information when the mobile node changes its active network interface (i.e. change the Home Address). According to the Mobile IPv6 specification, a mobile node is not allowed to register multiple care-of addresses bound to a single Home Address. Since NEMO Basic Support [RFC-3963] is based on Mobile IPv6, the same issues apply to a mobile node acting as a mobile router. Multihoming issues pertaining to mobile nodes operating Mobile IPv6 and mobile routers operating NEMO Basic Support are respectively discussed [ID-MIP6ANALYSIS] and [RFC-4980] in Monami6 and NEMO Working Group. In this document, we thus propose a new identification number called Binding Identification (BID) number for each binding cache entry to accommodate multiple bindings registration. The mobile node notifies the BID to both its Home Agent and correspondent nodes by means of a Binding Update. Correspondent nodes and the home agent record the BID into their binding cache. The Home Address thus identifies a mobile node itself whereas the BID identifies each binding registered by a mobile node. By using the BID, multiple bindings can then be distinguished. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 5] Internet-Draft MCoA January 2008 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 [RFC-2119]. Terms used in this draft are defined in [RFC-3775], [RFC-3753] and [RFC-4885]. In addition or in 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 BID allows a mobile node to register multiple binding cache entries for a given Home Address. The BID MUST be unique for a binding to a specific care-of address for a given home address and care-of address pair. The zero value and a negative value MUST NOT be used. Each BID is generated and managed by a mobile node. After being generated by the 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. Bulk Registration A mobile node can register multiple bindings at once by sending a single binding update. The mobile node does not necessarily put all the available care-of addresses in the binding update, but several care-of addresses. A mobile node can also replace all the bindings available at the home agent with the new bindings by using the bulk registration. The bulk registration is supported only for home registration and de-registration as explained in Section 5.5. A mobile node MUST NOT perform bulk registration with correspondent nodes. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 6] Internet-Draft MCoA January 2008 3. Protocol Overview A new identification number (BID) is introduced to distinguish multiple bindings pertaining to the same Home Address. Once a mobile node gets several IPv6 global addresses on one or more of its interfaces, it can register these addresses with its home agent. If the mobile node wants to register multiple bindings, it MUST generate a BID for each care-of address and record the BID into the binding update list. A mobile node can manipulate each binding independently by using a BID. The mobile node then registers its care-of addresses by sending a Binding Update with a Binding Identifier mobility option. The BID MUST be included in the Binding Identifier mobility option. After receiving such Binding Update and 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. Even if there is already an entry for the mobile node's home address, the home agent MUST register a new binding entry for the BID stored in the Binding Identifier mobility option. The mobile node registers multiple care-of addresses either independently in individual Binding Updates or multiple at once in a single Binding Update. If the mobile host wishes to register its binding with a correspondent node, it must perform return routability operations. The mobile host MUST manage a Care-of Keygen Token per care-of address. The mobile host exchanges CoTI and CoT for the corresponding care-of addresses if necessary. When the mobile host registers several care-of addresses to a correspondent node, it uses the same BID as the one generated for the home registration's bindings. The binding registration step is the same as for the home registration except for calculating authenticator. For protocol simplicity, the bulk registration is not supported for correspondent nodes in this document. Return Routability introduced in [RFC-3775] cannot be easily extended to verify multiple care-of addresses stored in a single Binding Update. If the mobile node decides to act as a regular mobile node compliant with [RFC-3775] , it just sends a Binding Update without any Binding Identifier mobility options. The receiver of the Binding Update deletes all the bindings registering with a BID and registers only a single binding for the mobile node. Note that the mobile node can continue using BID even if only a single binding is active at some time. When a home agent and a correspondent node check the binding cache database for the mobile node, they search a corresponding binding entry with the pair of Home Address and BID of the desired binding. If necessary, a mobile node can use policy and filter information to Wakikawa (Editor), et al. Expires July 31, 2008 [Page 7] Internet-Draft MCoA January 2008 look up the best binding per sessions, flow, packets, but this is out of scope in this document. If there is no desired binding, it searches the binding cache database with the Home Address as specified in Mobile IPv6. The first matched binding entry may be found, although this is implementation dependent. The mobile node may return to the home link through one its interfaces. There are three options possible for the mobile node when its returns home. 1. The mobile node uses only the interface with which it attaches to the home link. It de-registers all bindings related to all care-of addresses. The interfaces which are still attached to the visited link are not used. 2. The mobile node uses only the interfaces still attached to the visited link. The interface with which the mobile node attaches to the home link is not used. 3. The mobile node may simultaneously use both the interface attached to the home link and the interfaces still attached to the visited links. Section 5.6 describes the returning home procedures in more detail. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 8] Internet-Draft MCoA January 2008 4. Mobile IPv6 Extensions This section summarizes the changes to Mobile IPv6 necessary to manage multiple bindings bound to a same Home Address. 4.1. Binding Cache Structure and Binding Update List The BID is required in the binding cache and binding update list structure. 4.2. Message Format Changes 4.2.1. Binding Identifier Mobility Option The Binding Identifier mobility option is included in the Binding Update, Binding Acknowledgment, Binding Refresh Request, and Care-of Test Init and Care-of Test message. 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 = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding ID (BID) | Status |C|O|H|D|Resrvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ + + : IPv4 or IPv6 care-of address (CoA) : + + +---------------------------------------------------------------+ Figure 1: BID Mobility Option Type Type value for Binding Identifier is TBD Length 8-bit unsigned integer. Length of the option, in octets, excluding the Type and Length fields. MUST be set to 4 when the 'C' flag is unset. Otherwise, the Length value MUST be set to either 8 or 20 depending on the 'D' (DSMIPv6) flag. Binding ID (BID) Wakikawa (Editor), et al. Expires July 31, 2008 [Page 9] Internet-Draft MCoA January 2008 The BID which is assigned to the binding carried in the Binding Update with this mobility option. BID is 16-bit unsigned integer. A value of zero is reserved. Status When the Binding Identifier mobility option is included in a Binding Acknowledgment, this field overwrites the status field correspondent to each binding in the Binding Acknowledgment. If this field is zero, the receiver MUST use the registration status stored in the Binding Acknowledgment message. This Status field can be used to carry error information for a Care-of Test message. The status is 8-bit unsigned integer. The possible status codes are the same as the status codes of Binding Acknowledgment. Care-of address (C) flag When this flag is set, a mobile node can store a Care-of Address corresponding to the BID in the Binding Identifier mobility option. This flag MUST be used whenever a mobile node sends multiple care-of addresses in a single Binding Update, i.e. bulk registration. It MUST be also used for the independent binding registration as a substitute for an alternate care-of address option. This flag is valid only for binding update sent to the home agent. Overwrite (O) flag When this flag is set, a mobile node requests a home agent to replace all the bindings to binding entries stored in a Binding Update. This flag is valid only for binding update sent to the home agent. Simultaneous Home and Foreign Binding (H) flag This flag indicates that the mobile node registers multiple bindings to the home agent while is attached to the home link. This flag is valid only for a binding update sent to the home agent. DSMIPv6 (D) flag This flag indicates that the care-of address field MUST be set to IPv4 care-of address. If this flag is set, the Care-of Address field MUST be used. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 10] Internet-Draft MCoA January 2008 Reserved 5 bits Reserved field. Reserved field MUST be set with all 0. Care-of Address This field has the variable length depending on the specified flags. When C flag is set and D flag is unset, an IPv6 Care-of Address matched to the BID is stored in this field. If both C and D flags are set, an IPv4 Care-of Address is stored. This field MUST NOT be used if a Binding Identifier mobility option is included in any other messages than a Binding Update message. The receiver SHOULD ignore this field if the mobility option is not presented in Binding Update message. 4.3. New Status Values for Binding Acknowledgment New status values for the status field in a Binding Acknowledgment are defined for handling the multiple Care-of Addresses registration: MCOA NOTCOMPLETE (TBD < 128) In bulk registration, not all the binding identifier mobility option are successfully registered. Some of them are 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 (TBD < 128) When a mobile node returns home, it MUST NOT use NDP for the home address on the home link. The detail can be found in Section 5.6 MCOA MALFORMED (TBD more than 128) Registration failed because Binding Identifier mobility option is not formed correctly. MCOA BID CONFLICT (TBD more than 128) The home agent cannot cache both a regular binding and a BID extended binding simultaneously. It returns this status value when the received binding conflicts with the existing binding cache entry(ies). Wakikawa (Editor), et al. Expires July 31, 2008 [Page 11] Internet-Draft MCoA January 2008 MCOA PROHIBITED(TBD more than 128) It implies the multiple care-of address registration is administratively prohibited. MCOA BULK REGISTRATION NOT SUPPORTED (TBD more than 128) The bulk binding registration is not supported. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 12] Internet-Draft MCoA January 2008 5. Mobile Node Operation 5.1. Management of Care-of Addresses and Binding Identifier There are two cases when a mobile node has several Care-of Addresses. Note that a mixture of the two cases are possible. 1. A mobile node uses 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 multiple prefixes are announced on the link the interface is attached to. Several global addresses are configured on this interface for each of the announced prefixes. The difference between the above two cases is only a number of physical network interfaces and therefore does not matter in this document. The Identification number is used to identify a binding. To implement this, a mobile node MAY assign an identification number for each care-of addresses. How to assign an identification number is implementation specific, but the following rules MUST be followed. 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 binding to a specific care-of address for a given home address and care-of address pair. The value should be generated from a value comprised between 1 to 65535. Zero and negative values MUST 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 to register with. 5.2. Return Routability: Sending CoTI and Receiving CoT When a mobile node wants to register bindings to a Correspondent Node, it MUST have the valid care-of Keygen token per care-of address, while the HoTI and HoT can be exchanged only once for a Home Address. If the Mobile Node manages bindings with BID, it MUST include a Binding Identifier mobility option in a Care-of Test Init message. It MUST NOT set the any flags in the mobility option. The receiver (i.e. correspondent node) will calculate a care-of Keygen token as specified in [RFC-3775] and reply a Care-of Test message and the Binding Identifier mobility option as described in Section 6.2. When the mobile node receives the Care-of Test message, the Care-of Test message is verified as same as in [RFC-3775]. If a Binding Identifier mobility option is not presented in CoT in reply to the CoTI containing the Binding Identifier mobility option, the Wakikawa (Editor), et al. Expires July 31, 2008 [Page 13] Internet-Draft MCoA January 2008 correspondent node does not support the Multiple Care-of Address registration. Thus, the mobile node MUST NOT use a Binding Identifier mobility option in the future Binding Update. The Mobile Node MAY skip re-sending regular CoTI message and keep the received care-of Keygen token for the regular Binding Update, because the correspondent node just ignores and skip the Binding Identifier mobility option and calculates the care-of Keygen token as [RFC-3775] specified. 5.3. Binding Registration When a mobile node sends a Binding Update, it MUST decide whether it registers multiple care-of addresses or not. However, how this decision is taken is out-of scope in this document. If a mobile node decides not to register multiple care-of addresses, it completely follows the RFC3775 specification. For the multiple Care-of Addresses registration, the mobile node MUST include a Binding Identifier mobility option(s) in the Mobility Option field of a Binding Update as shown in Figure 2. The BID is copied from a corresponding Binding Update List entry to the BID field of the Binding Identifier mobility option. When ESP is used for binding update, the care-of address MUST be stored in the Care-of Address field by setting C flag as a substitute for the alternate care-of address option. The alternate care-of address option MUST be omitted. Additionally for binding registration to a correspondent node, the mobile node MUST have both active home and care-of Keygen tokens for Kbm (see Section 5.2.5 of [RFC-3775]). The care-of Keygen tokens MUST be maintained for each care-of address that the mobile node wants to register to the correspondent node, as described in Section 5.2. After computing an Authenticator value for the Binding Authorization mobility option, it sends a Binding Update which contains a Binding Identifier mobility option. The Binding Update is protected by a Binding Authorization Data mobility option placed after the Binding Identifier mobility option. IPv6 header (src=CoA, dst=HA) IPv6 Home Address Option ESP Header (for home registration) Mobility header -BU Mobility Options - Binding Identifier mobility option - Binding Authorization mobility option (for Route Optimization) Figure 2: Binding Update for Binding Registration Wakikawa (Editor), et al. Expires July 31, 2008 [Page 14] Internet-Draft MCoA January 2008 5.4. Binding Bulk Registration The bulk registration is an optimization for registering multiple care-of addresses only to a home agent by using a single Binding Update. If a mobile node, for instance, does not want to send a lot of control messages through an interface which bandwidth is scarce, it can use this bulk registration and send a Binding Update containing multiple or all the valid care-of addresses. A mobile node sets the C flag in a Binding Identifier mobility option and includes the particular care-of address in the Binding Identifier mobility option. The mobile node stores multiple sets of a Binding Identifier mobility option in a Binding Update as shown in Figure 3. In the bulk registration, all the other binding information such as Lifetime, Sequence Number, binding Flags are shared among the bulked Care-of Addresses. The alternate care-of address option MUST be omitted when ESP is used to protect a binding update. In the bulk registration, the Sequence Number field of a Binding Update SHOULD be carefully configured. This is because all the bulk- registered bindings uses the same Sequence Number specified in the Binding Update. If each binding uses different sequence number, a mobile node MUST use the largest sequence number from the binding update list used for the bulk registration. If it cannot select a sequence number for all the bindings due to sequence number out of window, it MUST NOT use the bulk registration for the binding which sequence number is out of window and uses a separate Binding Update for the binding. IPv6 header (src=CoA, dst=HA) IPv6 Home Address Option ESP Header Mobility header -BU Mobility Options - Binding Identifier mobility options (C flag is set, O flag is optional, BID and CoA are stored) Figure 3: Binding Update for Binding Bulk Registration If the mobile node wants to replace existing registered bindings on the home agent with the bindings in the sent Binding Update, it can set O flag. Section 6.3 describes this registration procedure in detail. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 15] Internet-Draft MCoA January 2008 5.5. Binding De-Registration When a mobile node decides to delete all the bindings for its home address at a visiting network, it simply sends a regular de- registration Binding Update which lifetime is set to zero. A Binding Identifier mobility option is not required. If a mobile node wants to delete a particular binding(s) from its home agent and correspondent nodes (e.g. from foreign link), the mobile node simply sets zero lifetime for the sending binding update. The Binding Update MUST contain an appropriate Binding Identifier mobility option(s). The receiver will remove only the care-of address(es) that matches to the specified BID. For the bulk de- registration, the care-of addresses field of each mobility option SHOULD be omitted, because the receiver will remove all the care-of addresses matching the specified BID. 5.6. Returning Home The mobile node may return to the home link, by attaching to the home link through one of the interfaces on the mobile node. When the mobile node wants to return home, it should be configured with what interface it needs to use. The mobile node may use only the interface with which it is attached to the home link, only the interfaces still attached to the visited link or use both interfaces attached to the home link and visited link simultaneously. The following describes each option in more detail. 5.6.1. Using only Interface attached to the Home Link The mobile node returns home and de-registers all the bindings as shown in Figure 9. How to de-register all the bindings is the same as binding de-registration from foreign link described in Section 5.5. 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. While the mobile node de-registers all the bindings from the home agent, it may continue registering bindings for interface attached to visited link to the correspondent node as shown in Figure 9. These bindings at correspondent node MUST be created before a mobile node returns home. 5.6.2. Using only Interface attached to the Visited Link The mobile node returns home and shutdown the interface attached to the home link as shown in Figure 10. The binding of the home attached interface MUST be deleted by sending a de-registration binding update from one of active interface attached to the foreign links. This scenario is not the most efficient because all the Wakikawa (Editor), et al. Expires July 31, 2008 [Page 16] Internet-Draft MCoA January 2008 traffic from and to the mobile node is going through the bi- directional tunnel, whereas the mobile node is now accessible at one hop from its home agent. 5.6.3. Simultaneous Home and Visited Link Operation The mobile node returns home and continues using all the interfaces attached to both foreign and home links as shown in Figure 11. The mobile node indicates this by setting the 'H' flag in the BID mobility option. There are additional requirements on the Returning Home procedures for possible ND conflicts at the home link described below. In [RFC3775], the home agent intercepts packets meant for the mobile node using proxy NDP while the mobile node is away from the home link. When the mobile node returns home, the home agent deletes the binding cache and stop the proxy NDP 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 while it keeps several interfaces attached to the foreign links and continues using them. Therefore, even though both the mobile node and the home agent need to intercept packets, the ND states of the home address can conflict between the home agent and the mobile node. For instance, if the proxy ND for the Home Address is stopped by the home agent, packets are always routed to the interface attached to the home link and are never routed to the interface attached to the foreign link. It is required to avoid this ND conflicts in the case of the simultaneous home and foreign attachment. In this specification, the home agent MUST intercept all the packets meant for the mobile node and decide whether to send the traffic directly to the home address on the link or tunnel to the care-of address. The home agent would make this decision based on the type of packets and flows. How to make this decision is out of scope in this document. The delicate part would be to create a neighbor cache entry for the mobile node so that the home agent can deliver the packets on-link. The home agent would need to know the Layer-2 address of the interface with which the mobile node is attached to the home link. In order to create the neighbor cache entry for the mobile node, following operations are required. The mobile node sends a de-registration binding update to the home agent from the interface attached to the home link. In the Binding Update, the BID mobility option must be stored for the BID assigned to the interface. The H flag MUST be set in the BID mobility option. When the H flag is appears, the home agent learns and remembers that the mobile node wants to continue using interfaces attached to both Wakikawa (Editor), et al. Expires July 31, 2008 [Page 17] Internet-Draft MCoA January 2008 foreign and home links. If H flag is unset, the home agent deletes either all the bindings or the binding corresponding to the BID. When the home agent sends the Binding Acknowledgment, it MUST store one of two status values such as [Binding Update Accepted (0)] [MCOA RETURNHOME WO/NDP (TBD)] in the BID mobility option depending on home agent configuration at the home link. The new values are: o Binding Update Accepted (0): NDP is permitted for the home address at the home link. This is regular returning home operation of [RFC3775] o MCOA RETURNHOME WO/NDP (TBD): NDP is prohibited for the home address at the home link When the home agent is the only router at the home link, it can intercept all the packets by IP routing without proxy NDP. It stops proxy ND for the requested home address and replies the [Binding Update Accepted] value to the mobile node. The neighbor cache entry for the mobile node is created by the regular NDP operation (i.e. NS/NA exchange). On the other hand, if the home agent is not the only router, it MUST continue defending the home address by proxy NDP to capture all the mobile node's traffic. The home agent, then, returns [MCOA RETURNHOME WO/NDP] value in the Status field of the BID mobility option. The home agent also learns the mobile node's layer-2 address (i.e. MAC address) during this binding de- registration. It keeps the learned layer-2 address as the neighbor cache entry for the mobile node so that it can construct the layer-2 header for the packets meant for the mobile node and forwards them directly to the mobile node's interface attached to the home link. According to [RFC3775], the mobile node MUST NOT assign the home address to the interface attached to the home link and MUST NOT attempt NDP operations for the home address before the completion of binding de-registration. It MUST NOT send and reply to Neighbor Solicitation for the home address. The home address MUST be tentative address at this moment until it receives Binding Acknowledgment with success status value. When the mobile node receives the binding acknowledgment and BID mobility option, it assigns home address at the interface attached to the home link according to the status field of the BID. If the value is [Binding Update Accepted], the mobile node can start defending the home address using NDP. The home agent can create neighbor cache entry for the mobile node by NS and NA exchange as normal IPv6 operation. If the home agent receives the [MCOA RETURNHOME WO/NDP], it MUST NOT Wakikawa (Editor), et al. Expires July 31, 2008 [Page 18] Internet-Draft MCoA January 2008 defends its home address at the home link by NDP. When the mobile node sends packets from the interface attached to the home link, it MUST learn the layer2 address (i.e. MAC address) of the next hop (i.e. default router, it can be home agent) during the binding de- registration and construct the packet including layer 2 header with the learned home agent's layer-2 address. 5.7. Receiving Binding Acknowledgment The verification of a Binding Acknowledgment is the same as Mobile IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a Binding Acknowledgment is described in Section 6.3. If a mobile node includes a Binding Identifier mobility option in a Binding Update with A flag set, a Binding Acknowledgment MUST carry a Binding Identifier mobility option in the Mobility Options field. If no such mobility option is included in the Binding Acknowledgment replied to the Binding Update for the multiple care-of address registration, this indicates that the originator node of this Binding Acknowledgment might not recognize the Binding Identifier mobility option. The mobile node SHOULD stop registering multiple care-of addresses by using a Binding Identifier mobility option. If a Binding Identifier mobility option is present in the received Binding Acknowledgment, the mobile node checks the registration status for the Care-of address(es). The status value MUST be retrieved as follows. 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 Acknowledgment. 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 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 give up registering multiple bindings to the peer sending the Binding Acknowledgment. It MUST return to the regular Mobile IPv6 [RFC-3775] for the peer node. o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the mobile node SHOULD stop using bulk registration to the peer sending the Binding Acknowledgment. o If [MCOA MALFORMED] is specified, it indicates that the binding identifier mobility option is formatted wrongly. For example, if the C flag is set, all mobility options MUST have C flag. It is Wakikawa (Editor), et al. Expires July 31, 2008 [Page 19] Internet-Draft MCoA January 2008 same for O flag. How to handle other error status codes is specified in [RFC-3775]. o If [MCOA BID CONFLICT] is specified, the binding entry specified by the Binding Identifier mobility option is already registered as a regular binding. In such case, the mobile node SHOULD stop sending Binding Updates with BID, or SHOULD use O flag for the peer to reset all the registered bindings. 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 [RFC-3775]). The operation of sending a Binding Refresh Request is described in section Section 6.4. If a mobile node receives a Binding Refresh Request with a Binding Identifier mobility option, this Binding Refresh Request requests a new binding indicated by the BID. The mobile node SHOULD update only the respective binding. The mobile node MUST put a Binding Identifier mobility option into the Binding Update sent to refresh the entry. If no Binding Identifier mobility option is present in a Binding Refresh Request, the mobile node sends a Binding Update according to its Binding Update List. On the other hand, if the mobile node does not have any Binding Update List entry for the requesting node, the mobile node needs to register either a single binding or multiple bindings depending on its binding management policy. 5.9. Sending Packets to Home Agent When a multihomed mobile node sends packets to its home agent, there are conceptually two ways to construct packets. 1. Using Home Address Option. (required additional 24 bytes) 2. Using IPv6-IPv6 tunnel. (required additional 40 bytes) Beside the additional size of packets, no difference is observed between these two. The routing path is always the same and no redundant path such as dog-leg route occurs. However, in this document, the mobile node is capable of using multiple care-of addresses for outgoing packets. This is problem in home agent side because they must verify the Care-of address for all the packets received from the mobile node (i.e. ingress filtering). When it uses the Home Address option, the home agent MAY check the care-of address in the packet with the registering binding entries. This causes additional overhead to the home agent. Therefore, the mobile node Wakikawa (Editor), et al. Expires July 31, 2008 [Page 20] Internet-Draft MCoA January 2008 SHOULD use the bi-directional tunnel even if it registers a binding(s) to the home agent. 5.10. Bootstrapping When a mobile node bootstraps and registers multiple bindings at the first time, it SHOULD set O flag in the Binding Identifier mobility option. If old bindings still exists at the Home Agent, the mobile node has no way to know which bindings are still remained at the home agent. This scenario happens when a mobile node reboots without correct de-registration. If O flag is used, all the bindings are replaced to the new binding(s). Thus, the garbage bindings are surely replaced by new bindings registered with the first Binding Update. If the mobile node receives the Binding Acknowledgment with the status code set to 135 [Sequence number out of window], it MUST retry sending a Binding Update with the last accepted sequence number which is notified by the Binding Acknowledgment. For Correspondent nodes, the mobile node cannot use the O flag because of no bulk registration support. Thus, if necessary, it MUST sends a regular binding first to overwrite the remaining bindings at the correspondent node. Then, it can re-register the set of bindings by using Multiple Care-of Address Registration. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 21] Internet-Draft MCoA January 2008 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. How to select the most suitable binding from the binding cache database is out of scope in this document. Whenever a correspondent node searches a binding cache for a home address, it SHOULD uses both the Home Address and the BID as the search key if it knows the corresponding BID. In the example below, if a correspondent node searches the binding with the Home Address and BID2, it gets binding2 for this mobile node. binding1 [a:b:c:d::EUI, care-of address1, BID1] binding2 [a:b:c:d::EUI, care-of address2, BID2] binding3 [a:b:c:d::EUI, care-of address3, BID3] Figure 4: Searching the Binding Cache A correspondent node basically learns the BID when it receives a Binding Identifier mobility option. At the time, the correspondent node MUST look up its binding cache database with the Home Address and the BID retrieved from the Binding Update. If the correspondent node does not know the BID, it searches for a binding with only a Home Address as performed in Mobile IPv6. In such case, the first matched binding is found. But which binding entry is returned for the normal search depends on implementations. If the correspondent node does not desire to use multiple bindings for a mobile node, it can simply ignore the BID. 6.2. Receiving CoTI and Sending CoT When a correspondent node receives a CoTI message which contains a Binding Identifier mobility option, it MUST process it with following steps. First of all, the CoTI message is verified according to [RFC-3775]. The Binding Identifier mobility option MUST be, then, processed as follows: o If a correspondent node does not understand a Binding Identifier mobility option, it just ignores and skip this option. The calculation of a care-of Keygen token will thus be done without a BID value. The correspondent node returns a CoT message without a Binding Identifier mobility option. The mobile node can thus know Wakikawa (Editor), et al. Expires July 31, 2008 [Page 22] Internet-Draft MCoA January 2008 whether the correspondent can process the Binding Identifier mobility option or not, by checking if such option is present in the CoT message. o If either or both C and O flag is set in the mobility option, the Correspondent Node SHOULD NOT calculate a care-of Keygen token and MUST include a Binding Identifier mobility option which status value set to [MCOA MALFORMED] in the returned Care-of Test message. o Otherwise, the correspondent node MUST include a Binding Identifier mobility option which status value MUST be set to zero in the returning a CoT message. o All the Binding Identifier mobility options SHOULD be copied from the received one except for the Status Field for CoT. The Care-of address field of each Binding Identifier mobility option, however, can be omitted, because the mobile node can match a corresponding binding update list by using BID. 6.3. Processing Binding Update If a Binding Update does not contain a Binding Identifier mobility option, its processing is same as in [RFC-3775]. But if the receiver already has multiple bindings for the home address, it MUST replace all the existing bindings by the received binding. As a result, the receiver node MUST have only a binding for the mobile node. If the Binding Update is for de-registration, the receiver MUST delete all existing bindings from its Binding Cache. If a Binding Update contains a Binding Identifier mobility option(s), it is validated according to section 9.5.1 of [RFC-3775] and the following step. o If the home registration flag is set in the Binding Update, the home agent MUST carefully operate Duplicate Address Detection (DAD) for the received Home Address. If the home agent has already had a binding(s) for the Mobile Node, it MUST avoid running DAD check when it receives the Binding Update. The receiver node MUST process the Binding Identifier mobility option(s) in the following steps. When a correspondent node sends a Binding Acknowledgment, the status value MUST be always stored in the Status field of the Binding Acknowledgment and keep the Status field of Binding Identifier mobility option to zero. For the Home Agent, the status value can be stored in the Status field of either a Binding Acknowledgment or a Binding Identifier Wakikawa (Editor), et al. Expires July 31, 2008 [Page 23] Internet-Draft MCoA January 2008 mobility option. If the status value is specific to one of 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, [MCOA NOTCOMPLETE] MUST be set to the Status field of the Binding Acknowledgment so that the receiver can examine the Status field of each Binding Identifier mobility option for further operations. o The length value is examined. The length value MUST be either 4, 8, or 20 depending on C and D flag. If the length is incorrect, the receiver MUST rejects the Binding Update and returns the status value set to [MCOA MALFORMED]. o When C flag is specified, the care-of address MUST be given in the Binding Identifier mobility option. Otherwise, the receiver MUST reject the Binding Identifier mobility option and returns the status value set to [MCOA MALFORMED]. The operation of D flag is described in Section 8 o When multiple binding Identifier mobility options are presented, the receiver MUST support the bulk registration. Only a home agent can accept the bulk registration. Otherwise, it MUST reject the Binding Update and returns the status value set to [MCOA BULK REGISTRATION NOT SUPPORT] in the Binding Acknowledgment. o If the Lifetime field of the Binding Update is zero, the receiver node deletes the binding entry which BID is same as BID sent by the Binding Identifier mobility option. If the receiver node does not have appropriate binding which BID is matched with the Binding Update, it MUST reject this de-registration Binding Update for the binding cache. If the receiver is a Home Agent, it SHOULD also return the status value set to [not Home Agent for this mobile node, 133]. o If O flag is set in the de-registering Binding Update, the receiver can ignore this flag for de-registration. 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 no longer performs proxy NDP for this mobile node until this entry is deleted. o If the Lifetime field is not zero, the receiver node registers a binding with the specified BID as a mobile node's binding. The Care-of address is picked from the Binding Update packet as follows: * If C flag is set in the Binding Identifier mobility option, the care-of address must be taken from the care-of address field in Wakikawa (Editor), et al. Expires July 31, 2008 [Page 24] Internet-Draft MCoA January 2008 each Binding Identifier mobility option. * If C flag is not set in the Binding Identifier mobility option, the care-of address must be taken from the Source Address field of the IPv6 header. * If C flag is not set and an alternate care-of address is present, the care-of address is taken from the Alternate Care-of address mobility option. o Once the care-of address(es) has been retrieved from the Binding Update, it starts registering binding(s). * Only if O flag is set in the mobility option, the home agent first removes all the existing bindings and registers the received bindings. * If the receiver has a regular binding which does not have BID for the mobile node, it de-registers the regular binding and registers a new binding including BID according to the Binding Update. In this case, the receiver MUST return [MCOA BID CONFLICT]. * If the receiver node has already registered the binding which BID is matched with requesting BID, then it MUST update the binding with the Binding Update and returns [0 Binding Update accepted]. * If the receiver does not have a binding entry which BID is matched with the requesting BID, it registers a new binding for the BID and returns [0 Binding Update accepted]. If all the above operations are successfully finished, the Binding Acknowledgment containing the Binding Identifier mobility options MUST be replied to the mobile node if A flag is set in the Binding Acknowledgment. Whenever a Binding Acknowledgment is returned, all the Binding Identifier mobility options stored in the Binding Update MUST be copied to the Binding Acknowledgment. The Care-of address field of each Binding Identifier mobility option, however, can be omitted, because the mobile node can match a corresponding binding update list by using BID. 6.4. Sending Binding Refresh Request When a node sends a Binding Refresh Request for a particular binding registering with BID, the node SHOULD contain a Binding Identifier mobility option in the Binding Refresh Request. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 25] Internet-Draft MCoA January 2008 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 appeared in the Source Address field MUST be equal to one of the care-of addresses in the binding cache entry. If no binding is found, the packets MUST be silently discarded and MUST send a Binding Error message according to RFC3775. This verification MUST NOT be done for a Binding Update. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 26] Internet-Draft MCoA January 2008 7. Network Mobility Applicability Support of multihomed mobile routers is advocated in the NEMO working group (see R12 "The solution MUST function for multihomed MR and multihomed mobile networks" in [RFC-4886]. Issues regarding mobile routers with multiple interfaces and other multihoming configurations are documented in [RFC-4980]. Since the binding management mechanisms are the same for a mobile host operating Mobile IPv6 and for a mobile router operating NEMO Basic Support (RFC 3963), our extensions can also be used to deal with multiple care-of addresses registration sent from a multihomed mobile router. Figure 5 shows an example format of a Binding Update used by a mobile router. IPv6 header (src=CoA, dst=HA) IPv6 Home Address Option ESP Header Mobility header -BU Mobility Options - Binding Identifier - Mobile Network Prefix Figure 5: NEMO Binding Update Wakikawa (Editor), et al. Expires July 31, 2008 [Page 27] Internet-Draft MCoA January 2008 8. DSMIPv6 Applicability Dual Stack Mobile IPv6 (DSMIPv6) 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 addition to an IPv6 home address for use with IPv4-only correspondent nodes. This section describes how multiple care-of address registration works with IPv4 care-of and home addresses. 8.1. IPv4 Care-of Address Registration In DSMIPv6, the binding update and acknowledgment exchange is used to detect NAT. Thus, when a mobile node registers its IPv4 care-of address bound to IPv6 home address, it MUST first attempt to send a Binding Update with Binding Identifier mobility option independently. The bulk registration MUST NOT be used for the first binding update of the IPv4 care-of address. The Binding Update MUST be sent to the IPv4 home agent address by using UDP and IPv4 headers as shown in Figure 6. It is similar to [DSMIP] except for using BID mobility option instead of IPv4 care-of address option. IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP Header IPv6 header (src=V6HoA, dst=HAADDR) ESP Header Mobility header -BU Mobility Options - Binding Identifier (IPv4 CoA) Figure 6: Initial Binding Update for IPv4 Care-of Address When the home agent detects NAT for the received binding update, it MUST send the NAT detection option in the Binding Acknowledgment. Whenever the NAT detection option is found, the mobile node MUST NOT use the bulk registration for the IPv4 care-of address. Otherwise, it can send the IPv4 care-of address with other care-of addresses in the bulk registration mode. How to handle NAT is same as [DSMIP]. If 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 with other care-of addresses. Figure 7 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 BU from IPv4 care-of address, it MUST follows the Figure 6 and store more BID mobility options in the mobility options field. Note that IPv4 Care-of Address must be registered by non bulk Binding Wakikawa (Editor), et al. Expires July 31, 2008 [Page 28] Internet-Draft MCoA January 2008 registration, whenever it is changed. NAT detection MUST be carried out for every new IPv4 addresses. IPv6 header (src=V6CoA, dst=HAADDR) IPv6 Home Address Option ESP Header Mobility header -BU Mobility Options - Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA) - ... Figure 7: Binding Bulk Registration for IPv4 care-of address If the IPv4 care-of address is successfully registered, the mobile node sets up a relevant tunnel to the home agent according to [DSMIP]. If the home agent rejects the IPv4 care-of address, it MUST store the error code value in the Status field of the BID mobility option. The home agent MUST send the binding acknowledgment and all the received BID mobility options to the mobile node. In this case, the IPv4 address acknowledgment option MUST NOT be included in the Binding Acknowledgment. All the error codes for IPv4 care-of address registration MUST be stored in the Status field of the BID mobility option. The IPv4 address acknowledgment option is used only when a mobile node requests IPv4 home address management. 8.2. IPv4 HoA Management When the mobile node obtains an IPv4 home address, it MUST store the IPv4 Home Address option in the Binding Update. If the home agent accepts the binding update, the mobile node can also register multiple care-of addresses for the IPv4 home address in addition to the IPv6 home address. The same set of care-of addresses will be registered for both IPv6 and IPv4 home addresses. The mobile node cannot binding different set of care-of addresses to each home address. The home agent MUST returns a binding acknowledgment and IPv4 address acknowledgment option to the mobile node only when a mobile node requests IPv4 home address mobility management. In this case, this option MUST be presented before any BID options. The status field of the IPv4 address acknowledgment option contains only the error code regarding IPv4 home address management. The error value of the IPv4 care-of address registration MUST be stored in the BID mobility option. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 29] Internet-Draft MCoA January 2008 9. IPsec and IKEv2 interaction Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the use of IPsec to protect signaling messages like Binding Updates, Binding Acknowledgments and return routability messages. IPsec may also be used protect all reverse tunneled data traffic. The Mobile IPv6-IKEv2 specification [RFC-4877] specifies how IKEv2 can be used to setup the required IPsec security associations. The following assumptions were made in [RFC-3775], [RFC-3963] and the MIP6-IKEv2 specification 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 tunnel packet could either be a tunneled HoTi 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 address with IPsec are addressed. 9.1. Use of Care-of Address in the IKEv2 exchange For each home address 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 Wakikawa (Editor), et al. Expires July 31, 2008 [Page 30] Internet-Draft MCoA January 2008 re-establish the IKEv2 security association with the new care-of address. This will also result in new IPsec security associations being setup 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. For Mobile Prefix Discovery messages, [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 that corresponds to the mobile node's home address. 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 process the message as long as the source address is is one of the care-of addresses in the binding cache entry for the mobile node. 9.3. Tunnel Mode IPsec protected messages The use of IPsec in tunnel mode with multiple care-of address 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 [RFC-3775] mandates the use of IPsec protection in tunnel mode for the HoTi and HoT 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 HoTi and HoT messages The mobile node MAY use the same care-of address for all HoTi messages sent reverse tunneled through the home agent. The mobile node may use the same care-of address irrespective of which correspondent node the HoTi message is being sent. 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 reverse tunneled HoTi 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 HoTi 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 HoT message to the mobile node, the care-of address used in the outer IPv6 header is not relevant to the HoT message. So regular IPsec tunnel encapsulation with the care-of Wakikawa (Editor), et al. Expires July 31, 2008 [Page 31] Internet-Draft MCoA January 2008 address known to the IPsec implementation on the home agent is sufficient. 9.3.2. Tunneled Payload Traffic When the mobile 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, it must check that the care-of address is one of the care-of addresses in the binding cache entry. According to RFC 4306, the IPsec implementation on the home agent does not check the source address on the outer IPv6 header. Therefore 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, the Mobile IPv6 stack on the home agent MUST verify that the source address is one of the care-of addresses registered by the mobile node before decapsulating and forwarding the payload traffic towards the correspondent node. o For tunneled IPsec traffic from the home agent to the mobile node, The IPsec implementation on the home agent may not be aware of which care-of address to use when performing IPsec tunnel encapsulation. The Mobile IP stack on the home agent must specify the tunnel end point for the IPsec tunnel. This may require tight integration between the IPsec and Mobile IP implementations on the home agent. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 32] Internet-Draft MCoA January 2008 10. Security Considerations As shown in Section 9, the Multiple Care-of Addresses Registration requires IPsec protection for all the signaling between a mobile node and its home agent. 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 [ID- MIP6ANALYSIS] and is possible because the care-of addresses specified by the mobile node in the binding update messages are not verified by home agent (since Mobile IPv6 assumes an existing trust relationship between the mobile node and its home agent). Although such risk exists in Mobile IPv6, the risk level is escalated when simultaneous multiple care-of address bindings are performed. One fundamental difference is the degree of risk involved is much greater in the simultaneous binding support case. For a single care-of address binding, 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 fundamental difference is the form 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. Thus, in view of such risk, 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. Some solutions to advert such problems are described in Appendix. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 33] Internet-Draft MCoA January 2008 11. IANA Considerations The following Extension Types MUST be assigned by IANA: o Binding Identifier mobility option type:This must be assigned from the same space as mobility option in [RFC3775]. o New Successful Status of Binding Acknowledgment:This status code must be assigned from the same space as binding acknowledgement status codes in [RFC3775]. * MCOA NOTCOMPLETE (TBD) o New Unsuccessful Status of Binding Acknowledgment: These status codes must also be assigned from the same space as binding acknowledgement status codes in [RFC3775]. * MCOA MALFORMED (TBD) * MCOA BID CONFLICT (TBD) * MCOA PROHIBITED(TBD) * MCOA BULK REGISTRATION NOT SUPPORTED (TBD) Wakikawa (Editor), et al. Expires July 31, 2008 [Page 34] Internet-Draft MCoA January 2008 12. Acknowledgments The authors would like to thank Masafumi Aramoto (Sharp Corporation), George Tsirtsis (Qualcomm), Keigo Aso (Panasonic), Julien Charbon, Tero Kauppinen (Ericsson), Benjamin Lim (Panasonic), Susumu Koshiba, Martti Kuparinen (Ericsson), Romain Kuntz (Keio-U), Heikki Mahkonen (Ericsson), Hiroki Matutani (Tokyo-U), Koshiro Mitsuya (Keio-U), Nicolas Montavont, Koji Okada (Keio-U), Keisuke Uehara (Keio-U), Masafumi Watari (KDDI R&D) in alphabetical order, the Jun Murai Lab. at KEIO University. 13. References 13.1. Normative References [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", IETF RFC 2460, December 1998. [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver 2007. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [RFC-4886] Ernst, T., "Network Mobility Support Goals and Requirements", RFC 4886, July 2007. [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 35] Internet-Draft MCoA January 2008 13.2. Informative References [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivation-scenario-02 (work in progress), July 2007 [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007. [RFC-3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC-4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. [RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 36] Internet-Draft MCoA January 2008 Appendix A. Example Configurations In this section, we describe typical scenarios when a mobile node has multiple network interfaces and acquires multiple Care-of Addresses bound to a Home Address. The Home Address of the mobile node (MN in figures) is a:b:c:d::EUI. MN has 3 different interfaces and possibly acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The MN assigns BID1, BID2 and BID3 to each care-of address. +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +----+---+-+ +--+-+ CoA2| | | | Home Link +--+--+ | | ------+------ | MN +========+ | +--+--+ CoA1 | CoA3| | +---------------+ Binding Cache Database: home agent's binding (Proxy neighbor advertisement is active) binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address3 BID3] correspondent node's binding binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address3 BID3] Figure 8: Multiple Interfaces Attached to a Foreign Link Figure 8 depicts the scenario where all interfaces of the mobile node are attached to foreign links. After binding registrations, the home agent (HA) and the Correspondent Node (CN) have the binding entries listed in their binding cache database. The mobile node can utilize all the interfaces. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 37] Internet-Draft MCoA January 2008 +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +--------+-+ +--+-+ CoA2| | | Home Link +--+--+ | --+---+------ | MN +========+ | | +--+--+ | | | CoA3| +---|-----------+ +---------------+ Binding Cache Database: home agent's binding none correspondent node's binding binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address3 BID3] Figure 9: One of Interface Attached to Home Link and Returning Home Figure 9 depicts the scenario where MN returns home with one of its interfaces. After the successful de-registration of the binding to HA, HA and CN have the binding entries listed in their binding cache database of Figure 9. After de-registration, the ND state of the home address is managed by the MN. MN can communicate with the HA through only the interface attached to the home link. On the other hand, the mobile node can communicate with CN from the other interfaces attached to foreign links (i.e. route optimization). Even if MN is attached to the home link, it can still send Binding Updates for other active care-of addresses (CoA2 and CoA3) to CNs. If CN has bindings, packets are routed to each Care-of Addresses directly. Any packet arrived at HA are routed to the interface attached to the home link. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 38] Internet-Draft MCoA January 2008 +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +----+-----+ +--+-+ CoA2| | | Home Link +--+--+ | --+---+------ | MN +========+ | +--+--+ CoA1 | | | +---------------------------+ (Disable interface) Binding Cache Database: home agent's binding binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address2 BID2] correspondent node's binding binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address2 BID2] Figure 10: One of Interface Attached to Home Link and Not Returning Home Figure 10 depicts the scenario where MN disables the interface attached to the home link and communicates with the interfaces attached to foreign links. HA continues managing the ND state of the home address by Proxy neighbor advertisement. The HA and the CN have the binding entries listed in their binding cache database. All packets routed to the home link are intercepted by the HA and tunneled to the other interfaces attached to the foreign link according to the binding entries. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 39] Internet-Draft MCoA January 2008 Topology-a) +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +----+-----+ +--+-+ CoA2| | | Home Link +--+--+ | --+---+------ | MN +========+ | +--+--+ CoA1 | CoA3 | | +---------------------------+ Topology-b) +----+ | CN | +--+-+ | +---+------+ Router +----+ +------+ Internet |-------R | HA | | +----+-----+ | +--+-+ CoA2| | | | Home Link +--+--+ | --+-+-------+------ | MN +========+ | +--+--+ CoA1 | CoA3 | | +---------------------------+ Binding Cache Database: home agent's binding binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address2 BID2] correspondent node's binding binding [a:b:c:d::EUI care-of address1 BID1] binding [a:b:c:d::EUI care-of address2 BID2] binding [a:b:c:d::EUI care-of address3 BID3] Figure 11: Utilize Interfaces Attached to both Home and Foreign Links Figure 11 depicts the scenario where interfaces of MN are attached to both the home and foreign links. There are two possible topologies whether the HA is single router at the home link or not. The operation of ND is different in two topologies. The HA and CN have the binding entries listed in Figure 11 in their binding cache Wakikawa (Editor), et al. Expires July 31, 2008 [Page 40] Internet-Draft MCoA January 2008 database regardless of topologies. The HA also knows that the MN has attached to the home link. All the traffic from the Internet are intercepted by the HA and routed to either the interface attached to the home link or the interfaces attached to the foreign links. How to make the decision is out of scope in this document. There are two different treatments of the ND state of the home address. o MN defends the home address by regular ND (topology-a) o HA defends the home address by Proxy ND (topology-b) The first case is required that the HA is the single exit router to the Internet and is capable of intercepting packets without relying on proxy ND. The MN can manage the ND of the home address on the home link. In the second case, the HA is not only router at the home link and cannot intercept all the packets meant for the MN by IP routing. The HA needs to run Proxy ND to intercept all the packets at the home link. Since the MN cannot operate the ND of its home addrss at the home link, HA cannot resolve the layer-2 address of the MN at the home link. The HA MUST learn and record the layer-2 address (MAC address) of the MN's interface attached to the home link to forward packets. The packets forwarding is achieved without ND cache. The MN is also required to learn and record the layer-2 address of the HA's interface to send packets from the home link. Wakikawa (Editor), et al. Expires July 31, 2008 [Page 41] Internet-Draft MCoA January 2008 Appendix B. Changes From Previous Versions Changes from draft-ietf-monami6-multiplecoa-04.txt o Binding Unique Identifier is renamed to Bidning Identifier o New Status Code [MCOA NOTCOMPLETE], the home agent uses this status code in the Binding Acknowledgement when not all the bindings are accepted in the bulk registration. o [MCOA FLAG CONFLICTS] are now merged with [MCOA MALFORMED] o Add care-of address verification issue in the Security Consideration, the text is proposed by Benjamin Lim. o Support DSMIPv6 o Support simultaneous foreign and home location. (Section 5.5) o Editorial updates, thanks George Tsirtsis for detailed comments! Authors' Addresses Ryuji Wakikawa (Editor) Faculty of Environment and Information Studies, Keio University 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Phone: +81-466-49-1100 Fax: +81-466-49-1395 Email: ryuji@sfc.wide.ad.jp URI: http://www.wakikawa.org/ Thierry Ernst INRIA INRIA Rocquencourt Domaine de Voluceau B.P. 105 Le Chesnay, 78153 France Phone: +33-1-39-63-59-30 Fax: +33-1-39-63-54-91 Email: thierry.ernst@inria.fr URI: http://www.nautilus6.org/~thierry Wakikawa (Editor), et al. Expires July 31, 2008 [Page 42] Internet-Draft MCoA January 2008 Kenichi Nagami INTEC NetCore Inc. 1-3-3, Shin-suna Koto-ku, Tokyo 135-0075 Japan Phone: +81-3-5565-5069 Fax: +81-3-5565-5094 Email: nagami@inetcore.com Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA Email: vijay.devarapalli@azairenet.com Wakikawa (Editor), et al. Expires July 31, 2008 [Page 43] Internet-Draft MCoA January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wakikawa (Editor), et al. Expires July 31, 2008 [Page 44]