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

From: Patrice Calhoun <[email-masked]>
Date: Mon, 9 Apr 2001 11:29:07 -0700

Here is a question for you Sandy.

Is it at all possible for Mobile IP to provide the mobile's home address,
as it is done today, 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.

That would make this whole thing so much simpler.

PatC
>The following message never made it to the mailing
>list so I'm resending it. 
>
>-----Original Message-----
>From: Sandy Thuel [mailto:[email-masked]] 
>Sent: Thursday, April 05, 2001 11:32 AM
>To: James Kempf; [email-masked];
>[email-masked]
>Subject: RE: [mobile-ip] dynamic home addressing as a WG item??
>
>
>
>Hi James,
>
> Please see my comment in-line.
>
>> >I hear clearly that you'd rather NOT use DHCP
>> >but you haven't yet answered the question of
>> >whether or not configuration options are important.
>> >Are you implying that "address provisioning" is
>> >all that matters and other configuration options
>> >are NOT important? Or are you saying that no
>> >matter what configuration state is needed, Mobile
>> >IP should provision it?
>> 
>> If by "configuration options" you mean service discovery,
>> then I think there are better ways to do this (DNS SRV RR
>> interdomain, SLP intradomain, maybe LDAP also).
>
>No. I wasn't referring to service discovery but
>to parameters which are typically associated
>with DHCP options [RFC2132] such as subnet mask,
>domain name, gateway router(s), DNS server(s), 
>NTP server(s), etc.  Please correct me if I'm 
>wrong but my understanding was that these service
>discovery protocols don't allocate all these 
>parameters.  And even if they do, what is
>the extent of their deployment and support in
>today's networks to rely on them for mobile
>configuration support?
>
>> 
>> I think a case can also be made for provisioning a mobile
>> node's service access information via AAA if the mobile
>> node is away from home and needs to obtain service
>> access information from the home domain. This is
>> one case that I have some difficulty seeing DHCP solving
>> without massively twisting it from its initial design center.
>
>I agree that AAA is, in principle, a promising 
>candidate to be a repository for the configuration
>options I'm referring to and it could be a better
>alternative than DHCP.  Do you know of any efforts
>to extend the AAA infrastructure to support this?
>In any case, if I want a solution for today, I
>still think DHCP is the only game in town...
>
>> 
>> >Good observation.  Users that power-up devices
>> >frequently are likely to be less tolerant of
>> >configuration latency than those who keep their
>> >devices powered on for extended periods of time
>> >(e.g., cellphones).  But do you have any idea
>> >as to what latency is considered tolerable in
>> >either case?
>> 
>> This is a human factors question I can't really answer.
>> Compare the amount of time it takes for your mobile
>> phone to come up when you first turn it on with how
>> long it takes Windows to boot on your laptop. Somewhere
>> in the middle, the latency becomes annoying if you
>> tend to turn the device on and off frequently.
>> 
>
>If improving on a Windows bootup time is
>our baseline, configuration latency is
>not a problem at all :-)
>
>> 
>> >I didn't say that any protocol changes are
>> >necessary (unless the MN requires anything more than
>> >a home address, as per my comment on the following
>> >question).  What is needed is some *implementation*
>> >changes on home agents to provide DHCP
>> >proxy services.  As for what this implementation
>> >entails, one solution, as you implicitly suggest,
>> >is to have an API between the HA and a co-located
>> >DHCP proxy agent.  Rather than keeping the HA
>> >and DHCP proxies logically separated through an
>> >API, the implementation of DHCP proxies
>> >could be more tightly integrated with the HA.
>> >The issue here is not to debate on which is the
>> >best way to implement proxy services on home
>> >agents but to discuss whether or not ANY
>> >implementation changes to HA's to provide such
>> >services is a feasible requirement at this stage,
>> >when MIPv4 is already being deployed.
>> 
>> An API doesn't necessarily mean that the DHCP
>> proxy is physically separate, the API may be
>> provided by the operating system.
>
>Yes. That's what I meant when I said the DHCP
>proxy and HA can be "logically" separated by
>an API.
>
>> 
>> But I don't see any problem with having the
>> HA do DHCP out the back end, this is
>> an implementation choice.
>
>Agreed.  Now, we have agreed that there are
>different ways to implement this.  This settles
>affirmatively the question as to whether or not 
>it is implementable.  The more important question
>I'm trying to get at is whether or not it is
>feasible to require HA's to support this (picking
>a favorite implementation strategy of choice).
>Any thoughts?
>
>> 
>> 
>> >So you're implying once again that you don't
>> >care about any other configuration besides an
>> >IP address, correct? Note that if you DO care
>> >about anything other than an IP address, there is
>> >no other recourse but to extend Mobile IP to
>> >allow the MN to ask for it and get it from a
>> >HA.
>> 
>> As I mentioned above, I think there are other, better
>> ways of provisioning service discovery on mobile
>> nodes.
>
>I hope my clarification above on what I was
>referring to as configuration options clarifies
>what I meant by this question.
>
>Thanks,
>Sandy

---

From: Michael Thomas <[email-masked]>
Date: Mon, 9 Apr 2001 12:11:47 -0700 (PDT)

> provide its address, but it is only looking for provisioning
services.

   Yes. It's a DHCP INFORM.

	     Mike

---

From: "Sandy Thuel" <[email-masked]>
Date: Mon, 9 Apr 2001 17:25:41 -0400

Hi Pat,

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

> and have the mobile issue a DHCP message NOT
> to request

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.

> 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
* 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.

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?

Thanks for your comments!

Sandy