Monami6 Working Group R. Wakikawa Internet-Draft Keio University Intended status: Standards Track T. Ernst Expires: September 6, 2007 INRIA K. Nagami INTEC NetCore V. Devarapalli Azaire Networks March 5, 2007 Multiple Care-of Addresses Registration draft-ietf-monami6-multiplecoa-02.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 September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Wakikawa, et al. Expires September 6, 2007 [Page 1] Internet-Draft MCoA March 2007 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, et al. Expires September 6, 2007 [Page 2] Internet-Draft MCoA March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Multiple Care-of Addresses Registration . . . . . . . . . 7 3.2. Multiple Bindings Management . . . . . . . . . . . . . . . 7 3.3. Returning Home . . . . . . . . . . . . . . . . . . . . . . 8 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 10 4.1. Binding Cache Structure and Binding Update List . . . . . 10 4.2. Message Format Changes . . . . . . . . . . . . . . . . . . 10 4.2.1. Binding Unique Identifier sub-option . . . . . . . . . 10 4.2.2. Binding Acknowledgment . . . . . . . . . . . . . . . . 13 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 14 5.1. Management of Care-of Addresses and Binding Unique Identifier . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Return Routability: Sending CoTI and Receiving CoT . . . . 14 5.3. Binding Registration . . . . . . . . . . . . . . . . . . . 15 5.4. Binding Bulk Registration . . . . . . . . . . . . . . . . 16 5.5. Binding De-Registration . . . . . . . . . . . . . . . . . 16 5.6. Returning Home . . . . . . . . . . . . . . . . . . . . . . 17 5.7. Using Alternate care-of address . . . . . . . . . . . . . 18 5.8. Receiving Binding Acknowledgment . . . . . . . . . . . . . 18 5.9. Receiving Binding Refresh Request . . . . . . . . . . . . 19 5.10. Sending Packets to Home Agent . . . . . . . . . . . . . . 20 5.11. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 20 6. Home Agent and Correspondent Node Operation . . . . . . . . . 21 6.1. Searching Binding Cache with Binding Unique Identifier . . 21 6.2. Receiving CoTI and Sending CoT . . . . . . . . . . . . . . 21 6.3. Processing Binding Update . . . . . . . . . . . . . . . . 22 6.4. Sending Binding Refresh Request . . . . . . . . . . . . . 25 6.5. Receiving Packets from Mobile Node . . . . . . . . . . . . 25 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 26 8. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 27 8.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 27 8.2. Transport Mode IPsec protected messages . . . . . . . . . 28 8.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 28 8.3.1. Tunneled HoTi and HoT messages . . . . . . . . . . . . 28 8.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 Wakikawa, et al. Expires September 6, 2007 [Page 3] Internet-Draft MCoA March 2007 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . . 33 Appendix A. Example Configurations . . . . . . . . . . . . . . . 33 Appendix B. Changes From Previous Versions . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Intellectual Property and Copyright Statements . . . . . . . . . . 41 Wakikawa, et al. Expires September 6, 2007 [Page 4] Internet-Draft MCoA March 2007 1. Introduction A mobile node should use various type of network interfaces to obtain durable and wide area network connectivity. Assumed scenarios and motivations for multiple points of attachment, and benefits for doing it are discussed at large in [10]. IPv6 [1] conceptually allows a node to have several addresses on a given interface. Consequently, Mobile IPv6 [2] 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 [3] is based on Mobile IPv6, the same issues applies to a mobile node acting as mobile router. Multihoming issues pertaining to mobile nodes operating Mobile IPv6 and mobile routers operating NEMO Basic Support are respectively discussed [4] and [11] in Monami6 and NEMO Working Group. In this document, we thus propose a new identification number called Binding Unique Identification (BID) number for each binding cache entry to accommodate multiple bindings registration. The BID is assigned to either the interfaces or care-of addresses bound to a single home address of a mobile node. 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, et al. Expires September 6, 2007 [Page 5] Internet-Draft MCoA March 2007 2. Terminology Terms used in this draft are defined in [2], [5] and [6]. In addition or in replacement of these, the following terms are defined or redefined: Binding Unique 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 is generated to register multiple bindings in the binding cache for a given address in a way it cannot be duplicated with another BID. The zero value and a negative value MUST NOT be used. After being generated by the mobile node, the BID is stored in the Binding Update List and is sent by the mobile node by means of a sub- option of a 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. The BID is conceptually assigned to a binding. 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 Unique Identifier sub-option The Binding Unique Identifier sub-option is used to carry the BID. Bulk Registration A mobile node can register multiple bindings 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 which can be stored in a Binding Update. The bulk registration is supported only for home registration and deregistration as explained in Section 5.5. Note that a mobile node should not try to perform bulk registration with correspondent nodes. 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 [7]. Wakikawa, et al. Expires September 6, 2007 [Page 6] Internet-Draft MCoA March 2007 3. Protocol Overview We propose a new identification number (BID) to distinguish multiple bindings pertaining to the same Home Address. The procedures for the mobile node to register multiple bindings are described in the paragraphs below. 3.1. Multiple Care-of Addresses Registration Once a mobile node gets several IPv6 global addresses on interfaces, it can register these addresses with its home agent (home registration). If the mobile node wants to register multiple bindings to its home agent, it MUST generate a BID for each care-of address and record it into the binding update list. The mobile node then registers its care-of addresses by sending a Binding Update with a Binding Unique Identifier sub-option. The BID MUST be put in the Binding Unique Identifier sub-option. After receiving the Binding Update, the home agent verifies the request and records the binding in its binding cache. If the newly defined sub-option is present in the Binding Update, the home agent MUST copy the BID from the Binding Update to the corresponding field in the binding entry. Even if there is already an entry for the mobile node, the home agent MUST register a new binding entry for the BID stored in the Binding Unique Identifier sub-option. The mobile node registers multiple care-of addresses either independently (in individual BUs) or multiple at once (in a single BU). If the mobile node wishes to register its binding with a correspondent node, it must operate return routability operations. The mobile node MUST manage a Care-of Keygen Token per care-of address. If it is necessary (ex. Care-of Keygen token is expired), the mobile node exchanges CoTI and CoT for the releative care-of addresses. When the mobile node 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 by using Binding Unique Identifier sub-option as well as the other sub-options specified in RFC 3775. For simplicity, the bulk registration is not supported for correspondent nodes in this document. 3.2. Multiple Bindings Management The BID is used as a search key for a corresponding entry in the binding cache in addition to the Home Address. When a home agent and a correspondent node check the binding cache database for the mobile node, it searches a corresponding binding entry with the Home Address and BID of the desired binding. If necessary, a mobile node can use Wakikawa, et al. Expires September 6, 2007 [Page 7] Internet-Draft MCoA March 2007 policy and filter information to look up the best binding per sessions, flow, packets, but this is out of scope in this document and is currently discussed in Monami6 WG. 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. When one of the care-of addresses has changed, the mobile node sends a Binding Update with the new care-of address and the corresponding BID. The receiver of the Binding Update updates the binding which BID matches the BID contained in the received Binding Unique Identifier sub-option. The mobile node can manage each binding independently owing to BID. If the mobile node decides to act as a regular mobile node compliant with [2] , it just sends a Binding Update without a Binding Unique Identifier sub-option (i.e. normal Binding Update). The receiver of the Binding Update registers only a single binding for the mobile node and, if necessary, deletes all the bindings registering with a BID. Note that the mobile node can continue to use BID even if only a single binding is active at some time. 3.3. Returning Home When the mobile node returns home, there are two situations, since the home agent defends the mobile node's Home Address by using the proxy neighbor advertisement. It is impossible to utilize all the interfaces when one interface is attached to the home link and the others are attached to foreign links. If the proxy Neighbor Advertisement for the Home Address is stopped, packets are always routed to the interface attached to the home link. If proxy is not stopped, packets are never routed to the interface attached to the home link. The decision whether a mobile node returns home or not is up to implementers. The first situation is when a mobile node wants to return home with interface attached to the home link. In this case, the mobile node MUST de-register all the bindings by sending a Binding Update with lifetime set to zero. The mobile node MAY NOT put any Binding Unique Identifier sub-option in this packet. Then, the receiver deletes all the bindings from its binding cache database. A home agent MUST stop proxy neighbor advertisement for the home address of the mobile node. The second situation is when a mobile node does not want to return home, though one of its interfaces is attached to its home link. The mobile node disables the interface attached to the home link and Wakikawa, et al. Expires September 6, 2007 [Page 8] Internet-Draft MCoA March 2007 keeps using the rest of interfaces attached to foreign links. In this case, the mobile node sends a de-registration Binding Update for the interface attached to the home link with the Binding Unique Identifier sub-option. The receiver of the de-registration Binding Update deletes only the relative binding entry from the binding cache database. The home agent does not stop proxying neighbor advertisement as long as there are still bindings for the other interfaces. It is important to understand that this scenario is not the most efficient because all the 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 HA. In the above two cases, a mobile node cannot use interfaces attached to both home and foreign links simultaneously. If this is what a mobile node wants, a home agent can set up another link other than home link and uses the link for the mobile node to return virtually to home network. Even though packets from and to the mobile node are routed via the home agent, the hop count is kept in one. The overhead should be negligible since it is only for an additional IPv6 header and processing tunnel (encapsulation and decapsulation) per packets. The detail can be found in Figure 7 Wakikawa, et al. Expires September 6, 2007 [Page 9] Internet-Draft MCoA March 2007 4. Mobile IPv6 Extensions In this section are described 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 following additional items are required in the binding cache and binding update list structure. BID The value MUST be zero if the Binding Unique identifier does not appear in a Binding Update. Priority of the Binding Cache Entry A value of zero indicates No Priority. A value of 255 indicates that the binding corresponding to this BID is a default of this mobile node. The detail can be found in Figure 1. This information is used by [12]. 4.2. Message Format Changes 4.2.1. Binding Unique Identifier sub-option The Binding Unique Identifier sub-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 Unique ID (BID) |Priority/Status|C|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ + + + care-of address (CoA) + + + +---------------------------------------------------------------+ Figure 1: BID Sub-Option Wakikawa, et al. Expires September 6, 2007 [Page 10] Internet-Draft MCoA March 2007 Type Type value for Binding Unique Identifier will be assigned later. Length Length value MUST be 4 when C flag is unset. On the other hand if C flag is set, Length value MUST be set to 20. Binding Unique ID (BID) The BID which is assigned to the binding carried in the Binding Update with this sub-option. BID is 16-bit unsigned integer. A value of zero is reserved. Priority/Status When the Binding Unique Identifier sub-option is included in a Binding Update, this field indicates the priority field assigned to each binding. The receiver can utilize this priority to determine which binding is used to deliver packets. The priority is 8-bit unsigned integer. The higher value has higher priority. Values of zero and 255 are reserved for special meaning. A value of zero indicates No Priority. A value of 255 indicates that the binding corresponding to this BID is a default of this mobile node. This default binding is used by the flow binding scheme [12]. If the receiver cannot recognize 255, it MUST ignore this field. When the Binding Unique Identifier sub-option is included in a Binding Acknowledgment, this field indicates the status correspondent to each binding. The mobile node knows the registration status of each binding. The status is 8-bit unsigned integer. The possible status codes are listed below. If the status field is below 128, it indicates that the binding registration was successful. MCOA ACCEPTING BID (0) The registration of the correspond binding is successfully operated. MCOA REASON UNSPECIFIED (128) Wakikawa, et al. Expires September 6, 2007 [Page 11] Internet-Draft MCoA March 2007 Registration failed because of unknown errors MCOA INCOMPLIANT (129) Registration failed because Binding Unique Identifier sub- option is not compliant. MCOA BID CONFLICT (130) It indicates that a regular binding (ie without the BID set) is already registered for the home address, and is conflicting with a received Binding Update which BID was set. MCOA BULK REGISTRATION PROHIBITED (131) The C flag can be set only if a Binding Unique Identifier sub- option is presented only in a Binding Update or a 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 Unique Identifier sub- option. This flag must be used whenever a mobile node sends multiple bindings in a single Binding Update, i.e. bulk registration. 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 for Home Registration and Deregistration. Reserved 6 bits Reserved field. Reserved field must be set with all 0. Care-of Address Only when C flag is set, only a single Care-of Address matched to the BID is stored. This field is valid only if a Binding Unique Identifier sub-option is stored in Binding Update message. Otherwise, this field can be omitted. The receiver SHOULD ignore this field if the sub-option is presented in other than Binding Update. Wakikawa, et al. Expires September 6, 2007 [Page 12] Internet-Draft MCoA March 2007 4.2.2. Binding Acknowledgment The message format of Binding Acknowledgment does not change, but operations listed below are added in this draft. If a Binding Unique Identifier sub-option is included in a Binding Update with the A flag set, a receiver MUST reply a Binding Acknowledgment. The receiver node MUST include the same Binding Unique Identifier sub-option(s) in the Binding Acknowledgment. The receiver MUST specify relative status in the Status field of the Binding Acknowledgment. There are two status fields: the Status field of a Binding Acknowledgment and the Status field of a Binding Unique Identifier sub-option. In this specification, the Status field of a Binding Acknowledgment indicates the registration status of a "Binding Update". The status value in the Binding Acknowledgment is for all Binding Unique Identifier sub-options stored in the Binding Acknowledgment. For example, if the status value is 134 in the status field of the Binding Acknowledgment, all the care-of addresses stored in the Binding Unique Identifier sub-options are rejected because the duplicate address detection has failed on the home agent. The status field of the Binding Unique Identifier sub-option only informs the receiver about the binding relative to the sub-option. Whether each Care-of address has been successfully registered successfully or not is given in the Status field of each Binding Unique Identifier sub-option. New status values for the status field of a Binding Acknowledgment are defined for handling the multiple Care-of Addresses registration: MCOA PROHIBITED(TBD) It implies the multiple care-of address registration is administratively prohibited. MCOA BULK REGISTRATION NOT SUPPORTED (TBD) The bulk binding registration is not supported. MCOA FLAG CONFLICTS (TBD) The flags of the sub-options presented in a Binding Update conflicts. Wakikawa, et al. Expires September 6, 2007 [Page 13] Internet-Draft MCoA March 2007 5. Mobile Node Operation 5.1. Management of Care-of Addresses and Binding Unique Identifier There are two cases when a mobile node has several Care-of Addresses: 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 up to implementers. A mobile node assigns a BID to each care-of address when it wants to register them simultaneously with its Home Address . The value should be generated from a value comprised between 1 to 65535. Zero and negative values MUST NOT be taken 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 send a CoTI 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 Unique Identifier sub-option in a Care-of Test Init message. It MUST NOT set the C and O flag in the sub-option. The receiver (i.e. correspondent node) will calculate a care-of keygen token with the received BID and reply a Care-of Test message which contains a Binding Unique Identifier sub-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 [2] and the Binding Unique Identifier sub-option in the Care-of Test MUST be processed as follows: o If a Binding Unique Identifier sub-option is not presented in CoT in reply to the CoTI containing the Binding Unique Identifier sub- option, a correspondent node does not support the Multiple Care-of Wakikawa, et al. Expires September 6, 2007 [Page 14] Internet-Draft MCoA March 2007 Address registration. Thus, the mobile node MUST NOT use a Binding Unique Identifier sub-option in the Binding Update. It MUST send a regular Binding Update (i.e. no BID) to the correspondent node [2]. The Mobile Node MAY skip resending regular CoTI message and use the received care-of keygen token for the regular Binding Update, because the correspondent node just ignores and skip the Binding Unique Identifier sub-option and calculates the care-of keygen token as [2] specified. o If the status field of a Binding Unique Identifier sub-option is set to [MCOA BULK REGISTRATION PROHIBITED], the care-of keygen token MUST NOT be used for a Binding Update. It MUST re-send a Care-of Test Init message again with a corrected Binding Unique Identifier sub-option (i.e. C flag MUST be unset). o If the status field is set to less than 128, it sends a Binding Update through Return Routability procedure. The computation of MAC is the same as the one in [2] except for calculation of a care-of keygen token. The calculation of a care-of keygen token is modified as follows. BID is used to generate the care-of keygen token. care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | BID | 1))) 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, this decision is out-of scope in this document. If a mobile node decides not to register multiple care-of addresses, it completely follows the standard RFC 3775 specification. If a mobile node needs to register multiple Care-of Addresses, it MUST use BID to identify a care-of address. The mobile node includes a Binding Unique Identifier sub-option in the Mobility Option field of a Binding Update. The BID is copied from a corresponding Binding Update List entry to the BID field of the Binding Unique Identifier sub-option. If the mobile node wants to replace existing registered bindings on the home agent to the binding entry(s) in the Binding Update, it can set O flag. If a mobile node registers bindings to a correspondent node, it MUST have both active home and care-of keygen tokens for Kbm (see Section 5.2.5 of [2]. 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 Wakikawa, et al. Expires September 6, 2007 [Page 15] Internet-Draft MCoA March 2007 Authenticator value, it sends a Binding Update which contains a Binding Unique Identifier sub-option. The Binding Update is protected by a Binding Authorization Data sub-option placed after the Binding Unique Identifier sub-option. The Mobile Node MUST NOT set the C flag in the Binding Unique Identifier sub-option. 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 from a specific interface which has wider bandwidth. In this case, a mobile node sets the C flag in a Binding Unique Identifier sub-option and stores the particular care-of address in the Binding Unique Identifier sub-option. When the C flag is set, the length field of the suboption MUST be set to 20. The mobile node can store multiple sets of a Binding Unique Identifier sub-option in a Binding Update. 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. In the bulk registration, all the other binding information such as Lifetime, Sequence Number, binding Flags are shared among the bulked Care-of Addresses. Whether a mobile node registers multiple Care-of Addresses separately or in bulk is up to implementations. In the bulk registration, the Sequence Number field of a Binding Update SHOULD be carefully configured. 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. When multiple Binding Unique Identifier sub-options are presented, the flag field of all the sub-options MUST have the same value. For example, if C flag is set, the same flag MUST be set to all the sub- options. 5.5. 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. A Wakikawa, et al. Expires September 6, 2007 [Page 16] Internet-Draft MCoA March 2007 Binding Unique Identifier sub-option is not required. See Section 6.3 for details. If a mobile node wants to delete a particular binding from its home agent and correspondent nodes (e.g. from foreign link), the mobile node simply sets zero lifetime or uses the home address as the source address in a Binding Update. The Binding Update MUST contain a relative Binding Unique Identifier Sub-option (C flag MUST NOT be set). The receiver will remove only the care-of address that matches the specified BID. On the other hand, when a mobile node decides to return home (ie only uses its interface attached to the home link), it MUST de-register all the registered bindings. To do so, the mobile node stores multiple Binding Unique Identifier sub-options in a Binding Update which lifetime is set to zero or which source address is set to the Home Address. C flag MUST be specified in all the Binding Unique Identifier sub-options. The care-of addresses field of each sub- option MAY be omitted, because the receiver will remove all the care-of addresses which matches the specified BID. O flag is always ignored if a Binding Update is for binding de- registration 5.6. Returning Home When a mobile node returns home, it MUST de-register all bindings with the home agent. Although the mobile node SHOULD delete the bindings with Correspondent Nodes as well, the node MAY still keep the binding of the other interface active attached to foreign links only at the Correspondent Nodes. In such case, the mobile node still receives packets at the other interface attached to a foreign link thanks to route optimization. The mobile node also receives packets at the interface attached to the home link when correspondent nodes does not use route optimization. Note that when the mobile node does not want to return home even if one of interfaces is attached to the home link, the mobile node MUST disable the interface. Otherwise, address duplication will be observed because the home agent still defend the Home Address by the proxy neighbor advertisement and the mobile node also enables the same Home Address on the home link. After disabling the interface attached to the home link, the mobile node MUST delete the binding for the interface by sending a de-registration binding update. The de-registration binding update must be sent from one of active interfaces attached to foreign links. As a result, the mobile node Wakikawa, et al. Expires September 6, 2007 [Page 17] Internet-Draft MCoA March 2007 no longer receives packets at the interface attached to the home link. All packets are routed to other interfaces attached to a foreign link. 5.7. Using Alternate care-of address A mobile node can use an alternate care-of address in a following situation. One care-of address becomes invalid (e.g because the link where it is attached to is no longer available) and MUST be deleted. In such case, the mobile node can not send a Binding Update from the care-of address because the interface's link is lost. The mobile node needs to de-register the remote binding of the care-of address through one of its active care-of addresses. In this case, the mobile node include both Alternate Care-of Address sub-option and Binding Unique Identifier sub-option in a Binding Update. An Alternate care-of address sub-option can be presented only once in a Binding Update after a Binding Unique Identifier sub- option. The care-of address stored in an Alternate Care-of address sub-option is replaced the address in the source address field as same as [2] specified. If C flag is set in a Binding Unique Identifier sub-option, an Alternate Care-of Address sub-option SHOULD NOT be used. A receiver uses the care-of addresses and BID stored in each Binding Unique Identifier sub-option to modify corresponding binding cache entries. Any address can be specified in the Source address field of the IPv6 header of the Binding Update even without an Alternate Care-of Address sub-option. 5.8. Receiving Binding Acknowledgment The verification of a Binding Acknowledgment is the same as in 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 Unique Identifier sub-option in a Binding Update with A flag set, a Binding Acknowledgment MUST have a Binding Unique Identifier sub-option in the Mobility Options field. If no such sub-option appears in the Binding Acknowledgment replied to the Binding Update for the multiple care-of address registration, this means that the originator node of this Binding Acknowledgment might not recognize the Binding Unique Identifier sub-option. The mobile node SHOULD stop registering multiple care-of addresses by using a Binding Unique Identifier sub-option. If the originator is the home agent, the mobile node MAY try to discover a new home agent supporting the multiple care-of address registration or give up with the multiple care-of address registration. Wakikawa, et al. Expires September 6, 2007 [Page 18] Internet-Draft MCoA March 2007 If a Binding Unique Identifier sub-option is present in the received Binding Acknowledgment, the mobile node checks the Status field of the Binding Acknowledgment. If the status code indicates successful registration (less than 128), the originator successfully registered the binding information and BID for the mobile node. If the status code of the Binding Acknowledgment is greater than or equal to 128, the mobile node proceeds with relevant operations according to the status code of the Binding Acknowledgment. The status value of the stored Binding Unique Identifier sub-option may be used to decide further operation. o If the Status value of the Binding Acknowledgment 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 [2] 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 FLAG CONFLICTS] is specified in the Binding Acknowledgment, it indicates that the different flag values are used in Binding Unique Identifier sub-options in a Binding Update. If the C flag is set, all sub-options MUST have C flag. It is same for O flag. How to handle other error status codes is specified in [2]. The mobile node also learn detailed registration status from the Status field of each Binding Unique Identifier sub-option. If the value is greater than or equal to 128, the mobile node proceeds with relevant operations according to the status value. o If [MCOA BID CONFLICT] is specified, the binding entry specified by the Binding Unique Identifier sub-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 sending the Binding Acknowledgment. 5.9. 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 Unique Identifier sub-option, this Binding Refresh Request requests a binding indicated by the BID. The mobile node SHOULD update only the Wakikawa, et al. Expires September 6, 2007 [Page 19] Internet-Draft MCoA March 2007 respective binding. The mobile node MUST put a Binding Unique Identifier sub-option into the Binding Update sent to refresh the entry. If no Binding Unique Identifier sub-option is present in a Binding Refresh Request, the mobile node sends a Binding Update according to its Binding Update List for the requesting node. 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.10. 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 or triangular 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. Therefore, the mobile node SHOULD use the bi-directional tunnel even if it registers a binding(s) to the home agent. When it uses the Home Address option, the home agent MAY reject the packets because the Care-of address in the packet and the first found Care-of Address in the binding Cache of the home agent are different. The mobile node then receive Binding Error for the packet drop. 5.11. Bootstrapping When a mobile node bootstraps and registers multiple bindings at the first time, it SHOULD set O flag in the Binding Unique Identifier sub-option. when old bindings still exists at the Home Agent and Correspondent Nodes, the mobile node has no way to verify which bindings are left as a garbage in those nodes. This scenario happens when a mobile node reboots without correct deregistration. If O flag is used, all the bindings are replaced to the new binding(s). Thus, the garbage bindings are surely removed by the first Binding Update. XXX SEQ Wakikawa, et al. Expires September 6, 2007 [Page 20] Internet-Draft MCoA March 2007 6. Home Agent and Correspondent Node Operation 6.1. Searching Binding Cache with Binding Unique 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. If the priority is available for a binding cache entry, the priority can be used as additional key to search a binding. 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 2: Searching the Binding Cache A correspondent node basically learns the BID when it receives a Binding Unique Identifier sub-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 Care-of Test Init message which contains a Binding Unique Identifier sub-option, it MUST process it with following steps. First of all, the Care-of Test Init message is verified according to [2]. The Binding Unique Identifier sub-option MUST be processed as follows: Wakikawa, et al. Expires September 6, 2007 [Page 21] Internet-Draft MCoA March 2007 o If a correspondent node does not understand a Binding Unique Identifier sub-option, it will ignore and skip this option. The calculation of a care-of keygen token will thus be done without a BID value. After regular processing of HoTI message according to [2], it will return a Care-of Test message without use of a Binding Unique Identifier sub-option. The mobile node can thus know whether its correspondent can process or not the Binding Unique Identifier sub-option by checking if such option is present in the Care-of Test message. o If C flag is set in the sub-option, the Correspondent Node SHOULD NOT calculate a care-of keygen token and MUST include a Binding Unique Identifier sub-option which status value set to [MCOA BULK REGISTRATION PROHIBITED] in the returned Care-of Test message. All the fields of the Care-of Test message MUST be set to zero. All the Binding Unique Identifier sub-options SHOULD be copied from the received one except for the Status Field and the Care-of Address field. o If O flag is set in the sub-option, the Correspondent Node can ignore this flag and can process it as described in the next bullet. o Otherwise, the correspondent node MUST include a Binding Unique Identifier sub-option which status value MUST be set to [MCOA ACCEPTING BID] in the returning a Care-of Test message. The Binding Unique Identifier sub-option SHOULD be copied from the received one except for the Status Field and the Care-of address Field. The calculation of a care-of keygen token is modified as follows. The BID is used to generate the care-of keygen token. care-of keygen token := First (64, HMAC_SHA1 (Kcn, (care-of address | nonce | BID | 1))) 6.3. Processing Binding Update If a Binding Update does not contain a Binding Unique Identifier sub- 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 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. On the other hand, if a Binding Update contains a Binding Unique Identifier sub-option(s), the Binding Update is also validated Wakikawa, et al. Expires September 6, 2007 [Page 22] Internet-Draft MCoA March 2007 according to section 9.5.1 of [2] and the following step. o If the home flag is set in the Binding Update, the home agent MUST carefully operate 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 when it receives the Binding Update. If a Binding Unique Identifier sub-option(s) is present, the receiver node MUST process the sub-option. o The length value is examined. The length value MUST be either 4 or 20 depending on C flag. If the length is incorrect, the receiver MUST rejects the Binding Update and returns all the received Binding Unique Identifier sub-option which status value is set to [MCOA INCOMPLIANT]. The status field of the Binding Acknowledgment MUST be set to [REASON UNSPECIFIED, 128]. o When C flag is set, the receiver MUST support the bulk registration. Otherwise, it MUST reject the Binding Update and returns all the received Binding Unique Identifier sub-option which status value is set to [MCOA REASON UNSPECIFIED]. The status field of the Binding Acknowledgment MUST be set to [MCOA BULK REGISTRATION NOT SUPPORTED]. o When either C or O flag is set, the flags field of all the Binding Unique Identifier sub-option stored in the same Binding Update MUST be equal. Otherwise, the receiver MUST reject the Binding Update and returns all the received Binding Unique Identifier sub- option which status value is set to [MCOA REASON UNSPECIFIED]. The status field of the Binding Acknowledgment MUST be set to [MCOA FLAG CONFLICTS]. o When C flag is specified, the care-of address MUST be given in the Binding Unique Identifier sub-option. Otherwise, the receiver MUST reject the Binding Update and returns all the received Binding Unique Identifier sub-option which status value is set to [MCOA INCOMPLIANT]. The status field of the Binding Acknowledgment MUST be set to [REASON UNSPECIFIED, 128]. 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 Unique Identifier sub-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. If the receiver is a Home Agent, it SHOULD also return a Binding Acknowledgment to the mobile node, in which the Status field is set to [not Home Agent for this mobile node, 133]. If O flag is set in the deregistering Binding Update, the receiver can Wakikawa, et al. Expires September 6, 2007 [Page 23] Internet-Draft MCoA March 2007 ignore this flag for deregistration. 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 Unique Identifier sub-option, the care-of address must be taken from the care-of address field in each Binding Unique Identifier sub-option. * If C flag is not set in the Binding Unique Identifier sub- 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 sub-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 sub-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 specify [MCOA BID CONFLICT] to the Binding Unique Identifier sub-option which is replied to the Mobile Node. The Status field of the replying Binding Acknowledgment MUST be set to [Binding Update ACCEPTED, 0]. * 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. * 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. If all the above operations are successfully finished, the Binding Acknowledgment containing the Binding Unique Identifier sub-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 Unique Identifier sub-options stored in the Binding Wakikawa, et al. Expires September 6, 2007 [Page 24] Internet-Draft MCoA March 2007 Update MUST be copied to the Binding Acknowledgment. The Care-of address field of each Binding Unique Identifier sub-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 either a correspondent node or home agent notices that a registered binding will be expired soon, it MAY send a Binding Refresh Request. If the registered binding has BID, the correspondent node SHOULD contain a Binding Unique Identifier sub- option in the Binding Refresh Request. Then, the Correspondent Node can receive a Binding Update with a Binding Unique Identifier sub- option and can update only the particular binding. If the registered binding does not have BID, then the correspondent node sends a Binding Refresh Request without the sub-option. 6.5. Receiving Packets from Mobile Node When a correspondent 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, et al. Expires September 6, 2007 [Page 25] Internet-Draft MCoA March 2007 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 [8]. Issues regarding mobile routers with multiple interfaces and other multihoming configurations are documented in [11]. 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. Wakikawa, et al. Expires September 6, 2007 [Page 26] Internet-Draft MCoA March 2007 8. IPsec and IKEv2 interaction Mobile IPv6 [2] and the NEMO protocol [3] 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 [9] 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. 8.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 Unique Identifier sub-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, et al. Expires September 6, 2007 [Page 27] Internet-Draft MCoA March 2007 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. 8.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. 8.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. 8.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, et al. Expires September 6, 2007 [Page 28] Internet-Draft MCoA March 2007 address known to the IPsec implementation on the home agent is sufficient. 8.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, et al. Expires September 6, 2007 [Page 29] Internet-Draft MCoA March 2007 9. Security Considerations TBD Wakikawa, et al. Expires September 6, 2007 [Page 30] Internet-Draft MCoA March 2007 10. IANA Considerations TBD Wakikawa, et al. Expires September 6, 2007 [Page 31] Internet-Draft MCoA March 2007 11. Acknowledgments The authors would like to thank Masafumi Aramoto (Sharp Corporation), Julien Charbon, Tero Kauppinen (Ericsson), 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, and WIDE project for their contributions. 12. References 12.1. Normative References [1] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", IETF RFC 2460, December 1998. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [4] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", draft-ietf-monami6-mipv6-analysis-02 (work in progress), February 2007. [5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-06 (work in progress), November 2006. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [8] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-06 (work in progress), November 2006. [9] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-08 (work in progress), December 2006. Wakikawa, et al. Expires September 6, 2007 [Page 32] Internet-Draft MCoA March 2007 12.2. Informative References [10] 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-01 (work in progress), October 2006. [11] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-06 (work in progress), June 2006. [12] Soliman, H., "Flow Bindings in Mobile IPv6", draft-soliman-monami6-flow-binding-02 (work in progress), September 2006. 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. Figure 3 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, et al. Expires September 6, 2007 [Page 33] Internet-Draft MCoA March 2007 +----+ | 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 3: Multiple Interfaces Attached to a Foreign Link Figure 4 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 4. 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 when MN is attached to the home link, it can still send Binding Updates for other active care-of addresses (CoA2 and CoA3). If CN has bindings, packets are routed to each Care-of Addresses directly. Any packet arrived at HA are routed to the primary interface. Wakikawa, et al. Expires September 6, 2007 [Page 34] Internet-Draft MCoA March 2007 +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +--------+-+ +--+-+ CoA2| | | Home Link +--+--+ | --+---+------ | MN +========+ | | +--+--+ | | | CoA3| +---|-----------+ +---------------+ Binding Cache Database: home agent's binding (Proxy neighbor advertisement is inactive) 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 4: One of Interface Attached to Home Link and Returning Home Figure 5 depicts the scenario where MN disables the interface attached to the home link and communicates with the interfaces attached to foreign links. The HA and the CN have the binding entries listed in their binding cache database. MN disable the interface attached to the home link, because the HA still defends the home address of the MN by proxy neighbor advertisements. 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, et al. Expires September 6, 2007 [Page 35] Internet-Draft MCoA March 2007 +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +----+-----+ +--+-+ CoA2| | | Home Link +--+--+ | --+---+------ | MN +========+ | +--+--+ CoA1 | | | +---------------------------+ (Disable interface) 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] 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 5: One of Interface Attached to Home Link and Not Returning Home Figure 6 depicts the scenario where multiple interfaces of MN are attached to the home link. The HA and CN have the binding entries listed in Figure 6 in their binding cache database. The MN can not use the interface attached to a foreign link unless a CN has a binding for the interface. All packets which arrive at the HA are routed to one of the MN's interfaces attached to the home link. Wakikawa, et al. Expires September 6, 2007 [Page 36] Internet-Draft MCoA March 2007 +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +----------+ +--+-+ CoA2| | Home Link +--+--+ --+----+---+------ | MN +===================+ | +--+--+ | | | +---------------------------+ Binding Cache Database: home agent's binding (Proxy neighbor advertisement is inactive) none correspondent node's binding binding [a:b:c:d::EUI care-of address2 BID2] Figure 6: Several Interfaces Attached to Home Link and Returning Home Figure 7 depicts the scenario where interfaces of MN are attached to the foreign links. One of foreign link is managed by the home agent. The HA and CN have the binding entries listed in Figure 7 in their binding cache database. The home agent advertises a prefix which is other than home prefix. The mobile node will generate a care-of address from the prefix and registers it to the home agent. Even if the mobile node attaches to a foreign link, the link is managed by its home agent. It will tunnel the packets to the home agent, but the home agent is one-hop neighbor. The cost of tunnel is negligible. If the mobile node wants to utilize not only an interface attached to home but also interfaces attached to foreign link, it can use this foreign link of the home agent to return a one hop foreign link on behalf of a home link. This is different from the general returning home, but this enable the capability of using interfaces attached to both home and foreign link without any modifications to Mobile IPv6 and NEMO basic support. Wakikawa, et al. Expires September 6, 2007 [Page 37] Internet-Draft MCoA March 2007 +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +----+-----+ ++-+-+ CoA2| | | | Home Link +--+--+ | ----|-+------ | MN +========+ | +--+--+ CoA1 ---+-+------ CoA3 | | Foreign Link +---------------------------+ 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 7: Emulating to Utilize Interfaces Attached to both Home and Foreign Links Wakikawa, et al. Expires September 6, 2007 [Page 38] Internet-Draft MCoA March 2007 Appendix B. Changes From Previous Versions Changes from draft-ietf-monami6-multiplecoa-01.txt o Updating the text of BID definition. The older text was unclear whether a BID is assigned to a binding or a interface. It is now clearly defined that BID is assigned to each binding. o Removing R flag according to complexity. o Introducing O (Overwrite) flag. This flag is useful when a MN sends all the active CoAs to HA or CN all at once. It also useful when a MN reboots and sends a first BU to HA and CN. see Section 5.11 in detail. o Removing the Binding Error texts, since there is no way to know BID when BE is sent by CN. o Clearing up the Status code of Binding Unique Identifier sub- option and Binding Acknowledgment. Renewing the texts in Section 6.3. o Adding new section "Sending Packets to HA" and "Receiving Packets from MN". o adding how to handle correspondent nodes which do not support MCoA extension in Section 5.2. o Return routability is now extended to carry and use BID to generate Authenticator. Section 6.2 and Section 5.2 are added. o Adding a new section: IPsec and IKEv2 interaction. o Shortening Introduction. We also remove several useless texts in this doc. Wakikawa, et al. Expires September 6, 2007 [Page 39] Internet-Draft MCoA March 2007 Authors' Addresses Ryuji Wakikawa Keio University Department of Environmental Information, 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 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, et al. Expires September 6, 2007 [Page 40] Internet-Draft MCoA March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, et al. Expires September 6, 2007 [Page 41]