Subject: [MOBILE-IP] Use of DHCP in Mobile IP

From: Steven Glass - Solaris Software <[email-masked]>
Date: Wed, 7 Jun 2000 20:00:24 -0400

I have (*finaly*) submitted my id to the id editor.  My appologies for the
added delay (amazing how bogged down in other things you sometime have to
become).  For your perusal, I'm attaching it below with the caveat that the
editor may not accept it, and I may have to change it for resubmittal.

    It may be best to strip out the options, and put them in a separate
document.  I've also included "think:" sections where I think working group
feedback would be useful.

    This is also going to be announced on the dhc mailing list.

                              Cheers,
                                  Steve
Internet Engineering Task Force                                 S. Glass
INTERNET DRAFT                                          Sun Microsystems
Mobile IP Working Group                                      7 June 2000

                        Mobile IP Agents as DHCP Proxies

                  draft-glass-mobileip-agent-dhcp-proxy-00.txt

   Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   This document is a submission to the Mobile IP Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the [email-masked] mailing list.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.

   Distribution of this memo is unlimited.

   Abstract

   Since the inclusion of the Network Access Identifier (NAIs) into
the mobile ip fabric, home agents have had a way to identify mobile
nodes which do not have home IP addresses.  After authenticating the
registration request from such a mobile node, the home agent is then
expected to assign a home addresses to the mobile node in the
registration reply to be used on a semi-permanent basis.
Unfortunately, no specific mechanism has yet been proposed.  Ideally,
as DHCP centralizes address management, a home agent should contact a
DHCP server to allocate an address for the mobile node, thereby
preserving DHCP as the central address maintainer.  The technology
does exist for a Home Agent to use DHCP controlled addresses, namely
for the Home Agent to behave as a DHCP proxy agent.

   This document specifies the procedure for a Home Agent to follow
when contacting a DHCP server to obtain home addresses for mobile
nodes that require them.  It does so in the spirit of the design goals
of [1], and [2] (section 1.6).  Moreover, it specifies the
responsibilities of the home agent with regard to defending this

S. Glass                Expires 7 December, 2000                [page i]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

address, and maintaining it as appropriate.  Obviously, support must
be added to the home agent to provide for this functionality, so the
most desireable case is to limit changes to just the home agent.  This
document enhances the behaviour of the home agent in a way so that no
enhancements to the behaviour of a mobile node which is compliant with
[1] and [3] is required.  As a result, a clearer picture is also
obtained as to what needs to be addressed when a mobile node is not
assigned a home address before it roams, and the complications that
can result in various mobile ip situations.

   As always, optimizations and enhancements can be made, in this case
proposing changes to both home agent and mobile node.  These changes
are specified as optional extension support.  The exchange of
extensions is defined in such a way that if one side understands these
extensions, and the other side does not, interoperability is still
acheived.

   1. Introduction

   Mobile IP was designed to give nodes the ability to leave the
confines of their home subnet, allowing them to not only initiate new
connections from their roamed location, but to keep their current
connections active while receiving new connection requests through an
agent on their home subnet, known as the home agent.  Recent
enhancements to mobile ip have even allowed nodes which do not yet
have an IP address to connect to their home subnets, and receive an
address through their home agent.  No mechanism describing how the
home agent is to obtain such addresses has been officially proposed,
however, which may default home agents into have their own
address-pools from which they can hand out addresses.

   The ideal method would be to have the mobile node receive an
address from the same address pool as it would if it were at home,
most likely the DHCP address pool on it's home network.  Obtaining an
address directly would be difficult since any concept of a home
network to DHCP is the network on which the node is currenly residing.
Special enhancements to DHCP would have to be devised to get the DHCP
messages to, and from the home subnet, and it is likely such
enhancements would immitate functionality already designed for mobile
ip.

   The mechanism used to get a mobile node's request for a home
address already exists in the NAI extension of the mobile ip
registration process [3].  When the home agent receives a registration
request containing a zero home ip address, and an NAI extension, it
uses the NAI to associate the shared secret between the mobile node
and itself, and uses the MN-HA authenticator to identify the
registration as comming from the mobile node (if a MN-AAA
authenticator appears instead, authentication is done using that at
the AAA server).  The HA then finds an address to assign to the mobile
node.  The home agent, by definition, has an interface on the mobile
node's home link.  Using this interface and the mobile node's NAI, it
can generate the necessary DHCP messages as a DHCP proxy in an attempt
to obtain an address which it can assign to the mobile node.

S. Glass                Expires 7 December, 2000                [page 1]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   2. Overview

   A mobile node which is away from home without a home address
follows the proceedures detailed in [3], specifically sending a
registration request containing a zero home address to it's home
agent, includes an NAI extention, and appends a MN-HA identifier as
detailed in [1] to authenticate itself to the home agent (or a MN-AAA
authenticator to identify itself to the home AAA server if that method
of authentication is used).  Upon receiving such a registration, the
home agent must get an address to pass back to the mobile node in the
home address field of the registration reply.

   The home agent can now play a role similar to that of a DHCP proxy
agent generating DHCP messages as described in [2] on behalf of the
mobile node, as detailed below, in hopes of ultmately obtaining a
suitable address for use as the mobile node's home address.

   It is important to understand the exact role the home agent is
