Samita Chakrabarti writes: 2. Movement Detection by the MN Section 11.5.1 discusses mechanisms such as: - Check default router address (link-local) and or do periodic NUD for the default router. - Check the prefix of the router advertisement An implementation (router) may have same link-local addresses on its different interfaces. Thus mobile nodes which detect movement by doing periodic NUD to the default router and checking default router's link-local address cannot detect movement while moving from one subnet to another subnet served by the same router. At Connectathon at least one implementation failed to detect movement for the above reason. Proposal(s): * Draft should clarify that a router that provides service to the mobile nodes, MUST be configured with unique link-local addresses on its each link. * Having some unique id to distinguish different ESD part of the link-local addresses of each interface of the router. * The mobile node SHOULD compare both link-local address of the default router(its reachability) and the prefix in the prefix option of router advertisement (with the prefix of the mobile's interface) to determine movement at the L3 level. ------------------ Jari Arkko responds to Samita Chakrabarti: > * Draft should clarify that a router that provides service to > the mobile nodes, MUST be configured with unique link-local > addresses on its each link. Sounds pretty tough for *all* IPv6 routers. > * Having some unique id to distinguish different ESD part of > the link-local addresses of each interface of the router. But we don't have any, do we? > * The mobile node SHOULD compare both link-local > address of the default router(its reachability) and the prefix > in the prefix option of router advertisement (with the prefix > of the mobile's interface) to determine movement at the L3 level. This seems like the only possibility, unless someone invents something new. I'm willing to go for this, though it means that when a router has the same link-local address, movement detection is delayed until you see also an advertisement. Maybe its the best we can do? ------------------ Ed Remmell responds to Jari Arkko: *> Sounds pretty tough for *all* IPv6 routers. Ed Remmell: Agreed. > But we don't have any, do we? If the link-local scope address of the router is formed from a globally unique EUI-48 or EUI-64 (it is possible to check the universal/local bit in the interface ID part of the address to confirm this), then this is a non-issue. However, that may not always be the case. RFC-2461 is very clear that the source address of the RA MUST be a link-local scope assigned to the interface on which the RA is sent, so you can't add some text saying that a MIPv6-aware router SHOULD use a global scope source address when sending the RA because that would violate RFC-2461. But, then there is the modified Prefix Information option containing the router address, see my suggestion below. ------------------ JinHyeock writes: > Sounds pretty tough for *all* IPv6 routers. JinHyeock: The more serious problem is that two access routers may have same link-local addresses on their different interfaces. Because the uniqueness of link-local address is not guaranteed outside a link, we can't avoid this problem . > * The mobile node SHOULD compare both link-local > address of the default router(its reachability) and the prefix > in the prefix option of router advertisement (with the prefix > of the mobile's interface) to determine movement at the L3 level. I wonder it is useful to check link-local address for movement detection. Correct me if I am wrong. But I don't see any reason to check link-local address in RA for movement detection. IMHO, An MN SHOULD NOT use the router address in RA for movement detection. If MN is in a network with multiple access routers, it will receive the RAs with different router addresses. In this case, even though the router address in RA has been changed, a MN has not moved. On the other hand, because the router address in RA is link-local address, its uniqueness is not guaranteed outside a link. Hence the fact that MN receives the RA with the same router address doesn't imply that it still remains in the same IP subnet. I have a question. According to current implementations, when does MN send BU? If MN receives a RA with different prefix information, does it sends BU immediately or perform NUD with the default router beforehand? > This seems like the only possibility, unless someone invents > something new. I'm willing to go for this, though it means that > when a router has the same link-local address, movement detection > is delayed until you see also an advertisement. Maybe its the > best we can do? I see no reason to compare link-local address. Correct me if I am wrong, but I think link-local address in RA can play no role for movement detection. It gives no information on MN's movement whether MN receives a RA with same Router Address or different Router Address. Currently there are two proposals to shorten the time to receive a new RA. FastRA (draft-mkhalil-ipv6-fastra-03.txt) and FRD (draft-jinchoi-mobileip-frd-00.txt) ------------------ Vijay Devarapalli responds to JinHyeock: Many implementations follow something called Eager Cell Switching. a BU is sent immediately with the newCoA as the source address. ------------------ Ed Remmell responds to Jari Arkko: So, you need to be very careful about how you specify this. Router Advertisements do not necessarily contain all of the prefix information. If it is a solicited Router Advertisement, it SHOULD contain all of the prefix information, but if it is an unsolicited RA, it MAY not. So, I would only apply this rule to the MN receiving solicited Router Advertisements, in which case this rule doesn't really add much since most of the RAs received by the MN will likely be unsolicited. Overall, this seems to be an architectural problem that may not be easily fixed, without requiring the MN to do something like frequently solicit its current default router to force solicited RAs to be returned frequently (i.e. solicited beacons) for this purpose, which isn't a very nice solution since it is wasteful of both bandwidth and of the MN's battery power. But, see my suggestion below about the modified Prefix Information option. I was also thinking that you could check to see if the source MAC address of the RA has changed (i.e. when the RA is sent from the link-local scope address of the current default router), but this is not reliable, since in the load-balancing case multiple routers having different MAC addresses would potentially share the same link-local scope router address. Here's my idea about the modified Prefix Information option: The MIPv6 specification adds the (R) bit to the Prefix Information option, and this bit being set indicates that the prefix is actually the address of the router. Note that it might be site-local scope or global scope, but it is guaranteed not to be link-local scope. So, it is definitely better than using a link-local scope address to attempt to uniquely identify a router. Also, with how the definition of the site-local prefix is being changed so that it shares the low-order 48 bits (i.e. fec0:xxxx:xxxx:xxxx, the "xxxx:xxxx:xxxx" part is what I'm referring to) of the prefix with a global scope prefix assigned to the same link, there is much less potential for duplicate router addresses on adjacent links when this router address is site-local scope (this doesn't consider the non-on-link prefix case, however - i.e. the (L) on-link flag needs to be set in the Prefix Information Option for this statement to be true). Also, I expect in most cases when this option is used, the router address it contains is global scope. So, perhaps just tighten up the rules on this modified Prefix Information option containing the router address, to say that it MUST be sent in every Router Advertisement (unsolicited as well as solicited) that a Mobile IPv6 home agent sends, and that it is RECOMMENDED that the same be done by other IPv6 routers to better support Mobile IPv6 (i.e. it is hard to put any kind of requirement on other non-MIPv6-aware IPv6 routers). Also, if a IPv6 router includes its address in a modified Prefix Information Option in any Router Advertisement it sends, it MUST send that same modified Prefix Information Option (as long as that router address is still valid) in all Router Advertisements that it sends (this allows the MN to check unsolicited as well as solicited RAs for this information). Note that it is possible for the router to include more than one router address in the RA using this modified Prefix Information Option, in which case it MUST include all of those address (while they are still valid) in each RA it sends (basically, once it starts advertising a router address this way, it must continue to advertise that same address as long as it is valid in each RA it sends). Then, the new mobile node requirements text for this issue becomes something like: "If the Router Advertisement sent by the current default router contains the modified Prefix Information Option with the (R) bit set indicating that it contains the address of the router and with the (L) on-link flag set indicating that it can be used for on-link determination, then the mobile node SHOULD check each Router Advertisement received from that router (both unsolicited as well as solicited) to verify that it contains the same router address, and if it does not, then the mobile node SHOULD treat this as an indication that L3 movement has occurred." ----------------- Ed Remmell responds to JinHyeock: We do NUD of the current default router to make sure that it is still reachable. If NUD of our current default router fails, then in our MN implementation we treat that as an indication of L3 movement. This is pretty much the behavior that is specified for Mobile IPv6 default movement detection. Please refer to http://www.piuha.net./~jarkko/publications/mipv6/issues/issue170.txt This scenario is not as simple as you might think. In our MN implementation, we actually filter Parameter Discovery and Prefix Discovery using the current default router, so our current default router effectively becomes our virtual link, and when we have to change our current default router because NUD fails for that router, then we treat moving to a new router (even if it is on the same physical link) as a L3 move. To support receiving on the previous primary CoA, we deprecate the prefix associated with that CoA, and set the valid lifetime very short when we do the L3 move, and if it isn't included in the prefix information we get in the solicited RA from the new default router we discover, then it quickly becomes invalidated, but it stays around long enough to potentially smooth the link movement process. The reason why this is difficult is because the scenario of having multiple routers on the same link, each broadcasting different sets of prefixes (which is a valid configuration, BTW), is really not very different from the similar scenario of having overlapping RF coverage areas, and the mobile node being able to hear multiple routers even though they are actually on different physical RF links because the mobile node either doesn't have integration between its RF channel selection and Mobile IPv6 to notify it of L3 movement and it is bouncing back and forth real fast between the two different physical RF links (this can happen when the mobile node is operating on the fringe, and is having difficultly acquiring a RF link that has acceptable quality and signal strength), or because the RF cells are set up on the same RF channel so they actually interfere with each other and overlap coverage areas and bleed together as one apparent super-link when in fact they are two different physical RF links. Note that NUD is the only sure way to detect bi-directional reachability of the default router. Just being able to hear any old router does not mean that it is bi-directionally reachable; RF is strange that way, the router's transmissions might be able to be heard by the mobile node, but that doesn't mean that the mobile node's transmissions can be heard by that same router. In the scenario described above of overlapping RF coverage areas, one of the routers that the mobile node is hearing may not be bi-directionally reachable, while the other router is. In that case, the mobile node should be using the 2nd router (which is bi-directionally reachable) as its current default router. Per issue #170, it must only use a primary CoA which is covered by the prefix information advertised by that router. This guarantees that when it sends packets using that primary CoA as the source address, its current default router will recognize the source address of the packet as being on-link and not discard it due to ingress filtering. Also, it guarantees that packets sent to it at the primary CoA will be sent through the router which the mobile node has confirmed to be bi-directionally reachable. Yes, this looks like the real issue here. Note that if the link-local scope address of the router is formed from a globally unique EUI-48 or EUI-64, then this becomes a non-issue. It is too bad that the source address of the RA cannot be a global scope address, but instead MUST be a link-local scope address. However, some things are possible if we always include a non-link-local scope router address in the RA (both solicited and unsolicited RAs) using the modified Prefix Information option, see my other email. ------------------ Ed Remmell responds to Jari Arkko: (summarized from my prior lengthy email...) > This seems like the only possibility, unless someone invents > something new. I'm willing to go for this, though it means that > when a router has the same link-local address, movement detection > is delayed until you see also an advertisement. Maybe its the > best we can do? Unsolicited RAs MAY not contain all of the prefix information. Here's my idea about using the modified Prefix Information option for this: The MIPv6 specification adds the (R) bit to the Prefix Information option, and this bit being set indicates that the prefix is actually the address of the router. So, perhaps just tighten up the rules on this modified Prefix Information option containing the router address, to say that it MUST be sent in every Router Advertisement (unsolicited as well as solicited) that a Mobile IPv6 home agent sends, and that it is RECOMMENDED that the same be done by other IPv6 routers to better support Mobile IPv6 (i.e. it is hard to put any kind of requirement on other non-MIPv6-aware IPv6 routers). Also, if a IPv6 router includes its address in a modified Prefix Information Option in any Router Advertisement it sends, it MUST send that same modified Prefix Information Option (as long as that router address is still valid) in all Router Advertisements that it sends (this allows the MN to check unsolicited as well as solicited RAs for this information). Note that it is possible for the router to include more than one router address in the RA using this modified Prefix Information Option, in which case it MUST include all of those address (while they are still valid) in each RA it sends (basically, once it starts advertising a router address this way, it must continue to advertise that same address as long as it is valid in each RA it sends). Then, the new mobile node requirements text for this issue becomes something like: "If the Router Advertisement sent by the current default router contains the modified Prefix Information Option with the (R) bit set indicating that it contains the address of the router and with the (L) on-link flag set indicating that it can be used for on-link determination, then the mobile node SHOULD check each Router Advertisement received from that router (both unsolicited as well as solicited) to verify that it contains the same router address, and if it does not, then the mobile node SHOULD treat this as an indication that L3 movement has occurred." ------------------ JinHyeock Choi responds to Ed Remmell: Thanks for your thorough mail. It helped to clarify my thought. Correct me if I am wrong but it seems there is ambiguity on Movement Detection (at least to me till now). In L3 movement, there happen two incidents. 1) Current default router changes. 2) Current CoA becomes invalid. Usually 1), 2) happen at the same time. But not always. Hence, for movement detection, MN should check i) the reachability of current AR and ii) the validity of current CoA. I wonder that it is wise to identify the reachability of current access router with the validity of current CoA. IMHO, it seems safer to me to check i), ii) separately. For i), MN should perform NUD with Router Address. But for ii), MN should check the Prefix Information Options in RA. Here are some of my comments. >> We do NUD of the current default router to make sure that it is still >> reachable. If NUD of our current default router fails, then in our MN >> implementation we treat that as an indication of L3 movement. This is pretty >> much the behavior that is specified for Mobile IPv6 default movement >> detection. I wonder how long it takes to detect movement in your implementation? If you provide some number, it will help me a lot. According to CTIE implementation, without any optimization scheme, it takes several hundreds ms. >> Please refer to >> http://www.piuha.net./~jarkko/publications/mipv6/issues/issue170.txt >> This scenario is not as simple as you might think. Thanks for notifying this. >> Note that NUD is the only sure way to detect bi-directional reachability of >> the default router. Just being able to hear any old router does not mean You are right but the problem is that NUD takes time. I wonder we can support seamless handoff with NUD. >> It is too bad that the source address of the RA cannot be a global scope >> address, but instead MUST be a link-local scope address. However, some >> things are possible if we always include a non-link-local scope router >> address in the RA (both solicited and unsolicited RAs) using the modified >> Prefix Information option, see my other email. I agree that global scope router address will help to check the reachability of default router. It may also help to check the validity of CoA using prefix life time. ------------------ Ed Remmell responds to JinHyeock Choi: >> Correct me if I am wrong but it seems there is ambiguity on >> Movement Detection (at least to me till now). In L3 movement, >> there happen two incidents. >> 1) Current default router changes. >> 2) Current CoA becomes invalid. >> >> Usually 1), 2) happen at the same time. But not always. Yes. >> Hence, for movement detection, MN should check >> i) the reachability of current AR and >> ii) the validity of current CoA. >> >> I wonder that it is wise to identify the reachability of current access >> router with the validity of current CoA. >> >> IMHO, it seems safer to me to check i), ii) separately. For i), MN should >> perform NUD with Router Address. But for ii), MN should check the Prefix >> Information Options in RA. The primary CoA that you are using to register mobility bindings must be in the list of prefixes advertised by the current default router. When you move away from that router because it is no longer reachable, you must invalidate any prefixes you are still maintaining (and their associated CoAs) that are not in the set of prefix information advertised in the solicited RA by the new router that you discover because you can assume that they are now off-link. So: 1) determine current default router is unreachable 2) solicit for new default router by sending RS 3) discover new router by receiving solicited RA, invalidate all prefixes (and associated CoAs) not advertised in solicited RA. >> >> Here are some of my comments. >> > >>> > We do NUD of the current default router to make sure that it is still >>> > reachable. If NUD of our current default router fails, then in our MN >>> > implementation we treat that as an indication of L3 movement. > >> This is pretty > >>> > much the behavior that is specified for Mobile IPv6 default movement >>> > detection. >> >> I wonder how long it takes to detect movement in your implementation? >> If you provide some number, it will help me a lot. According to >> CTIE implementation, >> without any optimization scheme, it takes several hundreds ms. Yes, well we aren't done implementing Mobile IPv6 mobile node, actually my mobile node design won't be completed until next week some time. In my experience, IPv6 NUD takes approx. 45 seconds to determine that a neighbor is no longer reachable, when data is actively being exchanged with the peer. I agree this can be a long time. However, if you have some indication first that the neighbor might be unreachable, and then immediately force NUD into the PROBE state for that neighbor (and start actively probing by sending NS), then determination that the neighbor is unreachable actually can happen much faster, i.e. approx. 3 seconds (for the 3 NUD probes that are sent). L2 triggers can be used to force NUD to enter the PROBE state. I'm not necessarily referring to the kind of L2 triggers where the network sends special messages over IP to the mobile node to provide movement information, just knowledge of basic link movement events (i.e. link up after a corresponding link down) can help speed up this process by causing the mobile node to start actively probing the current default router sooner (with NS, per NUD). Also, you can use the Advertisement Interval option in the Router Advertisement, if it is available, to speed this up; for example, if your current default router is frequently sending "beacons" (i.e. very frequent sending of unsolicited RAs per a specified Advertisement Interval), the mobile node could decide that the current default router is not reachable after not receiving some number of the expected unsolicited RA beacons in sequence, for example if 4 expected beacons are not seen in sequence then force NUD into the PROBE state and start actively probing. The time between these beacons can be as short as 0.07 seconds (the current minimum allowed value for MaxRtrAdvInterval). So, in this case you could detect a L3 move in less than half a second. Pretty fast. That's assuming you completely skip NUD probing - the specification says you should still do NUD probing of the default router in this case, specifically in section 11.5.1 "Movement Detection": "If the above means do not provide indication that the mobile node is still reachable from its current default router (for instance, the mobile node receives no packets from the router for a period of time), then the mobile node SHOULD attempt to actively probe the router with Neighbor Solicitations, even if it is not otherwise actively sending packets to the router." I personally think that in the case of listening for unsolicited RA beacons per the Advertisement Interval, you can skip the NUD probing. The next message you send will be a RS, since you assume a L3 move in this case. You haven't invalidated any prefixes or CoAs yet, you'll do that after you receive the solicited RA if they aren't advertised in the next solicited RA. At least that's my plan for implementing this. >>> > Please refer to >>> > http://www.piuha.net./~jarkko/publications/mipv6/issues/issue170.txt >>> > This scenario is not as simple as you might think. > >> >> Thanks for notifying this. >> > >>> > Note that NUD is the only sure way to detect bi-directiona reachability of >>> > the default router. Just being able to hear any old router does not mean >> >> You are right but the problem is that NUD takes time. I wonder we >> can support >> seamless handoff with NUD. When combined with the other mechanisms mentioned above, you could perhaps shorten the time needed to detect a L3 move down to approx. 10 seconds, perhaps less. In the case of using the Advertisement Interval, I'd think that you might even be able to skip the NUD PROBE state and after missing receiving some number of beacons in sequence from your current default router, immediately decide that the current default router is unreachable and solicit by sending a RS to find a new one, that could be even faster than 5 seconds (depending on how fast the beacons are being sent). ------------------ Samita Chakrabarti responds to Jari Arkko: > Sounds pretty tough for *all* IPv6 routers. Most of the IPv6 routers should have a way to do this, it may be a matter of configuration. But I agree, it might be tough to impose universally. > But we don't have any, do we? No. > This seems like the only possibility, unless someone invents > something new. I'm willing to go for this, though it means that > when a router has the same link-local address, movement detection > is delayed until you see also an advertisement. Maybe its the > best we can do? I think, the movement detection only at the L3 level is a hard problem to solve. But Mobile IPv6 main spec does not need to address that fully; many believe another draft would be appropriate for this. IMHO, the above solution is the best we could do here. The Mobile IPv6 draft already indicates that movement detection can be initially handled at the L2 level. ------------------ Samita Chakrabarti responds to JinHyeock CHoi: > On the other hand, because the router address in RA is link-local address, > its uniqueness is not guaranteed outside a link. Hence the fact that MN > receives the RA with the same router address doesn't imply that it still > remains in the same IP subnet. The draft indicates that L2 level movement detection can be used in some networks and mobile nodes. But, for mobile nodes which don't have L2 level movement detection can perform both default router address check (from RA or by doing periodic NUD) and prefix check against the existing prefix of the COA. That should work in most cases. But for faster movement detection, I think L2 layer detection followed by a RS by the MN is more helpful. > I have a question. According to current implementations, when does MN > send BU? If MN receives a RA with different prefix information, does it > sends BU immediately or perform NUD with the default router beforehand? Some folks are only doing periodic NUD to the router to detect movement, I suppose they also watch for the link-local address in the RA to form the new COA and then sends BU. One implementation uses L2-trigger to detect movement and sends indication to the IP layer which then (I suppose) sends RS or watches for RA to form new COA and then sends BU. ------------------ Jin Hyeock Choi responds to Ed Remmell: > So: > 1) determine current default router is unreachable > 2) solicit for new default router by sending RS > 3) discover new router by receiving solicited RA, invalidate all prefixes > (and associated CoAs) not advertised in solicited RA. I am afraid step 1), 2) takes too much time for seamless handoff. According to ND, MN and access router should execute Random Delay when sending RS and solicited RA (maximally 1 and 0.5 sec respectively). Are 1), 2) absolutely necessary? I have to think it over more carefully but, with some modification, we may find a way to discover new router by receiving suitable unsolicited RA. > I personally think that in the case of listening for unsolicited RA beacons > per the Advertisement Interval, you can skip the NUD probing. The next > message you send will be a RS, since you assume a L3 move in this case. You > haven't invalidated any prefixes or CoAs yet, you'll do that after you > receive the solicited RA if they aren't advertised in the next solicited RA. > At least that's my plan for implementing this. What do you think of the case that MN receives an unsolicited RA with different Prefix Information Option? Can we skip NUD probing? IMHO, the relationship between NUD, RA and Movement Detection needs more thorough investigation. ------------------ Ed Remmell responds to Jin Hyeock Choi: > What do you think of the case that MN receives an unsolicited RA > with different > Prefix Information Option? Can we skip NUD probing? No. Just because the mobile node hears another router advertising different prefixes, doesn't mean that it should switch from its current default router (which it has already confirmed via NUD to be bi-directionally reachable). With RF, hearing another router doesn't mean it is bi-directionally reachable. Only something like NUD can determine if a router is bi-directionally reachable. The RS/solicited RA combo is also a pretty good indicator of bi-directional reachability. Unsolicited RA is not a good indicator. ------------------ Erik Nordmark writes: The case of overlapping RF coverage makes me want to ask a rather basic question: what delineates the boundary between one link and another? Shouldn't there be something (other than the extent of coverage) that delineates this boundary at L2? (some L2 implicit or explicit notion of a link such as different channels or something) If you don't have that then how do you know whether the routers can advertise the same prefix or different prefixes? If it's raining maybe they shouldn't because of poorer coverage? So I think what is being discussed is a case of partially overlapping *links* due to RF coverage issues. True that to the Mobile IP software this might not look much different (since it might not be aware of the L2 handover) but conceptually this feels different. ------------------ Erik Nordmark responds to Ed Remmell: > When combined with the other mechanisms mentioned above, you could perhaps > shorten the time needed to detect a L3 move down to approx. 10 seconds, > perhaps less. In the case of using the Advertisement Interval, I'd think > that you might even be able to skip the NUD PROBE state and after missing > receiving some number of beacons in sequence from your current default > router, immediately decide that the current default router is unreachable > and solicit by sending a RS to find a new one, that could be even faster > than 5 seconds (depending on how fast the beacons are being sent). I think you can potentially do this faster if we think about the fast RS space. The idea is that there is a set of hints that can indicate that an L3 movement has occurred. The hints can be some indication from L2, or the receipt of an RA from a router that hasn't been heard before or with a prefix option that hasn't been heard before. Note that the hint itself doesn't indicate L3 movement. The hint triggers the sending of a few RSs spaced per RFC 2461. If the RS doesn't cause the receipt of an RA from the old router (same source address) and with the old prefix option (different R-bit router address) then movement has been detected. Getting this to work really fast requires tweaking the rate limiting of the RAs, but that is something that can be discussed as part of the general IPv6 optimizations (wherever they will take place). ------------------ Greg Daley responds to Erik Nordmark: If the L2 hints that a link may have changed then this is a more reliable reason why you would believe an RA from a previously unseen router. This doesn't necessarily entail RS/RA exchange with a new router, especially if the new network undertakes the MIPv6 RA beaconing behaviour (~50ms spacing), or network side L2 systems provide or prompt an RA upon MN association. These systems are significantly faster than current RFC2461 based RS/RA. FastRS/RA systems are an obvious step if the MN receives link-up triggers, though. The existing proposal of FastRA (mkhalil et al) gives a good first approach at tackling this issue, by removing RA response delays. We've used it in our lab to good effect. It doesn't handle the issue of RS delay, which is highly link-layer dependent. The delays (also shared by DAD) seem to be aimed at reducing multicast packet bombing on links where many devices are configuring at once. This can happen in MIPv6 if many devices move and transmit simultaneously. At this stage, our early 802.11b tests with 10 nodes simultaneously transmitting multicast packets have shown few problems (all packets received in <20 ms, little or no packet loss). This isn't particularly helpful if the number of devices moving simultaneously exceed these values. So we're focussing on MAC simulation, in order to characterize behaviour in this area. Also, we have been looking at ways to avoid simulteneous movement (and thus RS delay) by performing random delays before disconnecting from the previous link (Nick Moore's idea). We're also looking at reducing the RS Delay time depending on the link type. I'm pretty sure though that on systems with logical point-to-point channels for the MN (TDMA/CDMA), these delays can be dispensed with completely. Please note that the same issues still exist with DAD delay especially when receiving multicast RA (lots of nodes detect movement simultaneously, and configure addresses). It may be possible to treat the random delay period before the DAD NS is sent as tentative in the same fashion as Optimistic DAD. This would extend the tentative period by up to a second, while still allowing unicast NA's and packet reception in the meantime. > Getting this to work really fast requires tweaking the rate limiting of > the RAs, but that is something that can be discussed as part of the > general IPv6 optimizations (wherever they will take place). RA rate limiting is relatively straightforward, if the MN has an address from which it can send the original RS (FastRA). I'm not sure that we'd want to significantly reduce the interval between solicited Multicast RA messages, which is the only available response if the RS comes from the unspecified address. ------------------ Momose Tsuyoshi writes: I'm implementing Mobile IPv6 code at kame project. KAME mip6 mobile node has this problem. > I think, the movement detection only at the L3 level is a hard problem > to solve. But Mobile IPv6 main spec does not need to address that fully; > many believe another draft would be appropriate for this. > IMHO, the above solution is the best we could do here. The Mobile IPv6 > draft already indicates that movement detection can be initially handled > at the L2 level. I agree to Samita. The mechanism of kame Mobile IPv6 implementation depends on NUD default router. And this cause failure of movement detection as told here. But I think it is the best way for kame mipv6 at this time. Most of Kame mobile ipv6 code is implemented in kernel part, and kame aims generic ipv6 (also including mipv6) protocol stack. So, it is required using the most generic way to detect it's movement. There may be a lot of network configurations such as 1 router with sending several RAs separately, multiple nodes which sends same prefix RA, multiple routers with multiple prefix RAs, etc. Using NUD of default router is the best way to be able to move such various type networks. I believe it isn't necessary to describe more complex movement mechanism in the MIPv6 spec. ------------------ Erik Nordmark responds to Greg Daley: > If the L2 hints that a link may have changed then this is > a more reliable reason why you would believe an RA from > a previously unseen router. This doesn't necessarily > entail RS/RA exchange with a new router, especially if the > new network undertakes the MIPv6 RA beaconing behaviour > (~50ms spacing), or network side L2 systems provide or > prompt an RA upon MN association. If you know that the MNs can get a local trigger from L2 that they might have moved, then there is no need to waste bandwidth by sending RAs every 50ms. The frequent RAs help when there is no such local trigger. And the frequent RAs don't guarantee that you've moved. In somebody adds an additional router on the link (or an additional existing router can reach the MN) then it doesn't mean that the old router is no longer bidrectionally reachable. An RS/RA exchange will indicate whether the old router is still bidirectionally reachable. > It doesn't handle the issue of RS delay, which is highly > link-layer dependent. The delays (also shared by DAD) seem > to be aimed at reducing multicast packet bombing on links > where many devices are configuring at once. > This can happen in MIPv6 if many devices move and transmit > simultaneously. It would be good to have some (experimental or simulation) data on this. In practise how close together would a busload or trainload of operating MNs get a movement hint (from L2 or from frequent RA beacons) when they move as a unit from one link to another? If they would all move within milliseconds I think it would be required to have some randomization. > At this stage, our early 802.11b tests with 10 nodes > simultaneously transmitting multicast packets have shown few > problems (all packets received in <20 ms, little or no > packet loss). This isn't particularly helpful if the number > of devices moving simultaneously exceed these values. > So we're focussing on MAC simulation, in order to > characterize behaviour in this area. Great that you are looking into this. > RA rate limiting is relatively straightforward, if > the MN has an address from which it can send the original > RS (FastRA). I'm not sure that we'd want to significantly > reduce the interval between solicited Multicast RA messages, > which is the only available response if the RS comes from the > unspecified address. Good point. I guess it depends on how accurate the movement hints are. If a movement hint with high probability corresponds to an actual movement there might not be much harm to send a multicast RA in response to an RS, because each movement will already incur a few multicast messages (MLD join of solicited node MC address(es), DAD, RS to find new routers). But if 90% of the movement hints are false (e.g. due to frequent L2 going up and down) then it would be a problem to incur additional multicast packets. In that case a strategy that first performs a unicast RS/RA exchange with the old default router(s) would make more sense. ------------------ Mohammed Kassi-Lahlou writes: Moreover to avoid the "ping-pong" problem, the mobile node must be sure that it has lost the contact with the current router, therefore the mobile node should not change each time it receives a new RA. ------------------ Paul Lai writes: I have done some studies on using L2 messages to carry L3 information (e.g. Prefix Option). I believe that this approach ('tagging cables with label') allows MN to detect L3 movement and also its neighboring ARs more 'quickly'. It is more reliable in a scenerio where there are 2 different ARs on the same link. MN might incorrectly interprete its L3 movement. You are most welcome to comment on my draft (http://www.ietf.org/internet-drafts/draft-paultan-seamless-ipv6-handoff-802-00.txt). I am in the process of performing some work (simulation) on this draft, and would really hope to hear/gather some comments (good/bad). ------------------ James Kempf responds to Erik Nordmark: > And the frequent RAs don't guarantee that you've moved. > In somebody adds an additional router on the link > (or an additional existing router can reach the MN) > then it doesn't mean that the old router is no longer bidrectionally > reachable. An RS/RA exchange will indicate whether the old router is > still bidirectionally reachable. From a deployment standpoint, I think it makes sense to limit links where 50 ms RAs are multicast to only one router. As Greg and JinHyoeck's paper indicates, 50 ms RAs consumes about 16.6 kbps. The more routers on the link, the more bandwidth consumed by nonsubscriber traffic. I have hard time seeing wireless providers and enterprises use the 50 ms RAs, even for free spectrum, though, perhaps it will be OK for SOHO use. > Good point. > I guess it depends on how accurate the movement hints are. This depends on the link layer. For 802.11, it is pretty accurate, since the MN is doing the moving, and will only give the hint if the AP has confirmed the move. However, there is a high probability of ping-pong in 802.11, depending on the AP deployment configuration. If the two APs between which the MN was ping-ponging are in different subnets, it could lead to ping-ponged RSs. Of course, one can ascribe this to a poor deployment but it is hard to get a deployment right. For cellular (FWIW), I think the probability of ending up on a different IP subnet is pretty low too, since the handovers are pretty tightly controlled. > If a movement hint with high probability corresponds to an actual movement > there might not be much harm to send a multicast RA in response to an RS, > because each movement will already incur a few multicast messages > (MLD join of solicited node MC address(es), DAD, RS to find new routers). > But if 90% of the movement hints are false (e.g. due to frequent L2 going up > and down) then it would be a problem to incur additional multicast packets. > In that case a strategy that first performs a unicast RS/RA exchange with the > old default router(s) would make more sense. Clarification: I think FastRA does unicast RS to the new router. So it would require oDAD to really make a difference. ------------------ Jari Arkko: Meeting results: Most people seem to favor a simple approach -- or maybe even not changing the specification at all -- and attaching a warning of the limitations of L3 movement detection. Official meeting minutes from IETF-56: 278 - movement detection HS: proposal #1 (ignore the issue) is reasonable and simplest, no point in complicating these algorithms now. A MN can change CoA based on new prefix or ll address change. JK: agree Ed Remmel: R-bit should be a MUST not just for HA's but for all routers Charlie: The solution is different depending on the link type. No one size fits all. A mandated solution could hurt performance on some media It would be a lot better to leave it as is. TJ: I agree with everything said so far. Now is not the time and place to fix this. Erik: If people implement this from the spec and doesnt work then it would be useful to mention the problem in the spec to reduce the probability of errors in stacks. TJ: Are there common cases where routers configure the same ll address on different interfaces? Erik: If there is one then that's enough. Vijay: Some implementations use eager switching and some don't. There are many different ways of doing this. There is no need to fix this in the spec. Some warnings are enough. Perhaps the new MIP WG charter should address this. BP: This needs in a different doc. From this discussion I would say leave it as is and document the problem. ------------------ Charlie Perkins writes: I have read over the text for issue #278, and it is very complicated. At the end, though, there does not seem to be any real action indicated. Ed Remmell suggests that we could mandate the Prefix Information option in all advertisements, but that's not necessarily a win for some links that do not live up to the worst case scenario. Most people seem to suggest not doing anything. Am I missing something? ------------------ Jari Arkko responds to Charlie Perkins: No, I think the consensus was that everyone realizes the limits of l3 mechanisms, and that its better to document the limitations and get over with than trying to develop additional or different schemes. One question is whether we have documented the limits of the movement detection algorithm, particularly wrt the same link-local address on two links. I.e. how can we do what erik requests below: > Erik: If people implement this from the spec and doesnt work then it > would be useful to mention the problem in the spec to reduce the > probability of errors in stacks. Can we develop some text to "mention the problem"? ------------------ Ed Remmel responds to IETF-56 minutes: >Ed Remmel: R-bit should be a MUST not just for HA's but for all routers Just FYI, that's not what I said at IETF56. What I said is that the 'R' bit information, when it is included in the RA, MUST be consistent with information in subsequent RAs sent by the same router, i.e. if the router includes a 'R' bit Prefix Information Option in a RA advertising its global address, then as long as that address is still valid it must include that same option in all RAs that it broadcasts. This is so that this information can be used by the MN for move detection (in conjunction with the link-local scope source address of the RA). If the information is not consistent in RAs that the MN receives from the same router, then it is difficult for the MN to use that information for move detection. Also, it is RECOMMENDED that other non-home agent IPv6 routers include the R-bit in their RAs. This is what I suggested in the online issue report. This issue has to do with the fact that a link-local scope source address is ambiguous when considered in a larger scope than link-local scope. To resolve the ambiguity, the MN could also use the 'R' bit information, when present in the RA, if and only if that information is consistent between RAs broadcast by the same router. Then, you could add the following MN requirement to the spec: "If the Router Advertisement sent by the current default router contains the modified Prefix Information Option with the (R) bit set indicating that it contains the address of the router and with the (L) on-link flag set indicating that it can be used for on-link determination, then the mobile node SHOULD check each Router Advertisement received from that router (both unsolicited as well as solicited) to verify that it contains the same router address, and if it does not, then the mobile node SHOULD treat this as an indication that L3 movement has occurred." ------------------ Jari Arkko responds to Ed Remmel: This would work for me, but in order to solve #278 we still need two additional pieces of text, I think: 1) The home agent requirement to keep a PI with R bit consistent for every RA, if R bit is used. 2) Explain the potential problem with link-local addresses, if the rule above is not used, for instance due to an old router that does not support R bit. ------------------ Ed Remmel responds to Jari Arkko: Yes, please make all of these changes. Then, IMO finally we will have successfully addressed the following open issue identified in draft-nordmark-mobileip-mipv6-hindsight-00.txt: " There is also one idea that could be added to Mobile IPv6 at a later stage, which is to make the movement detection more explicit. The idea is to configure the routers on each link to advertise a single global IPv6 address as the "identity" of the link in each Router Advertisement. This can be done by defining a new Neighbor Discovery option. Thus a Mobile Node when it receives a Router Advertisement can immediately tell whether it has moved - the global identity will be different for each link." In this case, "identity of the link" will normally be identity of a single router (excepting the case when a global scope anycast address is used to identify a set of routers on the same link, which is one possible way to implement this), but then in our MN implementation we treat a single router as a virtual link anyways so same intent. Thanks for listening ------------------ Jari Arkko responds to Ed Remmel: So, here's the proposed solution to issue #278: 1. Insert the following text to Section 11.5.1 (Movement Detection): "Note that it is possible, even if improbable, that two routers happen to be using the same link-local addresses. Therefore, tracking the source address of the Router Advertisements may not always be sufficient. However, if the Router Advertisement sent by the current default router contains a modified Prefix Information option with the Router Address (R) bit set, and with the On-Link (L) flag set to indicate an on-link prefix, then the mobile node SHOULD check all subsequent Router Advertisements received from the same link-local address. In this check, some of the Prefix Information options received in the new Advertisement should indicate the same global router address which was indicated earlier. If they do not contain the same address, then the mobile node SHOULD treat this as an indication that a movement has occurred." 2. Insert the following text to the end of Section 7.2 (Modified PI): "In addition, the following requirement can assist mobile nodes in movement detection. Barring changes in the prefixes for the link, routers that send multiple Router Advertisements with the Router Address~(R) bit set in some of the included Prefix Information options SHOULD provide at least one option and router address which stays the same in all of the Advertisements." ------------------ JinHyeock Choi responds to Jari Arkko: I am afraid there is some problem on the proposed solution to issue #278. Kindly find in-line comments. > So, here's the proposed solution to issue #278: > > 1. Insert the following text to Section 11.5.1 (Movement Detection): > > "Note that it is possible, even if improbable, that two routers > happen to be using the same link-local addresses. Therefore, > tracking the source address of the Router Advertisements may > not always be sufficient. However, if the Router Advertisement > sent by the current default router contains a modified Prefix > Information option with the Router Address (R) bit set, and > with the On-Link (L) flag set to indicate an on-link prefix, > then the mobile node SHOULD check all subsequent Router > Advertisements received from the same link-local address. In I can't understand why MN checks only the RAs from the same link-local address. If so, MN can detect movement only when old AR and new AR have same link-local address. If MN checks only RAs from the same link-local address, it may not detect movement even if RA from new AR arrives. > this check, some of the Prefix Information options received in > the new Advertisement should indicate the same global router > address which was indicated earlier. If they do not contain > the same address, then the mobile node SHOULD treat this as an > indication that a movement has occurred." Even though MN checks all incoming RAs, it may result in problem. Here is an example: R1 and R2 are routers on the link. Each advertise the P1/48 prefix to the other routers. Host MN is on the link. Assume R1 is the default router of MN and it sends RAs with a modified Prefix Information option with (R) bit and (L) bit set. So R1 keep advertising its global address. If MN treat the lack of global address of R1 as movement indication, when a RA from R2 arrives, it may mistake this incident as L3 movement. For Movement Detection, MN should check 1) The reachability of current AR 2) The validity of the prefix of current (primary) CoA Though the proposed solution may serve as some kind of hint, I am afraid that it helps to confirm neither AR reachability nor CoA validity. ------------------ Jari Arkko responds to JinHyeock Choi: > If MN checks only RAs from the same link-local address, it may not > detect movement even if RA from new AR arrives. Yes. But the intention for this new paragraph was to say what to do in the special case of having the same link-local addresses. I.e. its a new condition, not a replacement to all the conditions regarding MD. > Though the proposed solution may serve as some kind of hint, I am > afraid that it helps to confirm neither AR reachability nor CoA > validity. Right, but it wasn't intended to. It was intended to work as an additional condition for check 1 above. Note that it says "... check all subseqent RAs... from the same link-local address". So in your example above, an RA from the R2 would not have the same link-local address, and its receipt would not be taken as an indication of movement. I have reformulated the last sentence of the new paragraph to make this more clear: Note that it is possible, even if improbable, that two routers happen to be using the same link-local addresses. Therefore, tracking the source address of the Router Advertisements may not always be sufficient. However, if the Router Advertisement sent by the current default router contains a modified Prefix Information option with the Router Address (R) bit set, and with the On-Link (L) flag set to indicate an on-link prefix, then the mobile node SHOULD check all subsequent Router Advertisements received from the same link-local address. In this check, some of the Prefix Information options received in the new Advertisement should indicate the same global router address which was indicated earlier. If they do not contain the same address even if the Advertisement was sent from the same link-local address, then the mobile node SHOULD treat this as an indication that a movement may have occurred. Does this work for you? ------------------ JinHyeock Choi responds to Jari Arkko: Yes, it works for me. I understand that the above is to give MN hint of movement for the special case of same link local addresses. Thanks for clarification. ------------------ ------------------