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

From: "Sandy Thuel" <[email-masked]>
Date: Mon, 2 Apr 2001 17:37:08 -0400

Hi Folks,

As most of you know, there are two current drafts
dealing with the issue of how to dynamically 
configure the home address of a mobile node using
DHCP.  These are: the DHCP proxy draft by Steve
Glass and the Transient Tunneling draft by
Sandy Thuel, et al.  Since we didn't get a chance
to present the new drafts at IETF50 in MN, we 
want to elicit feedback from you  on the mailing
list in the hope of expediting our progress on 
this issue.

Although the DHCP proxy and Transient Tunneling
drafts address the same problem, there are several
key differences at the core of these mechanisms.
Instead of comparing/contrasting them, it is 
far more useful to get feedback from you on 
the following key questions:

1) What is the real value of DHCP options to mobile
  nodes? 

2) How important is it to minimize the power-up 
  configuration latency of a mobile node? 

3) How feasible do you think it is to 
  require changes on Mobile IP home agents 
  to provide a new service (e.g., DHCP proxy 
  service support)?

4) How do you feel about the idea of adding
   DHCP-specific extensions to Mobile IP?
  
All of us can stand to benefit from a serious
discussion on these issues.  PLEASE take a few
minutes to offer your perspectives/comments on 
these questions, even if all you have to say 
is that you don't care.  

Thanks!

Sandy Thuel

---

From: "Phil Neumiller" <[email-masked]>
Date: Mon, 2 Apr 2001 19:51:39 -0500

Hi Sandy,

Some comments below (this is so long that you might
want to get a beverage).

----- Original Message -----
From: "Sandy Thuel" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
> 1) What is the real value of DHCP options to mobile

I guess I would even go a step further and question
what is the real value of DHCP itself to mobile nodes?
In the short term, it appears to be of quite high value.

However...

In my K-mart crystal ball (kind of cracked and fuzzy) I
see lots of cheap wireless devices that will be used to
living in MANETs *or* in infrastructures in the future.  I see
this big train wreck of who gets to pick the mobile's IP
address coming.  I suppose, if its a Windows type of
box, it will be UPnP, if its Bluetooth type of device,
well um, we need to wait until the BT SIG releases the
next spec, if its an 802.11b device, I don' know of
*any* commercial MANETs on 802.11 (know of some
in labs!), if its a 3G device I am not sure yet but,
I am pretty sure you can rule out DHCP on a
CDMA radio!..., then we have zeroconf in there too
along with SLP, Jini, and all kinds of other stuff trying
to figure out what the heck is going on and what the IP
addr and COA is (did I forget to mention ou friend
MIP acting as an MN). If it starts out as a MANET
MN and wants to hand up to being a full fledged up routable
fixed citizen like in a docking station I don't know what
the best answer is currently.  Thank goodness we don't
have micro-mobility to worry about anymore!!!  At least
for now...

In the current home or enterprise WLAN/WPAN
markets the sheer simplicity of DHCP brings joy
to many people's hearts.  However,  in my crystal
ball I see a darker future of sheer chaos.  DHCP is
basically founded upon a client server model, an
anachronism in today's SAN infested B2B IP planet
that is rapidly going peer-2-peer, as fast as you can
say gnutella (that's April 2001 for Napster).

So what are we left with?  Burning IEEE MAC
addresses into the foreheads of everywireless device and
doing RARPs?  MANET addressing (a matter with its own
set of controversies)?  Or a host of other jihads that
I am sure could be enumerated (please don't).

>   configuration latency of a mobile node?

Are you are saying that DHCP would be a signficant
portion of this?  What proportion?  Do you have a guess?
Do you have analysis or measurements?  Would it be milliseconds,
seconds?  Depending on the link layer used, power up
configuration has a huge standard deviation all on its own.
Of course we must add DHCP latency onto that directly.

>   to provide a new service (e.g., DHCP proxy

Would need to be done in FAs too (for MIPv4)?

>    DHCP-specific extensions to Mobile IP

NO.  This is *EVIL*,  and a very terrible idea.  I never
want to see these words again!  :-)  No really, this is probably
not necessary.  At least in the protocol sense.  Could this not
be done by some clever spoofing inside an AR where the
DHCP server spoofs the FA/HA but hands out the actual
address?  I know this is kind of an implementor's hack, but
to change MIP enmeshes something so systemic as
DHCP with something so systemic with MIP and it makes
me say want to say YUCK really loud.  I actually prefer the
coding hack to the design hack!

When I re-read my comments I find they are of extremely
limited use (low S/N ratio) so in summary let me give you
my recommendation (worth about 2 cents these days):

1).  We must figure out who wins the "I assign the address
       to the MN battle" in all possible scenarios including
       handoffs from MANETS (infrastructure-less) to
       MIP supported networks and handins and outs of
       zeroconf/DHCP/slp/UPnP/(MIP ^ MANET) supported
       subnets [do all the logical permutations].

2).  Who is asking for DHCP support now, i.e. who is the
       IETF customer for this work?  Based on this, is this
       work justified or will it substantially improve routing
       configuration to/of mobile devices in the global Internet
       for the long term.

My fear is that DHCP may become a thing of the past and
things like BURP will open more doors to our future by
allowing non-local secure authentication (which normally
preceeds configuration) but we will see.

Best regards,

Phil

---

From: "Sandy Thuel" <[email-masked]>
Date: Tue, 3 Apr 2001 15:18:38 -0400