playing in this scenario.  The home agent is not playing the roll of a
DHCP relay, as it is not relaying any DHCP messages on behalf of the
mobile node.  From one perspective it is behaving as a DHCP proxy,
generating DHCP mssages on behalf of a mobile node.  In another
perspective, it is simply obtaining an address it will be using on one
of its own interfaces, namely an interface attached to the mobile
node's home link.  In this regard, the home agent is purely DHCP
client.  Should the mobile node return home, it will likely want to
assume ownership of this IP address, so in this light we will consider
the home agent as performing the job of a DHCP proxy, and will refer
to it as such for consistency.

   2.1  Mobile IPv4 with DHCP, and Mobile IPv6 with DHCPv6

   As the relationship of the mobile node and the home agent doesn't
change in regard to the home agent obtaining an address for a mobile
node in mobile IPv6, it would be nice if it were possible to use the
same mechanism in mobile IPv6 for a node to obtain a DHCPv6 address in
the analogous way.  In this case, mobile ip registration requests
should be sent as in [10] with the NAI extension appearing after the
registration request, and before the MN-HA or MN-AAA authenticator as
described in [3].  The home agent would then generate DHCP messages as
described in [11], obtaining an IPv6 address for use as the mobile
node's home address.  This document attempts to treat the IPv4 and
IPv6 cases together, providing a mechanism to be used in either
situation.  As the majority of documents referenced here are works in
progress, however, this document may need to be updated upon their
completion.

   3. Operation of a Home Agent as a DHCP Proxy Agent

    This section describes the proceedure a home agent should follow
upon receiving an authenticated registration request from a mobile
node requiring a home address in order to behave as a DHCP proxy
agent, and the responsibilities imposed on the home agent as a result.

S. Glass                Expires 7 December, 2000                [page 2]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   3.1 The Initial Registration Request

   1. The HA receives an authenticated registration request as defined
in [1] for a mobile node which it is willing to service, and for which
it does not have a current binding, and for which a home address needs
to be assigned.  This appears in the form of a mobile ip registration
request containing a zero mobile node home address, an NAI extension,
and MN-HA authenticator as described in [3] (or MN-AAA authenticator
if that security model is in use).  If the regisration request is
unacceptable, the appropriate error code as defined in [1] or [3] MUST
be returned to the mobile node's care-of address.

   2.  If the registration request has been authenticated as coming
from the mobile node identified by the NAI contained in the
registration request, the Home Agent builds a DHCPDISCOVER as defined
in [2] exactly as it would to obtain a[nother] IP address for one of
its links defined as being on the mobile node's home link (htype,
hlen, chaddr, etc), with the following difference.  The client
identifier option (type 61) as defined in [4] MUST be included,
wherein the type field MUST be set to 0, and the identifier MUST be
set to the NAI as sent by the mobile node in the NAI extension.  As
the Client ID option (type 51) allows for up to one octet for length,
a client id of up to 255 characters allows more than enough space for
the up-to 128 character NAI [5].  Furthermore, an IP Address Lease
Time option (type 51) SHOULD be included.  The lifetime requested in
the IP Address Lease Time option of the DHCP request SHOULD be the
shorter value of the of either the lifetime appearing in the
registration request, or the lifetime the home agent is willing to
grant in a registration reply to this mobile node [1].  In addition,
sname, giaddr, and yiaddr MUST be NULL, and hops is set to 0.

   The home agent MAY also include the DHCP Mobile IP Home Agent
option [4].  If the home agent includes this extension, it MUST set
the home agent address to the address apearing in the home agent field
of the registration request, or the address belonging to the home
agent on the link that will be servicing the mobile node.

   Note: this DHCP message may go through a DHCP relay agent.  The home
agent behaves no differently than as described above.

   3. The home agent waits a configured amount of time for a
DHCPOFFER from the DHCP server.  It is recommended that the Home Agent
wait no less than DHCPDISCOVER_TIMEOUT seconds for such a reply [2].
If no reply is received within that time period, and the home agent
has no other pool from which it can assign addresses to the mobile
node, it MUST return error 99 "Missing Home Address" as described in
[3].  If the DHCPOFFER is received, it is processed, specifically for
an acceptable home IP address, and lifetime.  If the data in any field
of the DHCPOFFER, specifically these two, are unacceptable, the home
agent SHOULD attempt to negotiate these with the DHCP server.

S. Glass                Expires 7 December, 2000                [page 3]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   If the DHCPOFFER includes the Mobile IP Home Agent option (type
68), the home agent SHOULD compare the address contained in this option
with its own, specifically the address identified as the home agent
address in the registration request, or the address on the link that
will be servicing the mobile node.  If the address is NOT the same
as the address being identified as the home agent address, the home
agent MUST generate a registration reply with error 136 "Unknown Home
Agent Address".  As with home agent discovery [1], this should prompt
the mobile node to choose a different home agent with which to
register.  (Think: the home agent SHOULD also put the address of the
home agent returned in the Home Agent Option in the home agent field
of the registration reply).  (Think: Furthermore, this home agent
SHOULD not reply to further home agent discovery packets from this
mobile node for the duration of the lifetime appearing in the
registration request).

   Upon receiving an acceptable DHCPOFFER, the home agent MUST
