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

From: "Sandy Thuel" <[email-masked]>
Date: Mon, 9 Apr 2001 17:27:50 -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 7:09 PM
To: Sandy Thuel; [email-masked];
[email-masked]
Subject: RE: [mobile-ip] dynamic home addressing as a WG item??

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: Patrice Calhoun <[email-masked]>
Date: Tue, 10 Apr 2001 07:12:55 -0700

>Patrice Calhoun writes:
> > 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.
>
>   Yes. It's a DHCP INFORM.

ok, so if the desired functionality is to retrieve DHCP configuration information
from the home network, the allow Mobile IP to provide home address assignment
via the current mechanisms, and once the mobile is registered, a DHCP INFORM
could be sent to the home network.

(btw, I suspect this will really only work with reverse tunnels if the packet
is a broadcast).

PatC

---

From: James Kempf <[email-masked]>
Date: Thu, 12 Apr 2001 12:50:33 -0700 (PDT)

Hi Phil,

>I would say its a "hack" not a trick and it has the negative
>effect of putting a routing protocol (MIP) under the yoke
>of something that is clearly an application layer duty.
>DON'T DO IT!  (That's how I really feel James...)

OK, then what would you suggest? I think extending
DHCP to the mobile is just as much of a hack.

		jak

---

From: kempf <[email-masked]>
Date: Thu, 12 Apr 2001 19:02:34 -0700 (PDT)

Hi Luca,

OK, I think I've got this sorted out now. (Note to PhilN: if you haven't
already, please read the drafts before you hit the "send" key...).

>Hmmm, as far as I know, DHCP stands for Dynamic Host *Configuration*
>Protocol. It has been designed exactly for distributing configuration
>information.
>

DHCP was originally designed to configure address information, it
was only due to the lack of a standardized configuration mechanism
that everything else got dumped in. Now, there are far better ways
of doing configuration of service discovery information (LDAP, SLP, DNS SRV RR). 
And the only reason 
DHCPpppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp
pkkkkkkkkkkkkkkkkkkkk was needed to do address configuration was because
IPv4 doesn't have autoaddress config nor router-advertised subnet
prefixes.

>
>I agree that something different could be used, but the way it is
>(very successfully) being done today is through DHCP. Network
>administrators just seem to like it a lot, so I think supporting it should
>be somthing we should make MIP capable of. If then we want to think at a
>better way to do it, it is fine by me.
>

The fact of the matter is that mobile IP is currently deployed in
3GPP2 networks without DHCP & there is no DHCP on 3GPP2 phones or
the brand new Sprint PCS modems I've just started seeing advertised
in the New York Times. They use PPP and Radius to configure the 
address information. So from the point of view of the system
administrators and users who are using mobile IP *today* this is a very big
change indeed, despite what enterprise network administrators think.

Not every IP node is connected to an enterprise network, in fact,
in the future, nodes homed and connected to enterprise networks
may be in the minority.

>I agree, we are probably thinking about two different scenarios.
>Nevertheless, I don't think anybody is saying that support for DHCP should
>be a MUST for MIP. What I would like to see is some way for MIP to support
>it, for the ISP's that think it is needed.
>

I disagree. I would rather see something that builds on the current
infrastructure, that won't involve 3GPP2 having to tear up their
current infrastructure. If DHCP is put in, people will think the
problem is solved.

>Again, that might work in the scenario you described above. It will not
>work (very well, at least) in scenarios where the mobile goes home from
>time to time, as Sandy pointed out already.
>

I think it will work just fine when the mobile node goes home. The
mobile node has mobile IP with address and routability configuration
(see below for more on this), uses that to get what it needs from the 
home agent, home agent uses DHCP out the back end (or Radius/Diameter
and PPP/BURP if it is in a WAN situation) to get the address/routability
information.

Now perhaps some perspective (especially for PhilN's benefit). 

I think we are talking about three different kinds of configuration 
information supplied by DHCP:

1) Information that is required for basic routing of packets to the host.
On IPv4, this consists of the IP address, the subnet mask, and perhaps
the gateway router. On IPv6, this consists of the subnet prefix, perhaps
an IP address if one is assigned, the router can be discovered.

2) Borderline service discovery information that would be difficult
to bootstrap. This is primarily DNS.

3) Service discovery information such as printers, LDAP servers and
the like.

---

From: James Kempf <[email-masked]>
Date: Tue, 17 Apr 2001 16:06:58 -0700 (PDT)

