Subject: Re: [MOBILE-IP] Dynamic Address Assignment in Mobile IP

From: Pete McCann <[email-masked]>
Date: Mon, 10 Apr 2000 17:30:14 -0500

Hi, Martin,

Martin Johnsson (MJ) writes:

MJ> Regarding the use of DHCP in corporate environment, the idea would
MJ> be to have the possibility to configure "everything" from the
MJ> beginning, i.e. both the address of the HA as well as MN's IP
MJ> address corresponding to the home network, and possibly also the
MJ> address corresponding to the visited network. This means that
MJ> tunneling via the HA (And FA) won't begin until you have all this
MJ> configured in the MN.

MJ> We have done this in actual implementation, and it works fine,
MJ> though there is a need to make some modifications in the DHCP
MJ> client when you request the IP addresses for both home + visited.

So are you saying that the MN uses DHCP to acquire both a home and
visited address?  What if the MN powers up on a network that is far
from home?  How do you contact the home network (which might be
another service provider) to allocate an address?  Do you tunnel the
DHCP request back to the home network?  And all this takes place
before the HA-FA tunnel is even set up... I am concerned that
solutions like this will start to look a lot like re-inventing Mobile
IP.

Maybe what you are doing is assuming that the MN always powers up "at
home," i.e., it gets a dynamically allocated HA in the visited
network.  This is OK for some situations, but what about when a user
wants to use an HA situated in a private network, and to use a private
address on that network?  The beauty of the NAI draft is that the
address can be allocated by the home network as part of the Mobile IP
registration, and the MN need not be given any sort of address on the
visited network.

I don't think we can do this with DHCP, unless we somehow:

1) Complete a "partial" MIP registration that does not assign an address,
   but informs the FA of the HA's identity.
2) MN sends DHCP request which is tunneled back to HA.  DHCP request
   contains some sort of client identifier which the FA remembers and
   associates with MN's link-layer address.
3) HA relays the request to the DHCP server.  HA also associates the
   client ID with the FA address.
4) HA gets a response from the DHCP server, and starts to associate
   the new IP address with the MN.  The response is tunneled back to
   the FA and the HA begins to intercept traffic on behalf of the MN
   (gratuitous and proxy ARP).
5) The FA receives the tunneled DHCP request and routes it to the proper
   MN using link-layer address.  It now records the MN's IP address and
   uses it to route furthur encapsulated traffic from the HA.

This is ludicrously complicated.  I think we are better off with the
NAI draft and letting the HA manage the address allocation state.
Other configuration info can be done with DHCPINFORM messages, which
would be tunneled back to the HA like any other traffic.

Question: do the DHCP message flows, even for DHCPINFORM, require
broadcast datagrams to be sent?  If so then the Encapsulated delivery
mode must be negotiated by the MN so that these broadcasts can be sent
back to the home network.

-Pete

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Apr 2000 09:44:53 -0700

>broadcast datagrams to be sent?

RFC 2131, section 4.4.3 states:

   The client then unicasts the DHCPINFORM to the DHCP server if it
   knows the server's address, otherwise it broadcasts the message to
   the limited (all 1s) broadcast address.  DHCPINFORM messages MUST be
   directed to the 'DHCP server' UDP port.

Section 3.4 states:

   The server responds to a DHCPINFORM message by sending a DHCPACK
   message directly to the address given in the 'ciaddr' field of the
   DHCPINFORM message.  The server MUST NOT send a lease expiration time
   to the client and SHOULD NOT fill in 'yiaddr'.