transmit a DHCPREQUEST for the IP address being offered to the unicast
address of the DHCP server as described by [2], and awaits a
configured amount of time for a DHCPACK.  It is recommended that the
home agent wait at least DHCPREQUEST_TIMEOUT seconds for the DHCPACK
from the DHCP server.  If no reply is received to the DHCPREQUEST, the
home agent MUST generate another DHCPREQUEST for an address apearing
in another DHCPOFFER from a DHCP Server, or MAY transmit another
DHCPDISCOVER as in (1) above, or, if no other address assignment
mechanism is available, the home agent MUST send a registration
response to the mobile node with error 99 "Missing Home Address" as
described in [3].

   4. Upon recieving a DHCPACK with a suitable IP address and lifetime
for the mobile node, the home agent MUST query the network for the
address, as in the usual duplicate IP address detection mechanisms as
is described in [2].  If the address is in use, the home agent SHOULD
transmit another DHCPREQUEST for an address appearing in another
DHCPOFFER from a DHCP Server, or transmit another DHCPDISCOVER
message.

   If a DHCPNAK is received instead, the home agent MUST do one of the
following: either renegotiate with the DHCP server, send out another
DHCPREQUEST for an address appearing in another DHCPOFFER from a DHCP
Server, send out another DHCPDISCOVER as described in (1) above, or if
no other address assignment mechanism is available, send a
registration response to the mobile node with error 99 "Missing Home
Address" [3].

   Think: what about the other possible responses to the DHCPREQUEST?

   5. If the address in the DHCPACK is deemed suitable for use as an
IP address for this interface, and as a home ip address for the mobile
node, the home agent puts this address into the home address field of
the registration reply.  The home agent MUST also fill in the lifetime
of the registration reply with the shortest value of either the
lifetime appearing in the registration request, the lifetime normally
granted by the home agent, or the lifetime granted by the DHCP server.

S. Glass                Expires 7 December, 2000                [page 4]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

The home agent MUST also include the NAI option as per [3], and append
the usual HA-MN authenticator as described in [1], or the HA-AAA
authenticator if that security mechanism is in use.  The home agent
MUST also claim, and defend the address as described in [3].

   If no suitable address can be obtained from a DHCP agent, and no
other method of obtaining an address is available, the home agent MUST
send a registration reply to the mobile node with error 99 "Missing
Home Address" [3].

   3.2 Re-registration Requests

   This sections details the behaviour of a home agent upon receiving
a registration request from a mobile node for which it already has a
binding.

   1. The mobile node sends a registration request to a home agent
with which it already has a binding.  It MUST include either the IP
Address assigned to it by the home agent, or the 0 address in the home
address field of the registration request, and it MUST include the NAI
that it originally used to obtain the binding and address.

   2. The home agent receives an authenticated registration request,
it MUST check to see if already has a binding, and is providing home
agent services for this mobile node.  This determination can be based
on NAI, or (non-zero) home address.  Before sending a registration
reply to the mobile node's care-of address, the home agent MUST use
the NAI, or (non-zero) home address to check to see if this mobile
node was assigned a DHCP administered home address, and, if the home
address appearing in the current registration request is non-zero,
make sure the mobile node is using the same home address it was
assigned in the previous registration using the NAI.  If the
registration request contains the zero address, the home agent MUST
associate the address which was assigned to the mobile node's NAI by
DHCP.

   3. If the address the mobile node is using was assigned by DHCP,
the home agent builds a DHCPREQUEST message exactly as it would for
any DHCP address it were renewing as in [2] with the same exceptions
as described in section 3.1 above.  The message is unicast to the DHCP
server that assigned the mobile node's current home address, the IP
address being renewed (appearing in the yiaddr and ciaddr fields) MUST
be set to the mobile node's home address, and the Client ID option
(type 51) MUST be included with the type field set to 0, and the
client-id set to the mobile node's NAI appearing in the registration
request.  The home agent SHOULD include the IP Address Lease Time
option, where the lifetime is the shorter of either the lifetime
appearing in the registration request, or the lifetime the home agent
is willing to grant is placed in the IP Address Lease Time option.
The home agent MAY also include the Mobile IP Home Agent option (type
68) with the address set to the home agent address appearing in the
registration request, or the address of the home agent on the
interface that will be servicing the mobile node.

S. Glass                Expires 7 December, 2000                [page 5]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   4. The home agent waits a configured amount of time for the
DHCPACK.  It is recommended that the home agent wait at least
DHCPREQUEST_TIMEOUT seconds for the reply from the DHCP server.  If a
DHCPACK is received within this time, the home agent checks the IP
address, and lifetime.  If they are acceptable, meaing the IP address
is identical to what the mobile node is using as appears in the home
address field of the registration request, the home agent generates a
registration reply to be sent to the care-of address appearing in the
registrtion request, includes the IP address returned by the DHCP
server, and the shorter lifetime of either that appearing in the
reregistration request, what it is configured to approve, or that of
the address lease granted by the DHCP server and appearing in the
DHCPACK.

   Note: due to the nature of mobile ip, an IP address returned by
