MIP6/NEMO Working Group Ryuji Wakikawa INTERNET DRAFT Keio University/WIDE Category: Standards Track Vijay Devarapalli 16 Feb 2004 Nokia Pascal Thubert Cisco Systems Inter Home Agents Protocol (HAHA) draft-wakikawa-mip6-nemo-haha-01.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes an inter Home Agents (HAHA) protocol to provide multiple Home Agents support for both Mobile IPv6 and the Nemo Basic Support protocol. The HAHA protocol provides Home Agent redundancy and load-balancing for both protocols. The HAHA protocol allows multiple Home Agents to be placed at different links. It also allows a Mobile Node to utilize multiple Home Agents simultaneously. The protocol consists of 3 mechanisms, Home Agent List management, Binding Synchronization, and Home Agent Switching. A Mobile Node picks one Home Agent as its primary Home Agent and registers with it. The primary Home Agent synchronizes the binding cache information with other Home Agents. Any of Home Agents can intercept a packet meant for the Mobile Node and tunnel the packet directly to its current Care-of address. Alternatively, the Home Agent can tunnel the packet to the primary Home Agent. Wakikawa, et al. Expires 16 Aug 2004 [Page 1] Internet Draft HAHA protocol 16 Feb 2004 Contents Status of This Memo 1 Abstract 1 1. Introduction 4 2. Terminology 6 3. Overview of Inter Home Agents Protocol 7 4. Message Formats 10 4.1. New Mobility Header Messages . . . . . . . . . . . . . . 10 4.1.1. Home Agent HELLO Message . . . . . . . . . . . . 10 4.1.2. Binding Information Request Message . . . . . . . 11 4.1.3. Binding Information Update Message . . . . . . . 13 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. Home Address . . . . . . . . . . . . . . . . . . 15 4.2.2. Mobile Network Prefix Option . . . . . . . . . . 15 4.2.3. Binding Cache Entry Information Option . . . . . 16 5. Home Agent Lists Management 17 6. Home Agent Failure Detection 18 7. Binding Synchronization among Home Agents 19 7.1. Requesting Binding . . . . . . . . . . . . . . . . . . . 19 7.2. Notifying Binding . . . . . . . . . . . . . . . . . . . . 19 8. Primary Home Agent Switching 21 8.1. Home Agent initiated Switching . . . . . . . . . . . . . 21 8.2. Mobile Node initiated Switching . . . . . . . . . . . . . 21 9. Scenarios 23 9.1. Single Home Agent Activation . . . . . . . . . . . . . . 23 9.2. Multiple Home Agent Activation . . . . . . . . . . . . . 24 10. Modifications to Mobile IPv6 and the Nemo Basic Support Protocol 27 11. IANA Considerations 29 12. Security Considerations 30 A. Changes from -00 32 Wakikawa, et al. Expires 16 Aug 2004 [Page 2] Internet Draft HAHA protocol 16 Feb 2004 B. Distributed Home Network 33 Addresses 38 Wakikawa, et al. Expires 16 Aug 2004 [Page 3] Internet Draft HAHA protocol 16 Feb 2004 1. Introduction In Mobile IPv6 [2], a Mobile Host could be tunneling and receiving all its traffic through a bi-directional tunnel with its Home Agent, unless it uses Route Optimization with its Correspondent Nodes. In Nemo Basic Support protocol [7], the default mode of operation is to tunnel all traffic meant for the Mobile Network through the Home Agent serving the Mobile Router. Consequently, Home Agents could become a considerable bottleneck in the performance of Mobile IPv6 and Nemo protocols. This becomes more significant when the Home Agent serves thousands of Mobile Hosts and Mobile Routers. Sometimes the Mobile Network could be closer to the Correspondent Node than the Home Agent. If the Mobile Router could pick another Home Agent closer to its current location, the tunneling overhead on every packet could be reduced to a much shorter path in the Internet. This draft specifies the inter Home Agents protocol (HAHA protocol) to provide reliability, redundancy and load balancing of Home Agents. Problem statements of Home Agent Reliability is summarized in [1]. For the HAHA protocol, the definition of Home Agent is extended to place multiple Home Agents at different links. Multiple Home Agents could be located on different links and still serve the same home prefix. Mobile IPv6 uses a IPv6 Neighbor Discovery based mechanism for maintaining the list of Home Agents serving the same prefix, at each Home Agent. If the Home Agents are not present on the same physical link, Neighbor Discovery based mechanisms don't work. The HAHA protocol defines a mechanism for Home Agents List management using new MH messages for Home Agents located on different links. Network configurations such as Home Network Prefix Assignments and route distributions among Home Agents are described in [8]. In appendix B, a distributed home network scenarios are described. The HAHA protocol makes it possible to have two new scenarios which would not have possible with Mobile IPv6 and the Nemo Basic Support Protocol. These scenarios are Single Home Agent Activation and Multiple Home Agent Activation and are explained in the following paragraphs. In the scenario of Single Home Agent Activation, a Mobile Node always selects the best Home Agent to register its binding depending on Mobile Node's current location or Home Agent status. The Mobile Node's binding is always maintained by the single Home Agent. For example, when a Mobile Node registers its binding to the nearest Home Agent, the path between the Mobile Node and the Home Agent can be the shortest possible path. This is particularly useful for a Mobile Node which moves over geographically wide areas such as a Mobile Router on an airplane. Wakikawa, et al. Expires 16 Aug 2004 [Page 4] Internet Draft HAHA protocol 16 Feb 2004 In the scenario of Multiple Home Agent Activation, a Mobile Nodes registers its binding to multiple Home Agents at the same time. The Mobile Node sends a binding update to its primary home agent. After the home registration, the primary Home Agent exchanges the binding information with the other Home Agents. The Mobile Node's binding is maintained by multiple Home Agent. Thereafter, the Mobile Node can use any of these Home Agents which have the binding. The Mobile Node can accept packets which are tunneled by any of the Home Agents. Alternatively, a Home Agent who intercepts packets can tunnel packets to the primary Home Agent. In this case, the Mobile Node receives packets through the primary Home Agent. If many Home Agents are scattered on the Internet, the Home Agent nearest to the correspondent node intercepts packets meant for the Mobile Node or the Mobile Network and tunnels them to the Mobile Node. The route path between the correspondent node and the Home Agent can be kept short. Wakikawa, et al. Expires 16 Aug 2004 [Page 5] Internet Draft HAHA protocol 16 Feb 2004 2. Terminology There is a separate Nemo terminology document [3], which defines the terms related to Network Mobility used in the document. 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. Home Agent A Home Agent is originally defined in [2]. Traditional Home Agents, if they all serve the same home prefix are configured on a single link. This document extends the definition of Home Agents such that the Home Agents need not be on the same link. There could be multiple Home Agents attached to different links serving the same home prefix. Primary Home Agent A Home Agent who receives Binding Update from a Mobile Router. The Mobile Router is always associated with a primary Home Agent to register its binding. Mobile Node, Mobile Host, and Mobile Router In this document,three terms are used to express mobile entities as defined at [10]. 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 entity moving on the Internet. A Mobile Node implies either a Mobile Host, Mobile Router, or both. Wakikawa, et al. Expires 16 Aug 2004 [Page 6] Internet Draft HAHA protocol 16 Feb 2004 3. Overview of Inter Home Agents Protocol The HAHA protocol addresses the issues of home agent reliability described in [1]. The HAHA protocol prevents Home Agent failure and Home Link failure from Mobile IPv6. It provides mechanism of failure detection and its recovery by binding synchronization. Local HAs Distribtuion Global Home Distribution Home Link1 ----+---- +--------+ | |Internet| +--------+ | +--------+ |Internet|---+ Home Link2 | +--------+ | --+---+---+--Home Link | | | | ----+------ HA HA HA Home Link3 The Combination Home Link1 HA HA HA | | | +---+---+ | +- HA +--------+ | |Internet|----+- HA Home Link2 +--------+ | | +- HA +----+----+ | | | Home Link3 HA HA HA Local Home Agent distribution is the configuration when multiple home agents are placed locally in same routing domain. Multiple home agents are configured at the same home link for a particular mobile nodes. When one of home agents goes down, another home agent takes over the inactive home agent and serves same mobile nodes continuously. It is possible to balance load locally among home agents. Local multiplexing is effective for load balancing and home agent redundancy. Global Home Agent distribution is used to avoid home link failure. Multiple home agents are placed globally despite routing domains. Multiple home agents serving a same home network are distributed Wakikawa, et al. Expires 16 Aug 2004 [Page 7] Internet Draft HAHA protocol 16 Feb 2004 to different routing domains. Therefore, the routes for the home network are advertised from multiple routing domains. Each mobile node can pick the best home agent among distributed home agents according to network environments and topological position. When multiple Home Agents are configured at different links, each Home Agent is expected to know the other Home Agents beforehand and establishes Security Association with them for a secure path towards the other Home Agents. Each Home Agent maintains a list of all other Home Agents that serve the same Home Network. The Mobile IPv6 mechanism of using router advertisements for maintaining the Home Agent list cannot be used if the Home Agents are placed on geographically different links, because router advertisements can not be sent over link-local scope. Therefore, each Home Agents periodically unicasts a Home Agent HELLO message instead of Router Advertisement to the other Home Agents configured at different links. Whenever a Home Agent receives a Home Agent HELLO message, it updates its Home Agent List according to the information in the received HELLO message. The Home Agent manages the Home Agent List as same as the Mobile IPv6 specification. If the lifetime of an entry is expired in the Home Agent List, the Home Agent should delete the the entry from the Home Agent List and MAY assume the Home Agent which entry is deleted becomes unreachable (i.e. system down). Synchronizing Binding of a particular Mobile Node allow to activate multiple Home Agents simultaneously. When a primary Home Agent receives a Binding Update and creates a Binding, it notifies the Binding to the other Home Agents by unicasting Binding Information Update messages. Home Agents receiving the Binding Information Update message records Binding information and the address of the primary Home Agent into their Binding Cache. Home Agents MUST return Binding Information Acknowledgment messages with appropriate status code to the sender Home Agent. A Home Agent sends a Binding Information Request message to solicit a Binding Information Update message to the primary Home Agent if needed. When a Home Agent wants a Mobile Node to change the primary Home Agent, it sends a Home Agent Switch Request message to trigger the Dynamic Home Agent Address Discovery to a Mobile Node. After receiving an ICMP Home Agent Address Discovery Request, the Home Agent should reply an ICMP Home Agent Address Discovery Reply with addresses of appropriate Home Agent addresses. If the Home Agent has already had the desired new primary Home Agent, it contains the address of the new Home Agent in the Home Agent Switch Request message. The Mobile Node switches its primary Home Agent to the new Home Agent. When the Mobile Node changes the primary Home Agent proactively, it selects a new Home Agent from its home agent list. Wakikawa, et al. Expires 16 Aug 2004 [Page 8] Internet Draft HAHA protocol 16 Feb 2004 After determination of the new Home Agent, it simply registers its binding to the new Home Agent. The Mobile Node should de-register its binding from the old Home Agent before the home registration to the new Home Agent. The scenarios for the HAHA protocol are described in Section 9. In the Single Home Agent Activation scenario, only a primary Home Agent manages a binding for a Mobile Node and takes responsibility for tunneling packets from and to a Mobile Node. The Mobile Node can switch its primary Home Agent to a Home Agent located in different link by the HAHA protocol. In the Multiple Home Agents Activation scenario, a primary Home Agent shares the registered binding for a Mobile Node with all other Home Agents. Each Home Agent intercepts packets and take responsibility for delivering intercepted packets to either the Mobile Node or the primary Home Agent. The Mobile Node accepts tunneled packets directly from the Home Agent. Otherwise, when the primary Home Agent receives tunneled packets from other Home Agents, it delivers packets to the Mobile Node. The Mobile Node always tunnels outgoing packets to the primary Home Agent. The Mobile Node can switch its primary Home Agent to a Home Agent located in different link by the HAHA protocol. Wakikawa, et al. Expires 16 Aug 2004 [Page 9] Internet Draft HAHA protocol 16 Feb 2004 4. Message Formats 4.1. New Mobility Header Messages The Mobility Header format is defined in section 6 of [2]. 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, et al. Expires 16 Aug 2004 [Page 10] Internet Draft HAHA protocol 16 Feb 2004 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 Wakikawa, et al. Expires 16 Aug 2004 [Page 11] Internet Draft HAHA protocol 16 Feb 2004 sent only between Home Agents. 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. This message MUST include either the Home Address mobility option defined in section 4.2.1 or the Mobile Network Prefix Option defined in section 4.2.2. If a Home Agents want the Binding Cache Information for a particular Mobile Node it includes a Home Address mobility option. If a Home Agent wants to know the forwarding state setting up for a particular Mobile Network Prefix, it includes the Mobile Network Prefix Option. This message is optional if Home Agents send out unsolicited Binding Information Update messages. Binding Information Request message MUST be authenticated and encrypted by IPsec ESP. Wakikawa, et al. Expires 16 Aug 2004 [Page 12] Internet Draft HAHA protocol 16 Feb 2004 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. This message MUST include Binding Cache Entry Information option. Binding Information Update message MUST be authenticated and encrypted by IPsec ESP. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wakikawa, et al. Expires 16 Aug 2004 [Page 13] Internet Draft HAHA protocol 16 Feb 2004 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 Infroamtion 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Agent Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Wakikawa, et al. Expires 16 Aug 2004 [Page 14] Internet Draft HAHA protocol 16 Feb 2004 Home Agent Address A 16 byte field contains the new primary Home Agent Address. The Home Agent address MUST be recorded in the Home Agent list of the Mobile Router. If this field does not contain the valid global IPv6 address or the unknown Home Agent address, the Mobile Router sends dynamic Home Agent address discovery request message. Otherwise, the Mobile Router switches to this Home Agent immediately as its primary Home Agent. Home Agent Switch Request message MUST be authenticated and encrypted by the use of IPsec ESP mode. 4.2. New Mobility Options 4.2.1. Home Address The Home Address option has an alignment requirement of 8n+6. 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 = 0x8 | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Home Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This option is used when the Home Agent needs to figure out the Binding Cache information for a particular Mobile Node or Mobile Router. not useful when each Home Agent sends an unsolicited binding cache information for each BU it receives. 4.2.2. Mobile Network Prefix Option This option is already defined in the Nemo basic support [7]. 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, et al. Expires 16 Aug 2004 [Page 15] Internet Draft HAHA protocol 16 Feb 2004 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 = 0x9 | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Home Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reserved | # of MNPs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Mobile Network Prefixes . . . 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 receiving Home Agent can then setup forwarding for each Mobile Network Prefix. for Mobile IPv6, the ``Number of MNPs'' field is set to 0. Wakikawa, et al. Expires 16 Aug 2004 [Page 16] Internet Draft HAHA protocol 16 Feb 2004 5. Home Agent Lists Management 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 MH message is defined to notify similar information of Router Advertisement among Home Agents over the home link. 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 [2] 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. Wakikawa, et al. Expires 16 Aug 2004 [Page 17] Internet Draft HAHA protocol 16 Feb 2004 6. Home Agent Failure Detection Each Home Agent detects Home Agent failure by monitoring lifetime of each Home Agent List entry. When an entry is deleted because of lack of either Router Advertisements or Home Agent HELLO messages, the Home Agent is treated as invalid. When Home Agent Lifetime is notified with zero by Router Advertisements or Home Agent HELLO messages, the receiver MUST mark the sender Home Agent as invalid, too. Wakikawa, et al. Expires 16 Aug 2004 [Page 18] Internet Draft HAHA protocol 16 Feb 2004 7. Binding Synchronization among Home Agents A binding for a particular Mobile Node is shared among Home Agents. Therefore, each Home Agents can always know the binding for a particular Mobile Node and the primary Home Agent which is currently serving the Mobile Node. This makes it possible for Mobile Nodes to utilize multiple Home Agents simultaneously. Binding synchronization messages can be sent with either unicast or multicast routing. If unicast routing is used, full mesh flooding is required. Full mesh flooding incurs high overhead for synchronizing information among multiple entities. But there are existing mechanisms like CARP and BGP reflector mechanism to reduce the overhead. Therefore this document does not discuss any optimized synchronization schemes. This document assumes full mesh flooding, however, it can be replaced by any other mechanism which achieves full mesh flooding. 7.1. Requesting Binding 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 the primary Home Agent of the Mobile Node. 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. 7.2. Notifying Binding The primary Home Agent sends Binding Information Update messages when it is solicited by Binding Information Request message or when it creates or 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 Wakikawa, et al. Expires 16 Aug 2004 [Page 19] Internet Draft HAHA protocol 16 Feb 2004 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 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 Acknowledgement 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 Acknowledgement 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 Infromation Acknowledgement message MUST be authenticated and encrypted by IPsec ESP. If a message does not have IPsec ESP header, the message MUST be ignored. Wakikawa, et al. Expires 16 Aug 2004 [Page 20] Internet Draft HAHA protocol 16 Feb 2004 8. Primary Home Agent Switching A Mobile Node always associates with the best Home Agent from Home Agents configured for the Mobile Node. The Mobile Node initiates dynamic Home Agent discovery to get the most appropriate Home Agents. The Mobile Node can ensure the best Home Agent by issuing a Dynamic Home Agent Address Discovery Request message at each visiting foreign links. Alternatively, Home Agent can send Home Agent Switch Request message as a trigger of a Dynamic Home Agent Address Discovery Request message to the Mobile Node. The Home Agent initiated switching is useful for load-sharing of each Home Agents. A Home Agent can control the load average by moving some of Mobile Nodes to other Home Agents compulsory. The Mobile Node initiated switching guarantees a Mobile Node to register its binding to the best Home Agent all the time. For example, the best Home Agent is the nearest one. 8.1. Home Agent initiated 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. 8.2. Mobile Node initiated Switching When a Mobile Node decides to change its primary Home Agent, it selects the new Home Agent from its Home Agent list. The Mobile Node can start Dynamic Home Agent Address Discovery mechanism to update Home Agents information such as a preference value of each Home Agents. Wakikawa, et al. Expires 16 Aug 2004 [Page 21] Internet Draft HAHA protocol 16 Feb 2004 After selection of a new Home Agent, it registers its binding to the new Home Agent. Wakikawa, et al. Expires 16 Aug 2004 [Page 22] Internet Draft HAHA protocol 16 Feb 2004 9. Scenarios This section describes assumed scenarios of the HAHA protocol. Network configurations such as Home Prefix assignments and route managements are described in [8]. Two scenario are introduced such as the Single Home Agent Activation and the Multiple Home Agents Activation. Both can be applied to both Mobile IPv6 and the Nemo basic support protocol. In each figures descrbied below, the operation of Binding Information Acknowledgement message is omitted. The binding notification is assumed to be success all the time in this Section. 9.1. Single Home Agent Activation MN PHA HA2 HA3 CN | | | | | |------>| | | | 1. Home Registration | | | | | |======>|---------------------->| 2. Sending Packet to CN | | | | | via Primary HA"(PHA) |<======|<----------------------| 3. Sending Packet to MN | | | | | via PHA |<------|(HA1) | | | 4. Trigger primary HA switching | | | | | |-------------->|(PHA) | | 5. Sending Binding Update | | | | | | |<------|------>| | 6. Soliciting the binding | | | | | to other HAs. (no reply) |<--------------| | | 7. Sending Binding Acknowledgement | | | | | |==============>|-------------->| 8. Sending Packet to CN | | | | | |<==============|<--------------| 9. Sending Packet to CN | | | | | Figure 1: Local Home Agent Distribution All packets meant for a Mobile Node are routed to the primary Home Agent and are intercepted by the primary Home Agent as well as both Mobile IPv6 and Nemo basic support. Then, the primary Home Agent tunnels packets to the Mobile Node according to either the registered binding cache or the forwarding states established by a Binding Update (Seq2 and Seq3). Wakikawa, et al. Expires 16 Aug 2004 [Page 23] Internet Draft HAHA protocol 16 Feb 2004 When the Mobile Node switches its primary Home Agent, it sends a Binding Update to the new primary Home Agent (Seq5). The new primary Home Agent receiving the Binding Update verifies whether the other Home Agents still hold the binding for the Mobile Node. It sends Binding Information Request messages to all the other Home Agents (Seq6). If it receives any Binding Information Update message in response to the Binding Information Request messages, it sends a Binding Acknowledge to the Mobile Node with the status value set to 144 (another Home Agent is still active). Otherwise, the Home Agent accepts the Binding Update and becomes the primary Home Agent for the Mobile Node (Seq7). If the Mobile Node receives the Binding Acknowledge with a negative status code, it de-registers its binding from the old primary Home Agent and retries to send a Binding Update to the new primary Home Agent. Before trying home registration to the new Home Agent, the Mobile Node should de-register its binding from the current primary Home Agent. When the Mobile Node receives a Home Agent Switch Request from the current primary Home Agent, it MUST switch its primary Home Agent to the new Home Agent specified in the Home Agent Switch Request. The Mobile Node can also switch the primary Home Agent proactively without the Home Agent Switch Request. 9.2. Multiple Home Agent Activation Each Home Agent synchronizes a binding for a particular Mobile Node by the HAHA protocol. If all the Home Agents who have the binding for the Mobile Node can setup forwarding for the Home Address and the mobile network prefixes owned by the Mobile Node if any, it tunnels intercepted packets directly to the Mobile Node (Fig 3). On the other hand, if the Home Agent does not enable forwarding for the Home Address and the mobile network prefixes, it tunnels intercepted packets to the primary Home Agent (Fig 2) first. Then the primary Home Agent re-tunnels packets to the Mobile Node. It is a matter of operations whether forwarding setting is enable on all the Home Agent or not. In the figure 2, a Mobile Node first registers its binding to the primary Home Agent (Seq1). Once the primary Home Agent creates a binding for the Home Address of the Mobile Node and sets up forwarding for the Mobile Network Prefixes, it sends Binding Information Update messages to other Home Agents to synchronize the binding information (Seq2 and Seq3). When a Home Agent receives the Binding Information Update message, it records the binding and the primary Home Agent address (which can be retrieved from the source Wakikawa, et al. Expires 16 Aug 2004 [Page 24] Internet Draft HAHA protocol 16 Feb 2004 MN PHA HA2 CN1 HA3 CN2 | | | | | | |------>| | | | | 1. Home Registration | | | | | | | |------>| | | | 2. Sending binding to HA2 | | | | | | | |---------------------->| | 3. Sending binding to HA3 | | | | | | |======>|-------------->| | | 4. Sending Packet to CN1 | | | | | | via PHA |<======|<------|<------| | | 5. Sending Packet to MN | | | | | | via HA2 and PHA |======>|------------------------------>| 6. Sending Packet to CN2 | | | | | | via PHA |<======|<----------------------|<------| 7. Sending Packet to MN | | | | | | via HA3 and PHA |-------------->|(PHA) | | | 8. Home Registration | | | | | | | (HA1)|<------|-------------->| | 9. Sending binding to | | | | | | HA1 and HA3 |==============>|---------------------->| 10. Sending Packet to CN2 | | | | | | via PHA |<==============|<--------------|<------| 11. Sending Packet to MN | | | | | | via HA3 and PHA Figure 2: Multiple Home Agents with single bi-directional tunnel address of the Binding Information Update messages) in the binding cache entry. After the completion of the binding synchronization, all Home Agents start to distribute the network routes for the Mobile Network Prefixes to the Internet in the basic NEMO case. Therefore, when the Mobile Network Node communicates with a Correspondent Node, outgoing packets from the Mobile Network are tunneled to the closer primary Home Agent (Seq4) and incoming packets to the Mobile Network are intercepted by the Home Agent which is close to the Correspondent Node (Seq5). Then, the intercepted packets are forwarded/tunneled to the primary Home Agent. The primary Home Agent delivers the packets to the Mobile Router through the bi-directional tunnel (Seq5). In Mobile IPv6, the operation is same except for lack of Mobile Network Prefixes. If the Mobile Node decides to switch its primary Home Agent due to its movement, it sends a Binding Update to the new primary home agent. Then, the new primary Home Agent starts to synchronize the Wakikawa, et al. Expires 16 Aug 2004 [Page 25] Internet Draft HAHA protocol 16 Feb 2004 binding information with other Home Agents (Seq9). All Home Agent updates the binding and the primary Home Agent address according to the received Binding Information Update message. MN HA1 HA2 CN1 HA3 CN2 | | | | | | |------>| | | | | 1. Home Registration | | | | | | | |------>| | | | 2. Sending the binding | | | | | | to HA2 | |---------------------->| | 3. Sending the binding | | | | | | to HA3 |======>|-------------->| | | 4. Sending Packet to CN1 | | | | | | via HA1 |<==============|<------| | | 5. Replying to MN | | | | | | via HA2 |======>|------------------------------>| 6. Sending Packet to CN2 | | | | | | via HA1 |<==============================|<------| 7. Replying to MN | | | | | | via HA3 Figure 3: Multiple Home Agents with multiple bi-directional tunnels In the figure 3, a Mobile Node first sends a Binding Update to its primary Home Agent (Seq1). The primary Home Agent also notifies the binding information to other Home Agents by using Binding Information Update messages (Seq2 and Seq3). When a Home Agent receives the Binding Information Update message, it records the binding and the primary home agent address as a binding cache entry for the Mobile Node and sets up forwarding for mobile network prefixes if any. After creating the binding cache entry and setting up forwarding, each Home Agent starts to distribute network routes for the mobile network prefixes to the Internet. When the Mobile Network Node communicates with a Correspondent Node, outgoing packets from the mobile network are tunneled to the primary Home Agent (Seq4). Incoming packets to the mobile network are intercepted by the Home Agent which is close to the Correspondent Node (Seq5). Then, the intercepted packets are tunneled directly to the current Care-of Address according to binding and forwarding (Seq5). The procedure of primary Home Agent switching is same as the procedure described in Fig 2. Wakikawa, et al. Expires 16 Aug 2004 [Page 26] Internet Draft HAHA protocol 16 Feb 2004 10. Modifications to Mobile IPv6 and the Nemo Basic Support Protocol The HAHA protocol modifies the below items of Mobile IPv6 [2] and the Nemo Basic Support protocol [7]. - The new status values for the Binding Acknowledgment. When a Mobile Node receives this status for its home registration, it MUST de-register its binding from the old primary Home Agent and SHOULD re-try home registration. A Home Agent SHOULD use this status value only in the Single Home Agent Activation scenario. The primary Home Agent can not be duplicated in the scenario and can only have a binding for a particular Mobile Node all the time. Status 144 Another primary Home Agent is still active. - Binding Cache Registration The conceptual fields of each Binding Cache entry are defined in [2]. The HAHA protocol introduces an additional field to record the primary Home Agent address for a Mobile Node. When a Home Agent receives a Binding Information Update message, it creates or updates the binding cache entry. The Home Agent MUST record the primary Home Agent address in the binding cache entry. The address can be derived from the Source address field of IPv6 header in the Binding Information Update message. When a primary Home Agent receives a Binding Update from a Mobile Node, it MUST records its own address as the primary Home Agent address in the binding cache entry. - Tunneling packets to Mobile Node Home Agents Home Agents who registers a binding by the HAHA protocol can tunnel packets meant for the Mobile Node or Mobile Network to the current Care-of Address as well as the primary Home Agent. The Mobile Node can accept the tunneled packets. The Mobile Node MUST know all the Home Agents who has its binding in the home agent list so as to verify the Source address of outer IPv6 header. - Tunneling packets to primary Home Agent from Home Agents When one of Home Agents who has a binding intercepts packets meant for a particular Mobile Node, the Home Agent can tunnel packets to the primary Home Agent recorded in the binding cache. Wakikawa, et al. Expires 16 Aug 2004 [Page 27] Internet Draft HAHA protocol 16 Feb 2004 The primary Home Agent tunnels packets to the current Care-of Address of the Mobile Node. Wakikawa, et al. Expires 16 Aug 2004 [Page 28] Internet Draft HAHA protocol 16 Feb 2004 11. IANA Considerations This document defines three new Mobility Header messages - Home Agent HELLO Message - Binding Information Request Message - Binding Information Update Message - Binding Information Acknowledgment Message - Home Agent Switch Request Message This document defines two new Mobility Options. - Home Address - Binding Cache Entry Information Wakikawa, et al. Expires 16 Aug 2004 [Page 29] Internet Draft HAHA protocol 16 Feb 2004 12. Security Considerations Multiple Home Agents advertise routes for either same Home Prefix and possibly Mobile Network Prefix in the HAHA protocol, these routes MUST be correctly advertised. System Administrators MUST prevent malicious (blackhole) routes for these prefixes. A Home Agent MUST know the other Home Agent serving a same Mobile Node and MUST establish a secure association with each Home Agent. All signaling messages between the Mobile Node and the Home Agent MUST be authenticated and encrypted by IPsec ESP [5]. The Mobile Node MUST verify that packets are tunneled through the known Home Agent. In Multiple Home Agent Activation scenario, the Mobile Node may receives packets tunneled by multiple Home Agents. The Mobile Node MUST know all Home Agents who has its binding by the HAHA protocol in its Home Agent List by using Home Agent Address Discovery. It is necessary for a Mobile Node to know all other Home Agents in order to protect attacks launched by malicious Home Agents. Please refer to the Mobile IPv6 specification [2] and the Nemo Basic Support protocol specification [7] for security considerations. Wakikawa, et al. Expires 16 Aug 2004 [Page 30] Internet Draft HAHA protocol 16 Feb 2004 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] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6 (work in progress). Internet Draft, IETF. draft-ietf-mobileip-ipv6-22.txt. May 2003. [3] T. Ernst and H. Lach. Network Mobility Support Terminology (work in progress). Internet Draft, IETF. draft-ietf-nemo-terminology -00.txt May 2003. [4] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents (work in progress). Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-05.txt May 2003 [5] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2402, IETF. November 1998. [6] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 Specification. RFC 2473, IETF. December 1998. [7] V. Devarapalli and R. Wakikawa and A. Petrescu and P. Thubert. Nemo Basic Support Protocol (work in progress). Internet Draft, IETF. draft-ietf-nemo-basic-support-01.txt September 2003 [8] P. Thubert and R. Wakikawa and V. Devarapalli. Examples of basic Nemo usage (work in progress). Internet Draft, IETF. draft-ietf-nemo-basic-usage-00.txt October 14 2003. [9] T. Narten and E. Nordmark and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, IETF. December 1998. [10] J. Manner and M. Kojo. Mobility Related Terminology. draft-ietf-seamoby-mobility-terminology-05.txt November 2003 Wakikawa, et al. Expires 16 Aug 2004 [Page 31] Internet Draft HAHA protocol 16 Feb 2004 A. Changes from -00 - Obsolete two ICMP messages (Home Agent Solicitation and Advertisement Message) - Add a new MH message called Home Agent HELLO message - Change the name of Binding Information Reply Message to Binding Information Update Message - Add a new MH message called Binding Information Acknowledgment Message - Add a section for a detailed example in Appendix B Wakikawa, et al. Expires 16 Aug 2004 [Page 32] Internet Draft HAHA protocol 16 Feb 2004 B. Distributed Home Network This section describes a detailed example how multiple Home Agents are configured in different routing domains. The HAHA protocol does not completely cover all operations for this example at this time. Readers are expected to read [8] before reading this section. In distributed home network, a global Home is advertised by several sites that are geographically distributed and meshed using tunnels in a VPN fashion. Mobile Nodes locate the closest site using DHAAD against the global Home Network and bind there. Some form of inter-site synchronization (e.g. a routing protocol), which Mobile IPv6 and Nemo Basic Support do not provide, must take place in order to allow packets to be routed between the incoming site to the Mobile Node. The HAHA (Home Agent to Home Agent) protocol is being designed for that purpose. In one model, each site is responsible for a subnet of Home. When a Mobile Node roams far from its natural (default) site, it registers to a Home Agent on a remote site, that takes the registration and notifies at least the natural site of the foreign registration. There are at least 3 approaches in order to locate the Home Agent that has a registration for a given Mobile Node, Router or Mobile Network: - reactive This method is also referred to as 'on-demand'. In case of a binding cache miss, a Home Agent floods a Binding Information Request message to all the other Home Agents with the (destination of the packet) home address that is sought for. Every Home Agent that has a registration for that home address or for a Mobile Network that encompasses that home address responds. This approach is traditionally used in fast changing configurations, for instance if Mobile Nodes register and de-register very often. - proactive An information is pushed to all Home Agents with the Home Address and the Mobile Network Prefixes each time by Binding Information Update message This approach is preferred for stable configurations, for instance if Mobile IP is used as a tool to simplify the configuration and reconfiguration of mostly stable networks. - predictive Ranges of Home Addresses and prefixes are assigned to the Home Agents, following a rule that is commonly computed by all Home Agents. Dynamic Home Agent Address Discovery (DHAAD) returns Wakikawa, et al. Expires 16 Aug 2004 [Page 33] Internet Draft HAHA protocol 16 Feb 2004 only the address of one Home Agent, the one that is pre-allocated for that Mobile Node. When the wrong Home Agent intercepts packets, it can compute which is the right Home Agent and forward packets to it at L2 if they are directly connected, or via a HAHA tunnel which is established between Home Agents. This is what we call 'Z' routing. CN --------> closest HA CN ----------> closest HA / | / | / | / | / | Assigned / | HA v V ----------> Mobile Node Mobile Node The Predictive Mode minimizes the control traffic, which may be required for a large configuration. Some additional controls would be necessary for the HAHA protocol to allow the negotiation and the distribution of the shares of Home to be attributed to each Home Agent. One specific advantage of not relying on a Home Link for HAHA communication is that for a large configuration, the Home Agents can be organized hierarchically and distributed geographically, as a set of local clusters linked together to form a global Home Network. For instance, it is possible for a large ISP to partition the Home Network for a given worldwide service, and assign a partition to a cluster of Home Agents in each of the geographies. In predictive mode, each Home Agent in the world would be able to compute the best suited Home Agent in its local cluster (call this a Acting Wakikawa, et al. Expires 16 Aug 2004 [Page 34] Internet Draft HAHA protocol 16 Feb 2004 Home Agent) and the best suited Home Agent worldwide (call this the Assigned Home Agent) for each and any Home Address. HA HA | ______ | --+-----+--+- . -+- . -+-- TUNNEL --+-----+--+- . -+- .. -+-- | | | | ______ | | | | MR1 MR2 MRi MRN MR1 MR2 MRi MRN ------ ------ ------ ------ ------ ------ ---- - ---- /64 A:B:1:i::/64 /64 A:B:n:i::/64 Distributed Home Network /48 <------------------------------------------------------------------> extended HN Aggregated HN Virtual HN <----------------------><---------------------->...<---------------> Home Mob Mob Mob Mob Mob Mob Mob <-----><----->...<-----><-----><----->...<----->...<----->...<-----> Any Home Agent processing an anycast DHAAD can predict the Assigned Home Agent and local Acting Home Agents for a Home Address if that information is added to the DHAAD request. In the case of Mobile Routers, the service must be arranged in such ways that, for a given registration, all the Mobile Networks are assigned to a same Home Agent. Possible flows: In order to register, a Mobile Node uses DHAAD which returns one Home Agent in the closest cluster. This can be a Acting Home Agent if the Mobile Node is roaming far from Home, but hopefully it is in general the Assigned Home Agent for that Mobile Node. When this is a Acting Home Agent, it needs to register to the Assigned Home Agent as proxy binding. When a packet destined to a given Home Address arrives at a Home Agent from a Correspondent Node: If the Home Agent is Assigned Home Agent for that Home Address and it has a direct registration (it is primary), the Home Agent forwards the packet over its bi-directional tunnel established with the Mobile Node (the MNHA tunnel). If it has a proxy registration (it is secondary), it forwards the packet to the primary Acting Home Agent - or directly to the Mobile Node if that is practical for tunnel setup and security reasons. Else it drops the packet. Wakikawa, et al. Expires 16 Aug 2004 [Page 35] Internet Draft HAHA protocol 16 Feb 2004 Else If the Home Agent is Acting Home Agent for that Home Address and it has a direct registration (it is primary), the Home Agent forwards the packet over its MNHA tunnel. If it has a proxy registration (it is secondary), it forwards the packet to the primary Acting Home Agent - or directly to the Mobile Node if that is practical for tunnel setup and security reasons. Else, it forwards the packet to the Assigned Home Agent. CN ----------> Acting HA / closest to CN / / / Assigned / HA V " " " " " " Acting HA primary MN <----------- for that registration (closest to MN) CN ----------> closest HA | to CN | | | | v Acting HA, primary MN <--------- for that registration (closest to MN) Else (if the Home Agent is the 'wrong Home Agent') the Home Agent tunnels the packet to the best suited of the local Home Agents, be it the Assigned Home Agent, or a local Acting Home Agent. In the worst case, the packet may bounce from the receiving Home Agent to the local Acting Home Agent, then to the Assigned Home Agent, and finally to the Acting Home Agent that has the registration. It is up to the Assigned Home Agent to forward the proxy binding states to the Acting Home Agent on the receiving side in order to allow Acting Home Agent to Acting Home Agent 'Z' routing. Wakikawa, et al. Expires 16 Aug 2004 [Page 36] Internet Draft HAHA protocol 16 Feb 2004 If the Home Agents are distributed geographically, it is expected that, in general, the angles of the Z (the Home Agents) are close to the Mobile Node and Correspondent Node respectively, relatively to the distance between the Home Agents, which makes the cost of the bouncing acceptable in terms of distance and hops. When a packet from a registered Mobile Node arrives over the MNHA tunnel to a Home Agent (one that it is registered to), the Home Agent forwards the packet directly to the Correspondent Node. That Home Agent is supposed to be close to the Mobile Node, making the MN-HA-CN triangle as flat as possible and limiting the cost of the dogleg. Wakikawa, et al. Expires 16 Aug 2004 [Page 37] Internet Draft HAHA protocol 16 Feb 2004 Authors Addresses Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252-8520 Japan Email: ryuji@sfc.wide.ad.jp Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: vijay.devarapalli@nokia.com Pascal Thubert Cisco Systems Technology Center Village d'Entreprises Green Side 400, Avenue Roumanille Biot - Sophia Antipolis 06410 France Email: pthubert@cisco.com Wakikawa, et al. Expires 16 Aug 2004 [Page 38] Internet Draft HAHA protocol 16 Feb 2004 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Wakikawa, et al. Expires 16 Aug 2004 [Page 39]