Hi Phil,

 Thanks for taking the time to offer your
perspectives on DHCP!  See my comments in-line.

> In the short term, it appears to be of quite high value.

You're absolutely right in that this meta-question
needs to be answered at large. With the 
proliferation of different devices and 
address allocation mechanisms that promises to
be around in the foreseeable future, it is
really unclear what will emerge as the king 
address/configuration allocator.  However, given
its current entrenchment, I believe that DHCP 
will continue to play an important role for
some time to come.  As a result, enabling its
use for mobile IP nodes should not be overlooked.

> CDMA radio!...

Not necessarily!  Some cellular operators in
3GPP2 are looking into using DHCP.  The competition
here is IPCP(PPP), which typically does the
address allocation.  But PPP is unfriendly to
mobility, which has opened the door
for some to consider a MobileIP/DHCP solution.

> Of course we must add DHCP latency onto that directly.

We and others have taken DHCP latency measurements
and have found them to be in the ballpark of
100-300 msec. (after some much-needed optimizations
to enhance the performance of DHCP - e.g., 
taking the time-consuming address conflict 
checking step out of critical path at both
the server and the client).  This assumes RTT 
between server and client is negligible (say on
the order of 1 msec.).  However, if the RTT 
between the DHCP client and server is large,
the 2 RTT's involved in a client-server transaction
dominates the configuration latency and can
push it into the seconds scale.  The question is
how much of a latency is too much? How much is
OK?

> Would need to be done in FAs too (for MIPv4)?

Although I can envision putting a
DHCP proxy client service on FA's, that would
eliminate the key benefit of offering proxy 
services at the HA: reducing the RTT between
the proxy DHCP client and server.

> NO.  This is *EVIL*,  and a very terrible idea. 

We're in complete agreement here.

> preceeds configuration) but we will see.

I agree someone has to figure out these different
issues you've raised but am not sure that the
mobileip WG is the one to do so.  What we 
do know is that DHCP is heavily used now and that
we should leverage its use for configuring
mobile nodes (while it's around).  If some other
handy-dandy configuration protocol becomes
prevalent and popular in the future, we can think
about how to make it work for mobile IP nodes
then.

Regards,
Sandy

---

From: Luca Salgarelli <[email-masked]>
Date: Tue, 3 Apr 2001 11:22:22 -0400

Hi Phil.

Although my K-mart crystal ball would tend to agree with yours if I look at
some distant future :-), I would argue that today's and mid-term future
networks are going to be largely based on IPv4. In these networks, DHCP
seems to be the protocol of choice to dynamically configure clients. For
example, almost all the deployments I know of 802.11b use DHCP to configure
clients.

If we add mobility support to those networks (i.e. MIPv4), I think that
making MIPv4 gracefully interoperate with DHCP is not an option: it is a
requirement.

> Of course we must add DHCP latency onto that directly.

The DHCP proportion here is simple: a DHCP transaction takes 2 RTTs.

> not necessary.  At least in the protocol sense.  Could this not

I agree with you.

Luca

---

From: Alexandru Petrescu <[email-masked]>
Date: 09 Apr 2001 09:11:28 +0200

[sorry, late, hesitations about relevance to mip]

"Sandy Thuel" <[email-masked]> writes:
> > > 1) What is the real value of DHCP options to
> > > mobile nodes?

I guess stateful mechanisms (being already
available and centralizing control) are definitely
an option to be exploited by MNs during
configuration of their CoA.

> > > 2) How important is it to minimize the
> > > power-up configuration latency of a mobile
> > > node?

I don't know.  But in this context I know that
DHCPv6 mesages originally designed for power-up
could also be used for lower latency handoffs.

> > 1).  We must figure out who wins the "I assign
> > the address to the MN battle" in all possible
> > scenarios including handoffs from MANETS
> > (infrastructure-less) to MIP supported
> > networks and handins and outs of

I'm interested in "optimal autoconfiguration" with
a competition between stateless and stateful.  The
rfc's specify a certain order (first do stateless
then, depending on it, do stateful) but I think
there's room for improvement.  For example, I
could imagine the MN could use quick stateless to
obtain a temporary site-local address to query the
DNS, all at the same time doing a heavier DHCPv6
exchange to obtain the CoA to register with HA.

Alex

---

From: Luca Salgarelli <[email-masked]>
Date: Tue, 3 Apr 2001 11:22:22 -0400

Hi Phil.

I agree with you.

Luca

---

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

Hi Alex,

> [sorry, late, hesitations about relevance to mip]

I hope your hesitations have been dispelled by 
now :-)

> configuration of their CoA.

I think you misunderstood the question.  I was
referring to the so-called 'DHCP options' =
configuration state DHCP allocates other 
than addresses.  In addition, the questions in
my message where specifically targeted at using
DHCPv4 for configuring a home address, not a CoA.
Sorry for the confusion.  

> could also be used for lower latency handoffs.

Again, I think you're touching on the issue of
dynamically configuring a CoA (not a home address,
although it is certainly the case that any DHCP
performance improvements helps reduce any 
configuration latency (whether it is the
configuration of a CoA during handoffs or a
home address during power-up).

> exchange to obtain the CoA to register with HA.

Although this is an interesting issue, I'd rather
not open the IPv6/DHCPv6 configuration can of
worms at this moment.  Let's try to reach consensus
on how to handle the DHCPv4 case first.

Thanks!
Sandy