Hi Sandy,

It has been an interesting exchange.

>  Can you clarify the home networking model you
>  assume? You suggested in a previous message that
>  the MN would get a *home* address from the 
>  local access network: 
>

I have two different models  in mind:

	1) In IPv4, the mobile node gets a "home" address assigned
	by the local network. The advantage of this is that it
	reduces the size of the triangle route leg from the home
	agent for the mobile node initially. Since MIPv4 is not
	likely to  have route optimization nor regional registration
	widely deployed soon (because it was not specified early enough),
	this technique is a practical  way of reducing triangle
	routing, especially if the host network puts the HA directly
	on the routing path  which the mobile node's packets must
	travel. Like other optimization
	techniques, the assumption here is that most mobile nodes
	won't move far enough topologically from their initial 
	location that triangle routing will become a problem.

	2) In IPv6, either the above technique is used, or the mobile node 
	comes with a global address baked into it. I believe 3GPP is
	planning on doing the latter (though it isn't planning on using
	MIP). Since route optimization  is built into MIPv6, the first 
	technique may not be important. Another
	possibility is that the mobile node makes up its home address
	using address autoconfig when it first comes up.
	
In neither case do I think DHCP would be relevent. There may be some
few cases where the mobile node has to get an address from the HA,
these should be handled by mobile IP.
	
>  I don't understand how this works.   Are you
>  advocating a model where the MN has no 
>  fixed notion of a home network (i.e.,
>  the MN 'makes' the network it powers up on 
>  serve as its home network)?

Yes and no. From an addressing viewpoint, what does it
matter where the mobile node gets it's "home" address
from? The address is there for routing purposes,
the mobility protocol should arrange for the address
to optimize routing.

The only reason why the mobile node should care about
its home network is for AAA purposes, to determine
whether the mobile node has authorization to use
network resources or not. This is handled, in IPv4,
by the MIP AAA extension. And maybe for such
home network  related service configuration
information like the IMAP server.

>B) What constitutes *home* configuration state? 
>
>  Your classification of configuration state
>  was a nice step in the right direction. Allow
>  me to distinguish just two categories for
>  discussion purposes:
>  - routing and identity related: IP address, 
>    subnet mask, gateway router, domain name
>  - service (discovery) related: DNS,
>    HTTP proxy, IMAP server, NTP server,
>    printers, LDAP servers, etc.
>
>

Well, DNS is borderline. One could argue that DNS is identity
related in the sense that it indicates what you can resolve.

I actually prefer to keep it separate from the others because

a) DNS can be used to do service configuration itself.

b) IPv6 has its own DNS service discovery technique.

>C) Who should allocate *home* configuration state? 
>
>   (This is where the fire gets hot.)  You
>   seem to suggest the following solution: let
>   Mobile IP allocate the IP address and subnet
>   mask to the MN adding whatever extensions 
>   are needed to make it happen (= a new Mobile
>   IP extension for the subnet mask + changes to
>   the Mobile IP standard so the client sends 
>   registrations while at home).  Let service

Or the HA can proxy the DHCP lease renewal until
the MN deregisters.

>   discovery handle informing the MN of available
>   services where possible.  Otherwise, rely on 
>   AAA to inform the MN (e.g., DNS).
>
>   (Q: In your model, how does the MN get its
>   domain name? Through AAA? 

The NAI is needed in order to perform AAA. Typically,
this includes the domain name, but it need not.
So, yes, in that case if the domain name were
not preconfigured into the mobile node, it would
be obtained via AAA.

>Also, how would the
>   MN discover its gateway router in the absence
>   of an FA?)
>

I thought we were talking about mobile IP? There
is always an FA involved in MIPv4, except at home. 
In that case, it can use the HA as the router. In MIPv6, there
is an Access Router which the mobile node discovers
via a Router Advert.

>   There are several issues with this model.
>   First, we have a strong difference of opinion
>   regarding the issue of changing the Mobile IP
>   standard to require client registrations while
>   at home and extending it to piggyback routing
>   related config. state.  You don't seem to think
>   it's a big deal to do this.  We do, particularly
>   in the short-term, as we try to expedite 
>   the deployment of M-IP.  Changes of this nature
>   are very costly and they take time to be
>   adopted.  In addition, we must be careful in
>   thinking that a "tiny" extension to Mobile IP
>   will solve the problem.  Today we extend it to
>   handle the subnet mask, tomorrow... (you get 
>   the picture).
>

