Subject: [mobile-ip] Sub: Identifying link changes

From: [email-masked]
Date: Thu, 20 Jun 2002 12:08:13 +0530

Jari wrote:

> 2. R1 declares that it is no longer a default router. It will still
>    be a router, and send Router Advertisements.

>    Is this harmful? Only if (a) R1 performs DAD and (b) MN answers
>    the DAD. But how can we get into such a situation? R1 will of
>    course perform DAD if it still works as a home agent, and the
>    Binding Update has the 'D' bit on. But why would the MN answer
>    DAD? If the MN believes it is on foreign link, why would it
>    respond to a DAD on an old CoA?

In this case, R1 performs DAD for link-local address of MN also.

Is this assumption right?

If yes, Should MN respond for NS on its link-local address or not?

If no, and if MN is not responding for these NS's (for old CoA's of
MN), DAD will be successful. R1 will perfrom HA functionality i.e,
will proxy for MN's old CoA's which is still directly reachable for
the router R1. The packet is tunneled to MN's New primary CoA.

IMHO, this is not required

>    Come to think of it, I'm not even sure why the MN would
>    respond to NS on its own HoA before it has determined that
>    it is on the home link (11.6.7).

Yes, this is clearly mentioned in the returning home case.
Is this conditions, apply to foreign link CoA's also?

Samita wrote:

>As per section 11.4 (movement detection) when a MN changes it's
default-router
>and acquire a new primary COA, it indicates that MN may send a binding
update.

>If the previous default router still stays as a router, MN would still
continue
>to receive packets from CN. If that router dies or becomes a non-router,
then
>MN will have to send BU to stay connected.

>While MN is on the link, it
>should receive both prefixes from both the routers and it already keeps
track
>of list of COAs and default routers on the network. But it selects one of
them
>as it's primary default router and it also selects a corresponding COA.
>So, when it switches to the backup router it should know that there is no
>change in link has happened.

The idea of sending BU, is to maintain connection. So, there is no need for
sending a BU when the old router (though not acting as default router but
performs HA & router functionality) is still reachable.

I fully agree with this. Even, my earlier question was how to avoid sending
BU to previous router?
In order to do this, should MN maintain info about these routers also
(which are no longer default router)?

In section 11.4.1.(Movement Detection), it has been mentioned that MN
maintains or keeps track of only its default routers. Now, if MN needs to
check the reachability of this router(which is no longer a default router),
should it also maintain info about these routers which are turning from
default
routers to router.

In this case, how long we maintain these entries?
Can MN have its own local policy for doing this?
Is this conclusion right?

Srinivasan.D

---

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Jun 2002 18:24:59 +0300

> If yes, Should MN respond for NS on its link-local address or not?

I suppose it has to be responding on the link-local address, as it
would be the same even under the new router.

> should it also maintain info about these routers which are turning from

I suppose there'd be three ways out of this.

1) Make the forwarding-from-previous-coa work well. That is, we'd need to
    solve the DAD problem. Apperently it is not enough to not respond to
    NSes on the old coa, because of the link local problem you described above.
    Could we use the 'L' to let the home agent know that it should
    not do DAD on the link-local address in this case?

2) Have the MN keep track of the situation well enough so that it would
    know it is still on the same link. This would involve keeping information
    about non-default routers as well.

3) Forbid the possibility of a router to become a non-default router
    and still continue to act as a home agent. If we do this, then
    the BU sent for forwarding-from-previous-coa will fail. But that's
    allright because the CN's packets will end up in this LAN regardless.

Other options?

Jari

---

From: "Dr. Subrata Goswami" <[email-masked]>
Date: Thu, 20 Jun 2002 10:33:42 -0700

The following are some questions I have.

3.1) .....This specification also permits the 
   movement without obtaining a new CoA, when a valid CoA cannot be 
   obtained from the new AR (i.e, the mobile node uses the old CoA).

   What would this happen at all ? What are a few example scenarios in
which handover without an nCoA would be usefull?

3.1.2) In Figure 2 should not the PrRtAdv be sent from the oAR after the
HACK has been received? Is there a timer associated with HACK in the oAR
?

3.1.6) In Figure 3 should not the PrRtAdv be sent from the oAR after the
HACK has been received ? Is there a timer associated with HACK in the
oAR ?

3.1.8) ... The typical form 
   of such a positive indication is a F-BU sent from the oAR to the MN; 
   if the MN expects but does not receive the acknowledgement, then it 
   MUST resend the F-BU one more time.

Is the oAR sending out F-BU or F-BACK ?

3.1.8) ... If the MN has not yet received a F-BU from the oAR, then the
MN 
   SHOULD arrange for oAR to receive an appropriate F-BU associating the

   MN's oCoA to its nCoA.

????

---

From: "James Kempf" <[email-masked]>
Date: Tue, 25 Jun 2002 14:48:41 -0700

>     allright because the CN's packets will end up in this LAN regardless.

Well, this is somewhat radical (but basically an attempt to learn from the last year and a half of RO discussion). Since forwarding
from previous care of address is meant to be a handover accelerating/smoothing technique, we could remove it from the base document
and put it into a separate document, perhaps even the fast handover spec, so we can work out the complications without the time
pressure of having to get it done immediately. In addition to the point brought up in this thread, there is also the question of how
to set up an IPsec security association with a router, and I think there are probably other implications of trying to treat an
access router as a home agent that really haven't been entirely thought through yet.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Sat, 29 Jun 2002 00:59:12 +0300

Yet another issue to close.

If you remember the discussion, this was about the default router that turned to a non-default
router. This causes the mobile node to go for another default router on the same link, per
rules of the movement detection section. Since the old router is no longer in the default
router list, the MN thinks it has changed link, and may send a BU to the "previous HA".
This will however fail since the old HA will try to do DAD, which the MN itself will respond
to. Even if prefixes between the routers differ, the link local address will be the same, so
the MN will answer a DAD query if the 'L' bit was on.

We also discussed whether it makes sense to keep the previous coa functionality in the
draft at all, and the application of SEND techniques in this space. We also noted that
we don't enough experience to say exactly how security policies can be configured for the
prev coa forwarding to work, and we are not sure it is practical to configure per MN SAs
on the routers on the places you might be moving in.

I have a primary proposal on how to go forward. This is based on the observation that
the original situation isn't very typical, so we shouldn't try to optimize it. It is
sufficient to ensure that nothing horrible happens. So, we don't care even if the forwarding
from previous coa would fail in this situation, or if some unnessary tunneling would take
place. As long as the current coa works well and nothing breaks in the old coa, we are happy.
Forwarding from previous coa should of course work in the usual case when you actually move to
another link.

The proposal is that we allow MNs to request forwarding from previous CoA.
We do not require them to be aware that they might possibly be on the same
link due to one of the routers no longer being a default router. What happens
then is that forwarding-from-previous-coa is requested. We require the 'D'
and 'L' bits to be set in such BUs. This leads the HA to run DAD, which should
fail as the link local address is still in use on the same physical link.
Then, no forwarding will be done. (But this is fine, as the packets will
normally come to the link anyway.)

Does this work for everyone? (A possible backup proposal:
drop this functionality and deal with it in another spec.)

Jari