the DHCP server that is different from that which is already granted
is not acceptable.  Should it be impossible, for some unknown reason,
for the home agent to get the address currently being used by the
mobile node as its home address, the home agent MUST reply with error
99, "Missing Home Address".

   3.3 De-registration Requests

   Upon returning home the mobile node will deregister with the home
agent as described in [1].  The moblile node generates a registration
request with a lifetime of 0, and MUST use either the address assigned
to it most recent registration reply from this home agent, or the 0
address and the NAI it used in its most recent registration request.
The home agent MUST authenticate the [de]registration request, and if
a non-zero address appears as the mobile node's home address MAY
verify the mobile node is using the address it was assigned.  If not,
the home agent MAY return error 99, "Missing Home Address".
Otherwise, the home agent behaves as descrbed in [1] pertaining to
deregistering mobile nodes.

    The home agent MUST NOT transmit a DHCP release message for the
mobile node's home address; the mobile node may still need it.

    Once the mobile node has been successfully deregistered, the
responsibility for renewing, and defending this address belongs to it.
It SHOULD immediately send out a DHCPDISCOVER message as described by
[2] even though it knows the lease is otherwise good for the unused
balance of the previous registration.  The mobile node MUST include
the Client ID option (type 51) with the type set to 0, and the
client-id set to the NAI which was originally used to obtain the lease
via the home agent, and MAY include a requested IP Address option
(code 50) with the address set to the home address it is using.  The
mobile node MAY also include the IP Address Lease Time option (code
51), and any other option it wishes, including the Mobile IP Home
Agent option for future reference.

S. Glass                Expires 7 December, 2000                [page 6]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

    In response to this DHCPDISCOVER message, the mobile node should
receive one or more DHCPOFFER messages.  The mobile node SHOULD parse
these messages looking for the address it is using as its home
address, then identify and remember the DHCP server assigning this
address.

    At this time the mobile node generates a DHCPREQUEST for the
address received in the DHCPOFFER, and awaits the DHCPACK from the
DHCP server.  The mobile node SHOULD also cache the DHCPACK received
from the DHCP server for future reference [2].

    Note: A DHCPDISCOVER message is generated, and NOT a DHCPREQUEST
for two reasons.  Firstly, the mobile node is not likely to know the
unicast address of the DHCP server assigning its home address.
Secondly, some parameters in the DHCPDISCOVER may be different such as
htype, chaddr, and hlen (e.g. bridged networks of different
hardware-level topology).  These MUST now be set to those that are
appropriate for the mobile nodes home interface.

------------ Think: for minimal mobile node implementations -------------

    If the mobile node wishes the home agent to continue to renew its
address lease, it MUST deregister using the DHCP aquired address as
its home address, and 0 as the care-of address, setting the lifetime
to 0.  As this is not a legal deregistration request as described by
[1], the home agent can assume the mobile node is aware of it's DHCP
aquired address, and is asking the home agent to continue renewing its
address lease. If a home agent receives such a deregistration request,
it MUST check that the mobile node issuing the deregistration request
did indeed obtain its home address through DHCP, matching the address
with the NAI.  The home agent, upon approving the deregistration,
renews the mobile node's home address with the DHCP server using the
NAI in the Client ID option, and MAY include the IP Address Lease Time
option (code 51).  If the renewal is not successful, the home agent
MUST send a registration reply to the mobile node with error 99,
"Missing Home Address".  Alternatively, if the home agent does not
support lease maintenence while the mobile node is deregistered, it
MUST return error XX, "DHCP lease maintenance not allowed."  In this
scenario, if the mobile node wishes to continue to use the address
assigned to it, it MUST send out DHCPDISCOVER message as described
above, and attempt to renew the lease immediately upon successfully
deregistering.

    If the renewal is successful, the home agent sends a successful
registration reply to the mobile node, setting the lifetime to the
value it wishes the mobile node to contact it in precisely the same
way as described here so the home agent can renew the DHCP lease for
the mobile node.  Note: the lifetime included in the registration
reply MAY be the lifetime returned by the DHCP Server, or it MAY be
some other value.  The mobile node should use the same registration
renewal algorithm it uses to renew its mobile ip binding while away
from home.  The mobile node MUST also claim the address on the link,
and defend it as it would any other address it is using.
------------- Fin: for minimal mobile node implementations -------------

S. Glass                Expires 7 December, 2000                [page 7]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   3.4  Address Responsibilities

   The home agent, in negotiating for a home address for the mobile
node, has been given an (additional) IP address for one of its
interfaces.  It is also acting on behalf of the mobile node that it is
providing home agent services for.  As a result, the home agent MUST
defend this address as it would any other home address registered by a
mobile node [1].  Furthermore, the home agent MUST remember this
address, that the address was obtained through DHCP, the address of
the DHCP server that granted it, and the mobile node's NAI.  The home
agent MAY cache the DHCPACK for future reference.

   The mobile node uses this address as it would any address assigned
to it (by the home agent) including the exceptions described by [1] in
relation to what it MUST and MUST NOT do while on the foriegn subnet.
When using this address on its home subnet, it MUST defend this
address itself as it would any address it is using.

   4.0  New DHCP-Specific Mobile IP Options

   For optimizations, and enhancements, this document defines the
