Netext Working Group X. Cui (Ed.) Internet Draft Huawei Intended status: Informational A. Makela Expires: June 2010 TKK December 14, 2009 Reflector Extension for Route Optimization Agent draft-cui-netext-route-optimization-agent-ext-02.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 June 14 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 June 14, 2010 [Page 1] Internet-Draft Route Optimization Agent Extension December 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 in Route Optimization mode. 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 mode 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 accomplish 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 June 14, 2010 [Page 2] Internet-Draft Route Optimization Agent Extension December 2009 Table of Contents 1. Introduction...................................................4 2. Terminology....................................................4 3. Scenario Analysis and Use Case.................................5 3.1. Route Optimization Requirement from Other SDO.............5 3.2. Issues if the CN can't support Route Optimization.........6 3.3. Existing analysis and solutions...........................8 3.4. Use Case for Route Optimization Agent Extension...........9 3.5. Motivation of Route Optimization Agent...................13 3.6. Requirements on Route Optimization Agent.................15 4. Solution and Operation Consideration..........................16 4.1. Route Optimization Agent Operation.......................16 4.1.1. Incoming Flow Transmission..........................16 4.1.2. Outgoing Flow Transmission..........................18 4.1.3. Conceptual Data Structures..........................19 4.1.4. Configuration Variables.............................19 4.2. LMA Operation............................................20 4.3. MAG Operation............................................20 4.3.1. Inter-MAG Handover with Agent Takeover..............20 4.3.2. Inter-MAG Handover with Agent Revocation............21 5. Security Considerations.......................................21 6. IANA Considerations...........................................21 7. Acknowledgments...............................................22 8. References....................................................22 8.1. Normative References.....................................22 8.2. Informative References...................................22 APPENDIX A: Future Extension and Use Case........................24 A.1. Agent Extension for Mobile Router........................24 A.2. Extension for IPv4/MIP4..................................25 Author's Addresses...............................................25 Cui Expires June 14, 2010 [Page 3] Internet-Draft Route Optimization Agent Extension December 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 still can't set up Route Optimization to this CN, as [RFC3775] specifies "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 accomplish 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]. This document also provides the following context-specific explanation to the following terms used in this document. Cui Expires June 14, 2010 [Page 4] Internet-Draft Route Optimization Agent Extension December 2009 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. The binding source consists of home address of the source node and the home address of the source node and the Agent Binding Cache is cached in the mid-box (i.e. the agent entity) between the source/destination node pair. 3. Scenario Analysis and Use Case 3.1. Route Optimization Requirement from Other SDO 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]." Cui Expires June 14, 2010 [Page 5] Internet-Draft Route Optimization Agent Extension December 2009 3.2. 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 cannot 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. Take the Route Optimization procedure as the example. If the mobile node is setting up Route Optimization with a basic IP node which is attached to the MAG, the message flow is as below: Cui Expires June 14, 2010 [Page 6] Internet-Draft Route Optimization Agent Extension December 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 | | | | (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. (f) MN2 can't recognize the Home Test Init message and replies an ICMP error message to MN1. Cui Expires June 14, 2010 [Page 7] Internet-Draft Route Optimization Agent Extension December 2009 (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.3. Existing analysis and solutions [RFC4889] focuses on NEMO Route Optimization and provides many valuable analyses on this topic. The conclusion section (section 6) shows some consideration aspects on Route Optimization: the benefits a Route Optimization solution is expected to bring, the different scenarios in which a Route Optimization solution applies, issues a Route Optimization solution might face. [RFC4889] also introduces some scenarios in section 5. When RO is applied between Mobile Router and Correspondent Node, as [RFC4889] states, "However, new functionality is likely to be required on the Correspondent Node." [HMIP-Based-Route-Optimization] introduces some scenarios and solutions about Route Optimization, too. For example, Figure 11 in section 3 illustrates Proxy CN case. In this case a MR takes the proxy role of the correspondent node. But the solution in this scenario is not introduced in detail and the solution also requires the correspondent node (here is a MN but not a LFN) to support Routing Header and Home Address Option. This document wants to introduce a new extension solution for the similar scenario. In this solution there is no requirement or new functionality on the correspondent node and the agent can take all the mobility management function for the correspondent node. Cui Expires June 14, 2010 [Page 8] Internet-Draft Route Optimization Agent Extension December 2009 3.4. Use Case for Route Optimization Agent Extension The use case is related to 3GPP2 network. A mobile node in 3GPP2 network can attempt to set up Route Optimization with a correspondent node, but as mentioned above, Route Optimization may fail due to e.g. CN being in 3GPP network or in PMIP domain. As an approach to these issues, this document introduces Route Optimization Agent functionality. The functionality allows a separate network entity to manage Route Optimization-related signaling on behalf of the mobile node that is attached to the network. Benefits include bringing higher QoE/QoS to both the initiating and responding user and reducing network resource costs. The applicable scenarios include PMIP domain and fixed IPv6 nodes that only support basic IPv6 protocol. Possible caveats include performance issues appearing on the node running Route Optimization Agent. However, similar packets interception functionality is already present in e.g. Home Agent, so performance loss should be acceptable for any Router-like entities. The use case, taking the MAG as the Agent entity, is as below: Cui Expires June 14, 2010 [Page 9] Internet-Draft Route Optimization Agent Extension December 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 for Route Optimization in MAG. 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. Cui Expires June 14, 2010 [Page 10] Internet-Draft Route Optimization Agent Extension December 2009 (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 between MN1 and MN2, with some additional operation (specified in section 4.1) implemented. Cui Expires June 14, 2010 [Page 11] Internet-Draft Route Optimization Agent Extension December 2009 The Route Optimization Agent function may also be implemented in LMA, as below: MN1 HA LMA MAG MN2 | | | | | ===== MN1 attached to HA and MN2 attached to MAG ===== ===== LMA runs PMIP protocol for MN2 (basic IP) ===== ===== MN1 has no idea about the capability of MN2 ===== | | | | | | HoTI | | | | |---------->| HoTI | | | | |------------>| | | | CoTI | | | |------------------------>| | | | | | | | | | HoT | | | | HoT |<------------| | | |<----------| | | | | CoT | | | |<------------------------| | | | | | | | BU | | | |------------------------>| | | | Binding Ack | | | |<------------------------| | | | | | | | Traffic data | | | |------------------------>| Traffic | | | |---------->| Traffic | | | |---------->| | | | Traffic | | | Traffic |<----------| | Traffic data |<----------| | |<------------------------| | | | | | | Figure 3 Agent extension for Route Optimization in LMA. The Route Optimization Agent function may also be implemented in Access Router, as below: Cui Expires June 14, 2010 [Page 12] Internet-Draft Route Optimization Agent Extension December 2009 MN1 HA AR IP Node2(basic IP) | | | | ===== MN1 attached to HA and IP Node2 attached to AR ===== ==== MN1 has no idea about the capability of IP Node2 ==== | | | | | HoTI | | | |------------>| HoTI | | | |---------------->| | | CoTI | | |------------------------------>| | | | | | | | HoT | | | HoT |<----------------| | |<------------| | | | CoT | | |<------------------------------| | | | | | BU | | |------------------------------>| | | Binding Ack | | |<------------------------------| | | | | | Traffic data | | |------------------------------>| Traffic | | |-------------->| | | | | | Traffic | | Traffic data |<--------------| |<------------------------------| | | | | Figure 4 Agent extension for Route Optimization in AR. 3.5. Motivation of Route Optimization Agent 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: Cui Expires June 14, 2010 [Page 13] Internet-Draft Route Optimization Agent Extension December 2009 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 5 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 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. Cui Expires June 14, 2010 [Page 14] Internet-Draft Route Optimization Agent Extension December 2009 3.6. Requirements on Route Optimization Agent 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 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 Route Optimization Agent MAY check whether an Agent Binding Cache entry exists and if yes, the care-of address in the source address of the packet is replaced by the home address of the remote mobile node and the Home Address Option contained in the packet is removed. Cui Expires June 14, 2010 [Page 15] Internet-Draft Route Optimization Agent Extension December 2009 4. Solution and Operation Consideration 4.1. Route Optimization Agent Operation The Route Optimization Agent is a function that typically runs on LMA, MAG, Mobile Router or even the fixed Access Router for wired IP node. The Route Optimization Agent transfers all the IP packets from or destined to the simple IP 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 IP node. o Creating, maintaining and deleting the Agent Binding Cache for the IP 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 IP node. o Source Address replacement and Home Address Option elimination for the incoming traffic destined to the attached IP 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 of [RFC5213] for the role of correspondent node. The introduced Route Optimization Agent function in the reflector may be independent of the active Proxy Mobile IP function that specified in [RFC5213]. 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 to parse the IP header to check the packet type as soon as it receives the packet from the remote IP node. Cui Expires June 14, 2010 [Page 16] Internet-Draft Route Optimization Agent Extension December 2009 If the IP packet received from other IP node doesn't contain mobility header, i.e. the IP packet is not mobility-related signaling, the Route Optimization Agent entity needs to additionally examine the Destination Option extension header of the packet. If the Home Address Option (Option type = 201) is contained in the packet, the Route Optimization Agent entity needs to examine its Agent Binding Cache for an entry for the 3-Tuple address set (i.e. the home address, the source address and the destination address of the IP packet). If a corresponding Agent Binding Cache entry exists, it means Route Optimization has been established between the IP node pair. In this situation the Route Optimization Agent MAY replace the care-of address in the source address of the packet with the home address of the remote mobile node, remove the Home Address Option and forward the modified packet to the attached IP node. If no mobility header and no Home Address Option are contained in the packet, the Route Optimization Agent SHOULD forward the packet to the attached IP node without any modification. If no mobility header is contained in the packet, and the Home Address Option is contained, but no Agent Binding Cache entry exists, the Route Optimization Agent MUST drop this packet. (Note: This case follows the rule of [RFC3775]). If the IP packet received from other IP node contains the mobility header, the Route Optimization Agent needs to further check the MH type field in the mobility header. The Route Optimization Agent MAY execute the expansion solution for these mobility-related packets. If 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]. If 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]. If 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 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. Cui Expires June 14, 2010 [Page 17] Internet-Draft Route Optimization Agent Extension December 2009 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 to 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 MUST forward the packet to the remote IP node without any modification. 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. 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 is transferred as described in other specification. 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]. 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 attached IP node this situation. Cui Expires June 14, 2010 [Page 18] Internet-Draft Route Optimization Agent Extension December 2009 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 IP node the Route Optimization Agent creates or updates the Agent Binding Cache entry and includes the destination address of the Binding Update 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 (This document defines) or a normal Binding Cache entry ([RFC3775] defines). o The Agent Binding Cache entry contains a destination IP address, which is the true destination of the intercepted Binding Update message. Each Agent Binding Cache entry is mapped with a 3-Tuple address set (i.e. HoA of MN, CoA of MN and IP address of CN). The incoming packet lookup key is the source address and the destination address of the IP packet and the Home Address Option contained in the packet. For the incoming packet, if the HoA of MN, CoA of MN and CN address all matches, then the Agent Binding Cache entry is found. The outgoing packet lookup key is the destination address and the source address of the IP packet. 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. 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. Cui Expires June 14, 2010 [Page 19] Internet-Draft Route Optimization Agent Extension December 2009 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. If the Route Optimization Agent function is implemented in the MAG and inter-MAG handover happens simultaneously, the MAG SHOULD proceed as specified in section 4.3.1 and 4.3.2 of this document. 4.3.1. Inter-MAG Handover with Agent Takeover If the Agent function can be implemented in the new MAG (The previous MAG can get this information during the message exchange between pMAG and nMAG), the previous MAG SHOULD try to transfer the Agent Binding Cache entry to the new MAG as part of the context. The 3-Tuple address set (i.e. HoA of MN, CoA of MN and IP address of CN) MUST be transferred to the new MAG. Note some Node Keys in the previous MAG are not shared with other entities so the new MAG gets no binding management keys from the previous MAG. In this situation, the new MAG SHOULD send the Binding Refresh Request message to the remote mobile IP node as specified in [RFC3775] to refresh the agent binding. When the remote mobile IP node restarts the Return Routability and Route Cui Expires June 14, 2010 [Page 20] Internet-Draft Route Optimization Agent Extension December 2009 Optimization as specified in [RFC3775], the new MAG will take over the Agent role for the attached IP node. 4.3.2. Inter-MAG Handover with Agent Revocation If the new MAG does not support Route Optimization Agent function, the function is disabled or the 3-Tuple address set (i.e. HoA of MN, CoA of MN and IP address of CN) can't be transferred to the new MAG (The previous MAG can get this information during the message exchange between pMAG and nMAG), the previous MAG SHOULD send the Binding Revocation Indication message to the remote mobile node as specified in [CN-Binding-Revocation] to revoke the agent binding. When the remote mobile IP node releases the correspondent node binding as specified in [CN-Binding-Revocation], the session between the remote mobile IP node and the attached IP node fallbacks to the Bidirectional Tunneling mode. 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 Route Optimization Agent still follows the principle that providing network-based mobility management to the IP node that is attached to its access link. So this extension brings no new security issue to mobility management. But this extension requires the Route Optimization Agent to implement packet inspection on the packets destined to the IP node, which would impact the performance of the Agent entity 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. Cui Expires June 14, 2010 [Page 21] Internet-Draft Route Optimization Agent Extension December 2009 7. Acknowledgments The author would like to specially thank Hidetoshi Yokota, Sri Gundavelli, Qin Wu, Yungui Wang and Carlos J. Bernardos 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. [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007. [RFC5213] Sri, G., Kent, L., Vijay, D. Kuntal, C. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [CN-Binding-Revocation] Xiangsong, C. and A. Makela, "Binding Revocation from correspondent node in Route Optimization Mode", draft-cui-mext-cn-binding-revocation-00, (work in progress), November 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 June 14, 2010 [Page 22] Internet-Draft Route Optimization Agent Extension December 2009 [HMIP-Based-Route-Optimization] Hiroyuki, O., Keisuke, S. and Y. Takagi, "HMIP based Route optimization method in a mobile network", draft-ohnishi-nemo-ro-hmip-00 (expired), October, 2003. Cui Expires June 14, 2010 [Page 23] Internet-Draft Route Optimization Agent Extension December 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 6 Agent extension in Route Optimization. Cui Expires June 14, 2010 [Page 24] Internet-Draft Route Optimization Agent Extension December 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 Antti Makela Helsinki University of Technology P.O. Box 3000 FIN-02105 TKK FINLAND Phone: +358 9 451 5590 Email: antti.makela@tkk.fi Cui Expires June 14, 2010 [Page 25]