Subject: RE: Returning home and L bit (Was Re: [mobile-ip] MIPv6 v20 question re L bit)

From: "Ed Remmell" <[email-masked]>
Date: Thu, 6 Feb 2003 10:55:08 -0800

Vijay -

> If the HA were not defending the link local address the MN has
> to do the following.
>
> 1. MN realizes it is home (by receiving a router advert
>    with the home prefix)
> 2. MN does DAD for link local address (it cant use the link
>    local address till it does DAD, unless you can be sure
>    that your link local is unique)
> 3. MN does neighbor discovery to figure out HA's MAC address.
>    source address of NS is link local and target is HA's
>    address.
> 4. The HA responds with a neighbor advertisement
> 5. the MN gets hold of HA's MAC address
> 6. the MN sends a deregistration BU.
>
> what did you gain in this?

I would prefer to use regular Neighbor Discovery procedures whenever
possible. In step #2 above, the MN is performing DAD, not Address
Resolution. So, the NA response that the HA sends in step #4 is part of DAD
processing - I'd prefer not to use it for Address Resolution, which is
normally a separate procedure. I'd rather have a little extra latency in the
"MN returning home" scenario than make MIPv6-specific changes to Neighbor
Discovery.

At this point, if the MN needs to deregister, it would be performing Address
Resolution on the global scope address of the HA (since that is what it
persists in NVRAM), not the link-local scope address of the HA - the
Neighbor Advertisement that the HA sends in step #4 isn't even for an
address that belongs to the HA (i.e. it isn't the address that the HA uses
as a source address when it sends a Router Advertisement), it is for a MN
home address that the HA is proxying for. So, using the NA that the HA sends
in step #4 to resolve the address of the HA to be able to send a
deregistration BU to the HA in step #6 is definitely non-standard w/ regards
to Neighbor Discovery. Or, were you expecting that the MN would send the
deregistration BU to its own link-local scope home address that it just got
the DAD failure for? That is fairly confusing...

Also, in a follow-up email you sent, the MN behavior for the case where the
HA is still defending its link-local scope home address becomes trickier:

> 1. MN reboots at home. does not remember if it had a binding
>    at its HA.
> 2. when the MN receives an RA, it realizes it is at home
> 3. does DAD for the home address. DAD fails if HA is still
>    defending the MN's address
> 4. MN cant differentiate between HA defending its address
>    and some other node configuring its address
> 5. attempts a deregistration with its HA.
> 6. HA deletes the binding cache entry. if HA was not
>    defending MN's address, it responds with status 133 (Not
>    home agent for this mobile node)
> 7. if the MN receives a bind ack with status 133, it
>    concludes somebody on the home link has configured its
>    address.

As Greg O'Shea suggested, I'd like to see some explicit text in the MIPv6
specification that states that if the MN registers a binding with L=0, the
HA MUST NOT defend the link-local scope address corresponding to the home
address in the binding.

I do not see much benefit (anymore - at least not since S=0 was removed) to
having the HA defend the MN's link-local scope address, and I'd prefer for
the MN to have control over whether or not this occurs (so that I can
permanently disable it in our embedded systems MN implementation, and not
have to worry about special recovery logic for the scenario of the HA
defending the MN's link-local scope address causing MN DAD failure when
returning home).

Thanks.
- Ed Remmell
Elmic Systems, USA
http://www.elmic.com

---

From: "Ed Remmell" <[email-masked]>
Date: Fri, 7 Feb 2003 14:24:33 -0800

Jari -

> HA MUST NOT defend the link-local scope address corresponding to the home

I'd like it to be possible to have a simple MIPv6 MN implementation which
always registers with L=0 and which doesn't have the ND hacks to recover
from the situation of returning home when the HA is still defending the MN's
link-local scope home address (which it should not be doing when the MN
registers with L=0). I'm planning on implementing it this way anyways, but
the problem is that currently if the HA does conflict on the MN's link-local
scope home address when the MN returns home, the user application will need
to do the recovery by handling the DAD failure (we provide a callback
notification) and changing temporarily the interface ID to a random
interface ID that doesn't conflict to be able to do the NS/NA exchange on
the HA's global address to be able to send the deregistration BU - that does
make my example code ugly, to need to handle this special case.

Thanks.
- Ed Remmell
Elmic Systems, USA