following OPTIONAL extensions.  In each case, what is required for the
home agent and mobile node to support is detailed.  The extensions for
the mobile node to use are in the range 128-255, which as specified by
[1] are ignored (by the home agent) upon receipt if not understood.
In this way, a home agent which does not understand these extensions
will ignore them, the registration request will NOT be silently
discarded, and the mobile node's registration will be processed.
Conversely, the home agent reply extentions are in the range 0-127.
In this way, if a mobile node receives a registration reply which
contains an extension giving it some special information which it does
NOT understand it will silently discard the entire registration reply,
and attempt to reregister (with a different home agent).

    A home agent MUST NOT insert any DHCP-related mobile IP extensions
in a registration reply to a mobile node from which it did not receive
a DHCP-related mobile IP extension.  As these are optional extensions,
and support is not required to be compliant with this specification,
the appropriate assumptions which can be made by either side is
specified depending on the level of support provided by each end.  In
addition, allowable responses by home agents and mobile nodes when
using these extensions is detailed in the appropriate sections.

   All DHCP options conform to the requirements laid out in [7].

S. Glass                Expires 7 December, 2000                [page 8]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   4.1  Mobile IP DHCP Address Extension

   A mobile node wishing to obtain a DHCP address lease SHOULD include
the following extension in its registration request.  This extension
MUST appear before the MN-HA or MN-AAA authenticator, and SHOULD
appear after the NAI extension.  The "Mobile IP DHCP Address"
extension is defined as follows:

    0                   1                 2                     3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 0 9 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   type        |   Length      |A|L|S| reserved  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type  200(TBA)   "Mobile IP DHCP Address" extension
    Length           The number of bytes of the whole extension (MUST
                     be word aligned).  Currently 4 (may be extended)
    A     0 or 1     Set to 1 if the mobile node wishes to get the
                        address of the DHCP Server.
    L     0 or 1     Set to 1 if the mobile node wishes to get the
                        DHCP lease lifetime of the address.
    S     0 or 1     Set to 1 if the mobile node wishes to get the
                        subnet mask of its home link.

   Note: it is not necessary for any of the bits to be set.  The
presence of the "Mobile IP DHCP Address" extension is sufficient to
imply the mobile node wishes to be assiged a DHCP administered
address.  If the mobile node doesn't care to be informed of any of
this information, it MAY opt to leave each of the A, L, and S bits
unset.

   If a home agent receives a registration request containing a Mobile
IP DHCP Address Request extension, it SHOULD first attempt to obtain
an address through DHCP.  If it is able to obtain the address through
DHCP, it MUST include this extension in the reply before the HA-MN or
HA-AAA authenticator, and after the NAI extension.  The home agent
SHOULD also set the bits corresponding to the information it is
returning to the mobile node.  If the home agent is unable to obtain
an address through DHCP, it MAY try another mechanism to obtain an
address, in which case it MUST NOT include the "Mobile IP DHCP
Address" extension in the registration reply.  If the home agent can
not obtain a home address for the mobile node through any means
available to it, the home agent MUST return error 99 "Missing Home
Address".

   Mobile nodes which include this extension in their registration
requests SHOULD NOT expect notification from the home agent that the
address they are getting is DHCP administered.  The mobile node MUST
assume in the absense of DHCP related extensions that any home address
it receives in the registration reply is maintained by the home agent.

   If a mobile node includes this extension with the A bit set to 1,
it MUST be prepared to perform its own lease maintenance (see section
4.2) as a home agent returning this extension, and a Mobile IP DHCP
Server IP Address extension (defined below) will not be maintaining a
DHCP lease for the mobile node.

S. Glass                Expires 7 December, 2000                [page 9]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   4.2  Mobile Node's Maintaining Their Own DHCP Leases

   It would be useful for a mobile node to manage it's own DHCP
administered address from the foreign domain.  This can only happen in
situations where a reverse tunnel exists, either through a foreign
agent, or with a colocated care-of address.  Lease renewal requires
DHCPREQUEST messages be unicast to the DHCP server, and therefore
requires knowledge of the DHCP Server IP addrss.  In this way a mobile
node can have DHCP messages delivered to (and from) the home domain,
and can immediately continue to maintain its DHCP lease, possibly
without the need to broadcase a DHCPDISCOVER message, upon returning
to the home link.

   4.2.1  Mobile IP DHCP Server IP Address Extension

   In order to maintain their own leases, the mobile node must
minimally know the IP address of the DHCP server.  The "Mobile IP DHCP
Server Address" extension is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   type        | IP version no.|     DHCP Server IP Address ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type                   54(TBA)  "DHCP Server IP Address" extension
    IP version number      4 or 6   The IP version of the address
    DHCP Server IP Address          The IP address of the DHCP server

   If the DHCP server address is an IPv4 address, the IP version
number MUST be set to 4, and there MUST be 4 octets of address in the
DHCP Server IP Address portion of the extension.  If the DHCP server
address is an IPv6 address, the IP version number MUST be set to 6,
and there MUST be 16 octets of address in the DHCP Server IP Address
portion of the extension.  In either case, the extension is
word-aligned.

   Note: This mechanism makes it possible for a mobile node to obtain
an IPv6 address via DHCPv6 from its home link by using a mobile IPv4
registration request.  It may then use the usual mobile IPv6
mechanisms to inform correspondent nodes of its location, etc. [10]

