Network Working Group B. Koh Internet-Draft C. Ng Expires: November 30, 2004 Panasonic Singapore Labs J. Hirano Panasonic June 2004 Dynamic Inter Home Agent Protocol draft-koh-dihap-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 November 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft describes a proposed Dynamic Inter Home Agent solution to provide redundancy and load balancing of Home Agents. The proposed solution recommends additional communication between home agents that may be located far apart in terms of network topology but still belonging to or are trusted by the same administrative domains (service providers). While the mobile node is roaming away from its home network, intervening home agents in the path of the bidirectional tunnel between the mobile node and its registered home Koh, et al. Expires November 30, 2004 [Page 1] Internet-Draft DIHAP June 2004 agent may detect its presence. The intervening home agents that are affiliated to the current home agent of the mobile node then proceed to update it of their availability to serve as home agent for the mobile node. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Dynamic Inter Home Agents Protocol . . . . . . . . 4 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Home Agent Change Message . . . . . . . . . . . . . . . . 5 4.2 Affiliated Home Agent Update Message . . . . . . . . . . . 6 4.3 Home Interface List Update Message . . . . . . . . . . . . 7 5. Home Interface List . . . . . . . . . . . . . . . . . . . . . 9 6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 9 6.1 Home Agent Notification . . . . . . . . . . . . . . . . . 10 6.1.1 Separate Anycast . . . . . . . . . . . . . . . . . . . 10 6.1.2 Piggy-backed Anycast . . . . . . . . . . . . . . . . . 10 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 10 7.1 Original Home Agent . . . . . . . . . . . . . . . . . . . 10 7.1.1 Solo Operation . . . . . . . . . . . . . . . . . . . . 10 7.1.2 Centralised Operation . . . . . . . . . . . . . . . . 11 7.2 Affiliated Home Agent . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 15 Koh, et al. Expires November 30, 2004 [Page 2] Internet-Draft DIHAP June 2004 1. Introduction For Mobile IPv6 [6], mobile nodes either tunnel its traffic through a bi-directional tunnel via its home agent or it may employ route optimisation with the correspondent node it is in communication with. For NEMO Basic Support [1], the default mode of operation is to tunnel all traffic meant for the mobile network through the home agent serving the mobile router. As such, home agents may greatly affect the effectiveness and efficiency with respect to the terminals that deploy these two protocols. With the widespread prolification of mobile terminals and supporting services, this may gain increasing importance as a influencing factor. Sometimes, the mobile host and its network could be closer to the correspondent node than the Home Agent or the home agent becomes increasing congested and overloaded. By choosing a home closer to its current location, the network traffic could be significantly reduced as well as improving the overall performance of the mobile host or network. One solution for solving this problem is described in [3], the Inter Home Agents Protocol proposes that the mobile node be provided with multiple home agents and any of the home agents can forward packets to and from the the mobile node. However, the downside to the proposed solution is the constant updating between all of the home agents. This is irregardless of whether or not the other home agents are useful to the mobile node. There is hence a fixed increase in signalling overhead per number of home agents involved. This draft describes a proposed Dynamic Inter Home Agent solution to provide redundancy and load balancing of Home Agents. The proposed solution recommends additional communication between home agents that may be located far apart in terms of network topology but still belonging to or are trusted by the same administrative domains (service providers). While the mobile node is roaming away from its home network, intervening home agents in the path of the bidirectional tunnel between the mobile node and its registered home agent may detect its presence. The intervening home agents that are affiliated to the current home agent of the mobile node then proceed to update it of their availability to serve as home agent for the mobile node. The proposed solution employs the use of an addition Home Interface List as a repository of the received updates from other home agents including local interfaces that are serving as home agents. The location of the Home Interface List gives rise to the two operation modes of the solution. When the list is located on the home agent itself, this is referred to as the solo mode of operation. However, it is possible to locate the list on a topologically different location. This is referred to as the centralised mode of operation. Koh, et al. Expires November 30, 2004 [Page 3] Internet-Draft DIHAP June 2004 2. Terminology There are separate documents regarding Mobility terminology [5] as well as Nemo terminology [2], which defines the terms related to Network Mobility used in the document. This document in addition defines the following term. Affiliated Home Agent A home agent that is known and trusted by a singular or group of home agents. 3. Overview of Dynamic Inter Home Agents Protocol When a home agent is deployed, each home agent should be configured with the prefixes of other affiliated home agents. A Home Interface List comprising of information such as interface and mobile node addresses should be available to the home agent. The list may be located on the home agent or at a remote location (e.g. some other home agent) that is preconfigured in the home agent. This information is different from the Binding Cache of the home agent as its entries comprises of all the available interfaces able to serve as a home agent. Each entry should preferably have a metric to indicate preference for use as a home agent interface. The preference metric should be updated as the situation requires it. Each entry may optionally have a corresponding mobile node address to indicate that the interface should only be considered for the indicated mobile node. For each such mobile node entry, there should also be a corresponding selection metric. The home agent should first register all of its interfaces available to serve as home agent interfaces with the Home Interface List. When a registered interface is no longer available, it should be deregistered from the List. Unavailability may be due possibly to the link going down or congestion. When choosing an interface to serve as the home agent for the mobile node, the home agent may choose from its available local interfaces or it may alternatively consult the Home Interface List. Koh, et al. Expires November 30, 2004 [Page 4] Internet-Draft DIHAP June 2004 +-----------------------------------------------------+ | | | Internet HA4 | | | | HA2 | | | +-------+ | /---|==HA==| Home | | /-----/ | |Network| | /------/ | +-------+ | /-----HA3-----/ Packet Path | | MN-----HA1----/ | | | +-----------------------------------------------------+ During normal operation, the home agent (HA1, HA3) may detect or be informed of the presence of mobile nodes (MN) registered with an affiliated home agent (HA) roaming in their vicinity. Upon such occasion, the home agent (HA1, HA3) may choose to inform the destination affiliated home agent (HA)of its availability to serve as a home agent for the mobile node (MN). The Home Interface List of the destination affiliated home agent (HA) is updated accordingly. The home agent (HA) may choose to actively inform a registered mobile node (MN) to switch to another home agent interface. In this case, a Home Agent Change message may be sent to the mobile node (MN) with the address of the new home agent interface address (HA1). The mobile node (MN) should then proceed to register itself with the given home agent interface (HA1). The Home Interface List may be shared amongst several home agents. In this scenario, the list may be hosted on one of the home agents or at another remote location. 4. Message Formats 4.1 Home Agent Change Message The Home Agent Change message is used by a home agent to request a mobile node to perform a home registration with a specific home agent. The Home Agent Change message uses the MH Type value 8. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Koh, et al. Expires November 30, 2004 [Page 5] Internet-Draft DIHAP June 2004 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Alternate Home Agent Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Alternate Home Agent Address The address of the new home agent with which the mobile node should initiate a home registration. 4.2 Affiliated Home Agent Update Message The Affiliated Home Agent Update message is used by an affiliated home agent to inform a home agent of its availability and suitability to act as a home agent for the detected mobile node in question. The Affiliated Home Agent Update message uses the MH Type value 9. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Hop Limit Count| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Detected Mobile Node Care-of-Address + | | + + Koh, et al. Expires November 30, 2004 [Page 6] Internet-Draft DIHAP June 2004 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hop Limit Count 8-bit field specify the initial Hop Count of the IPv6 header. By subtracting Hop Limit Count from the Hop Count, it is possible to estimate the distance (in hops) of the affiliated home agent from the registered home agent. This value may then be used as the metric value in the Home Interface List Update message. Lifetime 8-bit unsigned integer. The number of time units remaining before the information contained within this update MUST be considered expired. One time unit is 4 seconds. Detected Mobile Node Care-of-Address The current Care-of-Address of the mobile node that was detected by the affiliated home agent. 4.3 Home Interface List Update Message The Home Interface List Update message is used by a home agent to update the Home Interface List when the home agent is operating in centralised mode. This means that the Home Interface List is actually hosted on an entity at a remote location and the home agent itself. The Home Interface List Update message uses the MH Type value 10. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: Koh, et al. Expires November 30, 2004 [Page 7] Internet-Draft DIHAP June 2004 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Agent Interface Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobile Node Home Address . . . | | Metric 8-bit unsigned integer. The number reflections the desirability of using the interface specified in the message as a home agent. Metric values for entries of local interfaces should not used to compare with the metric values for entries created for affiliated home agents as their derivation may differ. Lifetime 8-bit unsigned integer. The number of time units remaining before the information contained within this update MUST be considered expired. One time unit is 4 seconds. Home Agent Interface Address The address of the interface that is available to serve as a home agent. If the Mobile Node Home Address field exists, the interface will only serve as home agent for that mobile node. Mobile Node Home Address Only found for messages corresponding to Affiliated Home Agent Update messages. This field may be left out if not applicable. The existence of this field may be deduced from the Header Len field of the Mobility Header. Koh, et al. Expires November 30, 2004 [Page 8] Internet-Draft DIHAP June 2004 5. Home Interface List The Home Interface List maintains a record of available interfaces for which may serve as home agents for mobile nodes. A Home Interface List may either be maintained by each home agent node or else at a known location. The Home Interface List may be implemented in any manner consistent with the external behavior described in this document, for example by being combined with the node's Binding Cache as maintained by Mobile IP. When responding to a home registration request or performing load balancing for congested interfaces, the home agent may choose to utilise local interfaces or else the Home Interface List should be searched. Each Home Interface List entry conceptually contains the following fields: o The address of the interface to serve as a home agent o The address of the specific mobile node for which the interface is willing to serve as a home agent. This value may be left blank. Entries with a value in this field should be given higher priority when a request is made for the mobile node in question. o A metric value. This may be a preference value for using this interface. When there is a valid value in the mobile node address field however, this metric may be used to signify the proximity of the interface to the mobile node in question. o A lifetime value, indicating the remaining lifetime for this Home Interface List entry. This may be mandatory for all entries in a remotely located Home Interface List, else required only for entries with a valid mobile node address field value. The Home Interface List should be updated when interfaces come out or are taken off due to congestion or otherwise. 6. Mobile Node Operation The mobile node MUST be able to interpret the new Home Agent Change message in order for the Dynamic Inter Home Agent Protocol to function. Upon the receipt of the option, the mobile node should perform the following actions: o Check that there is a corresponding home registration entry for the source address given in the packet containing the option. If a corresponding entry is not found, the packet MUST be silently discarded. Koh, et al. Expires November 30, 2004 [Page 9] Internet-Draft DIHAP June 2004 o If a corresponding home registration entry was found, the Alternate Home Agent Address should be retrieved from the option and the Home Registration process started with the new Home Agent. o The mobile node MAY choose to expire the home registration with its old home agent, it may otherwise allow it to expire normally. 6.1 Home Agent Notification The mobile MAY choose to take no specific action to notify any nearby home agents. However, this may be the least effective method of implementing the solution. Better alternatives involving the use of anycasting are given below. 6.1.1 Separate Anycast For a mobile node that implements the Separate Anycast, whenever the mobile node sends a Binding Update to its registered home agent, a separate packet with the destination address set to the value of Mobile IPv6 Home-Agents anycast address [4] is sent. The source address of the packet should be set to the mobile node's current Care-of-Address. The packet should contain the address of the mobile node's current home agent. 6.1.2 Piggy-backed Anycast For a mobile node that implements the Piggy-backed Anycast, the mobile node should encapsulate the Binding Update to its registered home agent. The new IPv6 header should have the source address set to the mobile node's current Care-of-address and the destination address as the Mobile IPv6 Home-Agents anycast address. 7. Home Agent Operation 7.1 Original Home Agent The original home agent is the home agent with which the mobile node currently has a home registration. When the Home Interface List is located on the home agent itself, it is described as performing in solo mode. Locating the Home Interface List on a remote interface or on another home agent is called the centralised operation mode. 7.1.1 Solo Operation The home agent operates as per Mobile IP [6] and NEMO [1], however, it should also register the interfaces on which it is serving as a home agent with the Home Interface List. Home registration requests Koh, et al. Expires November 30, 2004 [Page 10] Internet-Draft DIHAP June 2004 are handled normally. However, if and when it decides to do load balancing either due to traffic congestion or impending link going down, it MAY arbitrarily choose a local interface or else query the Home Interface List. It MAY then send a message with the Home Agent Change message to the affected mobile node(s) requesting that the mobile node register itself with the new home agent. When the home agent receives an Affiliated Home Agent Update message addressed to itself, it should perform the following actions: o Check that the source address of the packet contains the address belonging to an affiliated home agent or group of home agents. The packet should be silently discarded otherwise. o Check that the Detected Mobile Node Care-of-Address field has a corresponding Care-of-Address entry in the Binding Cache and that it is a Home Registration. o Update the Home Interface List with the address of the affiliated home agent interface, the specified mobile node's home address, the lifetime for which the entry is valid and the metric. The metric described here is calculated by deducting the Hop Limit Count field in the Affiliated Home Agent Update message from the current Hop Limit value in the IPv6 header field. This should yield the approximate distance (in hops) to the affiliated home agent. 7.1.2 Centralised Operation The home agent in centralised operation is essentially similar to solo operation. The key difference being that all updates to the Home Interface List should be forwarded to the entity hosting the list. Additionally, the home agent should update its local interfaces that are serving as home agents with the remote Home Interface List together with a lifetime entry and should periodically do so before the lifetime expires. When the home agent receives an Affiliated Home Agent Update message from a intermediate home agent, it should as per Solo operation check that the source home agent of the the message is valid. The Detected Mobile Node Care-of-Address field is then checked with the Binding Cache for a match. Assuming a match is found, the Home Interface List Update message is created and sent to be updated at the remote Home Interface List. The remote Home Interface List may be queried for a home agent address by the home agent by sending a Query message with a payload Koh, et al. Expires November 30, 2004 [Page 11] Internet-Draft DIHAP June 2004 consisting of a magic number and the home address of the mobile node. The Reply message from the Home Interface List should have a payload consisting of the same magic number contained in the Query message as well as the selected home agent interface address. It is assumed that the home agents and the entity hosting the Home Interface List are known to each other. 7.2 Affiliated Home Agent Affiliated home agents MAY actively scan forwarded packets for the existence of a mobility header and an affiliated home agent address in the destination address field. They then send a Alternate Home Agent Update to the destination address of the intercepted packet. This assumes that the home agent is also a operating as a router. The more efficient and effective method would be for the mobile node to use anycasting. In any case, the affiliated home agent would take the following actions: o Detect presence of Binding Updates to a home agent. o Check that destination home agent belongs to list of affiliated home agents (e.g. by checking the network prefix). Perform relevant packet processing. Forwarding the packet if it was intercepted, Decapsulating and forwarding a piggy-backed anycast or discarding a separate anycast notification packet. o Check Home Interface List to look for available interface to serve as the home agent for the mobile node. o Create and send the Affiliated Home Agent Update message and send it to the home agent specified in the destination address. 8. IANA Considerations This document defines three new Mobility Header messages o Home Agent Change Message o Affiliated Home Agent Update Message o Home Interface List Update Message 9. Security Considerations A home agent MUST know whether the other home agent is an affiliated Koh, et al. Expires November 30, 2004 [Page 12] Internet-Draft DIHAP June 2004 home agent. Affiliated home agents SHOULD establish secure associations with each other before sending Affiliated Home Agent Updates. All signaling messages between the home agents SHOULD be authenticated and encrypted (e.g. by using IPsec ESP) Please refer to the Mobile IPv6 specification [6] and the NEMO Basic Support protocol specification [1] for security considerations. 10 References [1] Devarapalli, V., "Network Mobility (NEMO) Basic Support Protocol", draft-ietf-nemo-basic-support-03 (work in progress), June 2004. [2] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-00 (work in progress), May 2003. [3] Wakikawa, R., Devarapalli, V. and P. Thubert, "Inter Home Agents Protocol (HAHA)", draft-wakikawa-mip6-nemo-haha-01 (work in progress), February 2004. [4] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", IETF RFC 2526, March 1999. [5] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [6] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Authors' Addresses Benjamin Koh Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG EMail: benjamin@psl.com.sg Koh, et al. Expires November 30, 2004 [Page 13] Internet-Draft DIHAP June 2004 Chan-Wah Ng Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 SG Phone: +65 65505420 EMail: cwng@psl.com.sg Jun Hirano Matsushita Electric Industrial Co., Ltd. (Panasonic) 5-3 Hikarino-oka Yokosuka, Kanagawa 239-0847 JP Phone: +81 46 840 5123 EMail: hirano.jun@jp.panasonic.com Koh, et al. Expires November 30, 2004 [Page 14] Internet-Draft DIHAP June 2004 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 IETF's procedures with respect to rights in IETF 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 (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koh, et al. Expires November 30, 2004 [Page 15]