Mobile-IP Working Group Greg Daley INTERNET-DRAFT Monash University CTIE Expires: December 2003 JinHyoeck Choi Samsung AIT May 2003 Movement Detection Optimization in Mobile IPv6 draft-daley-mobileip-movedetect-01.txt Status of this Memo 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Definitions of requirements keywords are in accordance with the IETF Best Current Practice - [RFC-2119] Abstract This draft describes the state of the art techniques in movement detection and elaborates on their application to Mobile IPv6 networks. The aim of the draft is to describe the applicability of each mechanism and stimulate discussion on such techniques. Table of Contents Status of this Memo.......................................... 1 Abstract..................................................... 1 Table of Contents............................................ 1 Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 1] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 1.0 Introduction............................................. 2 2.0 Movement Detection Overview.............................. 3 2.1 Handoff Process.......................................... 3 2.2 Movement Detection Mechanism............................. 4 2.3 Movement Detection Performance with Neighbor Discovery... 7 3.0 Movement Detection Schemes............................... 8 3.1 Periodic Router Advertisement Beaconing.................. 8 3.2 RA caching in Link-layer Access Points................... 9 3.3 Solicitation on Interval Timeout......................... 9 3.4 Link-up Triggers on the Mobile Node...................... 10 3.5 Fast Router Advertisement ............................... 11 4.0 Performance Considerations............................... 12 4.1 Effects of Solicitation Delays........................... 12 4.2 Performance Comparisons.................................. 13 4.3 Avoiding NUD without eager binding....................... 14 4.4 Effects of Packet Loss................................... 14 5.0 Combining Movement Detection Optimizations............... 15 6.0 Predictive Handover Effects.............................. 15 7.0 IANA Considerations...................................... 16 8.0 Security Considerations.................................. 16 Normative References......................................... 17 Non-Normative References..................................... 18 Acknowledgements............................................. 18 Authors' Address............................................. 18 Appendix..................................................... Changes Since Last Revision.................................. 1.0 Introduction Seamless handoff systems aim at reducing the disruption caused by moving between IP networks. Movement Detection is a prerequisite task necessary for a Mobile IPv6 (MIPv6) Mobile Node (MN) to perform handover signaling[MIPv6-20]. As defined in the base MIPv6 specification, detection of movement is accomplished through reception of Router Advertisements (RAs), and comparison of these messages with previously received router information. Other handover operations, such as Duplicate Address Detection(DAD) and movement binding signaling occur subsequently to movement detection. Since Movement Detection is a the first operation to occur in a non-predicted handover, Movement detection optimizations aim at reducing the time before the RA is received by the MN. This reduction of movement detection time reduces handover duration. The MN inspects RA messages to determine if a router on that interface is providing routing information which supercedes or invalidates a current Care-of-Address (CoA). The CoA may be Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 2] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 invalidated because a router retracts a prefix (valid lifetime=0), timers expire which deprecate the existing CoA and Router entries or a heuristic is in place assumes movement if an RA is received with a new prefix, from a new router. In MIPv6, detection of movement causes configuration or selection of new Care of Addresses, and binding signaling is commenced. 2.0 The Current Status of Movement Detection Movement detection is one of a series of stages in accomplishing MIPv6 handover. The section below indicates the steps required for handovers to occur. 2.1. Handoff Process When an active MN moves to a new IP subnet, it changes its point of attachment to the network through the following handoff process. First Link-layer handoff occurs to change the wireless AP to which MN is associated. After a new Link-layer connection is established, Network-layer handoff is performed, which broadly involves movement detection, IP address configuration and location update. Initially, the MN's IP protocol implementation may be unaware of the link change, or may have been informed of the arrival by a link- trigger. Alternatively, the network itself may be aware of the MN's movement and may make use of this information to aid movement detection. The MN then checks the reachability of current AR. If the MN determines the AR is no longer reachable, the MN performs Router Discovery with new AR and subsequently a Router Advertisement with all options arrives from a new AR. Once the MN discovers a new AR with necessary informations, stateless or stateful address configuration including DAD is performed[RFC-2462]. This entails waiting for address validation to complete, before further packets may be sent or received by the MN. Mobility signaling procedures are then started, with the MN sending a Binding Update (BU) to its Home Agent. Additionally Return Routability (RR) procedures are started for route optimized conversations with Correspondent Nodes (CNs). As the Return Routability tests are completed, further BU messages are sent to CNs. Since Movement Detection is prerequisite for other network-layer handoff operations, for seamless handoff, it is necessary to detect movement as fast as possible given the underlying link technology. Proposals for predictive handovers change these assumptions and Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 3] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 ordering. The role played by movement detection in predictive handovers is defined in section 6.0. 2.2. Movement Detection Overview The primary movement detection mechanism for Mobile IPv6 defined in [MIPv6-20] uses the facilities of IPv6 Neighbor Discovery, including Router Discovery (RD) and Neighbor Unreachability Detection (NUD). In Movement Detection, an MN should check the (partial) reachability of the current AR and the validity of the current CoA. This allows the MN to distinguish between link-layer and network-layer handovers. In case of IP subnet change, an MN should also discover a new AR with necessary information, including on-link prefix to form a new CoA. In brief, the Movement Detection process is as follows: First there is some hint that MN may have moved to another subnet. This hint itself doesn't confirm movement. Then the MN probes the current AR to check its reachability and the validity of the current CoA. If it turns out that MN has actually moved, it searches for a new AR with Router Discovery. After an RA from a new AR arrives with necessary information, the MN performs further operations, forming a CoA and sending Binding Updates. There are 3 entities which may change in connection with MN movement, Access Point (Link-layer connection), Access Router and On-link Prefixes (IP Subnet). These changes are indicated to MN with the following: 1) Link-layer trigger (Some information from lower layer which notifies link change) 2) a new IP address (in source address field of RA) 3) a new Subnet Prefix (in Prefix Information Option in RA) To get the above indications, MN can perform NS/NA exchange, RS/RA exchange or just receive unsolicited RAs. The source address of the RA is a Link-Local address, its uniqueness is not guaranteed outside a link. Hence the fact that MN receives Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 4] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 the RA with the same address doesn't guarantee that it comes from current AR. ARs may omit a Prefix Information Option for efficiency. Hence the lack of the prefix of the current CoA in RA doesn't mean that current CoA is not valid. The above defects may results in the problem like this. Assume MN moves from AR1 to AR2. If AR1 and AR2 have the same link-local address, the MN may not detect its movement even after several RAs. The entities may change together or separately. Therfore any indications can't represent subnet movement precisely by itself. ------- ------- | AR1 | | AR2 | ------- ------- C::3 | |D::4 | | |AP1 | /-------------\ | / \ |AP2 / /-------\-------\ \ / \ \ \ / / \ Cell 1 \ \ / ------ \ Coverage \-----\-------/ | MN | / \ ------ / Cell 2 \---------------/ Coverage Figure 1. MN moving between two networks For example, in Figure 1, MN moves from AP1 to AP2 and all three entities change. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 5] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 ------- ------- | AR1 | | AR2 | ------- ------- A::1 | | A::2 |-----------------| | | /-------------\ | / \ | / /-------\-------\ \ / \ \ \ / / \ Cell 1 \ \ / ------ \ Coverage \-----\-------/ | MN | / \ ------ / Cell 2 \---------------/ Coverage Figure 2. MN sees two access routers on the same subnet In Figure 2, AR1 and AR2 are routers on the link. Each advertise a prefix A:: to hosts. When the MN moves from AP1 to AP2, it changes AP and AR but remains in same IP subnet. ------- ------- | AR1 | | AR2 | ------- ------- C::3 | | D::4 |-----------------| | /-------------\ / \ / \ \ ------ \ \ | MN | / Cell 1 \ ------ / Coverage \-------------/ Figure 3. Two Access routers on the same subnet In Figure 3, AR1 and AR2 are routers on the link which share a common AP. Each advertise a prefix C:: or D:: to hosts. Assume AR1 is MN's current default router. Then the arrival of a RA from AR2 doesn't mean MN has moved. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 6] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 ------- | AR1 | ------- C::3 | |-----------------| | | /-------------\ | / \ | / /-------\-------\ \ / ------ \ \ \ / | MN | / \ Cell 1 \ \ ------ / \ Coverage \-----\-------/ / \ / Cell 2 \---------------/ Coverage Figure 4. MN moves between wireless links in the same subnet In Figure 4, If MN moves AP1 to AP2, it still remains at same IP subnet even though it receives link-layer change notification from lower layer. An MN's Movement Detection scheme should combine available information to detect movement correctly. It should not mistake some hint as movement while the MN hasn't moved. That may result in continual handoff, and hence excessive mobility signaling. If the MN moves, it needs to detect movement sufficiently fast so that it can complete handover signaling without significantly degrading application performance. On the other hand, if the MN doesn't move though it receives some hints (like Figure 3,4), it is not imperative to detect its non- movement so fast. It will not degrade performance even if MN can't quickly confirm that it still remains at the same subnet. A movement detection scheme should not result in excessive signaling traffic. It should not flood the network with unnecessary RS/RA or NS/NA messages. 2.3. Movement Detection Mechanism Movement Detection Mechanism consists of following steps. Step 1. Hint Step 2. Checking the reachability of the current AR Step 3. Checking the validity of the current CoA Step 4. Discovering new AR with necessary information. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 7] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 2.3.1 Receiving Movement Hints There is a set of hints which can indicate that Network-layer movement has occurred. The hints can be Link-layer trigger, the receipt of a new RA or the lack of RA from current AR. This hint itself doesn't confirm L3 movement. 2.3.2 Checking the reachability of the current AR An MN checks whether current AR is still reachable by probing. The MN may probe with NS or RS. In case of NS probing similar to NUD, an MN sends unicast NS messages to the current AR. If the current AR replies with a NA, the MN can be sure that it is still reachable. If an NA doesn't arrive after 1 sec, the MN resends the NS. After 3 probe attempts, the MN decides that the AR is no longer reachable. If an MN actually has moved to new IP subnet, it will take 3 seconds to detect that the current AR is not reachable (sending 3 NS probes, plus waiting 1 second for each). With NUD, we can detect a node's presence very quickly. Conversely, it takes substantial time (3 Sec) to detect that node is NOT there. In order to reduce the time taken to detect a router's non-presence, the MN may use a timeout. Instead of retransmitting, the MN just sends one NS, and waits for a reply for fixed time. If the MN times out before receiving a reply, it assumes that it has moved. Attempts at avoiding the cost of NUD without resorting to eager bindings or NS/NA heuristics are discussed in section 4.3. 2.3.3. Checking the validity of the current CoA When the NS/NA exchange is for the AR's link-local address, the MN can't be sure that it still remains at the same IP subnet since link- local scoped addresses uniqueness is only guaranteed on the link. The MN may have moved to a new AR which happens to have the same link-local address as the current AR. Hence MN also has to confirm the validity of the current CoA by checking on-link prefixes. The MN sends a unicast RA to current AR. When a solicited RA with all options arrives, the MN checks whether Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 8] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 it contains the prefix of current CoA in any of its Prefix Information Options. As an alternative solution, the MN may send the NS to a globally unique router address, if it is carried in a MIPv6 modified Prefix Information Option advertised by the current router. An NA response from this router address can uniquely provide reachability confirmation for the router, since only the current router may have this address. 2.3.4. Discovering a new AR If it turns out that MN has actually moved, it has to find a new AR using Router Discovery[RFC-2461]. The MN sends a Router Solicitation to the All-routers multicast address. When a solicited RA with all options arrives, the MN selects a new AR, forms a new CoA and perform further operations. We can perform Movement Detection Steps 2,3,4, with only one RS/RA exchange as illustrated below. To check the reachability of current AR, instead of using NS, the MN sends an RS to the All-Routers multicast address. If current AR is still reachable, MN will receive an RA with all options within roughly 1.5 Sec (1 Sec random RS delay and 0.5 sec random RA delay). Since RA messages do not explicitly indicate if they are solicited, we can't say that the current AR is reachable if we receive an RA. We can say though, if we don't receive a RA in time, it's highly probable that the current AR is not reachable. If a solicited RA with all options arrives from current AR, the MN can confirm that current AR can still reach MN and current CoA is still valid. If no RA arrives from the current AR, but the MN receives several RAs from new ARs, the MN chooses a new default AR. Though the MN can't confirm reachability of the new AR, if its RA contains a Source Link-Layer Address option, the MN will gain a stale Neighbor Cache entry for the router. This means the MN can start sending packets. Moreover the solicited RA from the new AR contains all the necessary information for IP configuration. Hence the MN can perform further operations immediately without additional signaling messages or delay. After the handoff process is completed, the MN Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 9] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 can perform NUD with the new AR to confirm the reachability at its leisure. Below is a comparison of the comparitive merits of RS/RA and NS/NA probing The benefits and drawbacks of NS/NA probing are: 1) Since there is no Random Delay, MN and AR can send NS and NA immediately. 2) The solicited flag confirms bi-directional reachability. 3) The MN needs to perform at least one RS/RA exchange afterwards. (Unless a globally unique router address is probed). The benefits and drawbacks of RS/RA probing are: 1) With only one RS/RA exchange, MN can check the (partial) reachability of a current AR, validity of current CoA and receive all the necessary information from a new AR. 2) There are two random delays of up to 1 Sec for RS and 0.5 Sec for RA. Hence it take more time to RS/RA exchange with RA timouts being set appropriately. This may be solved with FastRA (Section 3.5). 3) It may cause excessive multicast RA traffic. 4) MN can't confirm reachability of AR. We may shorten the time taken to detect movement by performing multiple operations in parallel. For example, by sending NS to current AR and RS to all-routers multicast address at the same time, we can perform Step 2, 3, 4 simultaneously. If there are many wrong movement hints, this may cause excessive multicast traffic. There is still much to investigate about the necessary steps of Movement Detection, their order of performance order, efficient (NS and RS) probing mechanisms and the trade-off between Movement Detection time and signaling traffic. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 10] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 2.4. Movement Detection Performance with Neighbor Discovery Movement detection algorithms are based on Neighbor and Router Discovery mechanisms[RFC-2461]. Neighbor Discovery allows solicitation of NA in order to confirm reachability. Router Discovery allows the periodic multicast of RAs to nodes on a (fixed) IPv6 network. [RFC-2461] additionally allows solicitation of RAs in order to confirm network identity, or speed device configuration. Neighbor Discovery protocol constants were sized for networks of many nodes, where it was sufficient to provide configuration within a few seconds. This has caused significant delays to be built into Neighbor and Router Discovery[RFC-2461]. Networks supporting MIPv6 MNs need to be able to check (partial) reachability and receive RAs in shorter time intervals than are available for standard Neighbor Discovery. This is important if Mobile Nodes have existing higher- layer sessions when Movement Detection is performed, which may be affected by slow handover times. Movement detection performance is measured from the time when the new Link-layer connection is established until Movement Detection is completed through suitable RA reception from new AR. At first MN receives a hint that it may have moved. The time taken to receive for this hint varies. With Link-layer trigger support, it can be done instantly. Alternatively an MN can monitor periodic RA beacons. The base MIPv6 document uses RA Interval Timer expiry as a hint. An MN may implement its own policy to determining the number of missing RAs which it will interprets as hint for possible movement. With payload traffic tracking, we may get a hint earlier. An MN may implement its own policy to determining the interval of idle time with no traffic which it will interprets as a hint for possible movement. Care should be taken in this case to ensure that spurious hints do not cause unnecessary probing of the network. Without schemes such as those above to provide hints, the MN must wait to receive an RA from a new AR before undertaking Movement Detection. Hence the detection delay depends on the frequency of Router Advertisements. Periodic RA beaconing transmits packets within an interval varying randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. In [RFC-2461] minimums for these values are 3 and 4 seconds, respectively. Since MN movement is unrelated to the advertisement Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 11] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 time on the new network, the MN is expected to arrive on average half way through the interval. This is about 1.75 seconds with [RFC-2461] advertisement rates. Worst case performance (without packet loss) is when the MN arrives just after an RA, and the next RA is scheduled close to MaxRtrAdvInterval. If [MIPv6-20] advertisement intervals are in use, these values drop to 0.025 and 0.70 seconds respectively. Next the MN probes the current AR to check its reachability and CoA validity. There is no single agreed way mandated for this. For example, assume the MN uses NS probing. If the MN probes with NS using NUD-like retries, the AR's unreachability will be detected after 3 sec for the case when the MN actually has moved. If the MN uses one NS and a timeout, the duration depends on the timeout value. We may set timeout value as 2 * RTT time from MN to AR. There is no consensus on timeout values yet and the RTT time in wireless environment may be highly volatile. Afterwards, an MN should perform one RS/RA exchange, whether the current AR is reachable or not. This is subject to routers delaying 0-500 ms before responding to the RS, and the advice that the MN delays 0-1000 ms before sending an RS [RFC-2461]. Additionally, if there is no verified link-address available for Router Solicitation, the router must respond with a multicast RA. Movement detection optimizations seek to lower the time taken to perform Neighbor and Router Discovery, either through MN solicitation, or timely unsolicited advertisement of router information. To achieve this aim, modifications to NUD and Router Discovery are made on mobile-supporting networks and MNs. 3.0 Movement Detection Schemes 3.1 Periodic Router Advertisement Beaconing Beaconing is a term used to refer to multicasting of network identification information at regular intervals. Mobile IPv6 reduces the lower bound of the MinRtrAdvInterval and MaxRtrAdvIntervals to 30 and 70 ms respectively[MIPv6-20]. With these settings, beacons will be sent no more closely than 30 ms apart, and with no greater separation than 70ms. Routers are required to send the beacons at random times within this interval. This means that an MN will receive an RA within 70ms of arriving on the link, and may expect to receive an RA within 25ms, if we assume MN entry into the network to be randomly distributed in the interval. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 12] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 This technique requires no action on the part of the MN other than listening to RA multicasts. The bandwidth consumption by multicast beacons is 14 kbps when RAs only include one Prefix Information option. Addition of a Source-Link-layer-Address option and a MIPv6 Advertisement Interval option typically increase this to 16.6 kbps. On some networks, such overhead (~20 multicast packets per second) causes a serious burden on network bandwidth. In these cases, [RFC-2461] specified intervals SHOULD be used, if other movement detection mechanisms are available. Additionally, the reduced interval between messages may have side effects for non-MIPv6 nodes on the same networks. The AdvDefaultLifetime value is used to set the lifetime of the default router in seconds, as advertised in the Router Lifetime field of the RA. The minimum value specified in [RFC-2461] for this value is MaxRtrAdvInterval. This value is less than one second when using MIPv6 specified advertisement intervals. Even if default router lifetimes are rounded up to the nearest second, nodes which assume MaxRtrAdvInterval is at [RFC-2461] values could be confused about the lifetime of their default router. Routers SHOULD ensure that AdvDefaultLifetime is greater than or equal to 4 seconds, in order to avoid this confusion. 3.2 RA caching in Link-layer Access Points (Fast Router Discovery [FRD-00]) One method which requires no solicitation from the MN is network triggering of RA. Router advertisements are sent to the MN when it attaches to an access point (AP) associated with this network. In network deployments, the router may not be the link-layer device which the MN connects to, and therefore may be unaware of MN link- connection. Only in the case where the the AP advises the router of connection or AAA state, can the router send (unscheduled) unsolicited RAs before receiving packets from the MN. The Fast Router Discovery (FRD) draft[FRD-00] places the responsibility of sending triggered RA messages upon APs. The Access Points cache RA's recently sent from the router, and deliver a frame to the MN when it connects. This frame is datalink-unicast to the MN and contains the most recent unsolicited RA. In this case, less frequent transmission of unsolicited multicast RA messages may be used. At the same time, the first frame which is queued for the MN is the RA required for movement detection. Deployment of FRD requires each of the APs for the network to be Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 13] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 capable of both the caching and triggered sending operations. Analysis and experimental results indicate that this is potentially the fastest network-layer based movement detection optimization, dependent on AP processing capacity. 3.3 Solicitation on Interval Timeout As specified in MIPv6, the Advertisement Interval Option describes the maximum time between unsolicited RA messages (MaxRtrAdvInterval). This option is used in movement detection as a packet loss management system, where after elapse of one or more Advertisement Intervals without RA reception, the MN can send a router solicitation. In the case where MNs send RSs after the loss of multicast RA messages, all MN's which have not received the RAs will time out at the same instant. [RFC-2461] specifies an additional delay of 0-1000 ms required for the purposes of desynchronizing RS messages sent from many hosts. An MN which does not have other confirmation that it has moved SHOULD follow this policy. Further details of this issue, especially with regard to simultaneous movement, are presented in section 4.1. In the case where the MN moves by itself, this algorithm provides best performance when the MN connects to a new network just before an interval passes. If the MN is acting upon one packet's loss then this provides an RS immediately. If the timer elapses when there is no connection to a link, it is implementation dependent whether the RS packet is lost. Typically though, the MN will leave the previous access network on average half way through the mean RA interval. The expected time left until the Advertisement Interval elapses upon the MN leaving the network is: ExpIval = 0.75*MaxRtrAdvInterval - 0.25*MinRtrAdvInterval This does not account for the link-layer handover time, which may be tens or hundreds of milliseconds. When these values are the minimums described by [RFC-2461], this value is 2.25 seconds and therefore does not seem to provide significant benefit unless faster (MIPv6) beacons are being sent. At the MN specified beacon rate, the expected residual interval is 45 ms. Any of the methods which require responses to Router Solicitations as specified by [RFC-2461] also incur an additional delay of between 0 and 500 ms before a response is sent by the router. Section 3.5 describes a mechanism to cope with this issue. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 14] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 3.4 Link-up Triggers on the Mobile Node For situations where RA packets have been transmitted correctly, the Advertisement Interval's best case occurs when the timeout occurs just after the MN joins a new link. In environments where the MN can receive an indication a link has been joined, this information can be used to trigger an RS immediately[MIPv6-20], although once again a random delay before sending RS's is advised by [RFC-2461]. Additionally, even if the MN doesn't send an RS upon receiving a link-up trigger, it can use the trigger to validate received RA messages for movement detection with eager-binding. The MN may be able to enter an 'eager-binding' state until it receives its first RA on the new link. If it receives an RA from a previously unseen router at this time, it may be useful to confirm bidirectional reachability with this outer, and then undertake movement signaling. Upon entering a new subnet, there is a small chance that the MN will have a duplicate address collision with another device's Link-Local address[RFC-2462]. When an MN solicits an RA, it typically sends from the Link-Local address, unless this address is tentative[RFC-2461]. If the MN sends from the Link-Local address, unicast responses are allowed, and in this case, rate limiting of multicast RA messages is avoided. If the MN joins a link, then until it knows the identity of the link (has received an RA), it MUST assume that it is on a new link, where its Link-Local address is tentative. This means that RS messages will either be deferred until DAD operations have been performed on the Link-Local address or the RS MUST be sent with an unspecified address. A multicast response will be scheduled no sooner than: Max(LastMcastRATime + MinDelayBetweenRAs, now + 0-500 ms RS Response Delay) Where MinDelayBetweenRAs could be as high as 3 seconds. Even if the response is not multicast, the RS response delay is still incurred. 3.5 Fast Router Advertisement [FASTRA-02] Fast Router Advertisement (FastRA) removes the random delay required of a router before it responds to RS messages. It relies upon only one router on a subnet being configured for FastRA, so that responses are not simultaneous. FastRA principally aims at delivery of unicast RA messages, since the rate limiting of multicast RA messages specified in [RFC-2461] specifies that RA messages may not be sent within 3 seconds of each other. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 15] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 Similar action could be performed with multicast RA responses if FastRA adopted the MinDelayBetweenRAs as in [MIPv6-20]. In this case, the response would only be delayed if the last multicast RA occurred more recently than MinDelayBetweenRAs ago (or MaxFastRAs has been consumed). This could work well if the arrival of mobile nodes occurred much less frequently than the unsolicited multicast RA interval. FastRA incorporates a rate limiting feature aimed at diminishing the potential effect of FastRA traffic on nodes which are already connected to the network. Routers may transmit no more than MaxFastRAs advertisements in an interval before discarding solicitations until the next unsolicited multicast RA. Either of the solicitation mechanisms may be used to get FastRA response from a router, although Advertisement Interval timeout will only be invoked on packet loss if Link-triggers are available. Movement detections times are bounded only by the time to send the Multicast RS message and send the unicast RA response. Recent testing has indicated 95% of RAs were received within 15 ms of sending an RS on 802.11b networks, when Neighbor Discovery was being performed on the MN's Link-Local address. If RS messages include Source link-layer Address options[RFC-2461] or are multicast responses with no timer delays, movement detection time will be lower. 4.0 Performance Considerations 4.1 Effects of Solicitation Delays [RFC-2461] specifies that a node SHOULD delay a random interval of between 0 and 1000 (MAX_RTR_SOLICITATION_DELAY) ms before sending an RS if it is the first packet the node sends on the link [RFC-2461]. A similar delay is stipulated for DAD packets in [RFC-2462], for the same circumstances. These delays are provided for the case where many devices are configuring on the link at the same time. In a mobility environment, this may occur if many MNs are traveling together, for example on a train, or at peak hours on a freeway. For this environment, there is some possibility that the MNs' simultaneous transmission of multicast RS or DAD packets will will cause interference or backoff and retransmission. The effect of such simultaneous movement and subsequent multicast transmission is the topic of current research. On several wireless Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 16] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 technologies, the effect is thought to be minimal, especially where discrete codes or data channels are provided to each subscriber. There are certainly other environments where many devices simultaneously transmitting have a detrimental effect though, and in these cases, the configuration by MNs SHOULD be serialized. The serialization provided by a random timer is one mechanism by which simultaneous transmission may be avoided. Other methods, are reliant upon serializing effects in the link-layer, such as AAA operations. These effects are link-dependent and where they provide protection, MNs SHOULD take advantage of them to avoid random timer delays. It should be noted that multicast bombing may occur even in when no RS is performed, if many nodes simultaneously receive an RA beacon from a new router. These MNs' first operation is to undertake DAD procedures. Link procedures are unlikely to provide serialization in this case, since all MNs will receive the multicast at approximately the same time. In any case, the MN SHOULD undertake the RFC-2461 and RFC-2462 prescribed delays if any of the following is true: * The MN has no upper-layer sessions * The MN has no sessions which have sent or received data within UPPER_LAYER_ACTIVITY seconds. The value of UPPER_LAYER_ACTIVITY is implementation specific, but defaults to 120 seconds. * The MN has more highly preferred interfaces which have the currently bound CoAs configured for all current sessions. Also, these CoAs are known to be successfully receiving and sending data. This limits the effect of link contention to active devices requiring an expedited handover service. 4.2 Performance Comparisons A table is provided which indicates the relative performance of several movement detection schemes. These handovers do not include delays due to DAD for unicast responses, nor do they include RS/DAD delays to avoid multicast link bombing. Additionally, the cost of determining reachability with the current AR is ignored. Presented times are on a wireless link of ~2 Mbps, which is capable Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 17] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 of multicast at 1 Mbps. |--------------------------------------------------------------| | | Uni/Multicast| overhead | Move Detection Time (ms) | | | Advertisement| (kbps) | Avg | Max | |--------------------------------------------------------------| |Beacon | Multicast | >14 | 25 | 70 | | | | | | | |--------------------------------------------------------------| |FRD | Multicast L3 | <1 | <10 | <20 | | | (unicast L2?)| | | | |--------------------------------------------------------------| |Timer(a) | Unicast | <1 |ExpIval|MaxRtrAdvInterval | | | | | +250 | +500 | |--------------------------------------------------------------| |LinkRS | Multicast | <1 | 250 | 530 | |tentative| | | | | |--------------------------------------------------------------| |LinkRS | Unicast | <1 | 250 | 500 | |unicast | | | | | |--------------------------------------------------------------| |FastRA | Multicast | <1 | <10 | 60 | |tentative| | | | | |--------------------------------------------------------------| |FastRA | Unicast | <1 | <10 | <30 | |unicast | | | | | |--------------------------------------------------------------| Notes: (a) These duration values include link-layer handover time, where no other row does. 4.3 Avoiding NUD without eager binding The cost of performing NUD to the current AR in order to check whether movement has occurred is expensive in the case that it has. Proposals to avoid using NUD with the current access router have been made in the mobile-ip working group. One set of proposals which rely upon information in received router advertisements to guarantee that a previously configured router is uncontactable. It is also possible to make use of link-layer information which indicates a network domain change. Link-layer triggers pass information to the network-layer which either explicitly provide movement detection[WLANPIO-00], or disambiguate subsequently received RA information. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 18] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 Further reference will be made to drafts elaborating on these ideas as they become available. 4.4 Effects of Packet Loss Packet loss from (network and MN) triggered systems can be a significant factor MIPv6 handovers performance. When a quickly delivered RA message is lost, then the MN may wait until the next unsolicited multicast RA message, which can take up to four seconds (RFC-2461 MaxRtrAdvInterval). In MN triggered systems, if RS messages are lost and have to be resent, movement detection times are increased by up to four seconds. This timeout is governed by the value of the Neighbor Discovery constant RTR_SOLICITATION_INTERVAL. In solicited RA environments, the exchange of RS/RA messages is susceptible to loss of either packet, as is the case with NS/NA if the router needs to perform Neighbor Discovery on the MN before sending a unicast RA response. Beacon systems which transmit RAs at high rate are less susceptible to the adverse affects of packet loss, since replacement packets are transmitted quickly after the packet loss event. Backup effects from Advertisement Interval timers may play a part in the solicitation of replacement RA messages, although unless link- layer handover times are considered, these provide worse performance than beacon based systems. 5.0 Combining Movement Detection Optimizations When arriving on a network, an MN is unaware which movement detection optimizations are in place on the network, or whether any are in use. The MN may therefore choose to send an RS before it receives an unsolicited RA, even though either FRD or RA beaconing are in place. In all likelihood, both RA delivery mechanisms will be activated. In this case, the movement detection time will typically not be affected, except that more packets will be sent to the wireless medium. Therefore, if an MN has received a link-trigger, and the MN subsequently receives an RA before it has scheduled an RS packet to be sent, the MN SHOULD NOT send the RS. In most cases without packet loss, the presence of fast beacons will not significantly affect the performance of FastRA or FRD systems. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 19] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 As mentioned in section 4.4 though, the harm caused by packet loss is significantly lowered if beacons are received within a short period. If the overhead of running beaconing systems is sufficiently low for the wireless link type, then beacons MAY be used with either of FRD and FastRA. Networks with either of FRD or FastRA capability are unlikely to also use the other technology on their systems, since FRD and FastRA are closely matched in performance and have low latency times. If the network has both capabilities, there is some chance that RA messages from AP and Router attempt to be delivered simultaneously to the MN. Since there is no way for the MN to know that FRD is in use when soliciting, it MAY send an RS in any case, if it has not received an RA already from this link. 6.0 Predictive Handover Effects Movement detection optimizations' applicability is principally in non-predictive movement environments, although there may be some benefit for anticipated/fast handover systems as movement confirmation and correction mechanisms. Handover prediction allows MNs to select the network to which they move, and perform handover signaling in anticipation of this event. This allows the tunneling and buffering of MN traffic within network routers while the link-layer handover is occurring. With some link environments, it may not be possible to guarantee that the MN will arrive on the selected link, nor that the MN has indeed arrived on that link. In these cases, it is still necessary to confirm that the MN is arrived on the link through movement detection algorithms. This allows the MN to send corrective binding signaling in the case that the network is a different one than was the anticipated destination. 7.0 IANA Considerations No new message formats or services are defined in this document. 8.0 Security Considerations Movement detection optimizations are reliant upon reception of a Router Advertisement with properly configured Prefix Information Options [RFC-2461]. Since Movement Detection is based on Neighbor Discovery, its trust Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 20] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 models and threats are similar to the ones presented in [SEND- psreq-01]. The attacks described in 4.0 of [SEND-psreq-01] can be applied to Movement Detection too. Movement Detection schemes SHOULD incorporate the solutions developed in IETF SEND Working Group if available, where threat assessment indicates such procedures are required. Moreover the threats described in 4.2 of [SEND-psreq-01] may cause more serious problems. When there is an indication that the current IP connection has changed (Link down, New Router Advertisement et cetera), non-mobile nodes will first perform NUD[RFC-2461]. The MIPv6 handoff process (including Movement Detection) is time sensitive. So mobile nodes may start an eager handoff without Neighbor Unreachability Detection. If higher layer notification of connectivity is not available, and eager handoff strategies are in place, any node or router which advertises an RA with a false prefix will cause MNs to perform spurious handover signaling and DAD operations. For non-mobile case, if a node receives a bogus RA which doesn't include the prefix of its current address, it doesn't assume that its current prefix becomes off-link. In Neighbor Discovery, the only way to cancel a previous on-link indication is to advertise that prefix with the L-bit set and the Lifetime set to zero [RFC-2461]. Hence the node keeps using the current address and not so much harm is done. In the mobile case, the threat is more serious. Assume an attacker sends an RA which includes only false Prefix Information Options. If a MN receives a bogus RA which doesn't include the prefix of the current CoA, it will assume that movement has occurred. The MN will start DAD (with the bogus prefix) and send BUs (with a false CoA). Hence MN will be disconnected, or its packets will be intercepted and subject to man-in-the-middle attack[SEND-psreq-01]. Moreover if we configure MNs to send RS and DAD without delay, this bogus RA attack may cause multicast bombing too. An attacker can send a bogus RA without source link-layer Address option. Then all MNs will receive the bogus RA at the same time and start Neighbor Discovery simultaneously. They will send RS without delay at the same time and cause RS congestion. An attacker can deceive all MNs to believe they have moved simultaneously by sending a suitable bogus RA. In this case, DAD would be performed by all nodes on the link immediately on multicast RA reception. The security issues described above are not specific to any Movement Detection scheme presented in this draft but are inherent in any mechanism which uses only Router Discovery for movement detection. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 21] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 Information from lower layers will be useful to mitigate the above threats. Assume there is an MN for which link-layer trigger is provided to notify link-layer change. If the link-layer trigger precedes a new RA, it is likely that the RA is valid and the MN has actually moved. When the MN moves to a new IP subnet, link-layer change usually precede movement. So first link-layer change is notified to the MN and it anticipates movement. Hence when a new RA arrives, the MN can reasonably believe it. On the other hand, if the MN receives a new RA without the notification of link layer change, it is likely that the RA is bogus. In this case, the MN SHOULD be suspicious: Before initiating the handoff process, it SHOULD perform Neighbor Unreachability Detection to request a RA from its default router. Also, without link-layer information, RFC-2461 and 2462 delays before sending RS and DAD messages SHOULD be performed, until NUD has completed. This document references several other documents, each of which defines its own security considerations. Readers are referred to these documents for further information. Normative References [RFC-2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119 (BCP 14), Internet Engineering Task Force, March 1997 [RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [FASTRA-02] M. Khalil, J. Kempf, B. Pentland. IPv6 Fast Router Advertisement (FastRA), Internet Draft (work in progress), October 2002. [FRD-00] JinHyoeck Choi, DongYun Shin. Fast Router Discovery with RA Caching in AP. Internet Draft (work in progress), Feb 2003. [MIPv6-20] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6. Internet Draft (work in progress), January 2003. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 22] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 [SEND-psreq-01] P. Nikander (Ed.), J. Kempf, E. Nordmark. IPv6 Neighbor Discovery trust models and threats. Internet Draft (work in progress), January 2003. Non-Normative References [CGA-00] Tuomas Aura. Cryptographically Generated Addresses (CGA). Internet Draft (work in progress), February 2003. [WLANPIO-00] Paul Tan. Recommendations for Achieving Seamless IPv6 Handover in IEEE 802.11 Networks. Internet Draft (work in progress), February 2003. Acknowledgements Thanks to the authors and editors of the MIPv6 (David Johnson, Charles Perkins Jari Arkko), FastRA (Mohammed Khalil, James Kempf and Brett Pentland), and FastRD (JinHyeock Choi {thx from Greg} and DongYun Shin) drafts. We have relied heavily upon their work and aim only to illuminate their good ideas. Additionally, we thank Ed Remmell and Erik Nordmark for their contributions in the working group. We're sure they'll recognise some of their ideas presented here. Authors' Addresses: Greg Daley E-mail: greg.daley@eng.monash.edu.au Phone: +61-3-9905-4655 Address: Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton 3800 Victoria Australia JinHyoeck Choi E-mail: athene@sait.samsung.co.kr Phone: +82-31-280-9233 Address: i-Networking Lab, Samsung AIT (SAIT) Appendix: Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 23] INTERNET-DRAFT MIPv6 Movement Detection Optimizations May 2003 .. Changes Since Last Revision: Since 00: More diagrams indicating MD issues. Stronger elaboration of MD mechanisms(NUD/NS/NA/RD) Added stronger guidance for avoiding multicast bombing. Added section on avoiding NUD safely (w/placeholder for potential references to LinkIDs draft &etc). Added eager-binding heuristic after link-up trigger (EN). This document expires in December 2003. Daley, Choi draft-daley-mobileip-movedetect-00.txt [Page 24]