MIPSHOP Working Group W. Haddad Internet-Draft S. Krishnan Expires: October 3, 2005 Ericsson April 2005 Optimizing Micromobility Management draft-haddad-mipshop-omm-00 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 October 3, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Micromobility protocols address mobile nodes (MN) movements within a particular IP network domain. This document introduces a new protocol "Optimized Micromobility Management" (OMM), to manage Micromobility. The suggested solution is based on the Hierarchical Mobile IPv6 (HMIPv6) proposal and aims to increase the mobility performance by reducing the handover latency and the packet loss. Haddad & Krishnan Expires October 3, 2005 [Page 1] Internet-Draft Optimizing Micromobility Management April 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview of HMIPv6 . . . . . . . . . . . . . . . . . . . . . . 7 5. Problem, Motivation and Requirements . . . . . . . . . . . . . 8 6. Overview of the OMM Protocol . . . . . . . . . . . . . . . . . 10 7. OMM Protocol Description . . . . . . . . . . . . . . . . . . . 12 8. OMM New Bits, Options and Messages Structure . . . . . . . . . 15 8.1 The Address Check Information Option (ACIO) . . . . . . . 15 8.2 The Optimized Micro-Mobility Information Option (OMMIO) . 15 8.3 The VMAP (V) Bit . . . . . . . . . . . . . . . . . . . . . 16 8.4 Modified Router Solicitation message format . . . . . . . 17 8.5 Modified Binding Acknowledgement message format . . . . . 18 8.6 The Routing Path Update (RPU) Message . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Normative References . . . . . . . . . . . . . . . . . . . . 21 11. Informative References . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 24 Haddad & Krishnan Expires October 3, 2005 [Page 2] Internet-Draft Optimizing Micromobility Management April 2005 1. Introduction Managing Micromobility has been addressed in many different ways. Among existing proposals (e.g., [HMIPv6], [CIP], [HAWAII], etc), only the HMIPv6 proposal has been adopted by the IETF. This document introduces a new protocol, i.e., OMM, to manage Micromobility. The suggested solution is entirely based on the Hierarchical Mobile IPv6 (HMIPv6) proposal and aims to increase the mobility performance by reducing the handover latency and packet loss. For these purposes, the OMM protocol uses virtual mobility anchor points (VMAPs) and splits the handover event into two successive phases triggered by the network and the mobile node (MN). Haddad & Krishnan Expires October 3, 2005 [Page 3] Internet-Draft Optimizing Micromobility Management April 2005 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Haddad & Krishnan Expires October 3, 2005 [Page 4] Internet-Draft Optimizing Micromobility Management April 2005 3. Glossary +---------------------+---------------------------------------------+ | Term | Definition | +---------------------+---------------------------------------------+ | Mobility Anchor | A Mobility Anchor Point is a router located | | Point (MAP) | in a network visited by the mobile node. | | | One or more MAPs can exist within a visited | | | domain. | | | | | Virtual MAP (VMAP) | A virtual MAP is a router located inside | | | the IP network domain (i.e., a MAP is also | | | a VMAP), which implements a set of | | | features, which includes a subset of the | | | MAP features. A VMAP node stores the MN's | | | Regional Care-of Address (RCoA) and current | | | Local Care-of Address (LCoA) for a limited | | | period of time (e.g., the binding | | | lifetime), computes the new MN's LCoA and | | | encapsulates when needed data packets sent | | | by the CN to the MN's current location. At | | | any particular time during an ongoing | | | session(s), the mobile node should have AT | | | MOST one VMAP encapsulating data packets | | | and fowarding them to its new current | | | location. | | | | | Access Router (AR) | The mobile node's default router. The AR | | | aggregates the outbound traffic of mobile | | | nodes. An AR can also be a MAP/VMAP. | | | | | Regional Care-of | An RCoA is an IPv6 address obtained by the | | Address (RCoA) | mobile node from the visited network. An | | | RCoA is an address on the MAP's subnet. It | | | is auto-configured by the MN when receiving | | | the MAP option. | | | | | On Link Care-of | The LCoA is the on-link CoA configured on a | | Address (LCoA) | mobile node's interface based on the prefix | | | is advertised by its default router. | | | | | Tree Architecture | An IP network domain has a tree | | | architecture when any router located inside | | | the domain (i.e., except the ARs and the | | | root gateway(s)) has only one uplink and | | | one or more downlink(s). Such topology has | | | no mesh links. | | | | Haddad & Krishnan Expires October 3, 2005 [Page 5] Internet-Draft Optimizing Micromobility Management April 2005 | Mesh Architecture | A mesh network topology is defined as a | | | pure tree topology with additional mesh | | | links. This means that in a mesh topology, | | | at least one router located inside the | | | domain has one or more mesh link(s) in | | | addition to its uplink and downlink(s) | | | channels. | | | | | Random Architecture | A random network topology is used to | | | indicate a mesh topology with additional | | | uplinks. This means that in a random | | | topology, at least one router located | | | inside the domain has more than one | | | uplink(s), in addition to its downlink(s) | | | and mesh link(s) channels. | | | | | Local Binding | The Mobile Node sends a Local Binding | | Update (LBU) | Update (LBU) message to the MAP in order to | | Message | establish a binding between the RCoA and | | | the LCoA. | | | | | Routing Path Update | A Routing Path Update Message is sent by | | (RPU) Message | the new MN's New Access Router to the MN's | | | Previous LCoA (pLCoA). The RPU message is | | | used to trigger a Network Handover, which | | | is totally transparent to the MN. | | | | | Network Handover | A Network Handover can be defined in the | | (NH) | context of the OMM protocol, as the process | | | triggered by the network, of re-routing | | | data packets flow(s) sent to a particular | | | mobile node to its new location before the | | | MN sends a LBU message to the MAP. The NH | | | process aims to minimise the handover | | | latency as well as the packet loss. | +---------------------+---------------------------------------------+ Table 1: Glossary For more details about terms defined above, please refer to [HMIPv6] and [TOMOP]. Haddad & Krishnan Expires October 3, 2005 [Page 6] Internet-Draft Optimizing Micromobility Management April 2005 4. Overview of HMIPv6 The two main goals behind designing the [HMIPv6] protocol are to reduce both the heavy amount of signaling messages generated by the MIPv6 protocol and the handover latency. A third goal is to enable the MN to hide its movements and current location from the CN and the HA. HMIPv6 consists on deploying one or more special nodes called Mobility Anchor Point, i.e, MAP, within the IP network domain. A MAP can be defined as a local home agent, which intercepts all packets addressed to registered mobile nodes and tunnels them to the MN. When a MN enters to an HMIPv6 domain, it starts by selecting, then registering itself with the appropriate MAP. This is done by processing special information sent by the MN's AR in the Router Advertisement (RtAdv) message. These information allow the MN to auto-configure a regional care-of address (RCoA), which will be used by the MAP to capture packets sent from outside the domain to the MN's care-of address (i.e., RCoA), and a link care-of address (LCoA), which will be used by the MAP to locate the MN inside the MAP domain. It should be noted at this stage that HMIPv6 recommends that the MN selects the furthest MAP to avoid frequent MAP changes, which in turn implies going through the time consuming MAP registration procedure during the handover. Each time the MN moves to a new AR, it has to configure a new LCoA and registers it with the MAP. This is done by sending a Local Binding Update (LBU) message to the MAP. The LBU message allows the MAP to bind the new LCoA to the MN's RCoA. Haddad & Krishnan Expires October 3, 2005 [Page 7] Internet-Draft Optimizing Micromobility Management April 2005 5. Problem, Motivation and Requirements HMIPv6 protocol succeeds in eliminating redundant signaling messages in MIPv6, i.e., the HoTI/HoT and CoTI/CoT messages, while keeping only critical mobility messages, i.e., local binding update (LBU) and binding acknowledgement (BA) messages, exchanged between the MN and the MAP. However, HMIPv6 partially succeeds in reducing the handover latency since the LBU message sent from the MN to the MAP will most likely have to travel on a relatively long path within the domain before reaching the MAP (being supposedly static), in order to trigger a re- routing of the data packets flow to the MN's new LCoA (nLCoA). Such delay may result in packet loss, which becomes more alarming if the MN is moving at a high speed within the MAP domain while running time sensitive applications. This is mainly due to the fact that HMIPv6 recommends avoiding changing the MAP as much as possible. Consequently, HMIPv6 suggests choosing the furthest MAP in the hierarchical domain, which is in most cases the domain gateway node(s). In addition, HMIPv6 practically converts any network topology (i.e., mesh or random) to a tree topology, which if deployed alone, lacks both robustness and load balancing features. Based on that, HMIPv6 does not take any advantage from a mesh or random topology since all signaling messages are sent on the shortest uplink path to the root of the tree topology, i.e., the furthest MAP gateway. But it should be noted that HMIPv6 provides the lowest handover latency among other micromobility proposals (e.g., HAWAII and CIP) for the first handover only, i.e., when the MN enters into an HMIPv6 domain. But when the MN starts moving within the MAP domain then the handover performance start decreasing when compared to the two other proposals ([TOMOP], [MIPS]). Note that, although the mobility performance may increase in both CIP and HAWAII proposals, the CIP protocol continuously involves every node on the path between the gateway and the MN, and requires being implemented in the base station. On the other hand, the HAWAII proposal relies on sub-optimal routing path(s), which in turn can lead to an unoptimized load balancing in the access network. Haddad & Krishnan Expires October 3, 2005 [Page 8] Internet-Draft Optimizing Micromobility Management April 2005 Based on the above, the requirements for a new optimized micro- mobility protocol, which offer the main advantages of each of the above protocol, are: a. The load of signaling messages required during the handoff procedure should be minimized as much as possible. b. In order to minimize or eliminate the handoff latency and packet loss, the load of signaling messages should be concentrated only near the involved MN's new AR. c. As it is the case in HMIPv6, the handoff procedure should result at the end in a new optimal path between the MAP and the new MN's location. d. Any new node in the MAP domain which may be involved in the handoff procedure should be maintained in soft-state so that invalid bindings/keys are deleted automatically. e. All signaling Messages exchanged between routers and between routers and the MAP are authenticated. The above requirements led to the design of a simple proposal, which is totally built on top of HMIPv6 and increases the performance of IP handovers, which occur within an HMIPv6 domain. In addition, the OMM protocol takes full advantage from a mesh/random topology. Haddad & Krishnan Expires October 3, 2005 [Page 9] Internet-Draft Optimizing Micromobility Management April 2005 6. Overview of the OMM Protocol The OMM protocol aims to bring key advantages provided by some existing micromobility proposals, like CIP, HAWAII and HMIPv6, while minimizing/eliminating their different drawbacks. The OMM protocol fulfills requirements a), b) and c) by adding at most one message between the MN's nAR and one special node (i.e., VMAP) located nearby. Moreover, the OMM protocol allows the MN to skip the DAD or, in the worst case, to perform it in parallel with exchanging data. In short, the OMM protocol splits the IP handover into two successive events. The first one is a network handover (NH) and is triggered by the infrastructure itself (i.e., the MN's new AR). Note that the NH greatly benefits from a random network topology, i.e., it relies on sub-optimal routing of data packets (as in HAWAII) sent to the MN, in exchange for a shorter latency and minimum packets loss. The main goals behind triggering first a network handover are to reduce the latency and packet loss as much as possible. In other words, the NH aims to eliminate the latency variable from the second event, which is the handover triggered by the MN itself according to HMIPv6 protocol. For these purposes, the OMM protocol requires implementing a limited set of the MAP features on routers located between the MAP and the ARs, i.e., in order to convert them to VMAPs. Each time the MAP gets an LBU message from the MN, it sends a BA message, which is used also to store the MN's RCoA in the VMAP(s) located near the MN and on the path between the MAP and the MN. Note that these signaling data are stored in VMAP(s) in a soft state and must be removed immediatley after the expiration of the Binding Update Lifetime set by the MN in the LBU message. Each time, the network infrastructure triggers a NH, the VMAP simulates the MAP role for a limited period of time, i.e., until the second event is completed, thus significantly reducing the latency and packets loss. It becomes clear from the above that, in order to get the best performance from the NH, the selected VMAP must be located as close as possible to the MN's new AR (or within the nAR itself depending on the network topology). In the OMM protocol, the second event, i.e., handover triggered by the MN, aims only to re-direct data packets flow sent to the MN to a more optimal path. Such step is needed, especially that the first event, i.e., NH, may use a sub-optimal path to pull data packets flow to the MN's new LCoA. As described in HMIPv6, the second event Haddad & Krishnan Expires October 3, 2005 [Page 10] Internet-Draft Optimizing Micromobility Management April 2005 updates the MAP BCE with the new MN's LCoA in order to allow the MAP to tunnel data packets to the new MN's LCoA. Finally, it should be noted that the worst case scenario in OMM protocol is the failure of the NH, which means having only the handover triggered by the MN itself, as defined in HMIPv6. This lead us to the HMIPv6 case. Haddad & Krishnan Expires October 3, 2005 [Page 11] Internet-Draft Optimizing Micromobility Management April 2005 7. OMM Protocol Description As mentioned earlier, OMM protocol consists on implementing a limited set of MAP features (and one new feature) in routers located between the MAP and the ARs. A router with the added set of MAP features is called a virtual MAP (VMAP). A VMAP enabled router MUST provide the two following features: o Store the MN's IPv6 addresses (i.e., RCoA and LCoA) in its Virtual Binding Cache Entry (VBCE). This is performed upon receiving a BA message carrying a binding hop-by-hop message. o Check the ownership of the old MN's old LCoA (oLCoA), computes the new MN's LCoA (nLCoA) and tunnel data packets sent to the MN's nLCoA. This is performed upon receiving a Routing Path Update (RPU) message. The techniques proposed in this document work at their best when the following conditions are met: o The MAP domain has a random network topology. o Messages exchanged between routers (i.e., VMAPs and ARs), located within the same MAP domain are authenticated. o All routers located in the same MAP domain can be converted to VMAPs. This assumption applies also for the ARs. Note that this is not a required condition. If there are no VMAPs on the path between the nAR and the pLCoA the situation boils down to the base HMIPv6 case. However, it should be noted that adding links between ARs and converting some or all of them to VMAPs can bring additional performance to the OMM protocol and help avoiding updating all exiting VMAPs located between the MAP and the MN each time the MN switches to a new AR. HMIPv6 protocol requires the ARs to add the MAP functions data to their RtAdv messages sent to the MN. These information allow the MN to select the furthest MAP, auto-configure an RCoA and an LCoA and send them to the MAP in an LBU message. The two addresses enable the MAP to create the binding and to intercept data packets sent to the MN's RCoA and tunnel them to the MN's current location. When the MN enters for the first time to an HMIPv6 domain, it MUST follow the HMIPv6 protocol. The first new step introduced by the OMM protocol consists on alerting the MN of the support for the OMM protocol. This is done by setting the Optimization (O) bit (defined Haddad & Krishnan Expires October 3, 2005 [Page 12] Internet-Draft Optimizing Micromobility Management April 2005 in 8.10) in the RtAdv message sent by the AR. The second step starts when the MAP sends a BA message after receiving an LBU message from the MN. The MAP MUST insert in the BA message a new hop-by-hop option called "Virtual Binding" (VB). The VB must carry the MN's two IPv6 addresses sent to the MAP in the BU, the binding lifetime and the "Address Management Key" (Kam). Note that the Kam SHOULD be derived from hashing the shared secret established between the MN and the MAP so that the MN does not need to store a new Key. Finally, the MAP MUST authenticate the VB option with the Kam and MUST encrypt the Kam field with a shared key pre-computed between the MAP and the VMAPs. Upon receiving a BA message carrying a VB hop-by-hop option, the VMAP starts by checking if its VBCE has an entry corresponding to the MN's LCoA. If this is the case, the VMAP should update any existing value (e.g., binding lifetime) with the new one carried in the VB option. In case there is no entry, the VMAP MUST create one, which includes all data sent in the VB. The third step occurs when the MN switches to a new link. In such scenario, the MN starts by sending a RtSol message, which MUST contain its RCoA, its pLCoA and a proof of ownership of the two addresses. The proof is carried in a new option (i.e., "Address Check" (AC) option defined in Section 8.1) and is presented as the result of the following: Proof = First[64, HMAC(Kam, (RCoA | pLCoA)] The MN's addresses and the proof of ownership are carried in two different options defined in Section 8.1 and Section 8.2 The VMAP MUST delete from its VBCE all information related to one particular MN upon the expiration of the binding lifetime, unless another BA is sent by the MAP carrying a new binding lifetime (i.e., the MN has sent a new LBU message carrying the same LCoA to the MAP). The next step in the OMM protocol consists on triggering a network handover (NH). This is done by the MN's nAR upon receiving a RtSol message, which contains the two options. In such scenario, the AR SHOULD send in parallel a Route Path Update (RPU) message to the MN's pLCoA (carried by the RtSol message) and a RtAdv message to the MN. Note that the RPU message MUST be signed by the nAR. Haddad & Krishnan Expires October 3, 2005 [Page 13] Internet-Draft Optimizing Micromobility Management April 2005 When a VMAP receives an RPU message, it starts by checking its VBCE for an entry which contains the couple (RCoA, pLCoA). If an entry is found, the VMAP fisrct hecks whether the proof contained in the message is valid. If so, it computes the MN's nLCoA IID and updates its VBCE with the new MN's nLCoA. The same IID MUST be computed by the MN and in the same following way: nLCoA(IID) = First[64, HMAC(Kam, (RCoA | pLCoA | New_Subnet_Prefix)] After updating its VBCE, the VMAP starts tunnelling data packets sent by the MAP to the MN's pLCoA to its new location (i.e., nLCoA). The VMAP MUST delete the MN's correponding entry from its VBCE at the expiration of the routing binding lifetime (RBL) sent by the MN's nAR in the RPU message. Note that the RBL value may be predefined. After the MN gets a new LCoA, it MUST send an LBU message to the MAP. The LBU message updates the MAP's BCE, re-route the data traffic by using a more optimized route between the MAP and the MN and update the VMAP (i.e., via the BA message) on the new path between the MN and the MAP. It should be noted that many VMAPs may be updated by one specific BA message. However, the decision to turn on/off more than one VMAP on a particular path should be taken based on the network topology around that path. Haddad & Krishnan Expires October 3, 2005 [Page 14] Internet-Draft Optimizing Micromobility Management April 2005 8. OMM New Bits, Options and Messages Structure As it has been shown above, the OMM Protocol defines 4 new bits, 6 new options and introduces 1 new message. OMM defines new bit and options to be carried by the RtSol message. The new bit and options are the following: 8.1 The Address Check Information Option (ACIO) This option is used to carry the address check proof created by the mobile node. This option is used to verify whether the mobile node is really the owner of the addresses carried in the OMMIO option The format of the option is the following: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Proof | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length Length of the option. Option Data This contains the proof of ownership of the pLCoA and the RCoA 8.2 The Optimized Micro-Mobility Information Option (OMMIO) The Optimized Micro-Mobility Information Option (OMMIO) is a new option carried by the RtSol message sent by the MN upon receiving an RtAdv message from the AP. When used, the OMMIO MUST carry the MN's pLCoA and the RCoA. Haddad & Krishnan Expires October 3, 2005 [Page 15] Internet-Draft Optimizing Micromobility Management April 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . pLCoA . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . RCoA . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type Option Length Length of the option. Option Data This contains the pLCoA and the RCOA of the mobile node 8.3 The VMAP (V) Bit The VMAP bit is a new bit used in the OMM proposal to request VMAP node(s) located between the MAP and the MN's current location to store the MN's addresses (i.e., RCoA and LCoA) and the binding lifetime in their VBCE(s). The VMAP bit MUST be set by the MAP in the BA message each time the MAP receives a valid LBU message from the MN. Note that the MN MUST ignore such bit. Haddad & Krishnan Expires October 3, 2005 [Page 16] Internet-Draft Optimizing Micromobility Management April 2005 8.4 Modified Router Solicitation message format The modified Router Solication sent from a MN supporting this specification would look like this 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . ACIO . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . OMMIO . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address The Source Address MUST be the MN's nLCoA. Destination Address Typically the all-routers multicast address. Hop Limit 255 ICMP Fields: Type 133 Code 0 Checksum The ICMP checksum. See [ICMPv6]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Haddad & Krishnan Expires October 3, 2005 [Page 17] Internet-Draft Optimizing Micromobility Management April 2005 8.5 Modified Binding Acknowledgement message format When the binding acknowledgement message sent by the MAP it contains the VMAP (v) bit as described. The modified BA looks like this. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|V| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.6 The Routing Path Update (RPU) Message The Routing Path Update message sent from a nAR supporting this specification would look like this 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . ACIO . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . OMMIO . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address The Source Address MUST be one of nARs addresses. Destination Address The pLCoA of the MN. Haddad & Krishnan Expires October 3, 2005 [Page 18] Internet-Draft Optimizing Micromobility Management April 2005 ICMP Fields: Type Code 0 Checksum The ICMP checksum. See [ICMPv6]. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. ACIO The Address check information option as specified above OMMIO The OMM information option as specified above Haddad & Krishnan Expires October 3, 2005 [Page 19] Internet-Draft Optimizing Micromobility Management April 2005 9. Security Considerations The OMM protocol assumes that all signaling messages exchanged between routers (e.g., VMAPs) located within a MAP domain are authenticated. The OMM protocol does not introduce nor amplify any new or existing attacks or threats. However, it should be noted that triggering a network handover without providing a proof of ownership of the previous LCoA mentioned in the RtSol message sent by the MN to the nAR may allow to re-direct/steal data packets sent to another node attached to the MN's previous AR. Haddad & Krishnan Expires October 3, 2005 [Page 20] Internet-Draft Optimizing Micromobility Management April 2005 10. Normative References [EAR] J. Choi, D., Shin, "Fast Router Discovery with RA Caching", draft-jinchoi-dna-frd-00, July 2004. [ICMPv6] A. Conta, S. Deering, M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", draft-ietf-ipngwg-icmp-v3-06, November 2004. [HMIPv6] H. Soliman, K. elMalki, C. Castelluccia, L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-04, December 2004. [MIP6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [NDIS] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor Discovery for IP Version 6 (IPv6)", draft-ietf-ipv6-2461bis-01, October 2004. [SEND] J. Arkko, J. Kempf, B. Sommerfield, B. Zill, P. Nikander, Secure Neighbor Discovery (SEND), draft-ietf-send-ndopt-06, July, 2004. [TERM] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Haddad & Krishnan Expires October 3, 2005 [Page 21] Internet-Draft Optimizing Micromobility Management April 2005 11. Informative References [CIP] A. Valko, "Cellular IP: A New Approach to Internet Host Mobility", ACM Computer Communication Review, January 1999. [HAWAII] R. Ramjee, K. Varadhan, L. Salgarelli, S. Thuel, S.Y. Wang, T. La Porta, "HAWAII: A Domain-based Approach for Supporting Mobility in Wide-Area Wireless Networks," IEEE/ACM Transactions on Networking, , Vol 10, No. 3, June, 2002. [TOMOP] L. Peters, I. Moerman, B. Dhoedt, P. Demeester, "Influence of the Topology on the Performance of Micromobility Protocols", Proceedings of WiOpt'03, March 2003, Sophia Antipolis, France. [MIPS] D. Saha, A. Mukherjee, I. Misra, M. Chakraborty, N. Subhash, "Mobility Support in IP: A Survey of Related Protocols", IEEE Network, Vol. 18 No. 6, November 2004. 12. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. Authors' Addresses Wassim Haddad Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Email: wassim.haddad@ericsson.com Haddad & Krishnan Expires October 3, 2005 [Page 22] Internet-Draft Optimizing Micromobility Management April 2005 Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Email: suresh.krishnan@ericsson.com Haddad & Krishnan Expires October 3, 2005 [Page 23] Internet-Draft Optimizing Micromobility Management April 2005 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 (2005). 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. Haddad & Krishnan Expires October 3, 2005 [Page 24]