NEMO Working Group H. Ohnishi INTERNET DRAFT K. Sakitani Expires: April 2003 Y. Takagi NTT Corporation Oct 2003 HMIP based Route optimization method in a mobile network Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the nemo@ietf.org mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract In a nested mobile network situation, the packet transfer route between a correspondent node(CN) and a mobile node(MN) may become much longer than in the simple Mobile IP case, because packets can reach endpoints through all of the home agents (HAs) to which the mobile routers (MRs) and the MN belong. The existing route optimization function of Mobile IPv6 cannot solve this problem, because while it can bypass an MN's HA, it cannot skip the MRs' HAs. Furthermore, there is no route optimization method for communication nodes without Mobile IPv6 functionality, which are the so-called local fixed nodes (LFNs) within a mobile network. This draft provides solutions to achieve route optimization in these situations by using HMIP technology and proxy Mobile IP functions. Ohnishi, et al. [Page 1] Internet Draft HMIP based route optimization Oct 2003 1. Introduction Combining the existing Mobile IPv6 (MIPv6) [1] and Network Mobility (NEMO) technology [2] will facilitate mobility for various services. In both technologies, individual MNs or mobile routers (MRs) belong to their own home agents (HAs), which can independently provide mobility to the MNs or MRs. The important point here is that MNs or MRs may move into a mobile network and become connected to another MR there, meaning that they will be hierarchically connected to each other within one mobile network. A typical example is the case of passengers with terminals (MNs or personal area networks (PANs)) getting on a bus or train providing NEMO service via an MR. This is called a "nested mobile network." In this situation, the packet transfer route between a CN and an MN may become much longer than in the simple Mobile IP case, because the packets can reach endpoints through all of the HAs to which the MRs and the MN belong. The existing route optimization function of MIPv6 cannot solve this problem, because while it can skip an MN's HA, it cannot skip the MRs' HAs. Furthermore, there is no route optimization method for communication nodes without MIPv6 functionality, which are the so- called local fixed nodes (LFNs) within a mobile network. This draft thus provides solutions to achieve route optimization in these situations. 2. Protocol Overview 2.1. Route optimization bypassing the HAs of MRs This draft proposes an approach similar to the mechanism specified in HMIPv6 [3] to shortcut the HAs of MRs. In HMIPv6, by registering the location of an MN within a local network (LCoA) once to a mobility anchor point (MAP) and registering the location of the local network (RCoA) to the MNs' HAs (HA_MNs), the HAs can send packets to the MAP and it can relay the packets to the MN. The solution given here applies this hierarchical location management method to a mobile network in order to hierarchically manage the locations of the network and the MNs within it. In this approach, an MN registers its location within the nested mobile network once to a root-MR [6], and it also registers the location of the nested mobile network (the root-MR's subnet address) to its HA_MN. This hierarchical series of registrations enables the HA_MN to shortcut the MRs' HAs (HA_MRs) by sending packets to the root-MR directly, which then relays the packets to the MN. Since the HA_MN manages only the location of the whole nested mobile network, it does not have to manage the movement of the MN within the network. This approach enables the HA_MN to optimize the route to the mobile network regardless of the network's configuration. To describe the proposed method simply, we assume a two-layer nested mobile network like that shown in Figure 1. HMIP has Ohnishi, et al. [Page 2] Internet Draft HMIP based route optimization Oct 2003 two modes, basic and extended. The following explanation applies to basic mode. The method proposed in this draft can also be used with HMIP extended mode. The root-MR (MR1) adds an address (CoA_MR1) in its subnet to its router advertisement (RA) as optional information by using the MAP option field. The creation of this address is described in section 5.1. The MN creates its care-of address (LCoA_MN) based on the RA, which gives the location of the MN in the mobile network. The MN creates the address, RCoA_MN, by using CoA_MR1's prefix and its interface ID. It then registers binding information containing LoA_MN and RCoA_MN with MR1 and binding information containing RCoA_MN and its MN home address (HoA_MN) with the HA_MN. When the HA receives packets for the MN, it can send them directly to MR1 (via RCoA_MN) by using an IPinIP tunnel. MR1 then encapsulates the packets for the MN by using another IPinIP tunnel according to the binding table for HoA_MN and LCoA_MN. The packet transfer route can thus shortcut HA_MR1 in this manner. In this method, duplicate IPinIP tunnels do not arise in the core network but only within the mobile network. The sequence and packet formats are shown in figure 2-4. Ohnishi, et al. [Page 3] Internet Draft HMIP based route optimization Oct 2003 ____ | | | CN | |____| ___|____________________ | | | | | Internet | | | |________________________| __|_ __|_ | | access | | | AR | router | AR | |____| |____| ______|__ foreign __|_____________ home link __|_ link | | | MR1| MR |____| _________|_______ internal __|__ __|__ link | | | | | MN | | MN | |_____| |_____| Figure 1 Mobile node visiting a mobile network Ohnishi, et al. [Page 4] Internet Draft HMIP based route optimization Oct 2003 MN MR HA_MR HA_MN CN | | | | | |RA with MAPopt| | | | |<-------------| | | | | | | | | | BU | | | | |------------->| | | | | | | | | | BA | | | | |<-------------| | | | | | | | | | | BU | | | |--------------------------------------------->| | | | | | | | | BA | | | |<-------------------------------------------- | | | | | | | | | | | | | IPinIPinIP | | | | |------------->| IP in IP| | | | |------------------------------>| | | | | | IP packet | | | | |-------------->| | | | | | | | | | | | | | | | | | | | IP packet | | | | |<--------------| | | IP in IP| | | | |<------------------------------| | | IPinIPinIP | | | | |<-------------| | | | | | | | | | | | | | Figure 2 Sequence of packet transmission Ohnishi, et al. [Page 5] Internet Draft HMIP based route optimization Oct 2003 From MN to MR +---------------------------+ |src=LCoA_MN | BU to HA_MN | |dst=MR | CoA=RCoA_MN | +---------------------------+ From MR to HA_MN +-------------+ | BU to HA_MN | | CoA=RCoA_MN | +-------------+ From HA_MN to MR +-------------+ | BA to MN | | | +-------------+ From MR to MN +---------------------------+ |src=MR | BA to MN | |dst=LCoA_MN | | +---------------------------+ Figure 3 MIP message (BU/BA between MN and HA_MN) packet formats Ohnishi, et al. [Page 6] Internet Draft HMIP based route optimization Oct 2003 From MN to MR +-------------------------+-----------+ |src=LCoA_MN |src=RCoA_MN| IP packet | |dst=MR |dst=HA_MN | | +-------------------------+-----------+ From MR to HA_MN +-------------------------+ |src=RCoA_MN | IP packet | |dst=HA_MN | | +-------------------------+ From HA_MN to CN +------------+ | IP packet | | | +------------+ From CN to HA_MN +------------+ | IP packet | | | +------------+ From HA_MN to MR +-------------------------+ |src=HA_MN | IP packet | |dst=RCoA_MN | | +-------------------------+ From MR to MN +-------------------------+-----------+ |src=MR |src=HA_MN | IP packet | |dst=LCoA_MN |dst=RCoA_MN| | +-------------------------+-----------+ Figure 4 Data packet formats between MN and CN When there are more than two MRs above the MN (i.e., a hierarchy of 3 or more layers), all the sub-MRs relay the address of MR1 by using the MAP option field included in the RA message. The MN registers binding information containing RCoA_MN and LCoA_MN with MR1, which can then send packets to the MN via an IPinIP tunnel. Thus, this method can be applied to a nested multi-layer mobile network environment containing any number of MRs and an MN. By applying HMIPv6-based mechanisms and using the root-MR to provide a MAP function, we have ensured that the proposed method does not require any modification to HAs, CNs, or MNs. The sequence is shown in figure Ohnishi, et al. [Page 7] Internet Draft HMIP based route optimization Oct 2003 5. MN MR2 MR1 HA_MR1 HA_MR2 HA_MN CN | | | | | | | | | RA | | | | | | |<----------| | | | | | | | | | | | | | BU | | | | | | |---------->| | | | | | | BA | | | | | | |<----------| | | | | | | | BU | | | | | |------------------------------------>| | | | | | BA | | | | | RA |<----------------------------------- | | | |<-----------| | | | | | | | | | | | | | BU | | | | | | |----------------------->| | | | | | | | | | | | | BA | | | | | | |<-----------------------| | | | | | | | BU | | | | |------------------------------------------------------------->| | | | | | | | | | | | BA | | | | |<-------------------------------------------------------------| | | | | | | | | | | | | | | | | IP/IP | | | | | | |----------->|IP/IP/IP | | | | | | |---------->| | IP/IP | | | | | |------------------------------------>| | | | | | | | IP | | | | | | |------------>| | | | | | | IP | | | | | IP/IP | |<------------| | | |<------------------------------------| | | |IP/IP/IP | | | | | | IP/IP |<----------| | | | | |<-----------| | | | | | | | | | | | | Figure 5 Sequence of packet transmission Ohnishi, et al. [Page 8] Internet Draft HMIP based route optimization Oct 2003 2.2. Route optimization shortcutting the HA of the MN If the MN can execute the standard MIPv6 route optimization function by sending a binding update message with RCoA_MN and HoA_MN to a CN after completing the process described in Section 2.1, the CN can send packets directly to the mobile network (via RCoA_MN) without using an IPinIP tunnel. MR1 then relays the packets to the MN in the same manner described previously. In this case, the CN and MN can communicate without utilizing a route through an HA. 2.3. Combination of HMIPv6 with NEMO In an actual public network service environment, users and vehicles usually move around wide areas and pass through multiple local networks. In this case, HMIPv6 is effective, since it can reduce the handover times and location management burdens of the HAs, especially for vehicles with mobile networks. When HMIPv6 is used with NEMO technology, the proposed route optimization method described in Section 2.1 becomes more effective, because the MAP can play the role of the root-MR (MR1). Our proposed method combining HMIPv6 and NEMO is illustrated in Figure 6. Ohnishi, et al. [Page 9] Internet Draft HMIP based route optimization Oct 2003 +-------+ | HA | +-------+ | | +----+ | | CN | | +----+ +-----+ | | | | +---+ | | +-------+ | MAP | RCoA +-------+ _______________|_______ __|_ __|_ | | access | | | AR | router | AR | |____| |____| ______|__ foreign __|_____________ home link __|_ link | | | MR1| MR |____| _________|_______ internal __|__ __|__ link | | | | | MN | | MN | |_____| |_____| Figure 6 Combination of HMIPv6 with NEMO The MAP (basic mode) advertises an address on its subnet in an RA, and MR1 binds its current location (LCoA_MR1) with its RCoA_MR1 and the list of mobile network prefixes (MNP_MR1). MR1 then sends a binding update (BU) message containing this binding information, called BU_MR1, to the MAP. If MR1 becomes aware of the MAP's existence by detecting the MAP option field in the RA, it relays this information to the MN within the mobile network. (If no MAP exists in the local network, MR1 adds its own address in the MAP option field, as described in Section 2.1.) ThemMobile node creates its own care- of-address (LCoA_MN) with a mobile network prefix and its RCoA by using the prefix of the MAP's address and its own interface ID. It then registers binding information containing LCoA_MN and RCoA_MN with the MAP (via MN's binding update (BU_MN). The MAP also binds the information from BU_MN and BU_MR1 by matching LCoA_MN to the MNP_MR1. The MN also registers binding information Ohnishi, et al. [Page 10] Internet Draft HMIP based route optimization Oct 2003 containing RCoA_MN and HoA_MN with the HA_MN. When the HA receives packets for the MN, it can directly send them to the MAP (via RCoA_MN) by using an IPinIP tunnel. The MAP then relays them to the MN by using another IPinIP tunnel, with the routing header option referring to the binding table for RCoA_MN -> LCoA_MN -> MNP_MR1 -> LCoA_MR1 stored in the MAP (This mechanism is described in Section 5.4.2.). The packet transfer route can thus shortcut HA_MR1 in this manner. This mechanism is basically the same as that in the case of a three-layer nested mobile network, as described in Section 2.2. The important point here is that an MN in the mobile network does not have to send a BU to the HA_MN as long as the mobile network moves within the MAP domain, because the HA_MN manages RCoA_MN as the MN's location, as created from the MAP's address. This feature contributes to reducing the location management burden of the HA_MN. The sequence and packet formats are shown in figure 7-9. Ohnishi, et al. [Page 11] Internet Draft HMIP based route optimization Oct 2003 MN MR1 MAP HA_MR1 HA_MN CN | | RA | | | | | |<----------| | | | | | | | | | | | | | | | | | BU | | | | | |---------->| | | | | | | | | | | | BA | | | | | |<----------| | | | | | | | | | | | BU | | | | | |----------------------->| | | | | | | | | | | BA | | | | | |<-----------------------| | | | RA | | | | | |<-----------| | | | | | | | | | | | BU | | | | | |----------------------->| | | | | | | | | | | BA | | | | | |<-----------------------| | | | | | | | | | | | BU | | | | |------------------------------------------------->| | | | | | | | | | BA | | | | |<-------------------------------------------------| | | | | | | | | | | | | | | IP/IP/IP | | | | | |----------->| | | | | | |IP/IP/IP/IP| | | | | |---------->| | | | | | | IP in IP | | | | | |------------------------>| | | | | | | IP | | | | | |---------->| | | | | | | | | | | | | | | | | | | | | | | | IP | | | | IP in IP | |<----------| | | |<------------------------| | | | IP/IP/IP/IP | | | | |<----------| | | | | | | | | | | IP/IP/IP | | | | | |<-----------| | | | | | | | | | | | | | | | | Figure 7 Sequence of packet transmission Ohnishi, et al. [Page 12] Internet Draft HMIP based route optimization Oct 2003 From MN to MR1 +---------------------------+ |src =LCoA_MN |BU to HA_MN | |dst =MAP |CoA=RCoA_MN | | | | +---------------------------+ From MR1 to MAP +----------------------------------------+ |src =LCoA_MR1 |src =LCoA_MN|BU to HA_MN | |dst =MAP |dst =MAP |CoA=RCoA_MN | | | | | +----------------------------------------+ From MAP to HA_MN +--------------+ | BU to HA_MN | | CoA=RCoA_MN | | | +--------------+ From HA_MN to MAP +--------------+ | BA to MN | | | | | +--------------+ From MAP to MR1 +----------------------------------------+ |src =MAP |src =MAP |BA to MN | |dst =LCoA_MR1 |dst =LCoA_MN| | | | | | +----------------------------------------+ or +----------------------------------------+ |src =MAP |RH |BA to MN | |dst =LCoA_MR1 |LCoA_MN | | | | | | +----------------------------------------+ Ohnishi, et al. [Page 13] Internet Draft HMIP based route optimization Oct 2003 From MR1 to MN +---------------------------+ |src =MAP |BA to MN | |dst =LCoA_MN | | | | | +---------------------------+ or +----------------------------------------+ |src =MAP |RH |BA to MN | |dst =LCoA_MN |LCoA_MR1 | | | | | | +----------------------------------------+ Figure 8 MIP message (BU/BA between MN and HA_MN) packet formats Ohnishi, et al. [Page 14] Internet Draft HMIP based route optimization Oct 2003 From MN to MR1 +----------------------------------------+ |src =LCoA_MN |src =RCoA_MN|Data | |dst =MAP |dst =HA | | | | | | +----------------------------------------+ From MR1 to MAP +-------------------------------------------------+ |src =LCoA_MR1 |src =LCoA_MN|src =RCoA_MN| Data | |dst =MAP |dst =MAP |dst =HA | | | | | | | +-------------------------------------------------+ From MAP to HA_MN +---------------------------+ |src =RCoA_MN |Data | |dst =HA | | | | | +---------------------------+ From HA_MN to CN +------------+ |Data | | | | | +------------+ From CN to HA_MN +------------+ |Data | | | | | +------------+ From HA_MN to MAP +---------------------------+ |src =HA |Data | |dst =RCoA_MN | | | | | +---------------------------+ From MAP to MR1 +-------------------------------------------------+ |src =MAP |src =MAP |src =HA | Data | |dst =LCoA_MR1 |dst =LCoA_MN|dst =RCoA_MN| | | | | | | +-------------------------------------------------+ Ohnishi, et al. [Page 15] Internet Draft HMIP based route optimization Oct 2003 or +-------------------------------------------------+ |src =MAP |RH |src =HA | Data | |dst =LCoA_MR1 |LCoA_MN |dst =RCoA_MN| | | | | | | +-------------------------------------------------+ From MR1 to MN: +----------------------------------------+ |src =MAP |src =HA |Data | |dst =LCoA_MN |dst =RCoA_MN| | | | | | +----------------------------------------+ or +-------------------------------------------------+ |src =MAP |RH |src =HA | Data | |dst =LCoA_MN |LCoA_MR1 |dst =RCoA_MN| | | | | | | +-------------------------------------------------+ Figure 9 Data packet formats In the combination of HMIPv6 with NEMO, there is another solution in which each MR can also use its own address as the RcoA (basic mode). 3. Route optimization for LFNs Since LFNs do not support MIPv6 functionality, the route to an LFN cannot be optimized. In this section, we describe a method by which the closest MR can execute the MIPv6 route optimization function as a proxy MN for an LFN. In the case of communication between an LFN and an MN, the LFN should provide the functionality of a CN in route optimization for the MN. Therefore, the MR should be able to perform proxy functions for both the MN and the CN. Before the MR performs a proxy function, it should recognize whether the connected device has a mobility management function (MN/MR) or not (LFN). If the device does have a mobility management function, then it should perform route optimization, because it is preferable to distribute the burden of route optimization management, as well as to conform to the end- to-end concept, meaning that an MN should be able to determine the execution of route optimization by itself. There may be several ways to distinguish an LFN from an MN. One possible solution, which we apply here, is for the connected device to send a BU request to the MR if it is an MN. The MR can thus recognize that the device is an LFN if it does not receive a BU message within a certain period after connectivity is established. The proposed proxy route optimization method is illustrated in Figures 10 and 11. When the MR detects the initial packet transfer to the LFN, it first executes the return Ohnishi, et al. [Page 16] Internet Draft HMIP based route optimization Oct 2003 routability (RR) test. If the test is successful, it sends the BU to the CN, instead of to the LFN. This BU contains binding information with the LFN address as the HoA and CoA-MR1 as the CoA. When the MR receives the RR test message sent from the MN to the LFN, it performs the RR test function and executes route optimization as a proxy CN. A similar proxy function for Mobile IPv4 was also proposed in MBG [4]. LFN MR HA_MR CN | | | | | | | IP packet | | | |<--------------| | | IP in IP | | | |<--------------| | | IP packet | | | |<-------------| | | | | | | | | | | | | HOTI | | | |------------------------------>| | | HOT | | | |<------------------------------| | | COTI | | | |------------------------------>| | | COT | | | |<------------------------------| | | BU | | | |------------------------------>| | | BA | | | |<----------------------------->| | | | | | | IP with RH| | | |<----------------------------- | | IP with RH | | | |<-------------| | | | IP with HoA | | | |------------->| IP with HAO | | | |------------------------------>| Figure 10 Proxy MN Ohnishi, et al. [Page 17] Internet Draft HMIP based route optimization Oct 2003 MN MR1 HA_MR1 HA_MN MN | IP packet | | | | |----------->| | | | | | IP in IP | | | | |---------->| | | | | | IP packet | | | | |----------->| | | | | | IP in IP | | | | |----------->| | | | HOTI | | | |<------------------------------------| | | | HOT | | | |------------------------------------>| | | | COTI | | | |<------------------------------------| | | | COT | | | |------------------------------------>| | IP with RH | | | | |----------->| IP in IP | | | | |---------->| IP with RH | | | | |------------------------>| | | | IP with HAO| | | | |<------------------------| | | IP in IP | | | | |<----------| | | | | | | | | IP with HAO| | | | |<-----------| | | | | | | | | Figure 11 Proxy CN 4. Packet format: MAP option message format This format is defined in the HMIP draft. The most recent version of the HMIP draft does not include extended mode. The method in this draft will use the same format as that defined in a future HMIP draft. 5. Mobile router consideration 5.1. Detecting position in nested NEMO If an MR receives an RA with a MAP option, it recognizes whether it is attached to the NEMO or it is in the MAP domain. The MR relays the MAP option by including it in its own RA. If the MR receives an RA without a MAP option, it recognizes that it is the root-MR. It thus sends an RA with a MAP option. In basic mode, the MR includes its CoA in the MAP option. This CoA is created from the RA's prefix, which is sent by the access router, or a prefix which has been delegated by the access router. 5.2. Generating RCoA Ohnishi, et al. [Page 18] Internet Draft HMIP based route optimization Oct 2003 The MR generates RCoA when it receives an RA with a MAP option. The method of generation depends on the status of the "M" flag, which is described in HMIP [2]. "M" bit ON: the MAP address is used as RCoA (extended mode) "M" bit OFF: the MAP address's network prefix is used as RCoA's network prefix. RCoA is generated by combining the prefix and the interface ID. 5.3. Sending BU The MR sends a BU to the root-MR. In basic mode, it uses LCoA as the CoA and RCoA as the HoA in the BU message. In extended mode, the MR uses LCoA as the CoA and the HoA as the HoA in the BU message. After registering with the root-MR, it sends the BU to its own HA. This BU includes RCoA as the CoA and the HoA as the HoA. 5.4. Forwarding packets 5.4.1. From MR to CN The forwarding method depends on the following rules: -packets initiated by the MR (not the root-MR): The packets are encapsulated twice by IP headers. The first (inner) IP header has RCoA as the source address and the HA's address as the destination address. The second (outer) IP header has its own address as the source address and the root-MR's address as the destination address. -non IPinIP encapsulated packets: The packets are encapsulated twice by IP headers. The first (inner) IP header has RCoA as the source address and the HA's address as the destination address. The second (outer) IP header has its own address as the source address and the root-MR's address as the destination address. -IPinIP encapsulated packets, where the destination address is that of the root-MR: The packets are forwarded to the root-MR by usingIPinIP. -IPinIP encapsulated packets, where the destination address is the MR's own address: The packets are decapsulated (if the packets are multiply encapsulated packets, decapsulation also occurs multiply). They are then forwarded according to normal IP routing. If the packets are care-of test init (COTI), the Care-of Init Cookie and the source address of the MR are maintained in the root-MR. The root-MR uses this information to forward the COT when it receives the COT from the CN. -IPinIP encapsulated packets, where the destination address is neither that of the root-MR nor its own address: Ohnishi, et al. [Page 19] Internet Draft HMIP based route optimization Oct 2003 The packets are forward to the MR's HA by using an IPinIP tunnel. 5.4.2. From CN to MR If the number of layers in the hierarchy is less than 2, the root-MR forwards the packets by using single binding caches, which are registered by the lower MRs. If the number of layers is more than 3, the root-MR forwards the packets by using combined binding caches, which are also registered by the lower MRs. The following procedures are simply examples; any other procedure that achieves the same functionality could also be used. Example of 3-layer nested nemo: MR1, MR2, and MR3 are the root-MR, the middle MR, and the lowest MR, respectively. mode: HMIP basic mode MR1's BU includes its RCoA and LCoA and the prefixes belonging to itself. MR2's BU includes its RCoA and LCoA and the prefixes belonging to itself. The packet forwarding procedures in the root-MR are as follows: 1. Receive packets whose destination is MR1's RCoA. 2. Find MR1's LCoA from the binding caches registered by MR1 3. Recognize whether MR1's LCoA does not correspond to a prefix directly connected to MR3 4. Find whether MR1's LCoA corresponds to a prefix owned by MR2 5. Find MR2's LCoA 6. Forward the packet through MR2's LCoA, MR1's LcoA, and MR1's RCoA. This forwarding is achieved by using IPinIP or the routing header. 5.5. Route optimization for LFNs 5.5.1. Identification of node types belonging to the mobile network If a node sends a Mobile IP message, it is identified as a Mobile-IP- enabled node. Otherwise, a node is identified as an LFN. This route optimization function is provided only for LFNs. 5.5.2. Proxy CN function The MR provides the following functions as a CN proxy: -receiving COTI, sending COT -receiving Home test init (HOTI), sending HOT -receiving BU, sending BA These functions are defined in Mobile IPv6 [1]. 5.5.3. Proxy MN function The MR provides the following functions as an MN proxy: -receiving COTI, sending COT -receiving HOTI, sending HOT -receiving BU, sending BA These functions are defined in Mobile IPv6 [1] Ohnishi, et al. [Page 20] Internet Draft HMIP based route optimization Oct 2003 6. HA consideration HAs do not require any additional functions. 7. Security consideration 7.1. Binding update to HA and MAP These messages are authenticated by the method defined in MIPv6 [1][5] and HMIP. 7.2. Binding update to root-MR These messages have to be authenticated by IPsec. The question of how to establish security associations between lower MRs/MNs and the root-MR is outside the scope of this document. AAA- and PKI-based approaches can be applied. 7.3. Proxy MN/CN functions In these functions, the same CoA is assigned to multiple LFNs and is not the IP address owned by the LFN. This is something like a Mobile IPv4 FA CoA. Therefore, the LFN and the MR have to have some security relationship. The method of setting up this relationship is outside the scope of this document. The same mechanism implemented with an access authentication method like an AAA-based approach and PANA can be applied. 7.4. Extended mode in HMIP In extended mode, multiple MRs share one CoA. The MAP and root-MR can not identify COTI from the CoA. Therefore, these nodes have to maintain a cookie in the COTI message and identify the COT by using this information. This function does not lead to another security issue. In this mode, packets from an HA are decapusulated by the MAP. Applying IPsec to the data packets is difficult, because the MAP does not know the key that is shared by the HA and the MN. The HA has to have a function by which it can use different IPsec Security Association (SAs) to protect packets between itself and the MAP. References [1] D. Johnson, C. Perkins and J. Arkko "Mobility Support in Ohnishi, et al. [Page 21] Internet Draft HMIP based route optimization Oct 2003 IPv6," Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003. [2] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert "Nemo Basic Support Protocol," Internet Draft, IETF. draft-ietf-nemo-basic- support-01.txt (work in progress), Sep. 2003. [3] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier "Hierarchical Mobile IPv6 mobility management (HMIPv6)," Internet Draft, IETF. draft-ietf-mobileip-hmipv6-08.txt, June 2003. [4] T. Ihara, H. Ohnishi and Y. Takagi "Mobile IP route optimization method for a carrier-scale IP network," in Proc. IEEE International Conference on Engineering of Complex Computer Systems, Sep. 2000. [5] J. Arkko, V. Devarapalli and F. Dupont "Using IPsec to Protect Mobile IPv6 Signaling between MNs and Home Agents," Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt (work in progress), June 2003. [6] T. Ernst and H. Lach "Network Mobility Support Terminology," Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt (work in progress), May 2003. Author's Address Hiroyuki Ohnishi NTT Network Systems Laboratories, NTT Corporation 9-11-3 Midori-Cho Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422-59-4132 EMail: ohnishi.hiroyuki@lab.ntt.co.jp Keisuke Sakitani NTT Network Systems Laboratories, NTT Corporation 9-11-3 Midori-Cho Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422-59-3874 EMail: sakitani.keisuke@lab.ntt.co.jp Ohnishi, et al. [Page 22] Internet Draft HMIP based route optimization Oct 2003 Yasushi Takagi NTT Network Systems Laboratories, NTT Corporation 9-11-3 Midori-Cho Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422-59-6059 EMail: takagi.yasushi@lab.ntt.co.jp Ohnishi, et al. [Page 23]