S. Glass                Expires 7 December, 2000               [page 10]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   4.2.2  Mobile IP DHCP Lease Lifetime Extension

   Knowing the lifetime granted by the DHCP server may also be useful
for mobile nodes maintaining their own leases who do not wish to renew
on every mobile ip reregistration.  If a mobile node were to have to
do this, it may opt instead to have the home agent renew its DHCP
lease.  It also allows mobile nodes to determine if immediate lease
renewal is necessary upon returning to their home network.  The "Mobile
IP DHCP Lease Lifetime" extension is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |    Lifetime ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       (lifetime continued)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type       51(TBA)  "Mobile IP DHCP Lease Lifetime" extension
    Length      4       (Same as IP address lease time option (51)[4])
    Lifetime            The lifetime of the lease for the address
                        appearing in the home address field of this
                        registration reply.  This value MUST be copied
                        from the DHCPACK message as sent by the DHCP
                        Server.

   If the mobile node is renewing its own DHCP leases, it MAY renew
the lease any time it wishes.  If it has no knowledge of it DHCP lease
lifetime, the mobile node SHOULD attempt renew its DHCP lease
immediately prior to renewing its mobile ip registaration.

S. Glass                Expires 7 December, 2000               [page 11]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   4.3  Mobile IP Home Subnet Prefix Length Extension

   A home subnet prefix is useful to the mobile node to do move
detection to the home subnet.  Without it, the mobile node must hear
becons specifically from its home agent to know that it is home.
Though requestable by the mobile node itself (through DHCPINFORM, see
below), a home subnet mask extension is useful enough that it is
defined here so the information can be delivered to the mobile node in
the initial registration reply.  The "Mobile IP Home Subnet Prefix
Length" extension is defined as follows:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |  Prefix           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type    1(TBA)    "Mobile IP Home Subnet Prefix Length" extension
    Prefix            The number of bits of prefix as indicated
                      by either the subnet mask option in the DHCPACK
                      (converted to "bits of subnet"), or the prefix-
                      len returned for an IPv6 link, and which MUST be
                      applicable to the home address returned in the
                      mobile ip registration reply.

   Note: the DHCP server will return the prefix of the address being
leased in dotted-decimal notation for IPv4 addresses.  The home agent
MUST convert this into the above format by counting the number of
leading bits in the subnet mask option of the DHCPACK.  This "dualism"
of dotted-decimal mask and prefix-length already exists in mobile IP
as "Prefix Length" extensions in mobility agent becons and will not
cause confusion if treated in the analogous fashion.  If for some
reason the DHCP server returns a subnet mask which, in its
dotted-decimal format is not convertable to the above format, the
"Mobile IP Home Subnet Prefix Length" extension MUST NOT be included
in registration replies returned to the mobile node.

   4.4  Requesting Other DHCP Information by use of DHCPINFORM

   Once the mobile node has the IP address of its DHCP Server, the
mobile node MAY build a DHCPINFORM message, and unicast it to its DHCP
Server as defined in [2].  Such a message can request any information
listed in [2], or [4].  If, for example, the home agent did not
include a "Mobile IP Home Link Prefix Length" extension, the mobile
node may itself request to be informed of the prefix lengh (subnet
mask) associated with its address.

   It is not known how DHCP Servers will respond to a DHCPINFORM
message from a node looking for the lifetime of it's lease.  It is
advised that a mobile node that does not receive a Mobile IP DHCP
Lease Lifetime extension renew their leases upon each successful
mobile IP registration renewal.

S. Glass                Expires 7 December, 2000               [page 12]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   4.5 Using Home Agents that don't Support Mobile IP DHCP Extensions

   It is recommended that if a mobile node does not recieve any DHCP
extensions from the home agent, particularly in response to a
registration request containing a "Mobile IP DHCP Address" extension,
assume its address was obtained in some generic way by the home agent,
and is maintained by the home agent (either through DHCP, or some
other means).

   The method described below is not recommended as it is not known
how all DHCP server implementations will react to DHCPDISCOVER
messages coming from a non-zero IP source address.  Moreover, it means
the home agent is unaware that the mobile node is maintaining its own
lease for this address, and may already be maintaining the lease on
the mobile node's behalf.  In general this shouldn't be a problem, but
it means more work for mobile node, home agent, DHCP server, and more
bandwidth utilization on the home link, and all links comprising the
forward and reverse tunnels.

   If a mobile node is registered with a home agent which does not
support these extensions, it MAY transmit a DHCPDISCOVER message
containing the NAI it used to register with the home agent in the
client ID option (see section 3 above) back to its home link using the
mechanisms to reverse tunnel broadcast datagrams as described by [6].
This means the DHCP assigned address will be the source address of the
DHCPDISCOVER message eminating from the home agent, and NOT the usual
0 address.  In response, the mobile node may then receive multiple
DHPCOFFERS, from which it chooses the server offering the lease to the
address it is now using as the destination of subsequent DHCPREQUESTs
used in lease maintenence.

   If no such DHCP Server can be identified, the mobile node MUST
assume the address will be maintained by the home agent.

   5.0  Other Considerations

   This section covers considerations relating to the interaction of
