Subject: Re: [mobile-ip] Mipv6 issue #150: de-reg and failure

From: Marc Hasson <[email-masked]>
Date: Wed, 30 Oct 2002 17:39:29 -0800 (PST)

I'd like to sanity-check the final comment made by Jari in this excerpt
from a few days ago (I'm just catching up after being out ill a while):

 > >>Here's a text proposal for 10.4:
 > >>
 > >>      When the Status field in the Binding Acknowledgement is
 > >>      greater than or equal to 128, the home agent MUST send
 > >>      it to the same link-layer address as the Binding Update
 > >>      came from.
 > > 
 > > I don't think this is right since it doesn't cover the case where a MN is
 > > deleting it's binding while off-link - a MN might do that if it's doing
 > > a "graceful" shutdown.  This would only apply if the IPv6 source address
 > > is the home address of the MN.
 > 
 > Yes. Add "... and the Source Address of the Binding Update is on the
 > home link ...".
 > 
 > >>Question: can this be implemented easily? Note that there are
 > >>multiple ways to do this, including flushing the neigh/dst
 > >>cache for the home address when responding to the MN.
 > > 
 > > The MN shouldn't respond to NS's for its home address, so flushing
 > > the neighbor cache wouldn't work, right?
 > 
 > Yes. Looks like forcing the address is the only possibility.
 > 
 > Jari

Is that really true that a MN won't respond to the NS?  We have a
SHOULD in this text from the latest Oct 28 draft in section 13.6.4 on
Returning Home for the non-error case:

   After the Mobile Node sends the Binding Update, the Home Agent MUST
   remove the Proxy Neighbor Cache entry for the Mobile Node and MAY
   learn its link-layer address based on the link-layer packet or cached
   information, or if that is not available, it SHOULD send a Neighbor
   Solicitation with the target address equal to the Binding Update's
   source IP address.  The Mobile Node MUST then reply with a unicast
   Neighbor Advertisement to the Home Agent with its link-layer address.
   While the Mobile Node is waiting for a Binding Acknowledgement, it
   MUST NOT respond to any Neighbor Solicitations for its Home Address
   other than those originating from the IP address to which it sent the
   Binding Update.

Doesn't the above text about the MN responding only to the HA handle
the issue of getting back the error'ed BA as well?  That is, assuming one's
implementation can deal with preserving the Proxy ND cache entry while
also soliciting for the actual MN just for this particular error case
packet (whose src on this NS must match the original BU dst)?

If agreed, then the MUST in the latest proposed/included text should
only be that the packet is sent to the local MN whose link-layer
address is obtained either through the link-layer address of the
original BU packet or by NS with the MN itself.  The *protocol*, due to
the MN responding to HA's NS, handles this error case already.
Implementations should be free to choose which way to satisfy getting
the BA back, error'ed or not.  One *could* take the NS approach anyway
regardless of the spec, since the MN doesn't yet know an error is due
it, and then send the error'ed BA back.  And things would work except
for a potential conformance tester complaint seeing the NS/NA, right?

Also, I was concerned about this new link-layer address MUST
requirement in the text that ended up (now) in 11.0.2 that was
suggested above to handle this error case.  We didn't have a MUST
requirement on implementations before to pass/preserve/deal with a
link-layer address across v6 stack, IPsec, and mobility module, both
inbound and outbound on MH packets.  I note that ha-ipsec-01 requires
in section 5.1 that even on the home link a BU MUST come in with an
IPsec header, so this new link requirement really means at least all those
areas in my previous sentence must coordinate, even if "passively", on
the original source link-layer address associated with a packet.  I
don't think that this error path case is sufficiently different to
require this link-layer MUST when the non-error case already has a
protocol way to do it without looking at the original BU's link-layer
address.

   -- Marc --