MIP6/NEMO Working Group Ryuji Wakikawa INTERNET DRAFT Keio University/WIDE Category: Individual Pascal Thubert 03 Mar 2006 Cisco Systems Vijay Devarapalli Nokia Inter Home Agents Protocol Specification draft-wakikawa-mip6-nemo-haha-spec-01.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 August 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides the protocol specification of the inter Home Agent protocol designed for both Mobile IPv6 and the NEMO Basic Support protocol. This document describes Home Agent configurations, message formats and Mobile Host, Mobile Router, and Home Agent operations. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 1]
Internet Draft HAHA protocol base spec. 03 Mar 2006 Contents Status of This Memo 1 Copyright Notice 1 Abstract 1 1. Introduction 3 2. Terminology 4 3. Variety of Home Agent Configuration 5 3.1. With Home Link . . . . . . . . . . . . . . . . . . . . . 6 3.2. Without Home Link . . . . . . . . . . . . . . . . . . . . 8 4. Message Formats 9 4.1. New Mobility Header Messages . . . . . . . . . . . . . . 9 4.1.1. Home Agent HELLO Message . . . . . . . . . . . . 9 4.1.2. Binding Information Request Message . . . . . . . 10 4.1.3. Binding Information Update Message . . . . . . . 12 4.1.4. Binding Information Acknowledgment Message . . . 13 4.1.5. Home Agent Switch Request Message . . . . . . . . 14 4.2. New Mobility Options . . . . . . . . . . . . . . . . . . 15 4.2.1. IP Address Option . . . . . . . . . . . . . . . . 15 4.2.2. Mobile Network Prefix Option . . . . . . . . . . 15 4.2.3. Binding Cache Entry Information Option . . . . . 16 5. Home Agent Operation 17 5.1. Requesting Binding Cache . . . . . . . . . . . . . . . . 17 5.2. Notifying Binding Cache . . . . . . . . . . . . . . . . . 17 5.3. Trigger Home Agent Switching . . . . . . . . . . . . . . 18 5.4. Exchanging Home Agent Hello . . . . . . . . . . . . . . . 18 6. Mobile Node Operation 19 6.1. Receiving Home Agent Switch Request . . . . . . . . . . . 19 Addresses 21 Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 2]
Internet Draft HAHA protocol base spec. 03 Mar 2006 1. Introduction This document specifies the inter Home Agents protocol (HAHA protocol). The concept of HAHA protocol is described in [2]. The five new mobility header messages and the two new mobility header sub-option are defined to exchange binding information of mobile node and mobile router among home agents. Home Agent operations on this HAHA protocol are summarized in [3]. We assume that several Home Agents serve the same home network together at the same time. These home agents can be located either at the same home link or at the different link. Each home agent MUST be able to communicate with the other Home Agent. It is recommended to utilize IPsec ESP encryption for all traffic between Home Agents. Each Home Agent can be pre-known all the other Home Agent operationally or can be discovered dynamically. In either case, as like BGP operation, network administrator should be carefully authorized each Home Agent to join a HAHA network. The Binding Information Request, the Binding Information Update, and the Binding Information Acknowledgment are used by Home Agents to synchronize binding information of all mobile nodes and routers served by the Home Agents. When a binding cache is created at a Home Agent, the binding cache can be notified to all the Home Agents by Binding Information Update. After receiving the Binding Information Update, Binding Information Acknowledgment is returned to confirm binding cache recipient. If a Home Agent needs to solicit certain binding cache, it sends Binding Information Request to the HAHA network. The Home Agent Switch Request is sent by a Home Agent to a Mobile Host or Router. To change the primary Home Agent, this message triggers Dynamic Home Agent Address Discovery at the Mobile Host or Router. The sender Home Agent can includes one of Home Agent address as a desired Home Agent to switch over. The Home Agent HELLO is periodically pulsed among Home Agents. It uses live confirmation like HELLO of other routing protocols. This HELLO has the same field of Home Agent information option of Router Advertisement in order to manage Home Agent list. A Home Agent manages the list of other Home Agents by receiving the HELLOs. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 3]
Internet Draft HAHA protocol base spec. 03 Mar 2006 2. Terminology This document uses terms defined in [6], [5], [11], and [13]. Note: In this document,three terms are used to express mobile entities as defined at [13]. A Mobile Host is an end host capable of Mobile IPv6. A Mobile Router is a router of a mobile network supporting the Basic NEMO protocol. A Mobile Node is an entity moving on the Internet. A Mobile Node implies either a Mobile Host, Mobile Router, or both. The keywords ``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. Primary Home Agent A Home Agent who receives Binding Updates from a Mobile Node. The Mobile Node is always associated with a primary Home Agent to register its binding. Binding Cache Copy (BCC) A copy of Binding. BCC has all the fields of Binding defined in [5] and an additional field for an address of the Home Agent that is registered by Mobile Node. BCC can be stored in Binding Cache Database with small extensions, but BCC MUST be marked as BCC in Binding Cache Database. HA address is already defined in Mobile IPv6 [5] like ``the IP address of a home agent on its home link.'' HAHA address is an externally assigned local global address which the Home Agent has associated with one of its own network interfaces other than the interface attached to its home link. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 4]
Internet Draft HAHA protocol base spec. 03 Mar 2006 3. Variety of Home Agent Configuration This section shows possible Home Agents configurations for HAHA protocol. Those configurations are applicable to both Mobile IPv6 and the NEMO Basic Support protocol. The home network assignment is described in the home network model document [11]. Aggregated Home Network, Extended Home Network, and Virtual Home Network are introduced. HAHA protocol allows to distribute Home Agents anywhere on the Internet. This section describes distributed Home Agent configuration for all the home networks. We classify the Home Agent configuration into two cases depending on a physical home link availability or not in this document. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 5]
Internet Draft HAHA protocol base spec. 03 Mar 2006 3.1. With Home Link When multiple Home Agents are configured locally with a single home link, there are two possible configurations like below. Internet | Home Link ==+====+====+====== + + + HA1 HA2 HA3 ... (HA has only a HA address) Figure 1: Home Agents with only HA address Internet | --+----+----+------ + + + HA1 HA2 HA3 ... (HA has both a HA address + + + and a HAHA address) ==+====+====+====== Home Link Figure 2: Home Agents with both HA address and HAHA address When Home Agents are locally distributed, like Figure 1 and Figure 2, every Home Agents operate the same operation. In both cases, a Mobile Node sends a binding update to a HA address and setup a bi-directional tunnel between the Mobile Node's care-of address and the HA address of each Home Agent. After the creation of a Binding Cache, the Home Agent starts HAHA protocol to synchronize the Binding Cache among all the Home Agents by sending Binding Information Update to all the HA addresses. To activate all the Home Agents with Binding Synchronization, Home Agents MUST consider who will be responsible for Proxy Neighbor Discover of the Mobile Node (Proxy NDP negotiation). Only for Figure 2, each Home Agent can advertise a route of the aggregated home network to the Internet to intercept packets without Proxy NDP. As the alternate configuration, multiple Home Agents can be globally distributed on the Internet like Figure 3 and Figure 4. The Home Link is physically separated and configured at the different networks. Since the same route of the aggregated home network Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 6]
Internet Draft HAHA protocol base spec. 03 Mar 2006 are advertised from separated home links, each Home Link must be connected somehow at the L2 technology such as L2TP. Otherwise, for example in below figures, packets to HA1 may be routed to the Home Link2 according to the Internet routing and there is no way to re-routed to the Home Link1. +- - - + Internet +- - -+ | | Home Link1 L2-connectivity Home Link2 ==+====+====+== = = = = ==+====+====+== + + + + + + HA1 HA2 HA3 HA4 HA5 HA6 Figure 3: Home Agents with only HA address +- - - + Internet +- - -+ | | | | --+----+----+-- --+----+----+-- + + + + + + HA1 HA2 HA3 HA4 HA5 HA6 + + + + + + ==+====+====+== = = = = ==+====+====+== Home Link1 L2-connectivity Home Link2 Figure 4: Home Agents with both HA address and HAHA address In both Figure 3 and Figure 4, operations are same as the case of Figure 1 and Figure 2. However, in the case of Figure 4, the Home Agent may use HAHA address on behalf of HA address in all the operations. In such case, any messages of HAHA protocol are transmitted over the Internet, but not on the separated home link. A possible issue for the globally distributed Home Agents with home link is the redundant re-routing. Even if packets meant for a Mobile Node are arrived to the closest Home Link according to the Internet routing, packets may be forwarded to the far Home Link through L2 connection between Home Links. This is because only single Home Agent takes responsibility for intercepting and forwarding packets to the Mobile Node even if all the Home Agents have the same binding cache for the Mobile Node. As we noted before for Figure 2, Proxy NDP operation can be eliminated from Figure 4 by all the Home Agents Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 7]
Internet Draft HAHA protocol base spec. 03 Mar 2006 advertising the aggregated home network route to the Internet in Figure 4. In this case, all Home Agents can defend packets for the Mobile Node and the redundant re-routing is never happened. 3.2. Without Home Link In Mobile IPv6, an aggregated home network is used and configured virtually. Home Agent configure its Home Link without physical link. In the NEMO basic support, an either aggregated or extended home network can be applied. An extended home network conceptually eliminates the home link. +- - - + Internet +- - - -+ | + | | | | + + + HA1 HA2 HA3 + + + VHL1 VHL2 VHL3 Virtual Home Link(VHL) is not physically existed. Figure 5: Home Agent without Home Link For both an aggregated and an extended home network, each Home Agent MUST have a HAHA address. Home Agent may have a HA address when a home network is an aggregated home network. Each Home Agent MUST advertise a route of the aggregated home network to the Internet to intercept packets without Proxy NDP. With this route advertisement, Home Agent can be placed anywhere on the Internet. There is no classification such as local or global Home Agent distribution since there is no different between local or global distribution. A Mobile Node sends a binding update to a HAHA address and setup a bi-directional tunnel between the Mobile Node's care-of address and the HAHA address. After creation of a Binding Cache, the Home Agent starts HAHA protocol to synchronize the Binding Cache among all the Home Agents by sending Binding Information Update to the HAHA address of each Home Agent. All of Home Agents can intercept and forward packets meant for a Mobile Node according to synchronized binding cache information. Since the home link is virtual, proxy NDP operation is totally eliminated from Mobile IPv6 and the NEMO Basic Support. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 8]
Internet Draft HAHA protocol base spec. 03 Mar 2006 4. Message Formats 4.1. New Mobility Header Messages The Mobility Header format is defined in section 6 of [5]. This document defines five new mobility messages. 4.1.1. Home Agent HELLO Message The Home Agent HELLO message is pulsed to other Home Agents in order to inform activeness of the sender home agent. The format of the Home Agent HELLO message is as follows: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Preference | Home Agent Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HELLO Interval | Reserved | Prefix length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | Home Agent Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence 16-bit unsigned integer. The Sequence number of the HELLO message can be used to verify whether this HELLO message is the latest one or not. This value does not need to be recorded in Home Agent List. Home Agent Preference 16-bit unsigned integer. The preference for the home agent sending this hello. This preference is same as the home agent preference value of home agent information option defined in Mobile IPv6. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 9]
Internet Draft HAHA protocol base spec. 03 Mar 2006 Home Agent Lifetime 16-bit unsigned integer. The lifetime for the home agent sending this HELLO. This lifetime is same as the home agent Lifetime value of home agent information option defined in Mobile IPv6. HELLO Interval 16-bit unsigned integer. The interval for the home agent sending this HELLO. Reserved 8-bit unsigned integer. It must be initialized to zero by the sender and must be ignored by the receiver. Prefix Length 8-bit unsigned integer. The prefix length of the home prefix that HA is serving. The home prefix is retrieved from the Prefix Length field and following Home Agent Address field. Home Agent Address A 16 byte field contains an IPv6 global address of the home agent sending this hello. This message MUST include the Mobile Network Prefix Option defined in section 4.2.2 that is served by the Home Agent if available. Home Agent HELLO message MUST be authenticated and encrypted by IPsec ESP. 4.1.2. Binding Information Request Message The Binding Information Request Message is used to request Binding Cache Information corresponding to a particular Mobile Node. It is sent only between Home Agents. This message is often used during Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 10]
Internet Draft HAHA protocol base spec. 03 Mar 2006 bootstrap of a Home Agent. The format of the Binding Information Request message is as follows: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Identifier The 16-bit identifier to aid in matching Home Agent Information Update message. The identifier should never be set to 0. It should always be more than 1. Mobility Options MUST contain either IPv6 Address Option (Sub-type: Home Address) or Mobile Network Prefix Option. If a Home Agents wants the Binding Cache Information for a particular Mobile Node, it includes an IPv6 Address Option (Sub-type: Home Address). If a Home Agent wants to know the forwarding state setting up for a particular Mobile Network Prefix, it includes a Mobile Network Prefix Option. Binding Information Request message MUST be authenticated and encrypted by IPsec ESP. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 11]
Internet Draft HAHA protocol base spec. 03 Mar 2006 4.1.3. Binding Information Update Message The Binding Information Update message is used by the Home Agents to exchange Binding Cache Information. The message format is as follows: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Identifier The 16-bit identifier to aid in matching Home Agent Information Request and Home Agent Information Acknowledge message. The identifier should never be set to 0. It should always be more than 1. The identifier should be set random number for unsolicited Binding Information Update messages. Otherwise, the identifier should be set to the identifier in a Binding Information Request message if this is a solicited Binding Information Update message. Mobility Options MUST contain Binding Cache Entry Information option and MAY contain Mobile Network Prefix option followed by Binding Cache Entry Information option if necessary. This message MUST be authenticated and encrypted by IPsec ESP. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 12]
Internet Draft HAHA protocol base spec. 03 Mar 2006 4.1.4. Binding Information Acknowledgment Message The Binding Information Acknowledgment message is used by the Home Agents to confirm recipient of a Binding Information Update message. The message format is as follows: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Identifier The 16-bit identifier should be copied from the identifier field of the received Home Agent Information Update message. Status 16-bit Status value. Values of Status field greater than or equal to 128 indicate that the Binding Information Update was rejected by the receiving node. The following Status values are currently defined: 0 Binding is successfully synchronized Reserved 16-bit field reserved for future use. The value SHOULD be initialized to zero by the sender, and MUST be ignored by the receiver. Binding Information Acknowledgment message MUST be authenticated and encrypted by IPsec ESP. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 13]
Internet Draft HAHA protocol base spec. 03 Mar 2006 4.1.5. Home Agent Switch Request Message This message is sent by a Home Agent to a Mobile Node to trigger Dynamic Home Agent Discovery. The message format is as follows: 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit field reserved for future use. The value SHOULD be initialized to zero by the sender, and MUST be ignored by the receiver. Mobility Options MAY contain an IPv6 Address option (Sub-type: Home Agent Address) to specify a desired Home Agent. If the IPv6 Address Option is present, a receiver (i.e. Mobile Node) switches to the specified Home Agent immediately as its primary Home Agent. If the IPv6 Address option is not present, the receiver re-selects a Primary Home Agent by itself. The Mobile Node MAY start Dynamic Home Agent Address Discovery. Home Agent Switch Request message MUST be authenticated and encrypted by the use of IPsec ESP mode. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 14]
Internet Draft HAHA protocol base spec. 03 Mar 2006 4.2. New Mobility Options 4.2.1. IP Address Option This option is already defined at FMIP specification [4] like the below figure. 0 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 | Length | Sub Type | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HAHA protocol introduces new Sub-Type value for Home Agent address and Home Address. Sub-Type 4 Home Agent Address 5 Home Address 4.2.2. Mobile Network Prefix Option This option is already defined in the NEMO basic support [10]. This option is included in the Binding Information Request message only if a Home Agent is requesting information regarding a particular Mobile Network Prefix. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 15]
Internet Draft HAHA protocol base spec. 03 Mar 2006 4.2.3. Binding Cache Entry Information Option The Binding Cache Entry Information option has an alignment requirement of 8n+2. Its format is as follows: 0 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 = 0xa | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Home Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | # of MNPs | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . Mobile Network Prefixe Option . . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Binding Cache Entry Information option is valid in the Binding Information Update. The fields of Home Address, Care-of Address, Flags, Sequence Number, and Lifetime are copied from the registered binding of a particular Mobile Node or Mobile Router. 8-bit Reserved field MUST be set to zero. The field ``Number of MNPs'' tells the receiving Home Agent which Mobile Network Prefixes are owned by a Mobile Router. The prefixes are stored in Mobile Network Prefix Option followed by the Binding Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 16]
Internet Draft HAHA protocol base spec. 03 Mar 2006 Cache Entry Information option. The Home Agent who receives this option can setup forwarding for each Mobile Network Prefix. For Mobile IPv6, the ``Number of MNPs'' field is set to 0. 5. Home Agent Operation This section gives HAHA protocol operations on Home Agent. HAHA protocol operations consists of two functions: Binding Synchronization and Home Agent Switching. 5.1. Requesting Binding Cache When a Home Agent wants a binding for a particular Mobile Node, it can solicit Binding Information Update message. The Home Agent sends a Binding Information Request message to Home Agents. The Home Agent MUST set a random value to the Identifier field in the Binding Information Request message and MUST include either a Home Address mobility option or a Mobile Network Prefix mobility option. 5.2. Notifying Binding Cache The primary Home Agent can send Binding Information Update messages either when it is solicited by Binding Information Request message or when it creates/updates binding for a particular Mobile Node. When the primary Home Agent receives a Binding Information Request message, it MUST verifies the Source address field of the IPv6 header. If the source address is not among the known Home Agents, the message MUST be silently discarded. If a Home Agent who receives a Binding Information Request message is not the primary Home Agent for the requested Mobile Node, it MUST ignore the message. Otherwise, it SHOULD reply to the Binding Information Request message. The binding information of the requested Mobile Node are stored in the Binding Information Update message. The primary Home Agent MUST copy the binding information of the requested Mobile Node to each fields of a Binding Cache Entry Information option. If the Binding Information Update message is sent in response to the Binding Information Request message, the primary Home Agent MUST copy the Identifier field of the Request message to the same filed in the Update message. Otherwise, it MUST set zero to the Identifier field. When a Home Agent receives a Binding Information Update message, it MUST verify the Source address field of the IPv6 header. If the Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 17]
Internet Draft HAHA protocol base spec. 03 Mar 2006 source address is not among the known Home Agents, the message MUST be silently discarded. If the Binding Information Update message is sent from the primary Home Agent, the Home Agent SHOULD record the binding information and the primary Home Agent address into its Binding Cache. After registering the binding, the Home Agent MUST return a Binding Information Acknowledgment message to the sender Home Agent of the Binding Information Update message. If the sender Home Agent of the Binding Information Update message does not receive a Binding Information Acknowledgment message, it MUST retry to send a Binding Information Update message. Both a Binding Information Update message, a Binding Information Request message and a Binding Information Acknowledgment message MUST be authenticated and encrypted by IPsec ESP. If a message does not have IPsec ESP header, the message MUST be ignored. 5.3. Trigger Home Agent Switching A Mobile Node can change its primary Home Agent when it is requested by a Home Agent. When a Mobile Node receives a Home Agent Switch Request, it checks the Home Address field in the request. If the address in the Home Address field is global scope address and is already recorded in the Home Agent list of the Mobile Node, the Mobile Node MUST immediately switch to the requested Home Agent by the Home Agent Switch Request. On the other hand, if the requested address in the Home Agent Switch Request message is either unknown or empty, the Mobile Node MUST send a Dynamic Home Agent Discovery Request message to the Mobile IPv6 Home-Agents anycast address. After receiving a Dynamic Home Agent Discovery Reply, the Mobile Node selects the most appropriate home agent and changes its primary Home Agent to the selected Home Agent. The primary Home Agent switching is completed when the Mobile Node registers its binding to the new Home Agent. 5.4. Exchanging Home Agent Hello Mobile IPv6 uses Router Advertisement messages to manage Home Agent lists on each Home Agents. When Home Agents are placed at different links, Router Solicitation and Advertisement messages can not be used due to link-local limitation. Therefore, a new Mobility Header message is defined to notify similar information of Router Advertisement among Home Agents over the home link. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 18]
Internet Draft HAHA protocol base spec. 03 Mar 2006 A Home Agent MUST know other Home Agents which configured in different links beforehand. This is manually configured on each Home Agent. This mechanism MUST be used only between Home Agents on different links serving the same home prefix. It SHOULD not be used between Home Agents on the same link. A Home Agent MUST periodically send a Home Agent HELLO message. The Home Agent SHOULD also send a Home Agent HELLO message when its local information such as preference, lifetime, and registration status, etc. changes. A Home Agent HELLO message MUST be constructed with same information of a Router Advertisement message described in section 7 of [5] and MUST be sent by a unicast to the destination (other Home Agents). The receiver of a Home Agent HELLO message MUST verify the Source address field of the IPv6 header. If a Home Agent HELLO message is received from unknown Home Agent, the message MUST be silently dropped. If the source address is not in the list of known Home Agents, the message MUST be silently dropped. Otherwise, the receiver processes the Home Agent HELLO message to update its Home Agent list. The Sequence field should be checked to ensure the freshness of the received HELLO message. Any Home Agent HELLO message satisfying all of these tests MUST be processed to update its Home Agent list. The receiver Home Agent copy each field of the Home Agent HELLO message to its local Home Agent List. If the Lifetime field is set to zero, the receiver MUST delete the sender Home Agent from the Home Agent List. When a new Home Agent boots up, it SHOULD wait particular time to listen Home Agent HELLO messages of all configured Home Agents. 6. Mobile Node Operation 6.1. Receiving Home Agent Switch Request A Mobile Node can change its primary Home Agent when it is requested by a Home Agent. When a Mobile Node receives a Home Agent Switch Request, it checks the Home Address field in the request. If the address in the Home Address field is global scope address and is already recorded in the Home Agent list of the Mobile Node, the Mobile Node MUST immediately switch to the requested Home Agent by the Home Agent Switch Request. On the other hand, if the requested address in the Home Agent Switch Request message is either unknown or empty, the Mobile Node MUST send a Dynamic Home Agent Discovery Request message to the Mobile IPv6 Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 19]
Internet Draft HAHA protocol base spec. 03 Mar 2006 Home-Agents anycast address. After receiving a Dynamic Home Agent Discovery Reply, the Mobile Node selects the most appropriate home agent and changes its primary Home Agent to the selected Home Agent. The primary Home Agent switching is completed when the Mobile Node registers its binding to the new Home Agent. References [1] J. Faizan, H. El-Rewini, M. Khalil, Problem Statement: Home Agent Reliability (work in progress). Internet Draft, IETF. draft-jfaizan-mipv6-ha-reliability-01.txt Februry 2004. [2] R. Wakikawa, V. Devarapalli, P. Thubert, Inter Home Agents Protocol (HAHA) (expired). Internet Draft, IETF. draft-wakikawa-mip6-nemo-haha-01.txt Februry 2004. [3] P. Thubert, R. Wakikawa, V. Devarapalli, Global HA to HA protocol (work in progress). Internet Draft, IETF. draft-thubert-nemo-global-haha-01, October 2005. [4] R. Koodli. Fast Handovers for Mobile IPv6 (Experimental). RFC4068, IETF. July 2005. [5] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6 (Standards Track). RFC3775, IETF. June 2004. [6] T. Ernst and H. Lach. Network Mobility Support Terminology (work in progress). Internet Draft, IETF. draft-ietf-nemo-terminology-* *04.txt October 2005. [7] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents. RFC3776. IETF. June 2004. [8] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2402, IETF. November 1998. [9] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 Specification. RFC 2473, IETF. December 1998. [10] V. Devarapalli and R. Wakikawa and A. Petrescu and P. Thubert. Nemo Basic Support Protocol (Standards Track), RFC3963, IETF. January 2005. [11] P. Thubert and R. Wakikawa and V. Devarapalli. NEMO Home Network models (work in progress). Internet Draft, IETF. draft-ietf-nemo-home-network-models-06.txt Februry, 2006 Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 20]
Internet Draft HAHA protocol base spec. 03 Mar 2006 [12] T. Narten and E. Nordmark and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, IETF. December 1998. [13] J. Manner and M. Kojo. Mobility Related Terminology. (Informational) RFC3753, June 2004. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 21]
Internet Draft HAHA protocol base spec. 03 Mar 2006 Change Log from Previous Version Changes from draft-wakikawa-mip6-nemo-haha-protocol-00.txt. - Updating References - Correcting Typos - Updating IPv6 address option Authors Addresses Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 Japan Email: ryuji@sfc.wide.ad.jp Pascal Thubert Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 France Email: pthubert@cisco.com Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: vijay.devarapalli@nokia.com Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 22]
Internet Draft HAHA protocol base spec. 03 Mar 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Wakikawa, Thubert, Devarapalli Expires 03 Sep 2006 [Page 23]