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

From: "O'Neill Alan" <[email-masked]>
Date: Mon, 29 Mar 2004 02:47:01 -0500

Ok so I am hoping to clarify some of the alternative interpretations of
RFC3344bis, that I think we have discussed wrt dynamic HoA allocation, given
that RFC3344bis is mute on the point.

-------------------------

1) The first interpretation is that the address allocation lifetime in
RFC3344bis is not tied to the binding lifetime, and by default is UNDEFINED
(static=infinity until otherwise defined ?). Hence when the MN returns home
and cancels a binding then the packets remain deliverable because the MN
still has the address. This means that RFC3344bis does not deliver an address
life-time, and Charlie feels any such lifetime is out of scope of RFC3344bis.
I am not sure how many products interpret RFC3344bis this way.

FIX to RFC3344bis: So to fully support this interpretation in RFC3344bis,
some text needs to be added into to state this clearly.

Future Work outside of RFC3344bis: The additional work here then is define
how the address lifetime moves from UNDEFINED to DEFINED, and the address
subsequently recovered so that the HA can reallocate safely. This could use
MIP or non-MIP mechanisms.

-----------------------

2) An alternative view is that the default address lifetime is equal to the
MIP binding lifetime, such that the HA recovers the dynamically assigned HoA
on binding cessation. This works fine for virtual home networks (ie
cellular), such that the MN cannot return home and lose its address
prematurely. However, if a real home can be visited (such as enterprise) then
we have the forced in-session address deallocation problem on binding
cessation. I do know of MIP products that ship today that employ this
interpretation of RFC3344bis.

FIX to RFC3344bis: So to fully support this interpretation in RFC3344bis,
some text needs to be added to state this clearly, clearly indicating that
the address is deallocated automatically on returning home.

Future Work outside of RFC3344bis: In addition, some additional work then
needs to occur to address the uncontrolled address deallocation problem when
returning to real home networks, which for example could use the HALR/HALG
model. The interop with non_MIP address management mechanisms would also be
useful here.

---------------------

3) A third interpretation is not to interpret. By this I mean that RFC3344bis
leaves the address lifetime as UNDEFINED with no explanation, and hence some
systems can make it static whilst others can make the address lifetime equal
to the MIP lifetime.

FIX: Do nothing and wait for interop problems before fixing which I assume
no-one wants.

----------------------

A Personal Opinion

So I am generally troubled by RFC3344bis going ahead with interpretation 1,
given that it defines an incomplete entity lifecycle for a commercially
valuable entity. 

I also feel that the default lifetime in RFC3344bis (MIP lifetime v
UNDEFINED) should be representative of the major usage case, with future work
adding refinements via extensions such as HALR/HALG, and other non-MIP
mechanisms. I know of a significant requirement for dynamic address lifetimes
that are tied to the MIP session duration, because operators want to
statistically multiplex the address block across the MN population, and to be
able to recover addresses on MN failures (after MIP time-out). 

Personally, I cannot envisage a substantial requirement for dynamic address
allocation with UNDEFINED (static) lifetimes, given the dominant need for
statistical reallocation. However, if we do have a significant installed base
of, or requirement for, interpretation 1 in RFC3344bis, then I guess the wg
needs to consider this (info/views?), and then maybe we have to rely on
HALR/HALG type stuff even for the common case of address lifetime=binding
lifetime.

Alan.

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by other is 
strictly prohibited.  If you are not the inteded recipient please contact
the sender and delete all copies.
========================================================

-- 
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: Hans Sjöstrand <[email-masked]>
Date: Mon, 29 Mar 2004 11:50:32 +0200

Alan,

Í agree that there might in some scenarios be nive to add address 
allocation lifetimes to Home Agent implementations, especially in the 
cases where the home agent for some reason maintain an address pool. In 
these scenarious it might be whise to do a extension to mobile IP to 
perform address management. This is best started with a draft and then 
the WG will decide if it's worthwhile work to take on.

But to state saying that 3344 or even worse, Mobiel IP, is broken 
because there are no address lifetime management specified is going to 
far. I tried to explain that how the home agent allocates a address to 
the MN as the MN home address is not at all a business for the Mobilr IP 
protocool.

An example

Mobile IP should handle that computers can roam away from the home 
network, and still maintain all that it could do before. But not more! A 
computer that is turned on on a local LAN most often uses DHCP is 
dynamic address allocation is used in that LAN environment. The sysadmin 
has decided a lease time for these, quite common is one hour. So, the 
computer gets a lease for 1 hour, and must make sure that it's renewed 
before that expires if the computer intends to continiue using it. Note 
that the DHCP server *does not* arp to make sure that the computer still 
are out there and alive, and very seldom does the computer leave back 
the lease to the server before it expires.

