Network Working Group Andy(Zhigang). Huang Internet-Draft Huawei Technologies Expires: April 14, 2007 October 11, 2006 Route Optimization for Mobile Nodes in Mobile Network draft-huang-nemo-mn-ro-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 14, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies a mechanism for enabling mobile nodes in IPv6 mobile network to perform route optimization. The route optimization is possible because mobile router provides a care-of address for mobile nodes in mobile network which we call Virtual Care-of Address (VCoA). The VCoA uses the network prefix of the access network. Mobile nodes register VCoA as its own care-of address with home agent and correspondent nodes. With little modification to mobile nodes and correspondent nodes, mobile router deals with the packets forwarding between them. Huang Expires April 14, 2007 [Page 1] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Brief Description of Solution . . . . . . . . . . . . . . . . 4 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Messages between VMN and MR . . . . . . . . . . . . . . . 6 4.1.1. Route Optimization Request Message . . . . . . . . . . 6 4.1.2. Route Optimization Acknowledgement Message . . . . . . 7 4.1.3. Binding Refresh Request Message . . . . . . . . . . . 7 4.2. CoTI and CoT Message Format Changes . . . . . . . . . . . 7 5. Solution Details . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 8 5.2. Generating VCoA . . . . . . . . . . . . . . . . . . . . . 8 5.3. Registration Process . . . . . . . . . . . . . . . . . . . 9 5.4. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 10 5.4.1. Data Packet . . . . . . . . . . . . . . . . . . . . . 10 5.4.2. Registration Packet . . . . . . . . . . . . . . . . . 11 5.5. Route Optimization Process . . . . . . . . . . . . . . . . 11 5.6. Impact on Return Routability Process . . . . . . . . . . . 12 5.7. Moving out of Mobile Network . . . . . . . . . . . . . . . 13 5.8. MR Handover . . . . . . . . . . . . . . . . . . . . . . . 13 6. Home Agent and Correspondent Node Operation . . . . . . . . . 14 7. About Nested Mobile Network . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Huang Expires April 14, 2007 [Page 2] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 1. Introduction Mobile IPv6[RFC3775] allows a mobile node to perform route optimization with its correspondent node in order to avoid tunneling with its home agent, however, the "optimized" route is no longer optimized when the mobile node is attached to a mobile network. The route between mobile node and correspondent node has to pass through the bi-directional tunnel between mobile router and its home agent. The problem is well defined in section 2.4 of 'Network Mobility Route Optimization Problem Statement'[draft-ietf-nemo-ro-problem-statement-03]. NEMO Basic Support Protocol[RFC3963] is to preserve session continuity using the bi-directional tunnel between MR and its HA. The purpose of this document is to enable MNs behind the MR to perform Mobile IPv6 Route Optimization. This can reduce the overhead on MR because MR considers the packets of Local Fixed Nodes in the bidirectional tunnel between MR and HA. This document provides a mechanism to enable MN to get and register a topologically correct care-of address (VCoA) with its HA and CN. By use of VCoA, MN can get route optimization. 2. Terminology 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]. This document uses the terminology and abbreviation conformed to 'Mobility Related Terminology' [RFC3753] and 'Network Mobility Support Terminology'[draft-ietf-nemo-terminology-04] on the assumption that the reader is familiar with Mobile IPv6 and NEMO terminology. In addition, following terms are used: Virtual Care-of Address (VCoA) It is one of the addresses that mobile router generates on the egress interface. Mobile router reserves it for all VMNs which are attached to mobile network. VMN will regard VCoA as its own care-of address to register with HA and CN. Route Optimization Cache Mobile router stores the binding relationships between VMN's HoA and VMN_CoA in the Route Optimization Cache. It is mainly used to forward the packets between mobile nodes and correspondent nodes. Huang Expires April 14, 2007 [Page 3] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 Route Optimization Request (RO Request) VMN need send Route Optimization Request message to mobile router to get VCoA to register with its HA and CN, the message format is same as Binding Update message defined in RFC3775. Route Optimization Acknowledgement (RO Ack) Mobile router sends Route Optimization Acknowledgement message to VMN to confirm the Route Optimization Request message. Binding Refresh Request Mobile router sends Binding Refresh Request message to request VMN to update its Route Optimization information. Also it can be used to inform VMN of a new VCoA when handover has taken place on MR. 3. Brief Description of Solution The case that mobile network node and correspondent node are located in the same mobile network is not discussed in this document. And the communications between two mobile network nodes within a nested mobile network is also out of the scope. This case is depicted in section 3.2 of 'Network Mobility Route Optimization Solution Space Analysis' [draft-ietf-nemo-ro-space-analysis-03]. Huang Expires April 14, 2007 [Page 4] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 +--------+ +--------+ | MR_HA | | VMN_HA | +---+----+ +---+----+ | | +-----+---------------+---+ +--------+ | Internet |----| CN | +------------+------------+ +--------+ | +---+---+ | AR | +---+---+ | MR_CoA/VCoA +---+---+ | MR | +---+---+ | ---------+-------+-----------+------- | VMN_CoA | +----+---+ +----+---+ | VMN | | LFN | +--------+ +--------+ Figure 1 Visited mobile node in mobile network The scenario discussed in this document is illustrated in Figure 1. To realize more available route optimization, VMN need get a topologically correct CoA and register this CoA with HA and CN. When MR is attached to AR on the foreign link, MR gets its CoA (MR_CoA) through IPv6 stateless address autoconfiguration[RFC2461] [RFC2462] or Dynamic Host Configuration Protocol [RFC3315]. VMN MAY register MR_CoA with its HA and CN to perform route optimization. Then CN can send the packets to MN using MR_CoA as Destination Address in IPv6 header so that the packets will be routed to MR directly, not passing through the bi-directional tunnel between MR and its HA. Since MR_CoA has been registered with its HA by mobile router and used as the bi-directional tunnel endpoint, to make mobile router can easily differentiate between the packets from CN directly and the packets through the bi-directional tunnel between MR and its HA (mobile router has to process these two kinds of packets in a different way), it's better that MR can get another address for VMNs which want to perform real route optimization. Let us call this address VCoA (Virtual Care-of Address). How MR gets VCoA is detailed in section 5.2. When VMN moves to mobile network, first it will generate the care-of address (let's call it VMN_CoA) and register it with its HA. And it will register VMN_CoA with CN on the condition that CN supports route Huang Expires April 14, 2007 [Page 5] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 optimization defined in RFC3775. However, it is not the most available route optimization because the packets between VMN and CN have to go through bi-directional tunnel between MR and its HA. If VMN wants to perform a more available route optimization, it need register a topologically correct care-of address with its HA and CN. Here, VCoA is a good choice. After VMN realize that it has moved into mobile network, how VMN get to know is out of the scope, it sends a request with VMN_CoA and VMN's HoA to MR to get the VCoA, and then registers VCoA with HA and CN through 'multiple care-of addresses registration' [draft-ietf-monami6-multiplecoa-00] after mobile router responses with VCoA. Mobile router will store the binding relationships between VMN's HoA and VMN_CoA in the Route Optimization Cache and forward the packets from CN to VMN according to the binding relationships. The data packets from CN to VMN will be routed to MR because VCoA actually belongs to MR though VMN registers VCoA with its HA and CN. MR can easily and clearly know that the packets are destined for VMNs according to Destination Address (VCoA) in the IPv6 header. Then mobile router will extract HoA from type 2 routing header and look up the corresponding binding relationship in the Route Optimization Cache to get VMN_CoA, and finally encapsulate these packets to corresponding VMN. The data packets from VMN to CN are encapsulated by VMN, after mobile router receives the packets, it will de- encapsulate the packets and send the inner packet to CN directly. 4. Message Formats This paragraph introduces some messages which are necessary for the solution. These messages can reuse the message format defined in RFC3775. 4.1. Messages between VMN and MR 4.1.1. Route Optimization Request Message The Route Optimization Request message is used by mobile nodes in mobile network to request VCoA from mobile router, at the same time mobile nodes register binding relationship between care-of address and home address. The message has the same format as Binding Update defined in RFC3775. Just like RFC3775, Home Address option in Destination Option extension header MUST be included in the message to provide MR of VMN's HoA. Huang Expires April 14, 2007 [Page 6] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 4.1.2. Route Optimization Acknowledgement Message The Route Optimization Acknowledgement message is used by mobile router to response mobile nodes in mobile network with VCoA. It has the same format as Binding Acknowledgement message defined in RFC3775. Alternate Care-of Address option which carries VCoA MUST be included in the Mobility options. 4.1.3. Binding Refresh Request Message The Binding Refresh Request message is used by mobile router to request a VMN to update its binding information. Also it is also used to inform VMN of new VCoA when handover has taken place on MR. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|H| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mobile router binding (M) The Mobile router binding (M) bit is set by mobile router to indicate that the message is from MR. Handover of mobile route (H) The Handover of mobile route (H) bit is set by mobile router to indicate that handover has taken place on MR. When H bit is set, M bit MUST be set. Alternate Care-of Address option which can be used to carry new VCoA MUST be included in the Mobility options. 4.2. CoTI and CoT Message Format Changes HoTI/HoT and CoTI/CoT messages are same as RFC3775. However, Home Address option in Destination Option extension header SHOULD be added to CoTI message and type 2 routing header SHOULD be added to CoT messages. The reason is described in detail in Section 5.6. 5. Solution Details Huang Expires April 14, 2007 [Page 7] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 5.1. Conceptual Data Structures Mobile router SHOULD maintain a Route Optimization Cache for each VMN in mobile network which has applied for route optimization. Route Optimization Cache has two functions: when mobile router forwards the packets from CN, it will look up the Route Optimization Cache to encapsulate the packets to VMN; on the other hand, when mobile router has a handover from one access network to another, it will inform VMNs which are still in Route Optimization Cache of the new VCoA. Route Optimization Cache is similar to Binding Cache defined in RFC3775. Each Route Optimization Cache entry conceptually contains the following fields: The home address of VMN: this field is used as the key for searching the Route Optimization Cache when mobile router forwarding packets to VMN. The care-of address of VMN: this field is used as destination address of a packet forwarded by mobile router to VMN. A lifetime value: indicating the remaining lifetime for this Route Optimization Cache entry. The lifetime value is initialized from the Lifetime field in the Route Optimization Request message that created or last modified this Route Optimization Cache entry. The maximum value of the Sequence Number field is same as RFC3775. 5.2. Generating VCoA MR can get VCoA through stateless address autoconfiguration or stateful address autoconfiguration. In the stateless address autoconfiguration, mobile router combines the prefix in the RA from access router and link interface identifier to generate IPv6 address. On the MR egress interface, generally there is only one link interface identifier which has been used to generate MR_CoA. Here, we need another link interface identifier to generate VCoA. This link interface identifier MAY come from other interfaces of mobile router or be created in other ways. In the DHCPv6 method, mobile router can request two addresses on the egress interface from DHCP server at the same time. Mobile router will select one of them as MR_CoA and the other as VCoA by itself. Of course, as RFC2462 points out, mobile router can generate these two addresses through stateless address autoconfiguration and stateful address autoconfiguration at the same time. Huang Expires April 14, 2007 [Page 8] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 5.3. Registration Process The whole registration process is elaborated as follows. When MR leaves home network and attaches to foreign link, MR generates two addresses (MR_CoA and VCoA) on the egress interface. MR_CoA is used to register with its HA by MR according to RFC3963. VCoA is reserved for VMNs which hope to initiate more available route optimization. When VMN moves into mobile network, VMN first generates VMN_CoA and registers it with HA and CN according to RFC3775. Return routability process will be initiated by VMN before registering VMN_CoA with CN. To initiate more available route optimization between VMN and CN, VMN MUST get VCoA to register with HA and CN. VMN first sends the Route Optimization Request message to MR, asking for permission from MR. It's possible that MR could not provide all VMNs with the route optimization function due to limited resource. MR MUST ensure the basic service before it decides to support route optimization request from VMN. However, the criterion whether MR will allow the route optimization for VMN or not is out of the scope. If MR allows VMN to optimize the traffic path, MR will send Route Optimization Acknowledgement message to confirm the request and inform VMN of VCoA. At the same time MR need establish the binding relationship between VMN's HoA and VMN_CoA and store it in the Route Optimization Cache. To prevent malicious VMN from attacking other VMNs by spoofing MR into establishing wrong binding relationship, MR MUST ensure that HoA and VMN_CoA really belong to VMN. More details can be found in section 5.5. After getting VCoA from MR, VMN regards it as its own another care-of address and considers itself a multi-homing node because it has two care-of addresses (VMN_CoA and VCoA). VMN generates a BID for each care-of address and records it into the binding update list, then registers them by sending a Binding Update with a Binding Unique Identifier sub-option according to 'Multiple Care-of Addresses Registration'. This makes HA and CN to support multiple bindings bound to a single home address. The priority of Binding Cache Entry which is used to select a binding is notified by the VMN by means of a Binding Unique Identifier sub-option. VCoA SHOULD have higher priority than VMN_CoA so that VCoA can be selected in preference to VMN_CoA and the packets between CN and VMN will not pass through the bi-directional tunnel between MR and its HA. Huang Expires April 14, 2007 [Page 9] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 5.4. Packet Forwarding Provided that the same VCoA is shared as preference choice by all VMNs in mobile network, all packets from CN or HA to VMNs will normally sent to MR. MR need distribute these packets to real destination according to HoA in type 2 routing header. However, HoA is not the real location but an permanent identifier of VMN. It is VMN_CoA that can be used to directly route the packet to VMN in the mobile network, especially when there is intermeidary router between mobile router and VMN. MR need foward the packets according to the binding relationships in the Route Optimization Cache. 5.4.1. Data Packet After successful registration VCoA with higher priority with CN, the Binding Cache Entry of VCoA and VMN's HoA will be choosed by CN and the packets between CN and VMN will route along CN-AR-MR-VMN path. The data packet format from CN to VMN is compatible with RFC3775. The Source Address in the packet's IPv6 header is set to CN address and the Destination Address in the packet's IPv6 header is set to VCoA. Type 2 routing header containing HoA of VMN is included in the original packet. When MR receives the packets it will extract HoA from type 2 routing header and look up the corresponding binding relationship to get VMN_CoA. If the corresponding binding relationship does not exist, MR will discard the packets sliently. If the corresponding binding relationship exists, MR will encapsulate the packets and send them to VMN. The Source Address in the outer IPv6 header is set to MR address and the Destination Address in the packet's outer IPv6 header is set to VMN_CoA. The packet format sent from MR is illustrated as follows. IPv6 header (source = MR address, destination = VMN_CoA) IPv6 header (source = CN address, destination = VCoA) Routing header (type 2) VMN's HoA Any protocol Accordingly, the packets from VMN to CN will be encapsulated by VMN. The inner packet format is compatible with RFC3775 so that CN can recognize it without any difficulty. The Source Address in the inner IPv6 header is set to VCoA and the Destination Address in the inner IPv6 header is set to CN address. Home Address option containing HoA is included in the inner packet. The outer IPv6 header is used to route the packet to MR. The Source Address in the outer IPv6 header is set to VMN_CoA and the Destination Address in the outer IPv6 Huang Expires April 14, 2007 [Page 10] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 header is set to MR address. When MR receives the packets it will the de-capsulate the packets and send inner IPv6 packets to CN. The packet format sent from VMN is illustrated as follows. IPv6 header (source = VMN_CoA, destination = MR address) IPv6 header (source = VCoA, destination = CN address) Destination Options header Home Address option (VMN's HoA) Any protocol Data packets between HA and VMN are protected by ESP tunnel mode according to [RFC3776], so it's impossible for MR to get HoA from inner packet IPv6 header because the inner packet is encrypted. However, in route optimization mode, data packets between HA and VMN is unnecessary. 5.4.2. Registration Packet Registration packets between VMN and HA or CN include Binding Update message, Binding Acknowledgement message, Binding Error message and Binding Update Refresh message. HoTI/HoT and CoTI/CoT message exchanges will be separately discussed in the following section 5.6. Registration packets between CN and VMN are similar to the data packets between them. HoA contained in type 2 routing header and Home Address option in Destination Option extension header is used as identifier of VMN from the perspective of upper layer protocol. Registration packets between HA and VMN are protected by ESP transport mode according to RFC3776, especially, type 2 routing header and Destination Option extension header appear before ESP according to [RFC4303]. That is, HoA in these headers will not be encrypted by ESP, MR can verify and forward the registration packets as it deals with data traffic between CN and VMN. 5.5. Route Optimization Process Before VMN initiates route optimization request to register HoA and VMN_CoA with MR, the same return routability process as RFC3775 SHOULD be used to provide the security. To prevent malicious VMN from attacking other VMNs by tricking MR into establishing the wrong binding relationship, MR MUST be able to ensure that HoA and VMN_CoA really belongs to VMN which sends the Route Optimization Request. Referring to RFC3775, it seems as if MR acts as CN's role which VMN means to register with. Figure 2 depicts the message exchange process. VMN first sends HoTI and CoTI messages to MR and receives Huang Expires April 14, 2007 [Page 11] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 HoT and CoT messages from MR respectively. VMN gets the home keygen token from HoT message and the care-of keygen token from CoT message. Based on these two tokens VMN will compute binding management key Kbm which is used to generate the Binding Authorization Data mobility option in Route Optimization Request message. VMN VMN's HA MR | | | Home Test Init (HoTI) | | |------------------------->|------------------------->| | | | | Care-of Test Init (CoTI) | |---------------------------------------------------->| | | | | Home Test (HoT) | |<-------------------------|<-------------------------| | | | | Care-of Test (CoT) | |<----------------------------------------------------| | | Figure 2 Return routability process between VMN and MR Route Optimization Request/Acknowledgement messages are similar to Binding Update/ Acknowledgement defined in RFC3775. The message exchange is illustrated in figure 3. VMN sends Route Optimization Request message to MR, MR MUST re-generate the home keygen token and the care-of keygen token from the information contained in the packet. It then generates the binding management key Kbm and uses it to verify the authenticator field in the Route Optimization Request. Then MR sends Route Optimization Acknowledgement message to confirm the request and inform VMN of VCoA. VMN MR | | | Route Optimization Request | |----------------------------->| | | | Route Optimization Acknowledg|ement |<-----------------------------| | | Figure 3 Route Optimization Request/Acknowledgement 5.6. Impact on Return Routability Process According to RFC3775, return routability process has to be performed by VMN to register CoA with CN. As described in section 5.3, after Huang Expires April 14, 2007 [Page 12] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 VMN moves into mobile network, it will first register VMN_CoA with CN to realize route optimization if CN can also support Route Optimization mode. During the step, VMN has to perform HoTI/HoT and CoTI/CoT message exchanges to get the home keygen token and the care-of keygen token. When VMN means to register the second CoA (VCoA) with CN, HoTI/HoT message exchange is unnecessary because the home keygen token is the same. CoTI/CoT message exchange is necessary to get the care-of keygen token. There is some difficulty for mobile router to deal with CoT message because home address does not appear in CoTI/CoT messages. It results in that MR can not forward CoT messages to corresponding VMNs so that VMN will fail to perform CoTI/CoT message exchange. To solve the problem, it hopes that the same Home Address option in Destination Option extension header and type 2 routing header can be added to the CoTI and CoT messages. 5.7. Moving out of Mobile Network When VMN moves out of mobile network and attaches to a new foreign network, it will generate a new care-of address and register it with HA and CN. According to 'multiple Care-of Addresses registration' [draft-ietf-monami6-multiplecoa-00], VMN sends a regular Binding Update which does not contain Binding Unique Identifier, CN or HA MUST overwrite all existing bindings for the mobile node with the received binding. If VMN returns home, it MUST de-register all the bindings by sending a Binding Update with lifetime set to zero. The mobile node MAY NOT put any Binding Unique Identifier sub-option in this packet. Then, the receiver deletes all the bindings from its Binding Cache. 5.8. MR Handover When mobile router moves to another foreign link or returns home, it first generates the new MR_CoA and VCoA and deals with registration or de-registration with its HA according to RFC3963. Then it sends Binding Update Refresh message with M flag and H flag set to 1 to VMNs which still remain in the Route Optimization Cache. The new VCoA MUST be included in Alternate Care-of Address option. If the number of VMN is very large, MR SHOULD send Binding Update Refresh with a little time interval to prevent registration storms between VMN and CN. After VMN receives the Binding Update Refresh message with M flag and H flag set to 1, VMN gets the new VCoA from Alternate Care-of Address option and updates the corresponding Binding Update List entry, replacing the care-of address field with new VCoA. Then it registers Huang Expires April 14, 2007 [Page 13] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 the new VCoA with HA and CN by sending Binding Update with a Binding Unique Identifier sub-option. The BID is copied from a Binding Update List to the Binding Unique Identifier sub-option. It's possible that VMN could not register new VCoA with CN in time. If CN detect the old VCoA binding invalidation by packets loss or ICMP error messages such as ICMP_UNREACHABLE, it can change the binding entry of VMN_CoA for the VMN so as to recover the connection immediately. This mechanism is described in 'multiple Care-of Addresses registration' [draft-ietf-monami6-multiplecoa-00]. 6. Home Agent and Correspondent Node Operation Home agent and correspondent node operation conforms to RFC3775 and 'multiple Care-of Addresses registration'. The only difference is that CN SHOULD send CoT with HoA in type 2 routing Header as a response to CoTI. HoA can be extracted from Home Address option of Destination Option extension header in CoTI message. 7. About Nested Mobile Network Nested NEMO is out of scope of this solution. Note, the solution can work with nested NEMO but the actual routing within the NESTED NEMO is out of scope for now and is a problem of itself. 8. IANA Considerations TBD. 9. Security Considerations Return routability process is described in the section 5.5 to ensure that the correct binding relationship between VMN_CoA and HoA is created in mobile router. Regarding IPSec used to protect packets, some discussion has been described in the section 5.4. Currently, ESP header in tunnel mode is only used to protect the data packets between HA and VMN. However, it's possible to use ESP tunnel mode to protect the packets between CN and MN. If so, MR will not be able to get HoA from the packets to distribute the packets to each VMN. How to deal with it? Huang Expires April 14, 2007 [Page 14] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 10. Acknowledgments The authors would like to thank Carl Williams, Liyun Ou, Xia Qin for their comments. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbour Discovery for IP version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3753] Manner, J., Ed. and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [draft-ietf-monami6-multiplecoa-00] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00 (work in progress), June 2006. [draft-ietf-nemo-terminology-04] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-04 (work in progress), October 2005. Huang Expires April 14, 2007 [Page 15] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 11.2. Informative References [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [draft-ietf-nemo-ro-problem-statement-03] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility Route Optimization Problem Statement", draft-ietf-nemo-ro-problem-statement-03(work in progress), September 2006. [draft-ietf-nemo-ro-space-analysis-03] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network Mobility Route Optimization Solution Space Analysis", draft-ietf-nemo-ro-space-analysis-03 (work in progress), September 2006. Huang Expires April 14, 2007 [Page 16] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 Author's Address Zhigang Huang Huawei Technologies No.91 BaiXia Rd. Nanjing, Jiangsu 210001 China Phone: +86-25-84565415 Email: hpanda@huawei.com Huang Expires April 14, 2007 [Page 17] Internet-Draft draft-huang-nemo-mn-ro-00.txt October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Huang Expires April 14, 2007 [Page 18]