Netext Working Group X. Cui Internet Draft Huawei Intended status: Informational October 26, 2009 Expires: April 2010 Reflector Extension for Route Optimization Agent draft-cui-netext-route-optimization-agent-ext-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 April 26 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Cui Expires April 26, 2010 [Page 1] Internet-Draft Route Optimization Agent Extension October 2009 Abstract Route Optimization is a very useful feature in Mobile IPv6. Mobile node can communicate with correspondent node without the involvement of the home agent by Route Optimization. But there are some limitations to this feature. One problem is that the mobile node and the correspondent node must be capable for Route Optimization. This document introduces a Route Optimization Agent function used for Route Optimization and this extension mechanism can enable Route Optimization to be used between mobile node and simple IP node. In the extension solution, the Route Optimization Agent function may be implemented in LMA or MAG and the Agent entity can reflect the RO- related signal messages and fulfill the Route Optimization procedure on behalf of the simple IP node. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Cui Expires April 26, 2010 [Page 2] Internet-Draft Route Optimization Agent Extension October 2009 Table of Contents 1. Introduction..................................................4 2. Terminology...................................................4 3. Scenario Analysis and Use Case................................5 3.1. Issues if the CN can't support Route Optimization........5 3.2. Use Case for Route Optimization Agent Extension..........7 3.3. Motivation..............................................11 3.4. Requirements............................................12 4. Solution and Operation Consideration.........................13 4.1. Route Optimization Agent Operation......................13 4.1.1. Incoming Flow Transmission.........................14 4.1.2. Outgoing Flow Transmission.........................15 4.1.3. Conceptual Data Structures.........................16 4.1.4. Configuration Variables............................16 4.2. LMA Operation...........................................17 4.3. MAG Operation...........................................17 5. Security Considerations......................................18 6. IANA Considerations..........................................18 7. Acknowledgments..............................................18 8. References...................................................18 8.1. Normative References....................................18 8.2. Informative References..................................19 APPENDIX A: Future Extension and Use Case.......................20 A.1. Agent Extension for Mobile Router.......................20 A.2. Extension for IPv4/MIP4.................................21 Author's Addresses..............................................21 Cui Expires April 26, 2010 [Page 3] Internet-Draft Route Optimization Agent Extension October 2009 1. Introduction Mobile IPv6 protocol [RFC3775] provides a mobility extension to basic IPv6 and introduces Route Optimization (RO) mechanism. Route Optimization enables mobile node (MN) to establish a directly connection between mobile node and correspondent node (CN) without the involvement of MN's home agent (HA). But Route Optimization requires mobile node and correspondent node to have some certain capabilities, such as MN's transmitting Home Test Init (HoTI) message, Care-of Test Init (CoTI) message and direct Binding Update message to CN, and CN's reflecting Home Test (HoT) message, Care-of Test Init (CoT) message and Binding Ack message to MN. If the correspondent node is a simple IP node without support for Route Optimization, the MN with support for Route Optimization even can't set up Route Optimization to this CN, as [RFC3775] specified "If a mobile node attempts to set up route optimization with a node with only basic IPv6 support, an ICMP error will signal that the node does not support such optimizations and communications will flow through the home agent." From the MN's viewpoint, the IPv6 nodes with support for MIP and IPv6 nodes without support for MIP are using the unified address space, so the MN can't distinguish whether a correspondent node is a RO-capable node or a non-RO-capable node. When the network is composed of mobile IPv6 nodes, IPv6 nodes with support for Route Optimization and enormous quantity of simple IPv6 nodes with support for only basic IPv6 protocol, lots of Route Optimization attempts will go to a failure result. This document introduces an extension mechanism, which can be used for IP nodes with only support for basic IPv6 protocol, to fulfill the Route Optimization. 2. Terminology All the mobility related terms used in this document are to be interpreted as defined in the Mobile IPv6 specification [RFC3775] and Proxy Mobile IPv6 [RFC5213]. Cui Expires April 26, 2010 [Page 4] Internet-Draft Route Optimization Agent Extension October 2009 This document also provides the following context-specific explanation to the following terms used in this document. Route Optimization Agent (ROA) Route Optimization Agent is the logical function entity that acts reflector role in Route Optimization procedure on behalf of the correspondent node. Agent Binding Cache (ABC) The Agent Binding Cache is the cache of binding for binding source node and binding destination node, and is cached in the mid-box (i.e. the agent entity) between the node pair. 3. Scenario Analysis and Use Case 3.1. Issues if the CN can't support Route Optimization Mobile IPv6 provides the Route Optimization mechanism, which may be used between mobile nodes with support for MIPv6 or between mobile nodes and IP nodes with support for Route Optimization. In other situation, if the correspondent node can't support Route Optimization, the correspondent node will reply an ICMP ERROR message to the mobile node who initiates the Route Optimization. On the other hand, Proxy Mobile IPv6 [RFC5213] provides a network- based mobility solution. In Proxy Mobile IPv6 domain, Local Mobility Anchor (LMA) and Mobile Access Gateway (MAG) can provide proxy mobility management functionality for the mobile node. The LMA works as the mobility anchor for the mobile node and the MAG works as the mobility proxy for the mobile node, as [RFC5213] defined, LMA is "the entity that manages the mobile node's binding state" while MAG is "a function on an access router that manages the mobility-related signaling for a mobile node that is attached to its access link". But by now the MAG is only half-function proxy for the mobile node, because the MAG can only transmit mobility-related signal messages for the mobile node but can not dispose the mobility- related signal messages destined to the mobile node. The MAG is only an active proxy function but does not implement reactive agent function in current specification. The function of managing the mobility-related signaling defined for MAG is not fully specified by now. Cui Expires April 26, 2010 [Page 5] Internet-Draft Route Optimization Agent Extension October 2009 Take the Route Optimization procedure as the example. If the mobile node is setting up Route Optimization with a simple IP node which is attached to the MAG, the message flow is as below: MN1 HA LMA MAG MN2 | | | | | ===== MN1 attached to HA and MN2 attached to MAG ===== (a) ===== MAG runs PMIP protocol for MN2 (Basic IP) ===== ===== MN1 has no idea about the capability of MN2 ===== | | | | | | HoTI | | | | (b) |---------->| HoTI | | | (c) | |------------>| HoTI | | (d) | | |---------->| HoTI | (e) | | | |---------->| | | | | ICMP(Err) | (f) | | | |<----------| | CoTI | | | (g) |------------------------>| CoTI | | (h) | | |---------->| CoTI | (I) | | | |---------->| | | | | ICMP(Err) | (j) | | | |<----------| | ICMP(Err) | | | | (k) |<----------| | | | | | | | | | | | | | | | | | | Figure 1 Issue in Route Optimization. The detailed descriptions are as follows: (a) MN1 attached to Home Agent and MN2 attached to MAG, MAG runs PMIP protocol for MN2, which only supports basic IP protocol. During the lifetime of the session between MN1 and MN2, MN1 has no idea about the capability of MN2. (b~e) MN1 initiates a Route Optimization set up and sends Home Test Init message to MN2. The destination address of the packet is the home address of MN2 and the packet goes through HA, LMA and MAG, at last arrives at MN2. Cui Expires April 26, 2010 [Page 6] Internet-Draft Route Optimization Agent Extension October 2009 (f) MN2 can't recognize the Home Test Init message and replies an ICMP error message to MN1. (g~i) MN1 sends Care-of Test Init message to MN2. The destination address of the packet is the home address of MN2 and the packet goes through LMA and MAG, at last arrives at MN2 too. (j) MN2 can't recognize the Care-of Test Init message and replies an ICMP error message to MN1. (k) MN1 receives the ICMP error messages sent by MN2, has to stop Route Optimization set up. In this example, Home Test Init message and Care-of Test Init message are both mobility-related signaling, but the MAG doesnot manage or deal these messages for MN2. This miss induces the failure of Route Optimization. 3.2. Use Case for Route Optimization Agent Extension Route Optimization is specified in [RFC3775] and also adopted by other SDO, such as 3GPP2. 3GPP2 has specified some specific requirements and feature description in 3GPP2 documents. Section 4.4 "MIP6" of [X.S0011-001-D] is about MIP6 protocol and Figure 13 and Figure 16 in this section illustrate the protocol reference model for MIP6 Route Optimization mode. Section 5.3 "Home Agent Requirements" of [X.S0011-002-D] introduces the requirements of Home Agent on Route Optimization, as specified in section 5.3.6 "Return Routability Support for Route Optimization", "The Home Agent shall support Return Routability (RR) for Route Optimization as specified in [RFC3775] with the exception that IPsec is not used to protect the RR messages." Section 6 "MIP6 Route Optimization" of [X.S0047-0] introduces the requirements of mobile node on Route Optimization, as specified in section 6.1 "MS Requirements", "The MS may support the return routability procedure, binding update procedure, and packet processing for the Mobile Node Operation and Correspondent Node Operation, according to [RFC3775]." Based on 3GPP2 documents, mobile node in 3GPP2 network may (as far as it like) set up Route Optimization to the correspondent node, but as mentioned above, the correspondent node maybe cannot support that Cui Expires April 26, 2010 [Page 7] Internet-Draft Route Optimization Agent Extension October 2009 (e.g. CN is in 3GPP network or in PMIP domain). From the MN's viewpoint, all work well but the setting up is failed, the result is exactly disgusting. For above trouble, this document introduces the Route Optimization Agent function and this extension enables network entity to manage all the mobility-related signaling for the mobile node that is attached to the network. The use case, taking the MAG as the Agent entity, is as below: Cui Expires April 26, 2010 [Page 8] Internet-Draft Route Optimization Agent Extension October 2009 MN1 HA LMA MAG MN2 | | | | | ===== MN1 attached to HA and MN2 attached to MAG ===== a ===== MAG runs PMIP protocol for MN2 (Basic IP) ===== ===== MN1 has no idea about the capability of MN2 ===== | | | | | | HoTI | | | | b1 |---------> | HoTI | | | b2 | |------------>| HoTI | | b3 | CoTI |---------->| | c1 |------------------------>| HoT | | d1 | | |<----------| | | | | CoTI | | c2 | | HoT |---------->| | d2 | HoT |<------------| | | d3 |<----------| | CoT | | e1 | CoT |<----------| | e2 |<------------------------| | | | | | | | | | | | BU | | | f1 |------------------------>| BU | | f2 | |---------->| | | |Binding Ack| | g1 | Binding Ack |<----------| | g2 |<------------------------| | | | Traffic data | | | -|------------------------>| Traffic | | / | |---------->| Traffic | / | | |---------->| h | | | | Traffic | \ | | Traffic |<----------| \ | Traffic data |<----------| | -|<------------------------| | | | | | | Figure 2 Agent extension in Route Optimization. The detailed descriptions are as follows: (a) MN1 attached to Home Agent and MN2 attached to MAG, MAG runs PMIP protocol for MN2, which only supports basic IP protocol. During Cui Expires April 26, 2010 [Page 9] Internet-Draft Route Optimization Agent Extension October 2009 the lifetime of the session between MN1 and MN2, MN1 has no idea about the capability of MN2. (b1~b3) MN1 initiates a Route Optimization set up and sends Home Test Init message to MN2. The destination address of the packet is the home address of MN2 and the packet goes through HA and LMA and reaches MAG. (c1~c2) MN1 sends Care-of Test Init message to MN2. The destination address of the packet is the home address of MN2 and the packet goes through LMA and reaches MAG too. (d1~d3) MAG recognizes the Home Test Init message, which is a mobility-related signaling, and generates a Home Test message on behalf of MN2. The procedure for the MAG to generate the Home Test message is as the same with CN's operation specified in section 9.4.1 and section 9.4.3 of [RFC3775]. The MAG transmits Home Test message to MN1 and the packet goes through LMA and HA and arrives at MN1 at last. (e1~e3) MAG recognizes the Care-of Test Init message, which is a mobility-related signaling, and generates a Care-of Test message on behalf of MN2. The procedure for the MAG to generate the Care-of Test message is as the same with CN's operation specified in section 9.4.2 and section 9.4.4 of [RFC3775]. The MAG transmits Care-of Test message to MN1 and the packet goes through LMA and arrives at MN1 at last. (f1~f2) MN1 receives Home Test and Care-of Test message and sends Binding Update message to the address of MN2 as specified in [RFC3775]. The Binding Update message also reaches the MAG which the MN2 attached to. (g1~g2) MAG recognizes the Binding Update message, which is a mobility-related signaling, and caches the Home Address, Care- of Address and bindings on behalf of MN2. The procedure is as the same with CN's operation as specified in section 9.5.1 of [RFC3775]. The MAG also includes the IP address of the attached IP node (i.e. the destination of the Binding Update message) in the Agent Binding Cache entry. The MAG transmits Binding Ack message to MN1 and the packet goes through LMA and arrives at MN1 at last. (h) Route Optimization is achieved and Home Agent of MN1 is not involved in the traffic data transport. For the traffic flow between MN1 to MN2, the MAG forwards all the traffic packets Cui Expires April 26, 2010 [Page 10] Internet-Draft Route Optimization Agent Extension October 2009 between MN1 and MN2, with some additional operation (specified in section 4.1) implemented. 3.3. Motivation The motivation for this extension is based on some mechanisms that have been introduced in IETF. For example, Proxy ARP protocol, which is specified in [RFC1027] "Using ARP to Implement Transparent Subnet Gateways", has been adopted by lots of routers and gateways. One basic Proxy ARP flow is as below: Host A Gateway Host B | e0 | e1 | | | | ------- Host A and Host B attached to the Gateway ------- | | | | ARP request (IP B) | | |----------------------- > | | | | | | proxy ARP reply (IP B) | | |< ------------------------| | | | | | traffic data (IP B) | | |------------------------ >| traffic data (IP B) | | |------------------- >| | | | | | | Figure 3 Proxy ARP message flow. In this case, when host A wants to send IP packets to host B, if host A knows only the IP address of host B but doesn't know the MAC address of host B, host A need send out a ARP request message and broadcast the message in MAC layer. The gateway will receive this ARP request, whose destination IP address is the IP address of host B. The destination of this message is not the gateway, but the gateway knows that the destination (i.e. host B) is attached to itself and also knows the destination can't receive this ARP request, so in this situation, the gateway replies an ARP reply message for host B. In the proxy ARP reply message, the source IP address is the IP address of host B and the source MAC address is the MAC address of the e0 interface in the gateway. When host A receives this proxy ARP reply Cui Expires April 26, 2010 [Page 11] Internet-Draft Route Optimization Agent Extension October 2009 message, it can know how to send IP packets to host B. Host A will send IP packets to the gateway (i.e. the e0 interface) and the gateway will forward these packets to host B. Similar to this case, when the MAG in the PMIP domain receives some mobility-related signal messages (e.g. HoTI, CoTI and BU) destined to the mobile node that is attached to its access link, the MAG can also know that the mobile node can't recognize these messages. This judgment may depend on the policy profile of the mobile node, the configuration variables of the MAG, or other manners. Since the MAG is the mobility proxy of the mobile node and can manage the mobility- related signaling for the mobile node, it is reasonable for the MAG to dispose these messages on behalf of the mobile node. The Route Optimization Agent function MAY be implemented in this situation. 3.4. Requirements The Route Optimization Agent function introduced in this document depends on the operation of the network entity. The requirements of the Route Optimization Agent function include following: R1: Route Optimization Agent can recognize mobility-relate signal messages. When the Route Optimization Agent receives mobility-related signaling destined to the MN that is attached to the network, the Route Optimization Agent MAY intercept the messages and reply response messages for the mobile node. Since all the mobility-related signal messages contain mobility header and MH Type field, the Route Optimization Agent can easily fulfill this requirement. R2: Route Optimization Agent can achieve the operation of CN role for Return Routability and Route Optimization specified in [RFC3775]. [RFC5213] has specified some mechanisms for LMA/MAG to provide network-based mobility management function. For example, the MAG can create and maintain the Binding Update List as a mobile node does, and the LMA can create and maintain the Binding Cache for the mobile node. It is easy to expand the MAG to create and maintain an Agent Binding Cache Entry to meet this requirement, and it is also easy to expand the LMA to create and maintain Agent Binding Cache to hold the binding between the mobile node and the correspondent node. The LMA/MAG MAY do more agent operation than specified in [RFC5213] as specified in this document. R3: Route Optimization Agent can modify the outgoing packets and route the packets to the optimized route depending on the created Agent Binding Cache. The Route Optimization Agent MAY check whether an Agent Binding Cache entry exists and if the Agent Binding Cache entry exists the Route Optimization Agent modifies the destination Cui Expires April 26, 2010 [Page 12] Internet-Draft Route Optimization Agent Extension October 2009 address in the IP header and includes Type 2 Routing Header in the outgoing packets. The Route Optimization Agent should set the destination address to the care-of address of the destined mobile node and set the Home Address field in the Type 2 Routing Header to the home address of the destined mobile node. R4: Route Optimization Agent can modify the source address of the incoming packets depending on the created Agent Binding Cache. The care-of address in the source address of the packet is replaced by the home address of the remote mobile node. 4. Solution and Operation Consideration 4.1. Route Optimization Agent Operation The Route Optimization Agent is a function that typically runs on LMA, MAG or other special routers. The Route Optimization Agent transfers all the IP packets from or destined to the mobile node that is attached to the network. However, some more operations are defined in this document for the expansion solution. The operations for Route Optimization Agent consist of following: o Intercepting and disposing the mobility-related signaling destined to the attached mobile node. o Creating, maintaining and deleting the Agent Binding Cache for the mobile node to which the initiator wants to establish or release a Route Optimization. o Destination Address replacement and Type 2 Routing Header insertion for the outgoing traffic from the attached mobile node. o Source Address replacement for the incoming traffic destined to the attached mobile node. o Security operation for the Return Routability Procedure and Route Optimization. The Route Optimization Agent SHOULD works as specified in section 5.2 and section 15.4 in [RFC5213] for the role of correspondent node. Cui Expires April 26, 2010 [Page 13] Internet-Draft Route Optimization Agent Extension October 2009 Editor Note: The introduced Route Optimization Agent Function in the reflector may be separate with the active Proxy Mobile IP function specified in [RFC5213]. This is to say that the Agent Binding Cache management, the Binding Cache management and the Binding Update List management may be independent. Route Optimization Agent function may even be implemented in access router for fixed IP node. The details need more consideration and discussion. 4.1.1. Incoming Flow Transmission For the incoming flow (i.e. from the remote IP node to the IP node that is attached to the Route Optimization Agent), the Route Optimization Agent needs parse the IP header to check the packet type as soon as it receives the packet from the remote IP node. If the IP packets received from other IP nodes don't contain mobility header, i.e. the IP packets are not mobility-related signaling, the Route Optimization Agent entity needs examine its Agent Binding Cache for an entry for the address pair (i.e. the source address and the destination address of the IP packet). Additionally if a corresponding Agent Binding Cache entry exists, it means Route Optimization has been established between the IP node pair. The Route Optimization Agent MAY replace the care-of address in the source address of the packet with the home address of the mobile node. If the IP packets received from other IP nodes contain the mobility header, the Route Optimization Agent needs further check the MH type field in the mobility header. The Route Optimization Agent MAY execute the expansion solution for these mobility-related packets. When the received packet is Home Test Init Message, the Route Optimization Agent stops transferring the packet to the attached IP node and executes the operation as specified for the correspondent node role in section 9.4.1 and 9.4.3 of [RFC3775]. When the received packet is Care-of Test Init Message, the Route Optimization Agent stops transferring the packet to the attached IP node and executes the operation as specified for the correspondent node role in section 9.4.2 and 9.4.4 of [RFC3775]. When the received packet is Binding Update message, the Route Optimization Agent stops transferring the packet to the attached IP node and executes the operation as specified for the correspondent Cui Expires April 26, 2010 [Page 14] Internet-Draft Route Optimization Agent Extension October 2009 node role in section 9.5.1 and 9.5.4 of [RFC3775]. The exception is that the Route Optimization Agent should create or update Agent Binding Cache entity and include the destination address of the BU message in the Agent Binding Cache entry. 4.1.2. Outgoing Flow Transmission For the outgoing (i.e. from the IP node that is attached to the Route Optimization Agent to the remote IP node) flow, the Route Optimization Agent needs examine its Agent Binding Cache for an entry for the address pair (i.e. the source address and the destination address of the IP packet) as soon as it receives packet from the attached IP node. If no corresponding Agent Binding Cache entry exists, the Route Optimization Agent function is skipped. If a corresponding Agent Binding Cache entry exists, it means Route Optimization has been established between the IP node pair. The Route Optimization Agent MAY use a type 2 routing header to route the packet to the destination node by way of its care-of address. However, the Route Optimization Agent MUST NOT do this in the following cases: o When forwarding an IPv6 Neighbor Discovery packet. o When forwarding the packets that are noted in Section 6.1 of [RFC3775]. The Route Optimization Agent may implement following operation for Route Optimization: o The Route Optimization Agent inserts the Type 2 routing header and sets the Home Address in the routing header to the remote mobile node's home address (the original destination address to which the packet was being sent). o The Route Optimization Agent sets the Destination Address in the packet's header to the remote mobile node's care-of address copied from the Agent Binding Cache entry. o The Route Optimization Agent operation is achieved and the packet go forward as described in other specification. Cui Expires April 26, 2010 [Page 15] Internet-Draft Route Optimization Agent Extension October 2009 Note that the implementation creates some additional requirements for path MTU discovery since the modification changes the packet size. The Route Optimization Agent should choose an appropriate way to indicate the sending IP node this situation. 4.1.3. Conceptual Data Structures This document adds Agent Binding Cache to the Route Optimization Agent entity. When the Route Optimization Agent receives the Binding Update message destined to the attached mobile node the Route Optimization Agent creates or updates the Agent Binding Cache entry and includes the destination address of the BU message in the Agent Binding Cache entry. The newly introduced Agent Binding Cache entry for this extension contains two additional fields than the Binding Cache entry data structure specified in section 9.1 of [RFC3775]. o The Agent Binding Cache entry contains a flag indicating either this is an Agent Binding Cache entry or a normal Binding Cache entry. o The Agent Binding Cache entry contains an associated mobile node address, which is the true destination of the intercepted Binding Update message. Each Agent Binding Cache entry is mapped with a triple set (i.e. HoA of MN, CoA of MN and IP address of CN). The lookup key is the source address and the destination address of the IP packet. For the incoming packet, if the CoA of MN and CN address pair matches, then the Agent Binding Cache entry is found. For the outgoing packet, if the HoA of MN and CN address pair matches, then the Agent Binding Cache entry is found. Route Optimization may be applied between the IP node pair in these two cases. 4.1.4. Configuration Variables A configuration variable, EnableRouteOptimizationAgent is defined in this document for Route Optimization Agent function. Cui Expires April 26, 2010 [Page 16] Internet-Draft Route Optimization Agent Extension October 2009 This variable is available in Route Optimization Agent entity. When the value of this variable is 1, the Route Optimization Agent function is enabled. When the value of this variable is 0, the Route Optimization Agent function is disabled. The default value of EnableRouteOptimizationAgent is 0. 4.2. LMA Operation The Route Optimization Agent function may be implemented in LMA entity. When the LMA works as the Route Optimization Agent entity, LMA should follow the operation specified in section 4.1 of this document, and other network elements such as MAG, CN, MN and the HA of the MN are not impacted and follow the operation described in other specifications. 4.3. MAG Operation The Route Optimization Agent function may be implemented in MAG entity. When the MAG works as the Route Optimization Agent entity, MAG should follow the operation specified in section 4.1 of this document, and other network elements such as LMA, CN, MN and the HA of the MN are not impacted and follow the operation described in other specifications. Note if the Route Optimization Agent function is implemented in the MAG and MAG handover happens simultaneously, the previous MAG should try to transfer the Agent Binding Cache entry to the new MAG as part of the context. If the new MAG cannot support Route Optimization Agent function or the value of EnableRouteOptimizationAgent in the new MAG is 0, the Route Optimization would be interrupted. This case is for further study. Cui Expires April 26, 2010 [Page 17] Internet-Draft Route Optimization Agent Extension October 2009 5. Security Considerations The extension in this document is just to expand the scope of the mobility management to cover the reactive mobility management agent function, such as the acceptance of Route Optimization, and the MAG still follows the principle that providing network-based mobility management to the mobile node that is attached to its access link. So this extension brings no new security issue to mobility management. But this extension needs the MAG to implement packet inspection on the packets destined to the mobile node, which would impact the performance of the MAG and maybe bring some security risk. By the time when this document is written, no explicit security problem has been found and the accurate security consideration needs to be further studied. 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgments The author would like to specially thank Hidetoshi Yokota, Sri Gundavelli, Qin Wu and Yungui Wang for their comments and discussion on this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Sri, G., Kent, L., Vijay, D. Kuntal, C. and Basavaraj, P., "Proxy Mobile IPv6", RFC 5213, August 2008. Cui Expires April 26, 2010 [Page 18] Internet-Draft Route Optimization Agent Extension October 2009 8.2. Informative References [RFC1027] Smoot, C. and John Q., "Using ARP to Implement Transparent Subnet Gateways", RFC1027, October 1987. [X.S0011-001-D] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Introduction", X.S0011-001-D v2.0, November 2008. [X.S0011-002-D] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP Access Services", X.S0011-002-D v2.0, November 2008. [X.S0047-0] 3GPP2 TSG-X, "Mobile IPv6 Enhancements", X.S0047-0 v1.0, February 20, 2009. Cui Expires April 26, 2010 [Page 19] Internet-Draft Route Optimization Agent Extension October 2009 APPENDIX A: Future Extension and Use Case A.1. Agent Extension for Mobile Router This solution can also be applied in Network Mobility (NEMO) extension, where the Mobile Router provides mobility management for IP node with only support for basic IP. The extension for NEMO is as below: MN1 HA1 HA2 MR MN2 | | | | | ===== MN1 attached to HA and MN2 attached to MR ===== a ===== MR provides mobility management for MN2 ===== ===== MN1 has no idea about the capability of MN2 ===== | | | | | | HoTI | | | | b1 |---------> | HoTI | | | b2 | |------------>| HoTI | | b3 | CoTI |---------->| | c1 |------------------------>| HoT | | d1 | | |<----------| | | | | CoTI | | c2 | | HoT |---------->| | d2 | HoT |<------------| | | d3 |<----------| | CoT | | e1 | CoT |<----------| | e2 |<------------------------| | | | | | | | | | | | BU | | | f1 |------------------------>| BU | | f2 | |---------->| | | |Binding Ack| | g1 | Binding Ack |<----------| | g2 |<------------------------| | | | Traffic data | | | -|------------------------>| Traffic | | / | |---------->| Traffic | / | | |---------->| h | | | | Traffic | \ | | Traffic |<----------| \ | Traffic data |<----------| | -|<------------------------| | | | | | | Figure 4 Agent extension in Route Optimization. Cui Expires April 26, 2010 [Page 20] Internet-Draft Route Optimization Agent Extension October 2009 In this extension, Mobile Router manages the mobility-related signaling destined to the mobile node that is attached to its access link. Mobile Router responds Care-of Test and Home Test message and manages the binding cache on behalf of the MN. A.2. Extension for IPv4/MIP4 TBD. Author's Addresses Xiangsong Cui Huawei Technologies KuiKe Bld., No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing, P.R. China, 100085 Email: Xiangsong.Cui@huawei.com Cui Expires April 26, 2010 [Page 21]