Subject: RE : [Mip4] RFC3344biz Dynamic HoA bug ?

From: "KASSI-LAHLOU Mohammed FTRD/DMI/CAE" <[email-masked]>
Date: Thu, 25 Mar 2004 10:11:18 +0100

Hi,

How about if the MN deregisters by sending RREQs with binding CoA=HoA and lifetime not 0 (= binding lifetime)?

Kassi

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de O'Neill Alan
Envoyé : jeudi 25 mars 2004 03:03
À : [email-masked]
Objet : [Mip4] RFC3344biz Dynamic HoA bug ?

Wg,

I think I may have discovered a hole / corner case in RFC3344biz, but I thought a bit of discussion might be beneficial before putting it into the tracker.

A MN places 0.0.0.0 into the Home Address field of the RREQ to trigger assignment by the Home Agent. The address allocation lifetime is assumed to be the MIP binding lifetime because no other information exists, and permanent allocations are of course not good. However, what then happens when the MN returns home ?

The MN cancels the binding, and according to the spec ceases to use MIP signaling. However, if the address lifetime is tied to the binding lifetime then the MN just lost its address. I assume this might not have been spotted before because we are mostly focusing on cellular systems where the MN has a virtual home network, and hence cannot ever get home, but given the scope of RFC3344 this 'hole', if people concur, needs to be filled. The following options spring to mind.

a) We define a Home Address Lease Grant (HALG) Extension which is optionally returned by the HA in addition to the binding lifetime. The extension specifies an allocation lifetime that is greater than the binding lifetime (clearly cannot be less, and there is no point using it, if it is equal). A MN that returns home is then able to cancel its binding, but can maintain the use of the home address to avoid session disruption. Specifically, one can imagine the HA adding this extension during that deregistration. Note also that this separation of binding lifetime from address allocation lifetime also enables a MN to terminate MIP bindings in a foreign network (ie for
efficiency) yet still maintain the home address at the HA, so that it can later restart MIP with the same HoA and HA.

b) We might also want to consider defining a Home Address Lease Request
(HALR) Extension, with the MN requesting a lease-time and the HA reducing it to an acceptable value, with lease termination being signaled by requesting a zero lease-time (by analogy with binding lifetime processing).

c) The MN could then continue to use MIP to refresh this home address lease by periodically resending RREQs with binding CoA=HoA and lifetime=0, such that the HA can then return a new lease. Alternatively, the MN can report, and then maintain, the home address via DHCP (assuming some HA/DHCP back-end link), with these two options (and maybe others) being distinguished by flags in the HALG.

	Now in terms of RFC3344biz progression, as a first alternative we could minimally add clarification text that states that a MN that has been dynamically assigned a Home Address via MIP, will explicitly lose that address when it deregisters. This means that deregistered MNs that return home cannot maintain sessions, and must then go to DHCP (or whatever) to get a new address for local connectivity. Whilst non-ideal technically, it at least lets RFC3344biz progress with clarity. We could then define HALG, HALR and associated processing in a new document. 

	The second alternative is to remove dynamic home address allocation from RFC3344biz, and put that into the new doc along with the HALG and HALR work, so that RFC3344biz does not go forward with the corner case of returning home.

	The third option is to wrap the HALG, and minimal associated processing, into RFC3344biz to support the MN returning home, and hence to fix the corner case. The HALR can then be left to the new doc. 

	The fourth option is of course that I am mistaken about the corner case and we can all sleep soundly.

Thoughts ?

Alan

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Bjorn Andersson <[email-masked]>
Date: Thu, 25 Mar 2004 12:45:52 +0200

On Thu, Mar 25 2004, at 10:11:18 +0100, KASSI-LAHLOU Mohammed FTRD/DMI/CAE wrote:
> How about if the MN deregisters by sending RREQs with binding
> CoA=HoA and lifetime not 0 (= binding lifetime)?

I think this would be a good solution but it would break backwards
compatibility. This may be an issue for some.

  Bjorn

-- 
Bjorn Andersson <[email-masked]>
PGP id 5AFC144B