mobile ip, and DHCP.

   5.1  Additional Error Codes

   As this document primarily concentrates on the use of DHCP in a
mobile IP environment, there are no additional error codes defined for
basic operation.

------------ Think: for minimal mobile node implementations -------------

    There are, however, additional error codes defined for lease
maintenence in section 3.3.

------------ Fin: for minimal mobile node implementations -------------

S. Glass                Expires 7 December, 2000               [page 13]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   5.2  Returning Information from Other DHCP-Specific Options/Codes

   Without supporting optional DHCP extensions in mobile IP, there is
no way to proxy information other than the home address, and perhaps a
hint as to the DHCP lease time, to a MN.  Therefore, there is little
to be gained from the home agent including any other options in the
DHCPDISCOVER or DHCPREQUEST other than those mentioned in section 3:
Client ID option (code 61), IP address Lease Time option (code 51),
Requested IP Address option (code 50), and possibly Mobile IP Home
Agent option (code 68).  Using the method outlined in section 4.4,
however, a mobile node can use a DHCPINFORM message to obtain any
information about its home subnet it desires, and through mobile IP,
by a mechanism as if it were at home.  As a result, there is only a
limited need for DHCP extensions to mobile IP to help optimize the use
of DHCP by the mobile node and home agent.

   6.0  Caveats and Cautions

   The use of DHCP with mobile ip, while allowing address management
to be centralized, comes with some caveats, and cautions which site
administrators should be aware of.

   6.1  Home Address Availability

   There is no guarantee that DHCP administered addresses will be
available to a node, even in non-mobile ip situations.  A way around
this, however, which is not available to non-mobile IP aware nodes is
for a mobile node to be configured with multiple home agents on
different links, or multiple link prefixes in the home domain for home
agent discovery.  In this way, if one home agent is unable to obtain
an address lease for the mobile node, the mobile node may send a
registration request to a home agent on a different link (using the
same NAI) in hopes of obtaining a home address there.  Moreover, a
mobile node may obtain home addresses on different links using the
same NAI.

   6.2  Home Address Consistency

   As with any address assignment mechanism, there is a chance a
mobile node will not be able to obtain the same IP address it had been
using in the past.  This refers, of course, to an IP addresses for
which the mobile node's binding is no longer valid, or certainly for
which the DHCP lease has expired.  The mobile node should take care to
never allow a binding to expire for an IP address it may be dependant
on.  This applies not only to IP addresses obtained through DHCP, but
any address allocated by the home agent.  Although a DHCP server
SHOULD return the IP address used in a previous binding by the same
node [2], there is no guarantee the address will be available.  This
is exactly the same as in the case where the home agent is itself
handing out addresses from its own pool.  Should the home agent be
itself administering addresses, and such an address is implicity
returned to the address pool because a mobile node allowed its
registration to expire, there is no guarantee that address will be
available to the same mobile node in a subsequent session unless the

S. Glass                Expires 7 December, 2000               [page 14]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

home agent is reserving one IP address per potential mobile node, and
is therefore reserving specific IP addresses for individual mobile
nodes.  The idea of providing IP addresses from an address pool,
however, is to reuse addresses, if not allow the number of addresses
needed to be minimized, so such a home agent configuration seems to
defy the intent of dynamic IP address configuration.  In the case of
PPP assigned addresses, common practice seems to be to permanently
assign one IP address per dial-in line, but this situation is not
analogous as only one host can be connected to a dial-in line at a
time, and thereby there is no risk of multiple nodes needing this
address simultaneously, nor needing to obtain the same address across
different PPP sessions.

   6.3 Multiple DHCP Addresses

   If for some reason the mobile node wishes to obtain additional
addresses on the home link, while it seems possible for it to reverse
tunnel DHCPDISCOVER messages as described in [1] and [6] to its home
link, DHCPOFFERS arriving at the interface of the home agent on the
mobile node's home link will not contain enough information for the
home agent to know where to deliver them.  While it may be possible
for home agents to examine the contents of the decapsulated reverse
tunnel traffic, and note that it is sending a DHCPDISCOVER on behalf
of the mobile node, this is not recommended, and can lead to problems
when more than one mobile node is doing so simultaneously.

    Instead, mobile node's requiring multiple addresses MUST have one
NAI per required address on each of the required links.  Therefore, if
a mobile node has two interfaces each requiring a different address on
the same home link, it MUST have two NAIs, but if these interfaces are
on separate home links, only one NAI is required.

   If a mobile node has simultaneous DHCP leases, the way DHCP does
lease renewal requires each lease to be renewed independantly.  This
is the case if the mobile node is maintaining its own leases, or if
the home agent is doing lease renewal on behalf of the mobile node.

   6.4  Selecting an NAI

   Of concern are allowable characters that can be placed both in
NAIs, and the Client ID option.  [4] specifies the Client ID option,
and [5] specifies the character set and format restrictions for the
NAI.  At this time, there do not appear to be any conflicts with the
requirements laid out in [5] on NAI character restrictions, and those
restrictions placed on the Client ID option in [2].  System
Administrators are advised, however, to limit their assigned NAIs to
the intersection of the requirements as they may change over time.

S. Glass                Expires 7 December, 2000               [page 15]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   6.5  DHCPINFORM Caveat

   It is not known how DHCP Servers will respond to a DHCPINFORM
