Subject: Re: [mobile-ip] Mobile IPv6 draft revision

From: Marc Hasson <[email-masked]>
Date: Fri, 7 Sep 2001 18:31:16 -0700 (PDT)

Hi Charlie,

 > > The deregistration may be sent from
 > >  a) the Home Address (any Lifetime)
 > >  b) the latest Care Of Address (Lifetime = 0)
 > >  c) another address (Lifetime = 0)
 > > 

...

 > I think this is a basic inconsistency in the use of the Binding
 > Update, and I thought of a fairly trivial-to-implement solution:
 > 
 >    + Disallow Binding Updates with zero lifetimes in cases (b) and (c).
 > 
 > If the Binding Update, intended for deregistration, had a
 > lifetime of 1 second, then that would be enough time to use
 > the existing Binding Cache entry for delivering the Binding
 > Acknowledgement to the still non-local mobile node.

I think there are more implications here beyond sending off the
immediate BA.  Perhaps some more clarifications can be added.  What if
the BA is lost on its way to the MN?  The MN doesn't know the HA
actually received its deregistration BU so its going to have to
retransmit its BU.  Likely to be at more than a 1 second interval?
Meanwhile the HA has already deregistered and destroyed the binding.
On subsequent BUs is the HA supposed to *know* that a 1 second
lifetime is not enough to be useful so don't go through the true
registration stuff (DAD/ND, etc.) but just send a BA back to the MN to
"acknowledge" the deregistration that actually "lives" 1 more second?

Whats wrong with keeping the special deregistration lifetime of 0 on
the non-Home Address BUs?  (I won't ask why a zero is not mandatory on
the returned-to-home ones too so one path in the BU processing code may
be quickly selected.)  Just have the HA interpret the zero as the MN
asking "please confirm via a BA using this BU's info that I'm no longer
registered with you"?  This also sidesteps the issue of the lost BA and
getting back "success" vs. "not HA for this MN" errors on the
retransmission.  Both would be consistent success instead of implying
some kind of operational error for merely a lost packet.  The BCE lives
long enough, or exists temporarily/updated from this BU, just to get
the BA reply into some transmission queue before disappearing due to
the BU's zero lifetime.  Seems to me this takes care of the issue of
the MN retransmitting for a lost deregistration BU or BA without having
the HA go through any kind of registration "dance", having been misled
by a non-zero lifetime or burdened with more rules about lifetime
values.

What am I missing?  Another way to look at this is to simply state that
for deregistration the BA is constructed from the BSA-secured
deregistration BU's info (error #139 is one exception to "BSA-secured"
but for that and other errors the BA is built the same way).  Its *not*
exactly like sending "any other packet" as stated in 8.5/8.9 using a
BCE.  The earlier change you suggested, not quoted in this note, will
clean that up.  For deregistration BUs it may help to state a routing
header is included in the BA, built using the BU's info, only if the
deregistration BU was of non-local origin.  The BCE itself can, in
fact, be deleted before sending the BA for all deregistration cases.

   -- Marc --

---

From: "Peter Grimstrup (TED)" <[email-masked]>
Date: Mon, 10 Sep 2001 16:17:33 +0200

Hi Marc and Charlie,

Agree with Marcs comments and suggestions.

Peter