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

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

The following message never made it to the mailing
list so I'm resending it. 

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, April 05, 2001 9:17 AM
To: Sandy Thuel; [email-masked];
[email-masked]
Subject: RE: [mobile-ip] dynamic home addressing as a WG item??

At 12:14 PM 4/4/01 -0400, Sandy Thuel wrote:

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

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.

Did you have anything else in mind besides service discovery?

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

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

But I don't see any problem with having the
HA do DHCP out the back end, this is
an implementation choice.

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

                 jak