message from a node looking for the lifetime of it's address lease.
It is advised that a mobile node that does not receive a Mobile IP
DHCP Lease Lifetime extension not attempt to query the DHCP Server for
this information, and allow the home agent to renew its lease.

   7.0 Security Considerations

   The Mobile IP protocol requires the use of MN-HA or MN-AAA
authenticators to provide authentication of the MN to the HA/home
subnet.  Whenever a registration request is received by a home agent
it MUST be authenticated as having been sent by the MN identified by
either the home address, or if the home address is set to the 0
address, the NAI option appended to the registration request, but
appearing before, and thereby protected by, the MN-HA or MN-AAA
authenticator.  As a result, the DHCP address being requested by home
agents on behalf of mobile nodes they are servicing are being assigned
to machines which have been authenticated as belonging to the home
domain, and more specifically, are part of the subnet the assigned
address belongs to.  Moreover, as there is a one-to-one mapping
between NAI and Client ID, only one address per NAI will be assigned
per link, thereby preventing a situation where subnet addresses would
be more exhausted than if the mobile nodes were making the DHCP
requests on their own.

   8.0 Compliance Statements

   8.1  Mobile IP Compliance Statement

   Whereas this document follows mobile node and home agent
proceedures and requirements described in the mobile IP document
draft-ietf-mobileip-rfc2002-bis-LATEST.txt, which, upon obtaining RFC
status, will obsolete [1], mobile nodes complying with [1] (and [2],
and [3]) should function properly when interacting with home agents
complying with [1] (and [2], and [3]) and this specification.

   8.2  DHCP Compliance Statement

   Whereas this document details RFC2131, which obsoletes RFC1541, all
that is required is for a home agent and the DHCP server to follow
DHCP Client and Proxy requirements in RFC1541.

   9.0 Acknoledgements

   The author wishes to greatfully acknowledge the help provided by
David Miner, Carl Smith, and Michael Carney, all of Sun Microsystems.
Their knowledge of DHCP far surpasses mine, and were able to help
fill in many of the DHCP implementation details I was not clear on.

S. Glass                Expires 7 December, 2000               [page 16]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   10.0 Author's Name and Address

   Comments should be sent to the mobileip mailing list:

        [email-masked]

   or to the author:

   Steven M. Glass              [email-masked]
   Sun Microsystems
   1 Network Drive
   Burlington, MA. 01803
   Office: 1.888.555.9SUN
   Fax:    1.781.442.1677

   11.0 References

   [1]  RFC2002, "IP Mobility Support", C. Perkins, October 1996

   [2]  RFC2131, "Dynamic Host Configuration Protocol", R. Droms,
          March 1997

   [3]  RFC2794, "Mobile IP Network Access Identifier Extension for
          IPv4", P. Calhoun and C. Perkins.  March 2000.

   [4] RFC2132, "DHCP Options and BOOTP Vendor Extensions", Alexander &
          Droms, March 1997.

   [5] RFC2486, "The Network Access Identifier", B. Aboba, M. Beadles,
          January 1999.

   [6] RFC2344, "Reverse Tunneling for Mobile IP", G. Montenegro,
          May 1998

   [7] RFC2489  "Procedure for Defining New DHCP Options",  Droms,
          January 1999

   [9] Glass, S. "Mobile IP Registration Revocation", Work In Progress.

  [10] D. Johnson and C. Perkins, "Mobility Support in IPv6", Work In
          Progress.

  [11] J. Bound, M. Carney, and C. Perkins, "Dynamic Host
          Configuration Protocol for IPv6 (DHCPv6)", Work In Progress.

S. Glass                Expires 7 December, 2000               [page 17]

Internet Draft      Mobile IP Agents as DHCP Proxies        1 June, 2000

   12.0  Full Copyright Statement

      "Copyright (C) The Internet Society (2000).  All Rights Reserved.

      This document and translations of it may be copied and furnished
      to others, and derivative works that comment on or otherwise
      explain it or assist in its implementation may be prepared, copied,
      published and distributed, in whole or in part, without
      restriction of any kind, provided that the above copyright notice
      and this paragraph are included on all such copies and derivative
      works.  However, this document itself may not be modified in any
      way, such as by removing the copyright notice or references to the
      Internet Society or other Internet organizations, except as needed
      for the purpose of developing Internet standards in which case the
      procedures for copyrights defined in the Internet Standards
      process must be followed, or as required to translate it into
      languages other than English.

      The limited permissions granted above are perpetual and will not
      be revoked by the Internet Society or its successors or assigns.

      This document and the information contained herein is provided on
      an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
      ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
      IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
      THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   13.0  Chair's Address

   The Working Group can be contacted via its current chairs:

      Basavaraj Patil                Phil Roberts
      Nokia Corporation              Motorola
      M/S M8-540
      6000 Connection Drive          1501 West Shure Drive
      Irving, TX 75039               Arlington Heights, IL 60004
      USA                            USA
      Phone:  +1 972-894-6709        Phone:  +1 847-632-3148
      EMail:  [email-masked]    EMail:  [email-masked]
      Fax :  +1 972-894-5349

S. Glass                Expires 7 December, 2000               [page 18]