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

From: James Kempf <[email-masked]>
Date: Fri, 06 Apr 2001 08:09:05 +0900

Hi Sandy,

At 11:31 AM 4/5/01 -0400, Sandy Thuel wrote:

>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

Well, of these NTP and DNS servers are service
discovery, I agree that the others are configuration.
Using service discovery to discover DNS might
be quite difficult (especially if DNS SRV RRs were
used), so I suppose that could be considered a
configuration parameter as well.

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

The options related to IP address configuration
and routing (gateway router, subnet mask,
and domain name) are not handled by
service discovery currently but they could
be handled by a mobile IP extension or
AAA extension that hides the back end
implementation so network operators
could use the backend technique of their
choosing.

Regarding deployment of service discovery
techniques, well, DNS is
certanily widely deployed. I don't know
how many deployments support SRV RRs
but I suspect the number is growing.  I don't
know how widely deployed LDAP is
but it certainly is becoming more popular
in enterprise networks, and I believe
one could make a case as widely deployed
as DHCP. SLP is a complement to LDAP,
and it is not as widely deployed as the other
two, but growing.

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

No, but this is something that could easily become
a standardized Diameter extension.

>In any case, if I want a solution for today, I
>still think DHCP is the only game in town...

DHCP was developed for enterprise networks, it
has little or no deployment in wide area mobile
networks at this point, certainly not to the mobile node,
and its characteristics
are not particularly promising for wide area, IMHO.
Since a mobile node must have mobile IP on it
anyway, there is little point in requiring it to have
DHCP as well.

>Yes. That's what I meant when I said the DHCP
>proxy and HA can be "logically" separated by
>an API.

This is a fine implementation option, and perhaps
there are some points that would require standardization.

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

I don't think it should be required, a network
operator may choose to do address and
address parameter configuration out
the back end of the HA using Radius or
Diameter. But there are probably areas
that could be standardized.

>I hope my clarification above on what I was
>referring to as configuration options clarifies
>what I meant by this question.

Yes, thanx.

                 jak

---

From: "Sandy Thuel" <[email-masked]>
Date: Tue, 10 Apr 2001 11:30:33 -0400

Hi James,

> configuration parameter as well.

Precisely.  This is the reason why many networks
today use DHCP to allocate these configuration 
parameters.

> could use the backend technique of their

Sure.  But this is precisely the question:
who should allocate these configuration 
parameters? Some backend mechanism made
transparent through Mobile IP extensions?
AAA extensions? DHCP? I obviously believe
that DHCP should do it, at least today and in
the foreseeable future. 

> a standardized Diameter extension.

I wonder if anyone on this mailing list with
AAA expertise can shed some more light onto 
this possibility.

> are not particularly promising for wide area, IMHO.

Sure, DHCP was developed for enterprise networks
but why is this a problem? The point is that DHCP
IS widely deployed in LANs today and with a 
relatively simple solution you can use it to
configure remote mobile nodes *as if* they
were connected to their home networks, WITHOUT
the need to change DHCP in any way to make it fit
the special needs of mobile nodes.

> anyway, there is little point in requiring it to have

Fine.  You could make a Mobile IP client take on
the responsabilities a DHCP client is used to
handling but be ready to *change* that Mobile IP
client.  At the very least, you'd have to change
the Mobile IP standard to require mobile nodes
to register even while they're at home so that
they can maintain soft-state support on their
assigned home address.  Now, if you happen 
to also need configuration parameters, you not
only have to change the client state machine 
but you also need to extend Mobile IP messages...
Changing the Mobile IP standard to do this is 
the key problem you can avoid by letting DHCP 
handle the dynamic addressing and configuration
needs of the mobile nodes.  

> that could be standardized.

Point well taken.  'Requiring' this functionality
is too harsh a statement.  Let me try again.  What
I'm trying to understand is what is the 
dynamic addressing AND configuration model that 
is *likely* to be embraced by ISP's.  The model
you seem to like is one where, from the point of
view of the mobile node, Mobile IP handles all
of this (i.e., the mobile node gets any needed
address and configuration parameters from
Mobile IP).  And you'd like to leave the door open
for operators to choose any back-end mechanism
to do the actual address and configuration
parameter allocation they want (be it AAA,
DHCP or whatever).  Does this accurately capture
the model you have in mind?

Regards,
Sandy