Subject: Re: [mobile-ip] closing issue 48, identifying link changes and prev-coa

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Jul 2002 21:49:46 -0700

Jari,

I've got no problem with this (and, in any case, it is too late now).

        jak

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: <[email-masked]>
Cc: "James Kempf" <[email-masked]>; <[email-masked]>; "Samita Chakrabarti"
<[email-masked]>
Sent: Friday, June 28, 2002 2:59 PM
Subject: [mobile-ip] closing issue 48, identifying link changes and prev-coa

> 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
>
>