MEXT Working Group R. Wakikawa (Ed.) Internet-Draft Toyota ITC/Keio Univ. Intended status: Standards Track V. Devarapalli (Ed.) Expires: September 7, 2009 Wichorus T. Ernst INRIA K. Nagami INTEC NetCore March 6, 2009 Multiple Care-of Addresses Registration draft-ietf-monami6-multiplecoa-12.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 7, 2009. Copyright Notice Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 1] Internet-Draft MCoA March 2009 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 2] Internet-Draft MCoA March 2009 Abstract According to the current Mobile IPv6 specification, a mobile node may have several care-of addresses, but only one, called the primary care-of address, that can be registered with its home agent and the correspondent nodes. However, for matters of cost, bandwidth, delay, etc, it is useful for the mobile node to get Internet access through multiple accesses simultaneously, in which case the mobile node would be configured with multiple active IPv6 care-of addresses. This document proposes extensions to the Mobile IPv6 protocol to register and use multiple care-of addresses. The extensions proposed in this document can be used by Mobile Routers using the NEMO (Network Mobility) Basic Support protocol as well. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 4. Mobile IPv6 Extensions . . . . . . . . . . . . . . . . . . . . 13 4.1. Binding Cache Structure and Binding Update List . . . . . 13 4.2. Binding Update Message . . . . . . . . . . . . . . . . . . 13 4.3. Binding Identifier Mobility Option . . . . . . . . . . . . 14 4.4. New Status Values for Binding Acknowledgement . . . . . . 15 5. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 18 5.1. Management of Care-of Address(es) and Binding Identifier(s) . . . . . . . . . . . . . . . . . . . . . . 18 5.2. Binding Registration . . . . . . . . . . . . . . . . . . . 18 5.3. Bulk Registration . . . . . . . . . . . . . . . . . . . . 19 5.4. Binding De-Registration . . . . . . . . . . . . . . . . . 20 5.5. Returning Home: Using Single Interface . . . . . . . . . . 20 5.5.1. Using only Interface attached to the Home Link . . . . 21 5.5.2. Using only Interface attached to the Visited Link . . 21 5.6. Returning Home: Simultaneous Home and Visited Link Operation . . . . . . . . . . . . . . . . . . . . . . . . 21 5.6.1. Problems of Simultaneous Home and Foreign Attachments . . . . . . . . . . . . . . . . . . . . . 21 5.6.2. Overview and Approach . . . . . . . . . . . . . . . . 22 5.6.3. Sending Deregistration Binding Update . . . . . . . . 23 5.6.4. Sending Binding Acknowledgement . . . . . . . . . . . 24 5.6.5. Home Binding for Flow Binding Support . . . . . . . . 25 5.6.6. Sending Packets from the Home Link . . . . . . . . . . 26 5.6.7. Leaving from the Home Link . . . . . . . . . . . . . . 27 Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 3] Internet-Draft MCoA March 2009 5.7. Receiving Binding Acknowledgement . . . . . . . . . . . . 27 5.8. Receiving Binding Refresh Request . . . . . . . . . . . . 28 5.9. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 29 6. Home Agent and Correspondent Node Operation . . . . . . . . . 30 6.1. Searching Binding Cache with Binding Identifier . . . . . 30 6.2. Processing Binding Update . . . . . . . . . . . . . . . . 30 6.3. Sending Binding Refresh Request . . . . . . . . . . . . . 33 6.4. Receiving Packets from Mobile Node . . . . . . . . . . . . 33 7. Network Mobility Applicability . . . . . . . . . . . . . . . . 34 8. DSMIPv6 Applicability . . . . . . . . . . . . . . . . . . . . 35 8.1. IPv4 Care-of Address Registration . . . . . . . . . . . . 35 8.2. IPv4 Home Address Management . . . . . . . . . . . . . . . 36 9. IPsec and IKEv2 interaction . . . . . . . . . . . . . . . . . 38 9.1. Use of Care-of Address in the IKEv2 exchange . . . . . . . 38 9.2. Transport Mode IPsec protected messages . . . . . . . . . 39 9.3. Tunnel Mode IPsec protected messages . . . . . . . . . . . 39 9.3.1. Tunneled Home Test Init and Home Test messages . . . . 39 9.3.2. Tunneled Payload Traffic . . . . . . . . . . . . . . . 40 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 4] Internet-Draft MCoA March 2009 1. Introduction A mobile node may use various types of network interfaces to obtain durable and wide area network connectivity. This has increasingly become true with mobile nodes having multiple interfaces such as 802.2, 802.11, 802.16, cellular radios, etc. The motivations for and benefits of using multiple points of attachment are discussed in [ID- MOTIVATION]. When a mobile node with multiple interfaces uses Mobile IPv6 [RFC-3775] for mobility management, it cannot use its multiple interfaces to send and receive packets while taking advantage of session continuity provided by Mobile IPv6. This is because Mobile IPv6 allows the mobile node to only bind one care-of address at a time with its home address. See [ID-MIP6ANALYSIS] for a further analysis of using multiple interfaces and addresses with Mobile IPv6. This document proposes extensions to Mobile IPv6 to allow a mobile node to register multiple care-of addresses for a home address and create multiple binding cache entries. A new Binding Identification (BID) number is created for each binding the mobile node wants to create and sent in the Binding Update. The home agent that receives this Binding Update creates a separate binding for each BID. The BID information is stored in the corresponding binding cache entry. The BID information can now be used to identify individual bindings. The same extensions can also be used in Binding Updates sent to the correspondent nodes. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 5] Internet-Draft MCoA March 2009 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 to or as a replacement of these, the following terms are defined or redefined: Binding Identification number (BID) The BID is an identification number used to distinguish multiple bindings registered by the mobile node. Assignment of distinct BIDs allows a mobile node to register multiple binding cache entries for a given home address. The BIDs assigned to a same home address must not be duplicated at a time. Zero value is reserved for future extension. Each BID is generated and managed by a mobile node. The BID is stored in the binding update List and is sent by the mobile node in the Binding Update. A mobile node may change the value of a BID at any time according to its administrative policy, for instance to protect its privacy. An implementation must carefully assign the BID so as to keep using the same BID for the same binding even when the status of the binding is changed. More details can be found in Section 5.1. Binding Identifier Mobility Option The Binding Identifier mobility option is used to carry the BID information. Bulk Registration A mobile node can register multiple bindings at once by sending a single Binding Update. A mobile node can also replace some or all the bindings available at the home agent with the new bindings by using the bulk registration. Bulk registration is supported only for home registration (i.e. with the home agent) as explained in Section 5.3. A mobile node must not perform bulk registration mechanism described in this specification with a correspondent node. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 6] Internet-Draft MCoA March 2009 3. Protocol Overview A new extension called the Binding identification number (BID) is introduced to distinguish between multiple bindings pertaining to the same home address. If a mobile node configures several IPv6 global addresses on one or more of its interfaces, it can register these addresses with its home agent as care-of addresses. If the mobile node wants to register multiple bindings, it MUST generate a BID for each care-of address and store the BID in the binding update list. A mobile node can manipulate each binding independently by using the BIDs. The mobile node then registers its care-of addresses by sending a Binding Update with a Binding Identifier mobility option. The BID is included in the Binding Identifier mobility option. After receiving the Binding Update with a Binding Identifier mobility option, the home agent MUST copy the BID from the Binding Identifier mobility option to the corresponding field in the binding cache entry. If there is an existing binding cache entry for the mobile node, and if the BID in the Binding Update does not match the one with the existing entry, the home agent MUST create a new binding cache entry for the new care-of address and BID. The mobile node can register 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 as described in [RFC-3775]. This includes managing a Care-of Keygen token per care-of address and exchanging Care-of Test Init and Care-of Test message with the correspondent node for each care-of address. The mobile node MAY use the same BID that it used with the home agent for a particular care-of address. For protocol simplicity, bulk registration to correspondent nodes is not supported in this document. This is because the Return Routability mechanism introduced in [RFC-3775] cannot be easily extended to verify multiple care-of addresses stored in a single Binding Update. Figure 1 illustrates the configuration where the mobile node obtains multiple care-of addresses at foreign links. The mobile node can utilize all the care-of addresses. In Figure 1, the home address of the mobile node (MN) is 2001:db8::EUI. The mobile node has 3 different interfaces and possibly acquires care-of addresses 1-3 (CoA1, CoA2, CoA3). The mobile node assigns BID1, BID2 and BID3 to each care-of address. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 7] Internet-Draft MCoA March 2009 +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +----+---+-+ +--+-+ CoA2| | | | Home Link +--+--+ | | ------+------ | MN +--------+ | +--+--+ CoA1 | CoA3| | +---------------+ Binding Cache Database: home agent's binding (Proxy neighbor advertisement is active) binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] binding [2001:db8::EUI BID3 care-of address3] correspondent node's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] binding [2001:db8::EUI BID3 care-of address3] Figure 1: Multiple Care-of Address Registration If the mobile node decides to act as a regular mobile node compliant with [RFC-3775], it 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 the BID even if it has only a single binding that is active. Binding cache lookup is done based on the home address and BID information if a BID is available. This is different from RFC 3775, where only the home address is used for binding cache lookup. Binding cache lookup is operated for either protocol signaling and data packets. For the protocol signaling such as a Binding Update, BID should be always carried by a BID sub-option in a protocol signaling. Therefore, a correspondent binding cache that matches the specified BID MUST be found from the binding cache database. On the other hand, for the data packets, no BID information is carried in a packet. The binding cache lookup may involve policy or flow filters to retrieve a correspondent BID per packet in cases where some policy or flow filters are used to direct a certain packet or flow to a particular care-of address. However, the binding cache lookup using policy or flow filters is out of scope for this document. If no such Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 8] Internet-Draft MCoA March 2009 mechanism is available and no BID is found for a packet, a node SHOULD use the binding which was last verified by receiving data packets or signaling from the mobile node. In case the binding cache lookup for data packets, using the combination of home address and BID, does not return a valid binding cache entry, the home agent SHOULD perform the lookup based on only the home address as described in [RFC-3775]. In any case, to avoid problems with upper layer protocols and TCP in particular, a single packet flow as identified by the 5-tuple SHOULD only be sent to a single care-of address at a time. The mobile node may return to the home link through one of its interfaces. There are two options possible for the mobile node when its returns home. Section 5.6 and Section 5.5.1 describe the returning home procedures in more detail. 1. The mobile node uses only the interface with which it attaches to the home link. This is illustrated in Figure 2. It de-registers all bindings with the home agent related to all care-of addresses. The interfaces still attached to the visited link(s) are no longer going to be receiving any encapsulated traffic from the home agent. On the other hand, the mobile node can continue communicating with the correspondent node from the other interfaces attached to foreign links by using route optimization. Even if the mobile node is attached to the home link, it can still send Binding Updates for other active care-of addresses (CoA1 and CoA2) to correspondent nodes. Since the correspondent node has bindings, packets are routed to each Care-of Addresses directly. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 9] Internet-Draft MCoA March 2009 +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +----+-----+ +--+-+ CoA2| | | Home Link +--+--+ | --+---+------ | MN +--------+ | +--+--+ CoA1 | | | +---------------------------+ Binding Cache Database: home agent's binding none correspondent node's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] Figure 2: Using only Interface Attached to Home Link 2. The mobile node may simultaneously use both the interface attached to the home link and the interfaces still attached to the visited link(s) as shown in Figure 3. There are two possible topologies depending on whether the home agent is the only router on the home link or not. The operation of Neighbor Discovery [RFC-4861] is different in the two topologies. More details can be found in Section 5.6. The home agent and the correspondent node have the binding entries listed in Figure 3 in their binding cache database in both topologies. The home agent also knows that the mobile node is attached to the home link. All the traffic from the Internet is intercepted by the home agent first and routed to either the interface attached to the home link or the one of the foreign links. How the home agent decides to route a particular flow to the interface attached to the home link or foreign link is out of scope in this document. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 10] Internet-Draft MCoA March 2009 Topology-a) +----+ | CN | +--+-+ | +---+------+ +----+ +------+ Internet |----------+ HA | | +----+-----+ +--+-+ CoA2| | | Home Link +--+--+ | --+---+------ | MN +--------+ | +--+--+ CoA1 | | | +---------------------------+ Topology-b) +----+ | CN | +--+-+ | +---+------+ Router +----+ +------+ Internet |-------R | HA | | +----+-----+ | +--+-+ CoA2| | | | Home Link +--+--+ | --+-+-------+------ | MN +--------+ | +--+--+ CoA1 | | | +---------------------------+ Binding Cache Database: home agent's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] correspondent node's binding binding [2001:db8::EUI BID1 care-of address1] binding [2001:db8::EUI BID2 care-of address2] Figure 3: Simultaneous Home and Visited Link Operation This specification keeps backwards compatibility with [RFC-3775]. If a receiver (either home agent or correspondent node) does not support this specification, it does not understand the binding identifier mobility option. The receiver skip the unknown mobility option (i.e. Binding Identifier mobility option) and process the Binding Update as defined in [RFC-3775]. In order to keep the backward compatibility Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 11] Internet-Draft MCoA March 2009 with [RFC-3775], when a mobile node sends a Binding Update message with extensions described in this document, the receiver needs to reflect the Binding Identifier mobility option in the Binding Acknowledgement. If the mobile node finds no Binding Identifier mobility options in the received Binding Acknowledgement, it assumes the other end node does not support this specification. In such case, the mobile node needs to fall back to the legacy RFC-3775 compliant mobile node. If it is the home registration, the mobile node MAY try to discover another home agent supporting Binding Identifier mobility option for the home registration. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 12] Internet-Draft MCoA March 2009 4. Mobile IPv6 Extensions This section summarizes the extensions to Mobile IPv6 necessary for manage multiple bindings. 4.1. Binding Cache Structure and Binding Update List The BID is required to be stored in the binding cache and binding update list structure. The sequence number value MUST be shared among all the binding update list entries related to Binding Updates sent to a particular home agent or correspondent node. Whenever a mobile node sends either an individual or a bulk Binding Update, the sequence number is incremented. When a home agent receives an individual Binding Update, it should update the sequence number for all the bindings for a particular mobile node with the sequence number in the received Binding Update. 4.2. Binding Update Message This specification extends the Binding Update message with a new flag. The flag is shown and described below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|F|T|O| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Binding Update message Overwrite (O) flag When this flag is set, all the binding cache entries for a mobile node are replaced by new entries registering with this Binding Update message. This flag is only used when BID Mobility Option is carried with Binding Update. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 13] Internet-Draft MCoA March 2009 Reserved 6 bits Reserved field. 4.3. Binding Identifier Mobility Option The Binding Identifier mobility option is included in the Binding Update, Binding Acknowledgement, Binding Refresh Request, and Care-of Test Init and Care-of Test message. The Binding Identifier Mobility Option has an alignment requirement of 2n if the Care-of Address field is not present. Otherwise, it has the alignment requirement of 8n + 2. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Binding ID (BID) | Status |H| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ + + : IPv4 or IPv6 care-of address (CoA) : + + +---------------------------------------------------------------+ Figure 5: BID Mobility Option Type Type value for Binding Identifier is TBD Length 8-bit unsigned integer. Length of the option, in octets, excluding the Type and Length fields. It MUST be set to either 4, 8, or 20 depending on the care-of address field. When the care-of address is not carried by this option, the length value MUST be set to 4. If the IPv4 care-of address is stored in the care-of address field, the length MUST be 8. Otherwise, the Length value MUST be set to 20 for IPv6 care-of address. Binding ID (BID) The BID which is assigned to the binding indicated by the care-of address in the Binding Update or the Binding Identifier mobility option. The BID is a 16-bit unsigned integer. The value of zero is reserved and MUST NOT be used. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 14] Internet-Draft MCoA March 2009 Status The Status field is an 8-bit unsigned integer. When the Binding Identifier mobility option is included in a Binding Acknowledgement, this field overwrites the status field in the Binding Acknowledgement only for this BID. If this field is set to zero, the receiver ignores this field and uses the registration status stored in the Binding Acknowledgement message. The receiver MUST ignore this field if the Binding Identifier mobility option is not carried within either the Binding Acknowledgement or the Care-of Test messages. The possible status codes are the same as the status codes of Binding Acknowledgement. This Status field is also used to carry error information related to the care-of address test in the Care-of Test message. Simultaneous Home and Foreign Binding (H) flag This flag indicates that the mobile node registers multiple bindings to the home agent while is attached to the home link. This flag is valid only for a Binding Update sent to the home agent. Reserved 7 bits Reserved field. The value MUST be initialized to zero by the sender, and SHOULD be ignored by the receiver. Care-of Address If a Binding Identifier mobility option is included in a Binding Update for the home registration, either IPv4 or IPv6 care-of address for the corresponding BID can be stored in this field. For the binding registration to correspondent nodes (i.e. route optimization), only IPv6 care-of address can be stored in this field. If no address is specified in this field, the length of this field MUST be zero (i.e. not appeared in the option). If no address is specified in this field, a care-of address is taken from the source address field of the IPv6 header of the Binding Update. If the option is included in any other messages than a Binding Update, the length of this field MUST be also zero. 4.4. New Status Values for Binding Acknowledgement New status values for the status field in a Binding Acknowledgement are defined for handling the multiple Care-of Addresses registration: Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 15] Internet-Draft MCoA March 2009 MCOA NOTCOMPLETE (TBD less than 128) In bulk registration, not all the binding identifier mobility options were successfully registered. Some of them were rejected. The error status value of the failed mobility option is individually stored in the status field of the binding identifier mobility option. MCOA RETURNHOME WO/NDP (TBD less than 128) When a mobile node returns home, it MUST NOT use Neighbor Discovery Protocol (NDP) for the home address on the home link. This is explained in more detail in Section 5.6 MCOA MALFORMED (TBD more than 128) Registration failed because Binding Identifier mobility option was not formatted correctly. This value is used in the following cases. * when the wrong length value is specified (neither 4, 8 nor 20) in the length field of the Binding Identifier mobility option. * when a unicast routable address is not specified in the care-of address field of the Binding Identifier mobility option. * when a care-of address is not appeared in the care-of address field of the Binding Identifier mobility option stored in an IPsec ESP protected Binding Update. 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). MCOA PROHIBITED(TBD more than 128) It implies the multiple care-of address registration is administratively prohibited. MCOA BULK REGISTRATION PROHIBITED(TBD more than 128) Bulk binding registration is not either permitted or supported. Note that the bulk registration is an optional procedure and might not be available on a home agent. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 16] Internet-Draft MCoA March 2009 MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD more than 128) Simultaneous home and foreign attachment is neither supported nor permitted. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 17] Internet-Draft MCoA March 2009 5. Mobile Node Operation 5.1. Management of Care-of Address(es) and Binding Identifier(s) There are two cases when a mobile node might acquire several care-of addresses. A mixture of the two cases is also possible. Note that a mobile node can use BID regardless of the number of interfaces and care-of addresses. Whether a mobile node uses BID or not is determined by a local configuration. 1. A mobile node is using several physical network interfaces and acquires a care-of address on each of its interfaces. 2. A mobile node uses a single physical network interface, but receives advertisements for multiple prefixes on the link the interface is attached to. This will result in the mobile node configuring several global addresses on the interface from each of the announced prefixes. The difference between the above two cases is only in the number of physical network interfaces and therefore irrelevant in this document. What is of significance is the fact that the mobile node has several addresses it can use as care-of addresses. A mobile node assigns a BID to each care-of address when it wants to register them simultaneously with its home address. The BID MUST be unique for a given home address. The value is an integer between 1 and 65535. Zero value SHOULD NOT be used as BIDs. 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, at which time all of the care-of addresses MUST be mapped to BIDs. 5.2. Binding Registration For the multiple Care-of Addresses registration, the mobile node MUST include a Binding Identifier mobility option(s) in the Binding Update as shown in Figure 6. The BID is copied from a corresponding binding update List entry to the BID field of the Binding Identifier mobility option. When IPsec ESP is used for protecting the Binding Update, a care-of address MUST be carried in an alternate care-of address mobility option as described in [RFC-4877]. However, in this specification, the care-of address MUST be carried in the Care-of Address field of the Binding Identifier mobility option. In order to save bits of the Binding Update, the alternate care-of address option MUST NOT be included. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 18] Internet-Draft MCoA March 2009 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]) before sending the Binding Update. The care-of Keygen tokens MUST be maintained for each care-of address that the mobile node wants to register to the correspondent node. The Binding Update to the correspondent node is protected by the Binding Authorization Data mobility option that is placed after the Binding Identifier mobility option. IPv6 header (src=Care-of Address, dst=Home Agent Address) IPv6 Home Address Option ESP Header* Mobility header Binding Update Mobility Options Binding Identifier mobility option Binding Authorization mobility option+ (*) if necessary, for home registration (+) if necessary, for route optimization Figure 6: Binding Update for Binding Registration If the mobile node wants to replace existing registered bindings on the home agent with the single binding in the sent Binding Update, it sets the 'O' flag. The single binding will be registered with the assigned BID. Section 6.2 describes this registration procedure in detail. Note that if the mobile node wants to register a RFC-3775 compliant binding (i.e. no BID assigned to that binding), it sends a Binding Update without any Binding Identifier mobility option. 5.3. Bulk Registration Bulk registration is an optimization for binding multiple care-of addresses to a home address using a single Binding Update. This is very useful if the mobile node, for instance, does not want to send a lot of signaling messages through an interface where the bandwidth is scarce. This document specifies bulk registration only for the mobile node's home registration. A mobile node performing bulk registration with a correspondent node is out of scope. To use bulk registration, the mobile node includes a Binding Identifier Mobility option for each BID and Care-of address pair it wants to register in the same Binding Update message. This is shown in Figure 7. The rest of the fields and options in the Binding Update such as Lifetime, Sequence Number, and the flags in the Binding Update are common across all care-of addresses. When IPsec ESP is used for protecting the Binding Update, a care-of Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 19] Internet-Draft MCoA March 2009 address MUST be carried in an alternate care-of address mobility option as described in [RFC-4877]. However, in the bulk registration, the care-of addresses are always carried in the Care-of Address field of the Binding Identifier mobility option. In order to save bits of the Binding Update, the alternate care-of address option MUST NOT be included in such Binding Update. IPv6 header (src=Care-of Address, dst=Home Agent Address) IPv6 Home Address Option ESP Header Mobility header Binding Update Mobility Options Binding Identifier (including Care-of Address) Figure 7: Binding Update for Bulk Registration If the mobile node wants to replace existing registered bindings on the home agent with the multiple bindings in the sent Binding Update, it sets the 'O' flag in the Binding Update. 5.4. Binding De-Registration When a mobile node decides to delete all the bindings for its home address, it sends a regular de-registration Binding Update with lifetime set to zero as defined in [RFC-3775]. The 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, the mobile node sends a Binding Update with lifetime set to zero and includes a Binding Identifier mobility option(s) with the BID(s) it wants to de-register. The receiver will remove only the care-of address(es) that match(es) the specified BID(s). The care-of addresses field in each mobility option SHOULD be omitted by the sender (i.e. the field does not appear in the option) and MUST be ignored by the receiver. This is because the receiver will remove the binding that matches the specified BID. 5.5. Returning Home: Using Single Interface The mobile node may return to the home link, by attaching to the home link through one of its interfaces. When the mobile node wants to return home, it should be configured with information on what interface it needs to use. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 20] Internet-Draft MCoA March 2009 5.5.1. Using only Interface attached to the Home Link The mobile node returns home and de-registers all the bindings as shown in Figure 2 and as defined in [RFC-3775]. De-registering all the bindings is the same as binding de-registration from foreign link described in Section 5.4. After the de-registration step, all the packets routed by the home agent are only forwarded to the interface attached to the home link, even if there are other active interfaces attached to the visited link(s). While the mobile node de-registers all the bindings from the home agent, it may continue registering bindings for interface(s) attached to visited link(s) to the correspondent node as shown in Figure 2. 5.5.2. Using only Interface attached to the Visited Link The mobile node returns home physically but shuts down the interface attached to the home link. As a result, a mobile node does not return home even though it attaches to the home link by one of interfaces. Following procedures should be taken by the mobile node. Before shutting down the interface, any binding for the care-of address previously associated with the interface should be deleted. To delete the binding cache entry, the mobile node SHOULD send a de- registration Binding Update with the lifetime set to zero and include the corresponding BID information. If the mobile node does not send a de-registration Binding Update, the binding for the care-of address previously assigned to the interface remains at the home agent until its lifetime expires. In this scenario, despite the fact that the mobile node is connected to its home link, all of its traffic is sent and received via the home agent and its foreign links. 5.6. Returning Home: Simultaneous Home and Visited Link Operation 5.6.1. Problems of Simultaneous Home and Foreign Attachments The mobile node returns home and continues using all the interfaces attached to both foreign and home links as shown in Figure 3. The mobile node indicates this by setting the 'H' flag in the Binding Identifier mobility option as defined below. There are additional requirements on the Returning Home procedures for possible Neighbor Discovery state conflicts at the home link. In [RFC-3775], the home agent intercepts packets meant for the mobile node using Proxy Neighbor Discovery [RFC-4861] while the mobile node is away from the home link. When the mobile node returns home, the home agent deletes the binding cache and stops proxying for the home address so that a mobile node can configure its home address on the Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 21] Internet-Draft MCoA March 2009 interface attached to the home link. In this specification, a mobile node may return home, configure the home address on the interface attached to the home link, but still use the interfaces attached to the foreign links. In this case, a possible conflict arises when the both the home agent and the mobile node try to defend the home address. If the home agent stops proxying for the home address, the packets are always routed to the interface attached to the home link and are never routed to the interfaces attached to the visited links. It is required to avoid the conflict between the home agent and the mobile node, while still allowing the simultaneous use of home and foreign links. The following describes the mechanism for achieving this. 5.6.2. Overview and Approach In this scenario, 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 intercepts all the packets even when the mobile node is attached to the home link through one of its interfaces. The home agent would make this decision based on the type of flow. How to make this decision is out of scope in this document. Two scenarios are illustrated in Figure 3, depending on whether the Home Agent is the only router at the home link or not. The difference is on who defends the home address by (Proxy) Neighbor Discovery on the home link. 1. Mobile node defends the home address by the regular Neighbor Discovery Protocol (illustrated as topology-a in Figure 3). The home agent is the only router on the home link. Therefore the home agent is capable of intercepting packets without relying on the proxy Neighbor Discovery protocol and the mobile node can manage the Neighbor Cache entry of the home address on the home link as a regular IPv6 node. However, there is one limitation of this scenario. If a correspondent node is located at the home link, the home agent may not intercept the packets destined to the mobile node. These packets are routed only via the home link, but this is the most optimal path for the mobile node to communicate with nodes on the home link. 2. If there are other routers on the home link apart from the home agent, then it cannot be guaranteed that all packets meant for the mobile node are routed to the home agent. In this case, the mobile node MUST NOT operate the Neighbor Discovery protocol for the home address on the home link. This allows the home agent to keep using proxy neighbor discovery and thus it keeps receiving all the packets sent to the mobile node's home address. If the Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 22] Internet-Draft MCoA March 2009 home agent, according to its local policy, needs to deliver packets to the mobile node over the home link, an issue arises with respect to how the home agent discovers the mobile node's link local address. This specification uses the Mobility Header Link-layer Address Option defined in [RFC-5268] in order to carry the mobile node's link-layer address in the Binding Update. Likewise, the mobile node would also know the link-layer address of the default router address to send packets from the home link without Neighbor Discovery. The link-layer address is used to transmit packets from and to the mobile node on the home link. The packets are transmitted without the Neighbor Discovery protocol by constructing the link-layer header manually. This operation is similar to Mobile IPv6 [RFC-3775] when a mobile node sends a deregistration binding update to the home agent's link- layer address in the operation for returning home. 5.6.3. Sending Deregistration Binding Update o As soon as a mobile node returns home, it sends a de-registration Binding Update to the home agent from the interface attached to the home link. Note that if the mobile node runs the flow binding [ID-FLOWBINDING], it MAY create its home binding and continue registering its binding to the home agent from the home link. The mobile node does not need to operate binding deregistration described in this section. The detail operation can be found in Section 5.6.5 o The mobile node MUST include the Binding Identifier mobility option specifying the BID the mobile node had previously associated with the interface attached to the home link. The 'H' flag MUST be set in the Binding Identifier mobility option. For the binding deregistration, a mobile node SHOULD NOT store a care-of address in the Care-of Address field of the Binding Identifier mobility option. The receiver, the home agent, can match the removed binding with BID value in the Binding Identifier mobility option. o If the mobile node has to remove multiple bindings simultaneously, it overwrites the existing binding entries by using 'O' flag and should not send Binding Update messages for removing multiple care-of addresses. The mobile node contains multiple Binding Identifier mobility options for the active care-of addresses and sets 'O' flag in the Binding Update message. o When the 'H' flag is set, the home agent recognizes that the mobile node wants to continue using interfaces attached to both home and visited links. Note that H flag MUST be set for the subsequent Binding Updates sent from the mobile node (ex. Binding Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 23] Internet-Draft MCoA March 2009 Update for the interface(s) attached to the foreign link(s)). If the home agent does not allow this scenario, it MUST send a Binding Acknowledgement with the status code [MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED] set. o The mobile node SHOULD include the Mobility Header Link-layer Address Option [RFC-5268] to notify the mobile node's link-layer address to the home agent, too. The option code of the Mobility Header Link-layer Address option MUST be set to '2' (Link-layer Address of the mobile node). This link-layer address is required for the home agent to send the Binding Acknowledgement and to forward the mobile node's packet. o According to [RFC-3775], the mobile node MUST start responding to Neighbor Solicitation for its home address right after it sends the deregistration Binding Update to the home agent. However, in this specification, the mobile node MUST NOT respond to Neighbor Solicitation before receiving a Binding Acknowledgement, since the home agent may continue proxying for the home address. If the mobile node receives [MCOA RETURNHOME WO/NDP (TBD)] status value in the received Binding Acknowledgment, it MUST NOT respond to Neighbor Solicitation even after the Binding Acknowledgement. 5.6.4. Sending Binding Acknowledgement The operations described in this section is for Home Agent and not for Mobile Node. However, the Home Agent operations described in this section are related to the returning home using simultaneous use of home and foreign links. o When the home agent sends the Binding Acknowledgement after successfully processing the binding de-registration, it MUST set the status value to either 0 [Binding Update Accepted] or to [MCOA RETURNHOME WO/NDP (TBD)] in the Status field of the Binding Acknowledgment depending on home agent configuration at the home link. The new values are: * Binding Update Accepted (0): Neighbor Discovery Protocol is permitted for the home address at the home link. This is regular returning home operation of [RFC-3775] * MCOA RETURNHOME WO/NDP (TBD): Neighbor Discovery Protocol is prohibited for the home address at the home link The respective Binding Identifier mobility options need to be included in the Binding Acknowledgement. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 24] Internet-Draft MCoA March 2009 o If the Binding Update is rejected, the appropriate error value MUST be set in the status field. In this case, the home agent operation is the same as [RFC-3775]. o Only if the home agent is certainly the only router in the home link, it MAY turn off Neighbor Discovery for the requested home address and responds with the [Binding Update Accepted] status value to the mobile node. Since the mobile node will not reply to Neighbor Solicitation for the home address before receiving the Binding Acknowledgement, the home agent SHOULD use the link-layer address carried by the Link Layer Address option [RFC-5268] in the received Binding Update. After the completion of the binding deregistration, the mobile node starts regular Neighbor Discovery operations for the home address on the home link. The neighbor cache entry for the home address is created by the regular exchange of Neighbor Solicitation and Neighbor Advertisement. o On the other hand, the home agent returns [MCOA RETURNHOME WO/NDP] value in the Status field of the Binding Identifier mobility option. The home agent learns the mobile node's link-layer address by receiving the Mobility Header link-layer address option carried by the Binding Update. It stores the link-layer address as a neighbor cache entry for the mobile node so that it can send the packets to the mobile node's link-layer address. o Note that the use of proxy Neighbor Discovery is an easier way to intercept the mobile nodes' packets instead of IP routing in some deployment scenarios. Therefore, even if a home agent is the only router, it is an implementation and operational choice whether the home agent returns [Binding Update Accepted] or [MCOA RETURNHOME WO/NDP]. o If BID option is not included in the Binding Acknowledgement, the home agent might not recognize the simultaneous home and foreign attachment. The home agent might have processed the de- registration Binding Update as a regular de-registration as described in [RFC-3775] and deletes all the registered binding cache entries for the mobile node. Thus, the mobile node SHOULD stop using the interface attached to foreign link and use only the interface attached to the home link. 5.6.5. Home Binding for Flow Binding Support The Flow Binding extensions [ID-FLOWBINDING] allows nodes to bind one or more flows to a care-of address (BID). If a mobile node returns home and deletes its binding for the interface attached to the home link, flow bindings cannot be specified to that interface. Thus, it is necessary to keep the BID for the interface attached to the home Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 25] Internet-Draft MCoA March 2009 link. For this purpose, if the Flow Binding is being used, the home agent MAY create a home binding where the care-of address is equal to the mobile node's home address. This home binding is conceptual data structure and can be implementation specific. The home binding is created only when the mobile node is present at both the home and foreign links. The home binding is created when a mobile node requests by sending a Binding Update. When the home binding is used, the binding de-registration operation described in Section 5.6.3 is not necessary. Instead of sending a deregistering binding update, the mobile node needs to send a registering binding update with a Binding Identifier mobility option which H flag is set. The lifetime is set to the requesting lifetime of the home binding. Once the home agent receives the Binding Update, it creates a home binding as described in Section 5.2 except for one point. The main difference of the home binding is that the care-of address is set to the home address. The home agent needs to treat this binding as a home binding. The management of the home binding is same as the binding management described in this specification. The home binding can be also created by bulk binding registration (Section 5.3). The mobile node stores its home address in the care-of address field of the Binding Identifier mobility option and sets H flag to the option. It needs to refresh the lifetime of the home binding by sending Binding Updates. 5.6.6. Sending Packets from the Home Link o When the mobile node receives the Binding Acknowledgement with the status value 'Binding Update Accepted' and the BID option, it can configure its home address to the interface attached to the home link and start operating Neighbor Discovery for the home address on the home link. Packets can be transmitted from and to the mobile node as if the mobile node is a regular IPv6 node. o If the mobile node receives the status [MCOA RETURNHOME WO/NDP] in the Binding Acknowledgement, it MUST NOT operate Neighbor Discovery for the home address. When the mobile node sends packets from the interface attached to the home link, it MUST learn the link-layer address of the next hop (i.e. default router of the mobile node). A mobile node learns the default router's link-layer address from a Source Link-Layer Address option in Router Advertisements. The mobile node sends packets directly to the default router's link-layer address. This is done by constructing the packet including a link-layer header with the learned link-layer address of the default router. The home agent also forwards the packet to the mobile node on the home link by Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 26] Internet-Draft MCoA March 2009 using the mobile node's link-layer address. The link-layer address SHOULD be cached when the home agent received the deregistration Binding Update message. Note that the default router MUST NOT cache the mobile node's link-layer address in the neighbor cache when it forwards the packet from the mobile node to the home agent. 5.6.7. Leaving from the Home Link o When the mobile node detaches from the home link, it SHOULD immediately send a Binding Update for one of active care-of address with H flag unset. When the 'H' flag of BID option is unset in any Binding Update, the home agent stop forwarding the mobile node's packets to the home link. 5.6.7.1. Changing Behavior during the attachment to the home link If a mobile node decides to return home completely without any active foreign link attachment, it simply sends a deregistration Binding Update as described in Section 5.5.1. Once the home agent receives such de-registration Binding Update, the home agent clears all the binding(s) and state for the mobile node. If a mobile node decides to stop using the interface attached to the home link, it simply sends a Binding Update from one of the active care-of addresses. In the Binding Update, the mobile node should include the BID option for the care-of address and unset the H flag of the BID option. The home agent clears the state of the mobile node for the interface attached to the home link and stops forwarding the packets to the mobile node on the home link. 5.7. Receiving Binding Acknowledgement The verification of a Binding Acknowledgement is the same as Mobile IPv6 (section 11.7.3 of [RFC-3775]). The operation for sending a Binding Acknowledgement is described in Section 6.2. If a mobile node includes a Binding Identifier mobility option in a Binding Update with the 'A' flag set, a Binding Acknowledgement MUST carry a Binding Identifier mobility option. According to [RFC-3775], the receiver of the Binding Update ignores unknown mobility options and processes the Binding Update without the unknown mobility option. Therefore, if no such mobility option is included in the Binding Acknowledgement in response to a Binding Update for multiple care-of address registration, this indicates that the originating node of the Binding Acknowledgement does not support processing the Binding Identifier mobility option regardless of status value. In such case, the receiver of the Binding Update may create a regular binding. The Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 27] Internet-Draft MCoA March 2009 mobile node then no longer attempts multiple care-of address registration with that node. If this occurs with home registration the mobile node MAY attempt to discover another home agent supporting Binding Identifier mobility option for the home registration. If a Binding Identifier mobility option is present in the received Binding Acknowledgement, the mobile node checks the status field in the option. If the status value in the Binding Identifier mobility option is zero, the mobile node uses the value in the Status field of the Binding Acknowledgement. Otherwise, it uses the value in the Status field of the Binding Identifier mobility option. If the status code is greater than or equal to 128, the mobile node starts relevant operations according to the error code. Otherwise, the mobile node assumes that the originator (home agent or correspondent node) successfully registered the binding information and BID for the mobile node. o If the Status value is [MCOA PROHIBITED], the mobile node MUST stop registering multiple bindings with the node that sent the Binding Acknowledgement. o If the Status value is [MCOA BULK REGISTRATION NOT SUPPORT], the mobile node needs to stop using bulk registrations with the node that sent the Binding Acknowledgement. It should assume that none of the attempted registrations were successful. o If [MCOA MALFORMED] is specified, it indicates that the binding identifier mobility option is formatted wrongly presumably due to a programming error or major packet corruption. . 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 needs to stop sending Binding Updates with BID, or SHOULD use the 'O' flag to reset all the registered bindings as described in Section 5.9. 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 6.3. If a mobile node receives a Binding Refresh Request with a Binding Identifier mobility option, it indicates that the node sending the Binding Refresh Request message is requesting the mobile node to send a new Binding Update for the BID. The mobile node SHOULD then send a Binding Update at least for the respective binding. The mobile node Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 28] Internet-Draft MCoA March 2009 MUST include a Binding Identifier mobility option in the Binding Update. 5.9. Bootstrapping When a mobile node bootstraps and registers multiple bindings for the first time, it MUST set the 'O' flag in the Binding Update message. If old bindings still exists at the home agent, the mobile node has no knowledge of which bindings still exist at the home agent. This scenario happens when a mobile node reboots and loses state regarding the registrations. If the 'O' flag is set, all the bindings are replaced by the new binding(s). If the mobile node receives the Binding Acknowledgement with the status code set to 135 [Sequence number out of window], it MUST follow the operations described in [RFC-3775]. The 'O' flag can also be used in individual Binding Updates sent to the correspondent nodes to override any existing binding cache entries at the correspondent node. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 29] Internet-Draft MCoA March 2009 6. Home Agent and Correspondent Node Operation 6.1. Searching Binding Cache with Binding Identifier If either a correspondent node or a home agent has multiple bindings for a mobile node in their binding cache database, it can use any of the bindings to communicate with the mobile node. This section explains how to retrieve the desired binding for the binding management. This document does not provide any mechanism to select the suitable binding for forwarding data packets. A node which is either a correspondent node or a home agent SHOULD use both the home address and the BID as the search key of the binding cache if it knows the corresponding BID (example: when processing signaling messages). In the example below, if a node searches the binding with the home address and BID2, it gets binding2 for this mobile node. binding1 [2001:db8::EUI, care-of address1, BID1] binding2 [2001:db8::EUI, care-of address2, BID2] binding3 [2001:db8::EUI, care-of address3, BID3] Figure 8: Searching the Binding Cache The node learns the BID when it receives a Binding Identifier mobility option. At that time, the node MUST look up its binding cache database with the home address and the BID retrieved from the Binding Update. If the node does not know the BID, it searches for a binding with only the home address. In such a case, the first matched binding is found. If the node does not desire to use multiple bindings for a mobile node, it can simply ignore the BID. 6.2. Processing Binding Update If a Binding Update does not contain a Binding Identifier mobility option, its processing is the same as in [RFC-3775]. 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 one RFC-3775 compliant binding cache entry for the mobile node's home address. If the Binding Update is for de-registration, the receiver MUST delete all existing bindings from its Binding Cache. If the Binding Update contains a Binding Identifier mobility option(s), it is first validated according to section 9.5.1 of [RFC- 3775]. Then the receiver processes the Binding Identifier mobility option(s) as described in the following steps. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 30] Internet-Draft MCoA March 2009 o The length value is examined. The length value MUST be either 4, 8, or 20 depending on the Care-of Address field. If the length is incorrect, the receiver MUST reject the Binding Update and returns the status value set to [MCOA MALFORMED]. o When the Length value is either 8 or 20, the care-of address MUST be present in the Binding Identifier mobility option. If the unicast routable address [RFC-3775] is not present in the care-of address field, the receiver MUST reject the Binding Identifier mobility option and returns the status value set to [MCOA MALFORMED]. o If the Binding Update is protected with IPsec ESP, the care-of address MUST be present in the Binding Identifier mobility option. If no address is present in the care-of address field in the Binding Identifier mobility option, the home agent MUST reject the Binding Identifier mobility option and returns the status value set to [MCOA MALFORMED]. o If the care-of address is present in both the alternate care-of address mobility option and the Binding Identifier mobility option at the same time, the home agent MUST ignore the alternate care-of address mobility option and continue processing the Binding Update with the care-of address from the Binding Identifier mobility option. o When multiple Binding Identifier mobility options are present in the Binding Update, it is treated as bulk registration. If the receiving node is a correspondent node, it MUST reject the Binding Update and returns the status value in the binding Acknowledgement set to [MCOA BULK REGISTRATION NOT SUPPORT]. o If the Lifetime field in the Binding Update is set to zero, the receiving node deletes the binding entry that corresponds to the BID in the Binding Identifier mobility option. If the receiving node does not have an appropriate binding for the BID, it MUST reject the Binding Update and send a Binding Acknowledgement with status set to 133 [not home agent for this mobile node]. o If the 'O' flag is set in the de-registering Binding Update, it is ignored. If the 'H' flag is set, the home agent stores a home address in the Care-of Address field of the binding cache entry. The home agent MUST follow the descriptions described in Section 5.6. o If the Lifetime field is not set to zero, the receiving node registers a binding with the specified BID as a mobile node's binding. The Care-of address is obtained from the Binding Update Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 31] Internet-Draft MCoA March 2009 packet as follows: * If the Length value of the Binding Identifier mobility option is 20, the care-of address is copied the IPv6 address from the care-of address field in the Binding Identifier mobility option. When the Length value is 8, the address MUST be the IPv4 valid address. Detail information can be found in Section 8. * If the Length value of the Binding Identifier mobility option is 4, the care-of address is copied from the source address field of the IPv6 header of the Binding Update. * If the Length value of the Binding Identifier mobility option is 4 and an alternate care-of address is present, the care-of address is copied from the Alternate Care-of address mobility option. o Once the care-of address(es) have been retrieved from the Binding Update, the receiving nodes creates new binding(s). * If the 'O' flag is set in the Binding Update, the home agent removes all the existing bindings and registers the received binding(s). * If the 'O' flag is unset in the Binding Update and the receiver has a regular binding which does not have BID for the mobile node, it must not process the Binding Update. The receiver should sent a Binding Acknowledgement with status set to [MCOA BID CONFLICT]. * If the receiver already has a binding with the same BID but different care-of address, it MUST update the binding and respond with a Binding Acknowledgement with status set to 0 [Binding Update accepted]. * If the receiver does not have a binding entry for the BID, it registers a new binding for the BID and responds with a Binding Acknowledgement with status set to 0 [Binding Update accepted]. If all the above operations are successfully completed, a Binding Acknowledgement containing the Binding Identifier mobility options MUST be sent to the mobile node. Whenever a Binding Acknowledgement is sent, all the Binding Identifier mobility options stored in the Binding Update MUST be copied to the Binding Acknowledgement except the status field. The Care-of address field in each Binding Identifier mobility option, however, MAY be omitted, because the mobile node can match a corresponding binding update list entry using Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 32] Internet-Draft MCoA March 2009 the BID. When a correspondent node sends a Binding Acknowledgement, the status value MUST be always stored in the Status field of the Binding Acknowledgement and the Status field of Binding Identifier mobility option MUST be always set to zero. When the home agent sends a Binding Acknowledgement, the status value can be stored in the Status field of either a Binding Acknowledgement or a Binding Identifier mobility option. If the status value is specific to one of bindings in the bulk registration, the status value MUST be stored in the Status field in the corresponding Binding Identifier mobility option. In this case, the Status field of the Binding Acknowledgement MUST be set to [MCOA NOTCOMPLETE], so that the receiver can examine the Status field of each Binding Identifier mobility option for further operations. Otherwise, the status field of the Binding Identifier mobility option MUST be set to zero and the home agent status field of the Binding Acknowledgement is used. 6.3. Sending Binding Refresh Request When a node (home agent or correspondent node) sends a Binding Refresh Request for a particular binding created with the BID, the node SHOULD include the Binding Identifier mobility option in the Binding Refresh Request. The node MAY include multiple Binding Identifier mobility options if there are multiple bindings that need to be refreshed. 6.4. Receiving Packets from Mobile Node When a node receives packets with a Home Address destination option from a mobile node, it MUST check that the care-of address that appears in the source address field of the IPv6 header MUST be equal to one of the care-of addresses in the binding cache entry. If no binding is found, the packets MUST be discarded. The node MUST also send a Binding Error message as specified in [RFC-3775]. This verification MUST NOT be done for a Binding Update. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 33] Internet-Draft MCoA March 2009 7. Network Mobility Applicability The binding management mechanisms are the same for a mobile host that uses Mobile IPv6 and for a mobile router that is using the NEMO Basic Support protocol [RFC-3963]. Therefore the extensions described in this document can also be used to support a mobile router with multiple care-of addresses. [RFC-4980] is a document for an analysis of NEMO multihoming. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 34] Internet-Draft MCoA March 2009 8. DSMIPv6 Applicability Dual Stack Mobile IPv6 (DSMIPv6) [ID-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 The mobile node can use the extensions described in the document to register multiple care-of addresses, even if some of the care-of addresses are IPv4 address. Bulk registration MUST NOT be used for the initial binding from an IPv4 care-of address. This is because, the Binding Update and Binding Acknowledgement exchange is used to detect NAT on the path between the mobile node and the home agent. So the mobile node needs to check for a NAT between each IPv4 care-of address and the home agent. The Binding Update MUST be sent to the IPv4 home agent address by using UDP and IPv4 headers as shown in Figure 9. It is similar to [ID-DSMIPv6] except that the IPv4 care-of address option MUST NOT be used when the BID mobility option is used. IPv4 header (src=V4ADDR, dst=HA_V4ADDR) UDP Header IPv6 header (src=V6HoA, dst=HAADDR) ESP Header Mobility header -Binding Update Mobility Options - Binding Identifier (IPv4 CoA) *V4ADDR, HA_V4ADDR, V6HOA, HAADDR are defined in [ID-DSMIPv6] Figure 9: Initial Binding Update for IPv4 Care-of Address If a NAT is not detected, the mobile node can update the IPv4 care-of address by using bulk registration. The mobile node can register the IPv4 care-of address along with other IPv4 and IPv6 care-of addresses. Figure 10 shows the Binding Update format when the mobile node sends a Binding Update from one of its IPv6 care-of addresses. If the mobile node sends a Binding Update from IPv4 care-of address, it MUST follow the format described in Figure 9. Note that the IPv4 Care-of Address must be registered by non bulk Binding registration, Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 35] Internet-Draft MCoA March 2009 whenever it is changed. As shown in Figure 9, IPv4 care-of address will be appeared in Binding Identifier mobility option. The IPv4 care-of address mobility option defined in [ID-DSMIP6] MUST always be omitted. The receiver of the Binding Update message for an IPv4 care-of address MUST use the IPv4 address stored in the Binding Identifier mobility option instead of the IPv4 care-of address mobility option. IPv6 header (src=Care-of Address, dst=Home Agent Address) IPv6 Home Address Option ESP Header Mobility header -Binding Update Mobility Options - Binding Identifier (IPv6/v4 CoA) - Binding Identifier (IPv6/v4 CoA) - ... Figure 10: Binding Bulk Registration for IPv4 care-of address When the home agent returns a Binding Acknowledgement for the IPv4 care-of address registration, it SHOULD NOT use the IPv4 address Acknowledgement mobility option and SHOULD use only the Binding Identifier mobility option. The registration status for the IPv4 Care-of address is stored in the Status field of the Binding Identifier mobility option. However, if the home agent needs to store the status value specially defined for the IPv4 address Acknowledgement mobility option, it MUST store the status value in the IPv4 address Acknowledgement mobility option and MUST NOT store it in Binding Identifier mobility option. In such case, the home agent MUST include both the IPv4 address Acknowledgement mobility option and Binding Identifier mobility option. 8.2. IPv4 Home Address Management When the mobile node wants to configure an IPv4 home address in addition to the IPv6 home address, it can request for one using the IPv4 Home Address option in the Binding Update. If the home agent accepts the Binding Update, the mobile node can now register multiple care-of addresses for the IPv4 home address in addition to the IPv6 home address. The mobile node MUST always use the IPv4 home address mobility option for any purposes of the IPv4 home address management. The same set of care-of addresses will be registered for both IPv6 and IPv4 home addresses. The mobile node cannot bind a different set of care-of addresses to each home address. According to [ID-DSMIPv6], the home agent includes the IPv4 address Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 36] Internet-Draft MCoA March 2009 Acknowledgement option in the Binding Acknowledgement only if the mobile node had requested for an IPv4 home address in the corresponding Binding Update. The IPv4 address Acknowledgement option MUST be present before any Binding Identifier mobility option. The status field of the IPv4 address Acknowledgement option contains only the error code defined in Section 4.2.1 of [ID-DSMIP6]. The home agent MUST always include the IPv4 address Acknowledgement mobility option in the Binding Acknowledgement for the IPv4 home address registration. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 37] Internet-Draft MCoA March 2009 9. IPsec and IKEv2 interaction Mobile IPv6 [RFC-3775] and the NEMO protocol [RFC-3963] require the use of IPsec to protect signaling messages including Binding Updates, Binding Acknowledgement and return routability messages. IPsec may also be used protect all 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 [RFC-4877] 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 Home Test Init message or tunneled data traffic to the correspondent node. o The mobile node runs IKEv2 (or IKEv1) with the home agent using the care-of address. The IKE SA is based on the care-of address of the mobile node. The above assumptions may not be valid when multiple care-of addresses are used by the mobile node. In the following sections, the main issues with the use of multiple care-of 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 (Ed.), et al. Expires September 7, 2009 [Page 38] Internet-Draft MCoA March 2009 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. The home agent processes Mobile Prefix Discovery messages with the same rules of data packets described in Section 6.4. 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 Home Test Init and Home Test messages. The mobile node and the home agent may also choose to protect all reverse tunneled payload traffic with IPsec in tunnel mode. The following sections address multiple care-of address support for these two types of messages. 9.3.1. Tunneled Home Test Init and Home Test messages The mobile node MAY use the same care-of address for all Home Test Init messages sent reverse tunneled through the home agent. The mobile node may use the same care-of address irrespective of which correspondent node the Home Test Init message is being 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 Home Test Init message. If a different address is used as the source address, the message is silently dropped by the home agent. This document requires the home agent implementation to decapsulate and forward the Home Test Init message as long as the source address is one of the care-of addresses in the binding cache entry for the mobile node. When the home agent tunnels a Home Test message to the mobile node, the care-of address used in the outer IPv6 header is not relevant to the Home Test message. So regular IPsec tunnel encapsulation with the care-of address known to the IPsec implementation on the home agent is sufficient. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 39] Internet-Draft MCoA March 2009 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 still needs to be aware of which care-of address is being used. According to [RFC-4306], the IPsec implementation on the home agent does not check the source address on the outer IPv6 header. However, the stack on the home agent MUST still be informed about the source address in order to choose the most recently used care-of address, as discussed in Section 3 (in the absence of a user-supplied policy) 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 (Ed.), et al. Expires September 7, 2009 [Page 40] Internet-Draft MCoA March 2009 10. Security Considerations The security considerations for securing the Binding Update and Binding Acknowledgement messages with multiple care-of address are very similar to the security considerations for securing the Binding Update and Binding Acknowledgement. Please see [RFC-3775] for more information. The Binding Update and binding Acknowledgement messages with multiple care-of addresses are securely exchanged as described in [RFC-3775], [RFC-4877] and Section 9. Additional security considerations are described below. With simultaneous binding support, it is possible for a malicious mobile node to successfully bind a number of victims' addresses as valid care-of addresses for the mobile node with its home agent. Once these addresses have been bound, the malicious mobile node can perform a re-direction attack by instructing the home agent (e.g. setting filtering rules to direct a large file transfer) to tunnel packets to the victims' addresses. Such risk is highlighted in [ID- MIP6ANALYSIS]. These attacks are possible because the care-of addresses sent by the mobile node in the Binding Update messages are not verified by the home agent, i.e., the home agent does not check if the mobile node is at the care-of address it is claiming to be. The security model for Mobile IPv6 assumes that there is a trust relationship between the mobile node and its home agent. Any malicious attack by the mobile node is traceable by the home agent. This acts as a deterrent for the mobile node to launch such attacks. Although such a risk exists in Mobile IPv6, the risk level is increased when simultaneous multiple care-of address bindings are performed. In Mobile IPv6, a mobile node can only have a single care-of address binding per home address at a given time. However, for simultaneous multiple care-of address bindings, a mobile node can have more than one care-of address binding per home address at a given time. This implies that a mobile node using simultaneous binding support can effectively bind more than a single victim's address. Another difference is the degree of risk involved. In the single care-of address binding case, once the re-direction attack is initiated, a malicious mobile node would be unable to use its home address for communications (such as to receive control packets pertaining to the file transfer). However, in the simultaneous binding support case, a malicious mobile node could bind a valid care-of address in addition to multiple victims addresses. This valid care-of address could then be used by the malicious mobile node to set up flow filtering rules at its home agent, thereby controlling and/or launching new re-direction attacks. Thus, in view of such risks, it is advisable for a home agent to employ some form of care-of address verification mechanism before Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 41] Internet-Draft MCoA March 2009 using the care-of addresses as a valid routing path to a mobile node. These mechanisms are out-of scope for this document. In the binding registration of Mobile IPv6, a care-of address is always verified its reachability by a home agent. This reachability test may decrease the above risks. However, when bulk registration is used, a home agent cannot verify reachability of care-of addresses carried in a Binding Identifier mobility option. Therefore, the home agent can choose to reject bulk registration by using [MCOA BULK REGISTRATION PROHIBITED] in a Binding Acknowledgement. Alternatively, when a mobile node first registers a care-of address, it uses the individual binding updates for the first appeared care-of address. During the initial binding registration, a home agent can verify the address reachability for that given care-of address. After that, the mobile node uses bulk registration to refresh the care-of address. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 42] Internet-Draft MCoA March 2009 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 [RFC-3775]. o New Successful Status of Binding Acknowledgement: This status code must be assigned from the same space as binding acknowledgement status codes in [RFC-3775]. * MCOA NOTCOMPLETE (TBD) * MCOA RETURNHOME WO/NDP (TBD) o New Unsuccessful Status of Binding Acknowledgement: These status codes must also be assigned from the same space as Binding Acknowledgement status codes in [RFC-3775]. * MCOA MALFORMED (TBD) * MCOA BID CONFLICT (TBD) * MCOA PROHIBITED(TBD) * MCOA BULK REGISTRATION PROHIBITED (TBD) * MCOA SIMULTANEOUS HOME AND FOREIGN PROHIBITED (TBD) Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 43] Internet-Draft MCoA March 2009 12. Acknowledgements The authors would like to special thank George Tsirtsis for thorough review and suggestions. The authors would also like to thank Masafumi Aramoto, Keigo Aso, Julien Charbon, Tero Kauppinen, Benjamin Lim, Martti Kuparinen, Romain Kuntz, Heikki Mahkonen, Nicolas Montavont, Chan-Wah Ng for their discussions and inputs. Thanks to Susumu Koshiba, Hiroki Matutani, Koshiro Mitsuya, Koji Okada, Keisuke Uehara, Masafumi Watari and Jun Murai for earlier work on this subject. 13. References 13.1. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-4861] Narten, T., Nordmark, E., W. Simpson, and H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 2007.. [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC-4877] V. Devarapalli, F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. [ID-DSMIPv6] Soliman, H., "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-07 (work in progress), December 2008. [RFC-5268] R. Koodli, "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. 13.2. Informative References [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 44] Internet-Draft MCoA March 2009 Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivation-scenario-03 (work in progress), May 2008. [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007. [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", draft-ietf-monami6-mipv6-analysis-05 (Work in progress), May 2008. [ID-FLOWBINDING] H. Soliman, N. Montavont, N. Fikouras, and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-ietf-mext-flow-binding-00 (Work in progress), May 2008. [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC-4306] C. Kaufman (Editor), "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 45] Internet-Draft MCoA March 2009 Authors' Addresses Ryuji Wakikawa Toyota ITC / Keio University 6-6-20 Akasaka, Minato-ku Tokyo 107-0052 Japan Phone: +81-3-5561-8276 Fax: +81-3-5561-8292 Email: ryuji@jp.toyota-itc.com Vijay Devarapalli Wichorus 3590 North First St San Jose, CA 95134 USA Email: vijay@wichorus.com 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 Wakikawa (Ed.), et al. Expires September 7, 2009 [Page 46]