Internet Draft A. Petrescu, ed. Document: draft-petrescu-nemo-mrha-00.txt M. Catalina-Gallego Expires: April 2003 C. Janneteau H. Y. Lach A. Olivereau Motorola October 2002 Issues in Designing Mobile IPv6 Network Mobility with the MR-HA Bidirectional Tunnel (MRHA) Status of this Nemo 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 This document presents various issues related to designing a network mobility solution with Mobile IPv6 and the MRHA bidirectional tunnel. Several scenarios are presented with the MR at home and in a visited network, from which an argumentation is made that all routing information is available in the HA (when BR and HA are co-located) or can be communicated by ICMP Redirect (when the BR and HA are separated). This raises questions on when does the adding of more information than the 'R' bit into the Mobile IPv6 BUs is necessary. Other generic issues with an MRHA solution, like link-local addresses in Mobile IPv6, router renumbering, or ND for the MR are presented. Route Optimization and security aspects are only briefly touched. Petrescu et al. Expires April 2003 [Page i] INTERNET-DRAFT Mobile Networks with MRHA October 2002 Table of Contents Status of this Memo................................................i Abstract...........................................................i Conventions used in this document..................................1 1. Introduction....................................................1 1.1 Prior descriptions...........................................3 2. Definitions.....................................................3 3. Data structures.................................................4 4. Description of a Home Network...................................5 5. Scenarios.......................................................6 5.0 Manual mobile networks.......................................6 5.1 Scenarios with co-located HA and BR..........................7 5.2 Scenarios with HA and BR separated..........................11 5.3 MR Redirects to BR..........................................15 6. Informing the HA about the route to MR.........................16 6.1 ICMP Redirect from BR to HA.................................16 6.2 Static route method.........................................17 6.3 Dynamic route method........................................18 7. Other Issues...................................................18 7.1 Link-local addresses........................................18 7.2 MR as an MN.................................................19 7.3 Prefix-based routing and host-based routing.................19 7.4 Multicast subscriptions of the MR...........................19 7.5 Neighbour Discovery for MR..................................19 7.6 Separation of routing and mobility for MR...................20 7.7 Router Renumbering..........................................20 8. Mobile Router behaviour........................................21 8.1 CoA Configuration...........................................21 8.2 Discovering HA..............................................21 8.3 Sending BUs to HA...........................................22 8.4 Search order in various tables..............................22 9. Home Agent behaviour...........................................22 10. Route Optimization............................................22 11. Security Considerations.......................................23 11.1 Security of the MRHA tunnel................................23 11.2 Security for Route Optimization............................23 Acknowledgements..................................................24 Changes...........................................................24 References........................................................24 Authors' Addresses................................................26 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 RFC-2119 [1]. 1. Introduction This document identifies issues when designing an enhancement of the Mobile IPv6 protocol to support mobile networks. The background is the extensive use of the bidirectional tunnel between MR and HA. The HA acts on behalf of the link-local address of the Petrescu et al. Expires April 2003 [Page 1] INTERNET-DRAFT Mobile Networks with MRHA October 2002 moving interface of the Mobile Router when the MR is in a foreign network. The Mobile Router is using BUs and BAcks with the Home Agent to maintain the MRHA bidirectional tunnel. The modifications to Mobile IPv6 HA and MN are minimal. The BU format contains, in addition to all Mobile IPv6 fields, an additional bit 'R' that informs the HA that this is a mobile router instead of a mobile host. The 'R' bit is used by the HA to perform certain tasks differently for this home address than if it were a host. Traffic coming from outside the home link, or from other hosts on the home link, and directed to hosts behind the mobile router normally only need to go through the L2 address of the mobile router's correspoinding to its L3 address. With Proxy ND [19], it is the HA that pretends to own MR's L3 address by advertising new associations of of the MR's L3 address to the HA's L2 address, thus intercepting MR's home traffic and forwarding it to the current CoA of the MR. When the MR is in a foreign network, traffic coming from the mobile network and towards anywhere to the Internet, is first forwarded by the MR through the reverse tunnel MRHA to the HA. Then HA decapsulates and forwards to the specific host on the home link or outside the home link. When the MR acts as a mobile host, vanilla Mobile IPv6 is used. MR can send both BUs with the R bit set and without the R bit set. Depending on what is decided for the home address to be like (link-local or other), the HA could deduce both. A nemo solution with the MRHA tunnel should allow for a clean separation between routing maintenance and mobility bindings maintenance. The route maintenance is done unmodified between MR and BR, while the mobility bindings are done unmodified between MR and HA. Much of the argumentation made around routing can be considered as operator, or administrative issues, which seen otherwise can discard some of the conclusions, but not all. The document is organized as follows: the next sections present a description of the home network, where the HA could be co-located with the BR, or separated. Then a set of simple scenarios are presented describing the normal routing behaviour of the MR when it is at home, and the desired behaviour of routing and of ND messaging at home, when the MR is in a foreign network. These scenarios are presented such that they expose the need for new behaviours only in the case where the HA is separated from the BR; otherwise (HA/BR co-located), all routing information is already present in the HA. The following section presents possible approaches for adding to HA routing information related to MR, one based on ICMP Redirects, one based on static or dynamic routes (from previous documents) and a third approach as a slight Petrescu et al. Expires April 2003 [Page 2] INTERNET-DRAFT Mobile Networks with MRHA October 2002 modifications of dynamic routing where the HA "only listens" to route updates but doesn't advertise. Additional sections present other issues related to maintaining normal MR behaviour when it is not at home (e.g. renumbering or multicast subscriptions) and then detailed behaviour of the HA and of the MR. The Route Optimization problem and the Security Considerations are briefly touched at the end. 1.1 Prior descriptions of mobile network support with Mobile IPv6 A complete description of the previous proposals to support mobile networks or mobile routers with Mobile IP bi-directional tunnel can not be made here due to space constraints. The closest description to mobile network support in Mobile IPv6 with the MRHA tunnel can be found in [13]. The approach described in that document relies on the bidirectional tunnel between MR and HA. The solution proposed is valid for Mobile IPv6 as for Mobile IPv4. The MR and HA behaviours still represent a sensitive departure from the Mobile IPv6 protocol in that MR informs its HA directly about the tunnel interface and dynamically triggers additions of routing table entries in the HA's routing table for the MR's tunnel. In addition, the most recent version of the draft proposes usage of the PSBUs in order to inform the HA about the prefix of the mobile network (thus a combination with the PSBU approach). Moreover, the considerations about dynamic routing in this draft refer only to how dynamic routing would work with a MR, but not about the necessity of running a routing protocol between HA and MR. See sections 6.2 and 6.3 for an overview of the methods presented in these documents. Using PSBUs as proposed in [8] and [13] has many other side-effects not considered until recently. When the mobile network is assigned several prefixes instead of one, then it is not clear whether several BUs are being sent or only one with several prefixes inside. Remark that in the vanilla Mobile IPv6 case, only one CoA can be sent with a BU (the alternative CoA is only an alternative not a substitute). In the Mobile IPv4 case, the network mobility support with the MRHA tunnel has been reported at least by various teams at Cisco [4] and NASA [14]. 2. Definitions Many relevant definitions for network mobility with the MRHA (could me spelled emra) tunnel can be found in [9]. In addition to those definitions: MRHA bidirectional tunnel, sometimes referred to as a reverse tunnel. As described in [6], [12], [17], [20]. Petrescu et al. Expires April 2003 [Page 3] INTERNET-DRAFT Mobile Networks with MRHA October 2002 MIMR: the Mobile Interface of the Mobile Router: the interface that connects MR to the home link and that changes its Care-of Address when away from home. MR_HoA: mobile router's Home Address, or the home address of the MIMR. MNP: mobile network prefix, or the prefix of the link of the mobile network that will move away. Note that in the most general case a single MR may route multiple prefixes, in which case there would be multiples MNPs per one mobile network. FN: fixed node on the home link. It doesn't stand for fixed network. 3. Data structures A home agent that supports mobile networks maintains the following structures: destination cache [19], binding cache [12] and routing table [11]. The binding cache is modified from Mobile IPv6, such that. The Home Agent also maintains the MRHA Tunnel Table. A Mobile Router contains an on-link prefix list, a neighbour cache, a destination cache, routing table, a binding update list, a home agents list and so on. Additionally, it contains an MRHA Tunnel Table with the following fields: -interface number -address of the tunnel endpoint corresponding to the mobile router. This is normally a CoA. -address of the tunnel endpoint corresponding to the home agent. This is normally the HA address. -list of entries present in the neighbour cache. -list of entries present in the destination cache. -list of entries present in the prefix list. -list of entries present in the default router list. -list of entries present in every other structure. The idea behind the MRHA tunnel table is to have as little modifications as possible to the other ND and Mobile IPv6 tables such that the MR acts as if it were at home, but across the MR-HA tunnel. All the mechanisms related to ND and classic routing are being subjected to this tunnel table, such as to allow for mobility of the mobile network. One example is to stop doing ND for the home address of the MR's interface that acquired a new CoA. It also prevents the MR to have routing interactions with the visited domain, but it alows it to continue having "normal" routing interactions with its home domain, including exchanging of normal dynamic routing messages, multicast routing messages, ICMP redirects and others. Petrescu et al. Expires April 2003 [Page 4] INTERNET-DRAFT Mobile Networks with MRHA October 2002 4. Description of a Home Network When designing a NEMO solution with the MRHA tunnel, the first steps are to carefully consider the actual behaviour of the home network when the mobile network is at home, employing normal routing. Then this behaviour should be maintained as much as possible when the MR is not at home (e.g. MR should be able to send redirects through the MRHA tunnel); reciprocically, the normal behaviour of an FR at home should change when that FR is an MR and is at home (e.g. when MR at home, the MRHA tunnel should be torn down). When the MR is in a foreign network, its presence at home is simulated by the HA (as in Mobile IPv6 for hosts). Let us consider a simple case of a home network that supports movement of one of its links. The home network is made up of a home link and a mobile network link, separated by the Mobile Router. The home network is connected to the Internet via the Border Router, as presented in the figure: ---- | FN | ---- | ------- home link -------------------| HA/BR |---> Internet | ------- ---- ----- | MR | | LFN | ---- ----- | | mobile link --------- Current specification for Mobile IPv6 implies that the HA can be either co-located with the BR, or it can act as a separate one-interface machine (this is advantageous for deploying Mobile IPv6 without changing BRs). For mobile networks, the latter mode can be pictured like this: ---- ---- | FN | | HA | ---- ---- | | ---- home link -------------------| BR |------> Internet | ---- ---- ----- | MR | | LFN | ---- ----- | | mobile network link --------- It is assumed that routes outside the home link are managed by BR and MR, either in a static manner (operator fills in routing tables) or dynamic manner (application software partially manages routing tables). Remark that even when the dynamic style is used, it is still true that operator fills initial routing configuration files, where she/he puts the image of the network as being what the operator believes it to be. The dynamic behaviour of routing protocols intervenes when certain links come down or up due to Petrescu et al. Expires April 2003 [Page 5] INTERNET-DRAFT Mobile Networks with MRHA October 2002 failures, the operator view is no longer true, and the routers manage to find alternative paths. Also, the dynamic behaviour helps obtaining shortest paths over large networks, relying on several local operator's views of smaller sized networks. Addition of mobility should not change this. If static routing is used instead of dynamic routing, then static routes are added manually both on MR and on the BR. When considering adding *static* routes in a *dynamic* manner for prefixes shorter than /128 by Mobile IP, authors of this document realize (in truth, hopefully) that Mobile IP starts using semantics that are traditionally belonging to routing protocols. 5. Scenarios For the sake of completetess, we first describe a simple "manual" scenario for mobile networks based on the MRHA tunnel, that exposes relative simplicity, that uses static routing and doesn't use Mobile IP. Then, adding the Mobile IP behaviour, we present detailed scenarios of communication between an FN on the home link and an LFN on the mobile network link and a CN on the Internet, when the mobile network is at home and away from home in a visited network, and when the HA is co-located with the BR and separated from the BR. All in all, 16 simple scenarios are presented. The scenarios where HA is co-located with BR (1 up to 8) expose that there is no need for MR to communicate prefixes to its HA via BUs. In a normal routing function, when the MR is at home, it exchanges routing information with the BR (co-located with the HA) and thus those prefixes are communicated by e.g. RIP or OSPF. When the MR is not at home, this behaviour continues, but through the MRHA tunnel. The scenarios where HA and BR are separated (9 up to 16) expose that HA needs an entry in its routing table in order to be capable of forwarding packets to the MR (when it is not at home). An additional scenario is then presented where MR at home is using ICMP Redirect, a functionality that might be needed even when the MR is not at home. 5.0 Manual mobile networks Authors of this draft have experimented with "manual" mobile networks in IPv4, where the addition of routes and tunnels on the MR and on the BR are done manually, by operators talking on the phone. A home network was used that contains about 10 routers and about 12 subnets. That home network is connected to the Internet with a BR. All routers have static routes among them. Petrescu et al. Expires April 2003 [Page 6] INTERNET-DRAFT Mobile Networks with MRHA October 2002 Then, one slice of that home network (the mobile network) containing one "MR", one normal router and 6 subnets, was disconnected from home, and moved across the Atlantic. Once the "MR" was connected on the other side, it was manually configured with a new IPv4 address, mask and default route. Then a tunnel interface and a route were manually set up on the MR, a tunnel interface and a route were manually set up on the BR. All other routes on all other routers where not touched. Mobile IP software was not used. The entire network (the home and the mobile network) looked, and acted, as if the mobile slice were at home. During this, several applications were tested between hosts in the mobile network, hosts in the home network and hosts on the Internet (incidentally, one of the applications was relying on Mobile IPv4 for hosts, but in no relation with the mobile network moving). Again, this "manual" mobile networks scenario was not using any dynamic routing protocol, and the tunnel was not supporting any form of broadcast of multicast. 5.1 Scenarios with co-located HA and BR 1. FN sends packet to LFN, mobile network home, HA/BR colocated ---- | FN | ---- | ------- home link -------------------| HA/BR |---> Internet | ------- ---- ----- | MR | | LFN | ---- ----- | | mobile link --------- -FN scans its routing table for LFN's address, and finds default route towards BR (if towards MR, see section 6.1). -FN sends NS for L2 address of BR. -BR replies NA. -FN sends packet to BR. -BR scans its routing table for LFN's address, and finds route through MR; -BR sends NS for MR. -MR replies NA with its L2 address. -BR forwards packet to MR and sends ICMP Redirect to FN such that subsequent packets from FN to LFN go straight through MR and not through BR. -MR forwards packet to FN. The sensitive issue exposed here is the way in which initially the packet travels from FN to BR to MR, the dynamic addition of an entry in the routing table of the FN (even if FN doesn't run a routing protocol) and that subsequent packets will not go through BR, but from FN to MR to LFN. Petrescu et al. Expires April 2003 [Page 7] INTERNET-DRAFT Mobile Networks with MRHA October 2002 2. FN sends packet to LFN, mobile network visits, HA/BR colocated ---- / | FN | / ---- ----------/ | ------- | | ----------------| HA/BR |---| Internet | home link ------- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -FN scans its routing table for LFN's address, and finds default route towards BR. -FN sends NS for L2 address of BR. -BR replies NA. -FN sends packet to BR. -BR scans its routing table for LFN's address, and finds route through MR; -BR (being an HA) scans its BC and its routing table and finds it needs to encapsulate this packet towards MR's CoA. -BR encapsulates through the MRHA tunnel to MR's CoA. -MR decapsulates and forwards to LFN. 3. LFN sends packet to FN, mobile network home, HA/BR colocated ---- | FN | ---- | ------- home link -------------------| HA/BR |---> Internet | ------- ---- ----- | MR | | LFN | ---- ----- | | mobile link --------- -LFN scans its routing table for FN's address, and finds default route towards MR. -LFN sends NS for L2 address of MR. -MR replies NA. -LFN sends packet to MR. -MR scans its routing table for LFN's address, and finds route 'on-link'; -MR sends NS for FN. -FN replies NA with its L2 address. -MR forwards packet to FN. Petrescu et al. Expires April 2003 [Page 8] INTERNET-DRAFT Mobile Networks with MRHA October 2002 4. LFN sends packet to FN, mobile network visits, HA/BR colocated ---- / | FN | / ---- ----------/ | ------- | | ----------------| HA/BR |---| Internet | home link ------- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -LFN scans its routing table for FN's address, and finds default route towards MR. -LFN sends NS for L2 address of MR. -MR replies NA. -LFN sends packet to MR. -MR encapsulates this packet through the MRHA tunnel and sends to HA. -HA receives this packet and decapsulates. -HA scans its routing table for FN's address, and finds route 'on-link'; -HA sends NS for FN. -FN replies NA with its L2 address. -HA forwards packet to FN (on behalf of the MR). 5. CN sends packet to LFN, mobile network home, HA/BR co-located ---- CN link --| BR1|------ / ---- | / | ----------/ ---- ------- | | | CN | ----------------| HA/BR |---| Internet | ---- | home link ------- | | ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | --------- mobile net link -BR receives packet from CN towards LFN. -BR scans its routing table and finds dest through MR. -BR sends NS for L2 address of MR and MR replies NA. -BR forwards packet to MR. -MR forwards packet to LFN. Petrescu et al. Expires April 2003 [Page 9] INTERNET-DRAFT Mobile Networks with MRHA October 2002 6. CN sends packet to LFN, mobile network visits, HA/BR colocated ---- CN link --| BR1|------ / ---- | / | ----------/ ---- ------- | | | CN | ---| HA/BR |---| Internet | ---- ------- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -BR receives packet from CN towards LFN. -BR scans its routing table and finds dest through MR. -BR scans its routing table and its BC and realizes it needs to send this through the MRHA tunnel. -BR sends the packet through the MRHA tunnel to MR. -MR decapsulates and forwards to LFN. (this is sometimes referred to as triangular routing, since the packet from CN to LFN travels artificially through BR) 7. LFN sends packet to CN, mobile network home, HA/BR colocated ---- CN link --| BR1|------ / ---- | / | ----------/ ---- ------- | | | CN | ----------------| HA/BR |---| Internet | ---- | home link ------- | | ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | --------- mobile net link -MR receives packet from LFN towards CN. -MR scans its routing table to and finds dest through BR. -BR forwards packet to Internet towards CN. -BR1 forwards packet to CN. Petrescu et al. Expires April 2003 [Page 10] INTERNET-DRAFT Mobile Networks with MRHA October 2002 8. LFN sends packet to CN, mobile network visits, HA/BR colocated ---- CN link --| BR1|------ / ---- | / | ----------/ ---- ------- | | | CN | ---| HA/BR |---| Internet | ---- ------- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -MR receives packet from LFN towards CN. -MR scans its tables and finds it needs to send it through the MRHA tunnel. -BR receives this packet, decapsulates and forwards to Internet. -BR1 forwards this packet to CN. (this is sometimes referred to as triangular routing, since the packet from LFN to CN travels artificially through BR) 5.2 Scenarios with HA and BR separated 9. FN sends packet to LFN, mobile network home, HA separated BR ---- ---- | FN | | HA | ---- ---- | | ---- home link -------------------| BR |------> Internet | ---- ---- ----- | MR | | LFN | ---- ----- | | mobile network link --------- -FN scans its routing table for LFN's address, and finds default route towards BR. -FN sends NS for L2 address of BR. -BR replies NA. -FN sends packet to BR. -BR scans its routing table for LFN's address, and finds route through MR; -BR sends NS for MR. -MR replies NA with its L2 address. Petrescu et al. Expires April 2003 [Page 11] INTERNET-DRAFT Mobile Networks with MRHA October 2002 -BR forwards packet to MR and sends ICMP Redirect to FN such that subsequent packets from FN to LFN go straight through MR and not through BR. -MR forwards packet to FN. 10. FN sends packet to LFN, mobile network visits, HA separated BR ---- ---- / | FN | | HA | / ---- ---- ----------/ | | ---- | | -------------------| BR |---| Internet | home link ---- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -FN scans its routing table for LFN's address, and finds default route towards BR. -FN sends NS for L2 address of BR. -BR replies NA. -FN sends packet to BR. -BR scans its routing table for LFN's address, and finds route through MR; -BR sends NS for MR. -HA replies NA with its L2 address (on behalf of MR). -BR forwards packet to HA and sends ICMP Redirect to FN such that subsequent packets from FN to LFN go straight through MR and not through BR. BR also sends ICMP Redirect to HA, such that HA knows a route through MR. The logic of this last ICMP Redirect is described in section 6.1. -HA scans its routing table for LFN's address, and finds through MR; -HA scans binding cache and finds 'through MRHA tunnel'; -HA encapsulates and sends packet to MR. -MR decapsulates and forwards to LFN. The problem in the above case is how to inform the HA about the route towards MR. When MR at home, and HA being a host, normally HA doesn't have a route towards MR. See discussion in section 6.1. Petrescu et al. Expires April 2003 [Page 12] INTERNET-DRAFT Mobile Networks with MRHA October 2002 11. LFN sends packet to FN, mobile network home, HA separated BR ---- ---- | FN | | HA | ---- ---- | | ---- home link -------------------| BR |------> Internet | ---- ---- ----- | MR | | LFN | ---- ----- | | mobile network link --------- -LFN scans its routing table for FN's address, and finds default route towards MR. -LFN sends NS for L2 address of MR. -MR replies NA. -LFN sends packet to MR. -MR scans its routing table for LFN's address, and finds route 'on-link'; -MR sends NS for FN. -FN replies NA with its L2 address. -MR forwards packet to FN. 12. LFN sends packet to FN, mobile network visits, HA separated BR ---- ---- / | FN | | HA | / ---- ---- ----------/ | | ---- | | -------------------| BR |---| Internet | home link ---- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -LFN scans its routing table for FN's address, and finds default route towards MR. -LFN sends NS for L2 address of MR. MR replies NA. -LFN sends packet to MR. -MR encapsulates this packet through the MRHA tunnel and sends to HA. -HA receives this packet and decapsulates. -HA scans its routing table for FN's address, and finds route 'on-link'; -HA sends NS for FN. FN replies NA with its L2 address. -HA forwards packet to FN (on behalf of the MR). Petrescu et al. Expires April 2003 [Page 13] INTERNET-DRAFT Mobile Networks with MRHA October 2002 13. CN sends packet to LFN, mobile network home, HA separated BR ---- CN link --| BR1|------ ---- / ---- | | HA | / | ---- ----------/ ---- | ---- | | | CN | -----------------| BR |---| Internet | ---- | home link ---- | | ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | --------- mobile net link -BR receives packet from CN towards LFN. -BR scans its routing table to and finds dest through MR. -BR sends NS for L2 address of MR. -MR replies NA. -BR forwards packet to MR. -MR forwards packet to LFN. 14. CN sends packet to LFN, mobile network visits, HA separated BR ---- CN link --| BR1|------ ---- / ---- | | HA | / | ---- ----------/ ---- | ---- | | | CN | ---------| BR |---| Internet | ---- ---- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -BR receives packet from CN towards LFN. -BR scans its routing table to and finds dest through MR. -BR sends NS for L2 address of MR. HA replies NA on behalf of MR. -BR sends Redirect to HA informing it about a route towards MR. See section 6.1 on a discussion about this ICMP Redirect. -Simultaneously with previous packet, BR forwards packet to HA. -HA scans its routing table and finds an entry to MR (added as a result to ICMP redirect), it also has a BC entry for MR, so it sends the packet through the MRHA tunnel. Petrescu et al. Expires April 2003 [Page 14] INTERNET-DRAFT Mobile Networks with MRHA October 2002 The problem in the above case is how to inform the HA about the route towards MR. When MR at home, and HA being a host, normally HA doesn't have a route towards MR. See discussion in section 6.1. 15. LFN sends packet to CN, mobile network home, HA separated BR ---- CN link --| BR1|------ ---- / ---- | | HA | / | ---- ----------/ ---- | ---- | | | CN | -------------------| BR |---| Internet | ---- | home link ---- | | ---- ----- ----------\ | MR | | LFN | \ ---- ----- \ | | --------- mobile net link -MR receives packet from LFN towards CN. -MR scans its routing table and finds dest through BR. -BR sends packet to CN 16. LFN sends packet to CN, mobile network visits, HA separated BR ---- CN link --| BR1|------ ---- / ---- | | HA | / | ---- ----------/ ---- | ---- | | | CN | ----------| BR |---| Internet | ---- ---- | | ----------\ \ \ ---- Visited link --| AR |------ ---- | | ---- ----- | MR | | LFN | ---- ----- | | --------- mobile net -MR receives packet from LFN towards CN. -MR encapsulates this packet through the MRHA tunnel. -HA receives this packet, decapsulates and sends to CN. 5.3 MR Redirects to BR Also, consider the scenario where the FN has a default route towards the MR instead of the BR, and sending packets to a CN on the Internet. This might very well happen when the MR is at home Petrescu et al. Expires April 2003 [Page 15] INTERNET-DRAFT Mobile Networks with MRHA October 2002 and sending RAs, in addition to the RAs sent by the BR. FN might configure a default route through the MR instead of the BR. If MR is at home, MR will redirect the FN towards the BR. So, even if this looks like a wrong configuration on the FN (its default route should point to BR and not MR), packets will still travel correctly when MR is at home. This should be maintained when the MR is not at home. There are two possibilities: either the HA (replacing the MR) redirects the FN towards the BR, or it is the MR itself that sends the respective ICMP redirect message to the FN (through the MRHA tunnel). The first case supposes that HA maintains a routing table, which contains routes towards the mobile network. This is less desirable if the HA is not co-located with BR, and where we prefer not to have routing interactions with the HA. The latter case is more plausible, keeping the default routing behaviour to the MR. 6. Informing the HA about the route to MR In certain scenarios presented previously, with the HA dissociated from the BR and the MR in the visited network, there is a need for the HA to maintain in its routing table an entry towards the MR. A scenario where packets from CN towards LFN are looping between MR and HA has been described in detail in section 3.2.4 of [8]. Several solutions exist to avoid this looping, described below. 6.1 ICMP Redirect from BR to HA One alternative for avoiding the loop problem is by using ICMP Redirects [19] sent by BR to HA in order to communicate to HA the route it misses towards the MR. ICMP Redirects are deployed and used in existing networks. The classic behaviour of ICMP Redirects is presented in scenario 1. Scenarios 10 and 14 with MR-not-at-home and BR dissociated from HA, present the fact that classic ICMP Redirects are not triggered normally and thus modifications are needed. In addition to the normal behaviour with ICMP Redirects, described in [19], it could be modified according to the following. The decision by BR to send ICMP Redirect towards HA can be taken in at least three ways: -allow a number of iterations of a packet looping between HA and BR and after this fixed number decide to send the Redirect to HA such as the looping stops. This modifies the normal behaviour of BR. -another possibility is for BR to react at the moment it receives the proxy NA from HA (on behalf of the MR), compare to the current entry it has in the Neighbour Cache for MR, and then decide that, because MR has moved away, send Redirect to HA to inform HA about the route to MR. This is the route (or set of routes) normally maintained by the BR with the MR, doesn't contain any form of the new position (CoA) of the MR. This route, or set of routes (in which case a set of Redirects are sent), is copied from MR's routing table. All routes that have Petrescu et al. Expires April 2003 [Page 16] INTERNET-DRAFT Mobile Networks with MRHA October 2002 destination the MR's home address need to be communicated to HA with ICMP Redirects. This modifies the normal behaviour of BR. -yet another possibility is to consider modifications on HA (from vanilla Mobile IPv6), but don't touch BR, such that HA generates a new packet, thus obtaining a classic ICMP Redirect from BR. When the HA receives a packet that is not for itself, it encapsulates it with an IP-in-IP tunnel, having the src address its own address and the destination address copied from the dst address of the original packet. Then try to route this packet and find the default route towards BR. Then BR sends a normal ICMP Redirect informing HA there is a better route for this packet towards MR. Thus HA acquires the MR route dynamically. The packet will be passed on by BR to HA again, and further details are needed here. Remark that this is equivalent to one iteration of the loop (a particular case of the fixed iterations loop mentioned previously). 6.2 Static route method This is proposed by [4] and [13], where operator statically introduces a route in the HA, for MR's prefix, towards MR's address, or towards the specific MRHA tunnel. The first approach proposed in [4] suggests to configure a new static tunnel on the MR's HA towards MR_HoA. This static tunnel, that we call here MR_HoA_tunnel, is to be used as output interface of a new static entry added in the routing table of HA for MR's prefix: MR prefix -> MR_HoA_tunnel. Upon reception of a data packet from CN addressed to a LFN, MR's HA will consult its routing table and find a match for that packet for this static route since LFN address matches MR's prefix. As a results it will encapsulate the packet with an additional header that will have MR's HA as source address and MR_HoA as destination address. In order to forward this packet, now addressed to MR's Home Address, the MR will first consult its binding cache and discover MR's Care-of address. It will thus send the packet through the MRHA tunnel towards MR's current location. It is worth mentionning that this approach introduces a double encapsulation of an incoming packet to be forwarded to the MR: the first is due to the MR_HoA_tunnel, the second to the MRHA tunnel. The second approach proposed in [13] suggests a similar method but avoids the overhead introduced by the two tunnels. It consists in configuring a static route in MR's HA routing table for MR's prefix towards MR's Home Address: MR prefix -> MR_HoA. Upon reception of a data packet from CN addressed to a LFN, MR's HA will consult its routing table and, again, find a match for that packet for this static route since LFN address matches MR's prefix. This indicates the MR's HA that the packet should be routed towards MR_HoA. From its binding cache it discovers MR's CoA and as a consequence forwards the incoming packet for CN directly through the MRHA tunnel. This approach reduces the overhad of the MR_HoA_tunnel but requires a suitable coordination of the routing table and binding cache on the HA. Petrescu et al. Expires April 2003 [Page 17] INTERNET-DRAFT Mobile Networks with MRHA October 2002 Analyzed from the perspective where HA is separated from BR, and where MR doesn't normally maintain routes with HA, then this addition might seem superfluous. Consider a situation where MR and BR maintain routing information and where that manual route is added on HA. When the MR is not at home, consider that administrator decides to add a new fixed subnet at home, with its own router neighbouring with BR on the home link. Consider the new subnet's prefix being a longer prefix derived from the prefix assigned to the MR's subnet. This is perfectly feasible by changing configurations on the MR and BR. That can work perfectly even if MR is not at home. But if HA doesn't participate in this exchange (which is the case if HA separated from BR) then the manual route added previously in the HA is no longer valid. Thus, a potential issue. Further explanation or simplification needed here. 6.3 Dynamic route method It is possible for the HA, being either separated or co-located with the BR, to run a specific routing protocol, participating in the routing interactions between BR and all other neighbouring routers on the home link. Thus, the HA always has the necessary route it needs to join the MR's network. If the HA is a one-interface machine, and separated from the BR, it seems that it maintains information that is not always necessary to its well working as a HA. For example, it will maintain routes to all neighbouring routers, be it fixed or mobile. The routes to the fixed neighbouring routers are not necessary for its working as a host, since it suffices to only have a default route towards a BR, that will normally dynamically Redirect it towards the other fixed routers. Moreover, if HA runs a dynamic routing protocol, its route updates will never be taken into account by other routers, since they will always be one hop further than the routes already known by them. Thus it might be possible to have the HA as a silent routing, only receiving route updates from the neighbouring routers, but never sending route updates, since it does not have a network behind it (it is a "host") whose reachability it needs to advertise. RIP [11] supports having a silent host that only listens to update messages, but does not advertise new routes. With OSPF [18] the "listening only" requirement is complicated by the fact that the HA would needs to participate in OSPF's HELLO protocol. The advantage of using this solution is that it does not require additional changes to Mobile IPv6, and PSBUs are not needed. The disadvantage is that if the MR does not run a routing protocol then we still need some way of telling the HA the routes to the MNPs, which gets us back to sections 6.1 and 6.2. Further explanation or simplification needed here. 7. Other Issues 7.1 Link-local addresses When the MR is at home, and if it runs a dynamic routing protocol, it exchanges routing information with BR, by using its link-local address and BR's link-local address. When the MR is not at home, and HA defends the MR's home address, the HA is normally doing this for any type of addresses except link-locals. The immediate necessity would be for the HA to defend a link-local address of the MR, instead of a global-scoped home address. However, this is in conflict with the necessity of dynamic routing protocols to use link-local addresses only. If Mobile IPv6 spec is to be followed, then the HA will not allow re-direction of traffic of a Home Address towards a CoA, when that Home Address is link-local. Another issue concerning link local addresses: the MR has routes to the BR using BR's link local address. When the MR is away from home: how does the MR reach BR's link local address? Petrescu et al. Expires April 2003 [Page 18] INTERNET-DRAFT Mobile Networks with MRHA October 2002 How does it tell the difference between a link local address on the home link and a link local address on the visited link? 7.2 MR as an MN If the MR is at home and it has an address configured on the moving interface other than a link-local address, then the MR can act as an MH too, and send normal Mobile IPv6 BUs, binding that Home Address to a newly configured CoA; thus allowing the MR to be an MH for itself only, ignoring the LFNs. If the MR at home doesn't have other addresses than link-local on the mobile interface then the MR can not send normal Mobile IPv6 BUs and can not be an MH. It can however be an MR for the hosts on the mobile network. 7.3 Prefix-based routing and host-based routing Prefix-based hierarchical routing (where the mobile network link has a prefix that is a subset of the home-network link) is the preferred type of routing for IPv6. Practically though, it is possible for the BR to have a routing table entry containing the prefix of the mobile network, as well as a host-based entry that points to a certain LFN also in the mobile network. Those two entries might or might not have the same common sub-prefix. With a MR at home, being a normal router, BR will know how to forward to all hosts behind the MR as well as only to the specific LFN of the host-based route. This behaviour should be maintained when the MR is no longer at home and when it has a bidirectional tunnel MRHA. 7.4 Multicast subscriptions of the MR When the MR is at home, it normally joins certain multicast groups related to routing (e.g. all-routers multicast group with site scope). This is assumed by dynamic routing protocols, or by renumbering mechanisms. When the MR is no longer at home, its multicast subscription should continue as if it were at home. This can be achieved by "home subscription" techniques considered in relation with Mobile IPv6. 7.5 Neighbour Discovery for MR When MR is at home and sends RA towards the home link, it should not advertise itself as being capable of being a default router (Router Lifetime should be 0). When the MR is visiting, it should not respond to RSs sent on the visited link and it should not send RAs on the visited link. When the MR is at home, it doesn't normally use any information received from RAs sent by a neighbouring router, i.e. the BR. It has a link-local address and if it has a larger scope address configured on an interface, then that is normally done manually. Actually, routers are usually prohibited from using information received in RAs more than for logging and synchronization purposes. When the MR is in a foreign network, it needs a way to configure a Care-of Address. In the hosts case this is done by stateless or Petrescu et al. Expires April 2003 [Page 19] INTERNET-DRAFT Mobile Networks with MRHA October 2002 stateful autoconf. In the MR case, the stateful is possible, while the stateless is normally prohibited. A good way for address autococnfiguration for the MR should be identified, be it DHCP, or modified RAs, or modified router's behaviour to accept RAs. Assume the MR is at home and a non-link-local (site- or global) home address is configured on the interface connecting to the home link (supposedly the same interface that will change CoAqs when visiting). The MR-at-home will do periodic NAs for this home address; this behaviour should stop when MR is visiting. This modified behaviour is already taken into consideration by Mobile IPv6 MN. In the particular MR case, most ND operations of MR are delegated to the HA, and such most entries of Neighbour Cache, Destination Cache that are related to the home link will disappear. New entries that are relevant in the foreign network will populate those tables. When coming back home, all ND entries should be replaced back with the entries related to the home network. Another specific case in point is the default route. As already presented with the router behaviour with respect to RAs, a default route is not normally configured by MR from a received RA. When the MR is in a foreign network, it should have a default route that points to its BR (but through the MRHA tunnel) and another non-tunnelled default route towards the current AR. Moreover, all MR's routing table entries that pointed to BR when the MR was at home, should still continue to point to BR (through the MRHA tunnel). The same is true for all routing table entries of the BR. 7.6 Separation of routing and mobility for MR The necessity of the separation between mobility vs. routing exchanges holds true irrespective to whether dynamic or static routing is used. If static routing is used, then BR has routes towards the mobile network through the MR, and MR has routes towards the Internet through the BR. If dynamic routing is used, then the MR and BR dynamically exchange routing information that is manually configured in the routing configuration files of MR and of BR, as well as routing information that is delivered by other routers external to the home network (be it beyond the BR or beyond the MR). The entities concerned with routing in the home network are only BR and MR. This behaviour should continue when network mobility is introduced, presumably by deploying an HA (but not touching the BR). MR and HA should exchange only the information related to mobility but not the information related to routing. 7.7 Router Renumbering Router Renumbering for IPv6 [7] is a technique where routers of a home network are instructed to change the prefixes they advertise. In the context here, it should be possible for the MR to be re-numbered when it is at home as well as when it is visiting. The renumbering mechanisms provided by Mobile IPv6 (mobile prefix solicitations and advertisements) are not relevant for changing the prefixes advertised by the MR towards the mobile network; but these Petrescu et al. Expires April 2003 [Page 20] INTERNET-DRAFT Mobile Networks with MRHA October 2002 mechanisms should still be used for MR when MR is acting as an MH. In order for router renumbering to work for MR when acting as MR, the MR should at least be able to maintain its multicast subscription to all-routers group valid at home. 8. Mobile Router behaviour The MR-HA tunnel is an IP-in-IP tunnel maintained by MR and HA. This is not a "tunnel" in the sense referred to sometimes by employing the IPv6 routing headers. The behaviour of the Mobile Router is the behaviour of a normal router with the main exception of the order of search in relevant routing tables, with the addition of a step to search in the MRHA tunnel table. The exact search steps will be detailed later. Various implementations do it in various ways. A generic behaviour of a router forwarding a packet having destination d, or the behaviour of MR when it is at home: -determine the packet is for itself or not, by comparing d to all addresses assigned to all interfaces. -if not for itself then search the routing table for a prefix that matches d under a prefix. Pick d2. -search the destination cache for an exact match for d2. If found, then send the packet to the L2 address in the DC entry. If not found, then create it by doing the ND exchange; then send it to what ND found. From that behaviour, here is the modified mobile router behaviour: -determine the packet is for itself or not, by comparing d to all addresses assigned to all interfaces. -if not for itself then search the routing table for a prefix that matches d under a prefix. Pick d2. +determine whether this entry in the routing table has a corresponding entry in the MRHA tunnel table. If yes, then encapsulate towards the HA marked there and create a new packet, with source s CoA and new destination d from the tunnel table (Home Agent address). -search the destination cache for an exact match for d2, and that is not linked to the tunnel table. If found, then send the packet to the L2 address in the DC entry. If not found, then create it by doing the ND game; then send it to what ND found. 8.1 CoA Configuration This can be done by configuring an address based on a prefix received from the AR. However, routers don't take into account RAs, normally. It can be solved by saying that in this case MR is not quite a router but more of a host. It can also be done by means of DHCPv6 messaging, where there is no distinction between hosts and routers. 8.2 Discovering HA Do it as a Mobile IPv6 MH, except that. Anycast. Petrescu et al. Expires April 2003 [Page 21] INTERNET-DRAFT Mobile Networks with MRHA October 2002 8.3 Sending BUs to HA Do the normal Mobile IPv6 signalling with its Home Agent. The BUs sent contain a distinguishing bit 'R'. 8.4 Search order in various tables Further complicating the mobile routing issues, the Destination Cache is being specified with the option of being capable of being fusioned with the Routing Table. The same stands for the Binding Cache. It is then possible to have the DC, the BC and the routing table as a unique and only large routing table. With this kinds of unknowns, it is difficult for the authors, at present time, to specify a proper search order in the respective structures, even if we feel this is truly important. Or probably the behaviour of a MR and HA can be specified without going into the details of these structures, leaving implementations freedom of choice. 9. Home Agent behaviour The MR-HA tunnel is an IP-in-IP encapsulation tunnel [20] maintained by MR and HA. This is not a "tunnel" in the sense referred to sometimes by employing the IPv6 routing headers. The behaviour of the Home Agent is the behaviour of a normal Mobile IPv6 HA with the main exception of the order of search in relevant routing tables, with the addition of a step to search in the MRHA tunnel table. The exact search steps will be detailed. The Home Agent uses proxy-ND to defend the link-local address of the MR when the MR is not at home. When the MR is at home, the HA stops defending MR's link-local address. When the MR is not at home, the L2 address of the link-local address of the MR is requested by neighbouring routers (such as BR) or by FNs that have entries in their routing tables or destination caches through MR's link-local address. HA should reply to these requests with its own L2 address and as such receive all packets that have dst address containing any address of all hosts and routers in the mobile network. Following this, the HA will search its BC as well as its routing table, then it will encapsulate those packets through the MRHA tunnel and sent according to the normal HA's destination cache and routing tables, towards the current Care-of Address of the Mobile Router. When HA is a host, HA doesn't need to have a routing table containing entries towards MR or hosts and routers behind MR. When HA is a host, HA's routing table should contain only entries related to the neighbouring fixed routers. For example HA has a default route towards BR. 10. Route Optimization Route Optimization problem description is elsewhere. Petrescu et al. Expires April 2003 [Page 22] INTERNET-DRAFT Mobile Networks with MRHA October 2002 RO is an absolutely necessary need for mobile networks for Mobile IPv6. It might very well be that the need for RO might bring with it the need to put prefixes in the BUs towards CN. The previous scenarios allow for nested mobile networks as well. But the functioning suffers of drawbacks. The MRHA-enhanced Mobile IPv6 scenarios described previously suffer from important drawbacks, such as multiple nested tunnels, lack of route optimization with the CN. An example of an important inconvenient of using exclusively vanilla Mobile IPv6 with MRHA is when nesting: consider two mobile networks, each MR having its own HA in different domains. The first MR attaches to an AR and the second MR attaches under the first mobile network. In this case, two LFNs situated one on the first net and the second on the second net are capable to communicate with each other, but communication goes through both first MR's HA and through second's. In practice this exposes a paradox where if first MR loses connection to AR, then even if the two nets stay attached, the two LFNs can not communicate. 11. Security Considerations Security threat analysis of Mobile IPv6 when a Mobile Router is used instead of a Mobile Host. Not a threat analysis of RO. The threat analysis of Mobile IPv6 for hosts is presented in [10]. When router moves instead of host, new threats appear. When MR at home and using secured RIP [3] or OSPF [18] (whose IPv6 version [5] employs IPsec), then that level of security must be maintained when MR is away from home. 11.1 Security of the MRHA tunnel The MRHA tunnel is protected as required by the Mobile IPv6 specification for the MNHA tunnel [2]. MR and HA maintain a security association, share the same key. 11.2 Security for Route Optimization Since RO is not treated in this document, then the return routability tests for MR are not described. MR could do CoTI for MR's CoA and HoTI for LFN's address. In that case LFN's address must be bound to MR, presumably by delegation mechanisms. MR if acting as an MN must do HoTI/CoTI for itself, if that MN needs RO. If MR acting as MN, then its LFNs must not take Petrescu et al. Expires April 2003 [Page 23] INTERNET-DRAFT Mobile Networks with MRHA October 2002 advantage of the results of having an SA MN-CN. Or if they do, then MR must have some form of delegation support. Acknowledgements Some of the issues presented in this document have not yet been discussed publicly, as far as the authors are aware, except for the places where specific references to prior drafts is explicitely made. Some of the issues have been discussed on the nemo mailing list, and proper acknowledgment will be given here. This document being submitted for public review, all comments are welcome and contributors will be properly acknowledged. Changes October 2002: revision 00 submitted. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] Arkko, Jari, Devarapalli, Vijay, and Dupont, Francis, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, IETF Internet Draft, October 2002. (Work in Progress). [3] Baker, F. and Atkinson, R., "RIP-2 MD5 Authentication", RFC 2082, January 1997. [4] Cisco authors, "Cisco Mobile Networks", whitepaper browsed October 25, 2002 at http://www.cisco.com/univercd/cc/td/doc/product/software/ ios122/122newft/122t/122t4/ftmbrout.pdf [5] Coltun, R., Ferguson, D. and Moy, J., "OSPF for IPv6", RFC 2740, December 1999. [6] Conta, A. and Deering, S.,"Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [7] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000. [8] Ernst, Thierry, Olivereau, Alexis, Bellier, Ludovic, Castelluccia, Claude and Lach, Hong-Yon, "Mobile Networks Support in Mobile IPv6", draft-ernst-mobileip-v6-network-03.txt, IETF Internet Draft, March 2002. (Work in Progress). [9] Ernst, Thierry and Lach, Hong-Yon, "Network Mobility Support Terminology", draft-ernst-nemo-terminology-00.txt, IETF Internet Draft, October 2002. (Work in Progress). Petrescu et al. Expires April 2003 [Page 24] INTERNET-DRAFT Mobile Networks with MRHA October 2002 [10] Harkins, D., Mankin, A., Narten, T., Nikander, P., Nordmark, E., Patil, B. and Roberts, P., "Threat Models introduced by Mobile IPv6 and Requirements for Security", draft-ietf-mobileip-mipv6-scrty-reqts-02.txt, IETF Internet Draft, November 2001. (Work in Progress). [11] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1998. [12] Johnson, David B., Perkins, Charles E. and Arkko, Jari, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, IETF Internet Draft, June 2002. (Work in Progress). [13] Kniveton, Timothy J., Malinen, Jari T. and Devarapalli, Vijay, "Mobile Router Support with Mobile IP", draft-kniveton-mobrtr-02.txt, IETF Internet Draft, July 2002. (Work in Progress). [14] Leung, K. and Shell, D. and Ivancic, W. D. and Stewart, D. H. and Bell, T. L. and Kachmar, B. A., "Application of Mobile-IP to Space and Aeronautical Networks", IEEE Proceedngs of the Aerospace Conference, 2001. [15] Malkin, G., "RIP Version 2, Carrying Additional Information", RFC 1723, November 1994. [16] Malkin, G., "RIPng for IPv6", RFC 2080, January 1997. [17] Montenegro, G., ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001. [18] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [19] Narten, T., Nordmark, E. and Simpson, W., "Neighbour Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [20] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [21] Perkins, C., ed., "IP Mobility Support for IPv4", RFC 3344, August 2002. Petrescu et al. Expires April 2003 [Page 25] INTERNET-DRAFT Mobile Networks with MRHA October 2002 Authors' Addresses Alexandru Petrescu Miguel Catalina-Gallego Motorola Labs Motorola Labs Espace Technologique de St Aubin Espace Technologique de St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69354827 Phone: +33 1 69352541 Alexandru.Petrescu@motorola.com Miguel.Catalina@motorola.com Christophe Janneteau Hong-Yon Lach Motorola Labs Motorola Labs Espace Technologique de St Aubin Espace Technologique de St Aubin Gif-sur-Yvette 91193 Gif-sur-Yvette 91193 France France Phone: +33 1 69352548 Phone: +33 1 69352536 Christophe.Janneteau@motorola.com Hong-Yon.Lach@motorola.com Alexis Olivereau Motorola Labs Espace Technologique de St Aubin Gif-sur-Yvette 91193 France Phone: +33 1 69352516 Alexis@motorola.com Petrescu et al. Expires April 2003 [Page 26] INTERNET-DRAFT Mobile Networks with MRHA October 2002 Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Funding for the RFC editor function is currently provided by the Internet Society. Petrescu et al. Expires April 2003 [Page 27]