Subject: RE: FW: [mobile-ip] dynamic home addressing as a WG item??

From: Patrice Calhoun <[email-masked]>
Date: Tue, 10 Apr 2001 07:26:41 -0700

=>> Is it at all possible for Mobile IP to provide the mobile's home address,
>> as it is done today,
>
>To set the record straight: where does Mobile IP
>get the home address in your model? From an
>address pool in the HA (i.e., NOT through DHCP)?

How the HA allocates the address really is outside the scope of the protocol, 
and is purely an implementation decision. If an HA wants to issue DHCP requests
on behalf of the mobile, then so be it. If it wants to mantain an internal
address pool, which btw is pretty simple since it ALWAYS knows when the mobile
node is registered, then that's ok too.

>
>> and have the mobile issue a DHCP message NOT
>> to request
>> an IP address, but only to retrieve configuration information. So it would
>> provide its address, but it is only looking for provisioning services.
>
>Although the DHCPINFORM message in the DHCP standard
>was created to enable this very thing (i.e., a
>node with an externally configured address to
>query for some other local configuration
>parameters), DHCP client/server implementations
>didn't support it until very recently.

ok, so that could be used.

>
>>
>> That would make this whole thing so much simpler.
>>
>
>I don't agree that a model where you get the
>address from the HA and configuration options
>from DHCP would make this much simpler for the
>following reason.  Once the HA starts allocating
>addresses you have to now worry about:

>* provisioning/sizing the HA address pool

Sorry but this happens in one place or another (DHCP or HA). An HA has a limited
subnet size, so this isn't rocket science. If people want to use DHCP on the
backend, again the HA could issue the DHCP request on behalf of the mobile, and
no Mobile IP changes are required in this WG.

>* setting up some mechanism for reclaiming
> HA-allocated addresses (the equivalent of
> DHCP lease renewals) when the client no longer
> needs the address or when the HA who conferred
> an address has died.

When the HA determines that the mobile is no longer registered (either via an
explicit deregistration or soft-state), it would send the appropriate message to
its DHCP server on behalf of the mobile.

>
>On the latter point,
>do you assume the home address given by the
>HA is leased? If so, do you suggest changing the
>Mobile IP standard to require registration
>renewals while the mobile node is at home (just
>to renew the home address lease)?  If the
>address is not leased, how do you prevent rogue
>address problems?

I do not understand what a rogue address problem is, so perhaps you could
clarify.

PatC

---

From: "Sandy Thuel" <[email-masked]>
Date: Tue, 10 Apr 2001 13:57:34 -0400

Hi Pat,

Let me sum up and clarify some points. As
you suggested, it is possible to have the
following dynamic addressing and configuration
model for MNs:
 1- MN gets a home address from the HA in its
  registration reply.  The HA can allocate this
  address however it wants (be it through DHCP,
  its own address pool, AAA as suggested by jak,
  etc.)
 2- After the MN is registered with the home
  address it got in step #1, have a DHCP client
  on the MN send a DHCPINFORM to its home network
  (and yes, it would have to be reverse-tunneled)
  to get whatever other configuration options it
  needs.
 3- The MN is happy: it got its home address and
  all its configuration options.

 4- Now, say the MN returns to its home network.
   It sends a de-registration message to its HA,
   and continues to use the home address it got
   through some unknown means from Mobile IP when
   it powered up away from home.
 5- Some time after the MN de-registers, the
   MN powers down.  It no longer needs its
   home address but can't tell its HA because it's
   not supposed to be sending any registration
   messages to it since it's at home.
 6- Repeat steps 1-6 for a large number of MN's and
   you can imagine what'll happen to the address
   pool of whoever served as the address-allocator.
   This is what is referred to as a rogue address
   problem (i.e., addresses an address-allocator
   can't re-use because it has no safe
   way of reclaiming them).

 [Note: you can construct similar scenarios where
  say an operator reconfigures the address pool
  of the address-allocator and needs to reclaim
  or change a previously assigned address to the
  MN but can't get to it because there's no
  mobile IP message for the HA to inform this to
  an un-registered MN]

So the problem with the model you suggest
is that it is incomplete.  It assumes the MN
doesn't ever have to know who really allocated
its home address.  But this *isn't* true.
It DOES matter to the MN who allocated its
home address because there needs to be some
means for the MN to communicate with
its address-allocator so that it can defend its
address or release it when it no longer needs it.
Likewise, the address-allocator has to be able to
maintain its right to reclaim any previously
allocated address by telling the MN to give it
up.  So what are solutions to this problem?

Solution 1: Change the Mobile IP standard to
  make sure there is always a communication
  path between the MN and its HA regardless of
  its location.  In other words, *require* the
  MN to send registrations even while it's at
  home so that it can periodically tickle the
  HA to defend the home address that it (i.e.,
  the HA) or some other address-allocator (eg.,
  DHCP) gave to the MN.  In this solution,
  Mobile IP registration messages double-duty as
  registration and address renewals while the
  MN is away from home while they only serve the
  purpose of address renewals while the MN is at
  home.

Solution 2: Use Mobile IP to defend the home
  address while the MN is away from home
  (through registration messages that trigger
  the back-end renewals) BUT make the MN assume
  responsability for defending its home
  address when it returns home, taking Mobile IP
  completely out of the loop.  This is what
  DHCP proxy does: a DHCP client on the MN
  assumes control of defending the home address
  when the MN returns home.  This way, it
  avoids having to change the Mobile IP standard.

Solution 3: Decouple addressing and configuration
  as much as possible from Mobile IP and let the
  MN handle it at all times.  In other words, have
  a client that is specific to the address
  allocator (such as a DHCP client) directly
  handle transactions with the address allocator,
  regardless of whether the MN is at home or in
  a foreign network.  This is what Transient
  Tunneling does.

Sorry for the long message but I really hope this
gives a clear picture of why this problem isn't
as straightforward as it looks at first glance.

Does this answer all your questions, Pat?

Regards,
Sandy