Well, if you don't like that, then we can use AAA
to get the routing related config as well. In fact,
I think this is probably how 3GPP2 does it today.

As for reregistering at home, if the HA is proxying
the address via DHCP, the mobile node doesn't have
to reregister. The HA can continue to proxy until
the mobile node deregisters. I believe Charlie is
currently in discussion about deregistration in
2002bis.

>   Now, is DHCP the end-all solution? Of course
>   not.  DHCP is not God's gift to mankind any
>   more than PPP/Radius are (no offense intended).
>   But DHCP *is* here, now, and used quite
>   extensively.  I'll grant you that mobile phones
>   with DHCP clients aren't available today at
>   my favorite phone retailer and I would concede
>   that there are concerns about doing DHCP over
>   the air.  But there many other devices besides
>   cellphones which are mobile, wireless and have
>   DHCP clients.  I just don't buy the argument
>   that if-cellphones-don't-need-it-today-then-it
>   must-not-be-needed.
>

The issue I have with DHCP is that after you've 
got the config state on the mobile host, the
mobile host gets dumped back into the remote
network where the config state may or may not
make sense. Even assuming there is any logical
home network, which I think is not a vaild assumption.

Here's an example. What happens if the home
network uses "split" DNS, where different
names are resolvable inside and outside
the corporate network? The mobile node
is left outside the corporate
network with a DNS server inside that:

a) It may not even be able to reach through the
corporate firewall,

b) If it can reach the server, the names the server resolves
may not be reachable from the mobile node.

My point is that if you want to make the mobile
node part of the corporate network, you must
do a full job of it, and have the mobile
node become topologically part of the corporate
network, like a VPN. Not some partial solution,
where the mobile node gets configured with
home network state then gets dumped back onto
the remote network. Otherwise, how is
the mobile node going to sort through the
configuration from the home network and
make sense of what works and what doesn't?

>   On the security issue you have a real, valid
>   point.  DHCP is clearly not secure today
>   even though there's a lot of ongoing work to 
>   fix this. Running DHCP over a secure Mobile IP
>   tunnel would at least not open any new security
>   loopholes due to remote access.  There is
>   still the known vulnerability of DHCP to
>   attacks within the home network.  So, what are
>   we to do? Wait for DHCP to become secure before
>   we can use it? 

Yes, why not? We are not talking about a corporate
network where one system administration team has
control, we are talking about the Internet. There
are enough security problems to solve without
generating new ones.

>Wait for configuration-related 
>   extensions to AAA to come out so we can use
>   them? 

Actually, I've been talking with some people about
doing a draft on this. We should have something
ready by the next IETF.

>Wait for Mobile IP to be changed to
>   handle configuration state out to the MN?
>   Pick two out of three? Pick all three? It's
>   not clear to me which of these (and many other
>   scenarios we can dream up) will eventually 
>   win.  But what I can't understand is why we
>   can't give the option of enabling the use of 
>   what's already in place today.  We are not
>   proposing any changes to neither Mobile IP
>   nor DHCP, but just telling you how you could
>   use them together to do remote configurations
>   of MN's if you want to.  Your remote MN with
>   its DHCP client will be at least as secure as
>   if it were roaming within its home network.
>   If and when DHCP is made secure, kudos for
>   this solution.  And if someday AAA manages
>   to undertake dynamic configuration duties
>   under its wings, operators can go ahead and 
>   use it instead of DHCP.  What's so evil 
>   about this? 
>

Look, Sandy, I don't want to rain on your parade, but
I really think we should be looking at solving the
problem rather than putting a bandaide(tm) on it.
The problem is how to make the mobile node
topologically and configuration wise part of
the corporate network using mobile IP to handle
mobility rather than the current L2 technology
(L2TP and PPP). There are so many things that
could go wrong with simply punching a tunnel and retrieving
home configuration state. 

Nobody can stop you from filing your ID as an individual
contribution, and, in any event, if the WG chairs and
other WG members feel that this is an important enough
item to solve, then I'm not going to complain if it
gets onto the WG task lisk (though the MIP WG certainly
has more than enough to do now). However, if it does
get on the WG task list, I'm going to insist that
some of the problems I've identified get solved,
and maybe even suggest some solutions. But I'd
rather see a solution to the whole problem, rather
than trying to patch something together.

		jak