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

From: Alper Yegin <[email-masked]>
Date: Mon, 10 Sep 2001 12:41:09 -0700 (PDT)

This issue was included in the Conenctathon 2001 list:

 [5] Deregistering a care-of address (section 8.5)
 
 The draft says that binding acknowledgement MUST be sent using a routing
 header in the same way as any other packet sent to a mobile node using a
 care-of address.
 
 BUT, what should be the care-of address used in the case this was a
 deregistration? Draft should specify that it MUST be the care-of address
 used in the triggering binding update. (similarly, draft already specifies
 that for failed binding updates case).

MN should put wherever it wants to receive the BAck as the CoA in this 
de-registration BU.

alper

> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to 
[email-masked] using -f
> X-Accept-Language: en
> MIME-Version: 1.0
> To: [email-masked]
> Subject: Re: [mobile-ip] Mobile IPv6 draft revision
> Content-Transfer-Encoding: 7bit
> List-Archive: <http://playground.sun.com/mobile-ip/>
> List-Owner: <mailto:[email-masked]>
> List-Subscribe: <mailto:[email-masked]?body=subscribe>
> List-Unsubscribe: 
<mailto:[email-masked]?body=unsubscribe>
> 
> Comments inline
> 
> Peter
> 
> Parijat wrote:
> > 
> > That does not answer the basic question that a BA might be addressed to a 
CoA
> > which is no longer valid.
> > 
> 
> Well, if a MN send the deregistration from a Care-of Address it does
> not want to use (any more) asking for an acknowledgement, it should
> reasonably stay there for some minimum of time. Leaving before the BA
> is received is OK though, the MN may wish to retransmit the deregistration
> from its new location - but with the interpretation from Marc Hassons mail
> (7 sep, 18:31) that will be OK as well.
> 
> > I would suggest that cache deletion requests come in with zero lifetimes,
> > (perhaps even in case (a)?), and the acknowledgements to _deletion_ requests
> > be sent to the home address of the mobile node.
> 
> But maybe the MN just wants to stay away in privacy for some time for some
> reason - that happens, I guess. I think Marc's proposal will work.
> 
> > 
> > Of course, I am assuming that there is some need to keep a conceptual,
> > specific difference between binding cache deletion requests and binding
> > updates which merely have a very short lifetime.  It seems to be a neat 
thing
> > to have a separate binding deletion message rather than one which is a
> > degenerate case of a normal BU (okay, okay, zero lifetime BUs _are_
> > degenerate cases of normal BUs, but you know what I mean).
> > 
> Actually a nice idea, but...
> > --
> > Parijat Mishra
> > R & D Engineer,
> > Centre for Wireless Communications, NUS
> > Tel: (65)8709353

alper

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Sep 2001 11:26:52 -0700

Hello folks,

<...still catching up!...>

Here is an attempt to summarize the discussion and formulate a solution
for the problems with deregistration vs. Binding Cache entries, when
attempting to deliver a Binding Acknowledgement resulting from an
authenticated deregistration (a Binding Update with zero lifetime).

- My quickie solution about disallowing zero-lifetime Binding Updates is
  unlikely to work, so should not be used.

- A zero-lifetime Binding Update is to be treated slightly differently
  than Binding Updates with nonzero lifetimes, insofar as the Binding
  Acknowledgement should not be handled by the usual rules for Binding
  Cache entries.  This is because the Binding Cache entry is likely to
  be already invalidated.  Marc's point about retransmission makes this
  point elegantly.

- The rule for handling zero-lifetime Binding Update is to be based
  on Marc's formulation:

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

- The Care-of Address to be deregistered is located in the
  Alternate Care-of Address Sub-Option if that is present.
  Otherwise, it is located in the Source IP Address field of the
  IPv6 header of the packet containing the Binding Update.
  This is the same as has already been specified up until now.

- The Binding Acknowledgement is to be sent to the Mobile Node
  at the address in the Source IP address field of the Binding Update.
  If this is not the same as the Mobile Node's home address, then
  the Binding Acknowledgement is to be delivered using a Routing
  Header to the delivery address, _as if_ there were a Binding
  Cache entry associating the mobile node's specified delivery
  address with its home address.  This is the main point of
  difference with previous specification, and allows the mobile
  node to reliably turn off delivery of packets to its care-of
  addresses without having to be on the home network.

Please let me know if this makes good sense.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 21 Sep 2001 12:29:21 -0700

Hello folks,

Here's the new text in Section 8.5 which I have drawn up to fulfill the
requirements suggested by the previous discussion.  Even though the
reasoning was complicated, I think the actual result is pretty simple.

=========================================================================

   The packet in which the Binding Acknowledgement is returned
   MUST meet the specific authentication requirements for Binding
   Acknowledgements, defined in Section 4.4.  Furthermore, if the packet
   is to be sent to the mobile node at any address other than the mobile
   node's home address, it MUST be sent using a Routing header (even if
   the binding was rejected).  The intermediate IP address, to which 
   the packet will be delivered immediately before the home address, is
   determined as follows: 
   
    -  Whenever the Binding Update is accepted with a nonzero lifetime,
       the routing header will be constructed using the care-of address
       as described in Section 8.9. 
   
    -  Otherwise, the routing header will be constructed using the 
       Source IP Address of the packet containing the Binding Update.

=========================================================================

Suggestions for improved text are always appreciated.  My current plan is
to have the section related to Home Agent handling of deregistration to
just refer to this part of section 8.5, and to delete the (wrong) part
of section 5.2 which had mentioned use of the Routing Header.

Regards,
Charlie P.