Add mobile IP to this, Now we have a MN thats booted somewhree in the 
world, he registeres with it's HA. The HA must now make sure that it 
allocates a address to this MN, and that the HA maintains that address 
aslong as the MN is registerd with the HA. Thats his task. His task *is 
not" to leave back the IP address to the DHCP server if the session is 
ended.

When/if the MN returns home, the MN deregisteres with the HA and thereby 
releving the HA from it's task to maintain the address and now takes 
responsibility to maintain it himself.

This quite clearly illustrate that there are no need to have any more 
explicit adress management build into Mobile IP. There is no connectno 
between teh lifetime of the binding, adn the lifetime of the lease. How 
a HA allocates addresses are deployment specific. RFCF3344 should not / 
need not to be burdend by it. The HA implementation of course needs to 
be burdend with it, but thats a different thing.

Unfortunately I haven't had time to read Naveen PaulKandasamy and Kent 
Leung's draft about this. Hopefull it is compatible with what I wrote ;-)

Regards
/// Hasse

---

From: "Jee J.Z." <[email-masked]>
Date: Mon, 29 Mar 2004 22:30:45 +0100

Hi O'Neill,

IMHO, I think the third interpretation would be better. I think the HoA
lifetime is implementation dependent, since some small enterprises may
prefer 'permanent' HoA allocation while other large ISPs may prefer
dynamical one. Moreover, I don't understand why we should put forward this
issue (?). I mean, I think HoA allocation should be independent of any other
CoA configurations. When a MN boots in a foreign network and needs dynamical
HoA allocation, can't it just utilize its acquired CoA and NAI to request
its HA to act as a proxy DHCP client to ask for a  HoA from a DHCP server on
its home network? From then on, the MN renew its HoA lifetime independently
if needed. Why shall we worry about the loss of HoA when the MN returns
home?

I must be missing something obvious.

Cheers,
Jee

---

From: Kent Leung <[email-masked]>
Date: Mon, 29 Mar 2004 15:54:29 -0800

Here are my 2 cents .. :)

The registration lifetime is used for aging the mobility binding -
RFC 3344 states "The number of seconds remaining before the registration
is considered expired."  There are no message fields or extensions to specify
address lease time in any RFC.  The only plausible way to effectively manage
a reusable address pool is by releasing the address when mobility binding is
no longer needed.  So in effect, the address lease lifetime is the same as the
registration lifetime.  My interpretation,  #2 on Alan's list :)  Though 
for 3344bis,
I think since specification does not cover how address management works, it
shouldn't be required to cover what's wrong with it.

To support an address management function, here are some common scenarios.

1) DHCP is common in Enterprise and can be used as an external protocol 
with some
integration of DHCP and Mobile IP (see Proxy DHCP draft) using extensions.
2) Local pool managed by the HA requires some integrated Mobile IP 
signaling to maintain
the address lease.
3) AAA manages address pool in conjunction with HA.  HA notifies AAA server 
using
RADIUS messages when MN's session starts and stops.  From HA's perspective, 
this
scenario is like #2 where Mobile IP signaling is enhanced to provide 
information on when MN
is done with leased address.

For cases #2 and #3, there is the assumption that MNs don't support 
DHCP.  In general,
there are 2 methods for supporting address management, external protocol 
such as
DHCP or address management information in Mobile IP messages when HA manages
the address pool or interacts with AAA server.

Unfortunately, we had written our draft awhile back and didn't cover the 
return home
scenario as it's not common.  For Enterprise, DHCP using existing draft 
would work.
Typically SPs don't need to have MNs return home.  We welcome inputs for
ideas such as HALR/HALG for solutions there. :)

Kent

At 11:50 AM 3/29/2004 +0200, Hans Sjöstrand wrote:
>perform address management. This is best started with a draft and then the 
>WG will decide if it's worthwhile work to take on.
>
>But to state saying that 3344 or even worse, Mobiel IP, is broken because 
>there are no address lifetime management specified is going to far. I 
>tried to explain that how the home agent allocates a address to the MN as 
>the MN home address is not at all a business for the Mobilr IP protocool.
>
>An example
>
>computer that is turned on on a local LAN most often uses DHCP is dynamic 
>address allocation is used in that LAN environment. The sysadmin has 
>decided a lease time for these, quite common is one hour. So, the computer 
>gets a lease for 1 hour, and must make sure that it's renewed before that 
>expires if the computer intends to continiue using it. Note that the DHCP 
>server *does not* arp to make sure that the computer still are out there 
>and alive, and very seldom does the computer leave back the lease to the 
>server before it expires.
>
>not" to leave back the IP address to the DHCP server if the session is ended.
>
>between teh lifetime of the binding, adn the lifetime of the lease. How a 
>HA allocates addresses are deployment specific. RFCF3344 should not / need 
>not to be burdend by it. The HA implementation of course needs to be 
>burdend with it, but thats a different thing.
>