Internet DRAFT - draft-glass-mobileip-agent-dhcp-proxy
draft-glass-mobileip-agent-dhcp-proxy
Internet Engineering Task Force S. Glass
INTERNET DRAFT Sun Microsystems
Mobile IP Working Group 2 March 2000
Mobile IP Agents as DHCP Proxies
draft-glass-mobileip-agent-dhcp-proxy-01.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 MOBILE-IP@STANDARDS.NORTELNETWORKS.COM 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, if there was a way for a home
agent to contact a DHCP server to allocate an address for the mobile
node, it would preserve 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
acting on behalf of the mobile node.
S. Glass Expires August, 2001 [page i]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
This document specifies the procedure a Home Agent should follow
when contacting a DHCP server to obtain one or more home addresses for
mobile nodes that require them. Moreover, it does so in the spirit of
the design goals of [1], and [2] (section 1.6). It also specifies the
responsibilities of the home agent with regard to defending this
address, and maintaining it as appropriate. Obviously, simply
supporting home address assignment of any kind at the home agent
requires changes to the home agent, and so the most desireable
implementation solution is to not require changes to any other mobile
IP entity. 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. A clearer picture is also
presented as to what needs to be addressed when a mobile node is not
assigned a home address before it roams away from its home link, and
the complications that can result in various mobile IP situations
while the mobile node is attached to foreign links.
As always, optimizations and enhancements to such a mechanism can
be made, in this case proposing changes to both home agent and mobile
node. These changes are specified as optional extension support, and
are not required for compliance to this draft by a home agent
implementation; the exchange of extensions is defined in such a way
that if one side does not understand them, 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 to keep their
current connections active, but to also start and accept new
connections while visiting foreign links through an agent on their
home subnet, known as the home agent. Recent enhancements [3] 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 proposed, however.
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 is difficult since the only 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 imitate functionality already designed for mobile
ip. Moreover, a solution independant of the mobile ip services being
offered on the visited link (such as reverse tunnelling and
broadcast/multicast support) is desireable.
S. Glass Expires August, 2001 [page 1]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
The mechanism used to authenticate 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, it MUST contain an NAI
extension which it uses to locate the shared secret between the mobile
node and itself, verifying the MN-HA authenticator contained in the
registration request (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.
2.0 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. From 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 nothing more than
a 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, then
using the address it assignes to the mobile node in accordance with
[1], and will refer to it as a DHCP Proxy for consistency.
S. Glass Expires August, 2001 [page 2]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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.
Note: alternatively, on an IPv6 link, the home agent MAY use the
address autoconfigure mechanism present in IPv6. See appendix A.
3.0 Operation of a Home Agent as a DHCPv4 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.
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 source address of the registration request as
defined in [1].
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
S. Glass Expires August, 2001 [page 3]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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) MAY be included where the lifetime requested
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 MUST wait an acceptable 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 130, "Insufficient Resources". 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 IP address or lifetime, are unacceptable, the
home agent SHOULD attempt to negotiate these with the DHCP server.
If the DHCPOFFER includes the Mobile IP Home Agent option (code
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 DHCP Home Agent Option in the home agent
field of the registration reply. Furthermore, should this home agent
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 wait an acceptable
amount of time for a DHCPACK. It is recommended that the home agent
wait at least DHCPREQUEST_TIMEOUT seconds for the DHCPACK from the
S. Glass Expires August, 2001 [page 4]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
DHCP server. If no reply is received to the DHCPREQUEST, the home
agent MUST either generate another DHCPREQUEST for an address apearing
in another received DHCPOFFER from a DHCP Server, or the home agent
MAY transmit another DHCPDISCOVER as in (1) above, or, if no other
address assignment mechanism is available, or desireable, the home
agent MUST send a registration response to the source of the
registration request with error 130, "Insufficient Resources", making
sure to include the mobile node's NAI as it appeared in the
registration request, and the HA-MN authenticator, and HA-FA
authenticator if required by [1]. (Think: what about simply returning
a zero home address, at which time the foriegn agent SHOULD return
"Missing Home Address" to the mobile node?)
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 [1] [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, or if no other address assignment mechanism is available or
desireable, the home agent MUST send a registration response to the
source of the registration request with error 130, "Insufficient
Resources", making sure to include the mobile node's NAI as it
appeared in the registration request, and the HA-MN authenticator, and
HA-FA authenticator if required by [1]. (Think: what about simply
returning a zero home address, at which time the foriegn agent SHOULD
return "Missing Home Address" to the mobile node?)
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, or desireable, the
home agent MUST send a registration response to the source of the
registration request with error 130, "Insufficient Resources", making
sure to include the mobile node's NAI as it appeared in the
registration request, and the HA-MN authenticator, and HA-FA
authenticator if required by [1]. (Think: what about simply returning
a zero home address, at which time the foriegn agent SHOULD return
"Missing Home Address" to the mobile node?)
(Think: 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 lease time granted by the DHCP
server. The home agent MUST also remember that this address was
S. Glass Expires August, 2001 [page 5]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
assigned to the mobile node identifying itself by this NAI, and the
address of the DHCP server that assigned this address, and SHOULD
remember the lifetime granted by the DHCP server for future reference
The home agent MUST also include the NAI option as per [3], and
append the usual HA-MN authenticator, and if required HA-FA
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 [1] [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 130, "Insufficient
Resources", making sure to include the mobile node's NAI as it
appeared in the registration request, and the HA-MN authenticator, and
HA-FA authenticator if required by [1]. (Think: what about simply
returning a zero home address, at which time the foriegn agent SHOULD
return "Missing Home Address" to the mobile node?)
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 it MUST include the 0
address in the home address field of the registration request, and the
NAI that it originally used to obtain the binding and address.
2. The home agent receives and authenticates the registration
request. It MUST then check to see if it already has a binding, and
is providing home agent services for this mobile node. This
determination can be based on NAI, or a 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 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 this NAI (if present).
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,
and the home agent is either unaware of the DHCP lease time, or is
aware that [half of] the DHCP lease will expire before this
registration request (if approved) would expire, the home agent MUST
build a DHCPREQUEST message exactly as it would for any DHCP address
S. Glass Expires August, 2001 [page 6]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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 MAY include a requested IP Address option (code 50) with the
address set to the home address it is using. 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.
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, meaning 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
registration 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 130,
"Insufficient Resources".
3.3 De-registration Requests
Upon returning home the mobile node will deregister with the home
agent as described in [1]. The mobile node generates a registration
request with a lifetime of 0, and MUST use either the address assigned
to it in the 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, and if not deny the registration request with error 129,
"Administratively Prohibited". If the [de]registration request is
S. Glass Expires August, 2001 [page 7]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
acceptable, 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 mobile ip binding. 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, 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 mobile node 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 (set to it's previous HA, or to the
zero address) for future reference.
In response to this DHCPDISCOVER message, the mobile node SHOULD
receive one, or it MAY receive 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. It processes the DHCPACK as it would normally when
booting on this link and obtaining an address through DHCP. The
mobile node SHOULD also cache the DHCPACK received from the DHCP
server for future reference as recommended in [2].
Note: A DHCPDISCOVER message is generated upon returning to the
home link, 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 if the
home link of the home agent's is only part of the same 'virtual' link
as the mobile node); these MUST now be set to those that are
appropriate for the mobile nodes home interface.
------------ Think: for minimal mobile node implementations -------------
These thoughts apply if the working group feels there is interest
in having a home agent continue to maintain the least for a minimal
mobile node even after it has roamed [back] to its home link.
S. Glass Expires August, 2001 [page 8]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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 130,
"Insufficient Resources".. 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 -------------
3.4 Address Responsibilities
The home agent, in negotiating for a home address for the mobile
node while it is away from its home link, has effectively 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 foreign subnet.
When using this address on its home subnet, it MUST defend this
address itself as it would any address it is using.
S. Glass Expires August, 2001 [page 9]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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 extensions 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].
4.1 Mobile IP DHCP-Request 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 |C|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)
C 0 or 1 Set to 1 if the mobile node wishes to cache
the DHCP ACK returned by the DHCP Server.
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.
S. Glass Expires August, 2001 [page 10]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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 assigned 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, or MAY include one
indicating none of the information was assigned by DHCP. 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 130,
"Insufficient Resources".
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 will be 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.
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. Without using an
additional extension, this can only happen in situations where a
reverse tunnel exists, either through a foreign agent, or with a
colocated care-of address. Moreover, it can only happen in topologies
where broadcast/multicast support is provided on the home agent, and
the foreign agent if one is being used. DHCPDISCOVER messages must be
reverse tunneled as described by [6] for broadcast/multicast messages.
Lease renewal requires DHCPREQUEST messages be unicast to the DHCP
server, and therefore requires knowledge of the DHCP Server IP
address, either through configuration, or the DHCPDISCOVER mechanism.
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.
S. Glass Expires August, 2001 [page 11]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
4.2.1 Mobile IP DHCP ACK Extension
In some situations, the entire DHCPACK should be returned to the
mobile node. This MUST only be done when a mobile node includes a
mobile IP DHCP-Request extension in its registration request. This is
designed to pass the entire DHCPACK to the mobile node so it can parse
the information returned from the DHCP server as if it were on its
home subnet without the need for broadcast/multicast support. The
"Mobile IP DHCP ACK" 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 | DHCP ACK ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (TBA) "DHCP ACK" Extension
Length The length of the ACK in octets
DHCP Server IP Address The DHPC ACK sent by the DHCP Server
The DHCP ACK MUST appear in the DHCP ACK Extension exactly as it
was sent by the DHCP Server assigning the IP address being assigned to
the mobile node.
4.2.2 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 (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, this extension is always
word-aligned.
At any time the mobile node may include a "Mobile IP DHCP Server IP
Address" extension in any registration request to attempt to obtain
S. Glass Expires August, 2001 [page 12]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
the unicast address of the DHCP Server which assigned its address. If
this is done when the mobile node is roamed, it MUST maintain its own
DHCP lease upon obtaining the DHCP Server address, or altenately may
opt to send the extension only upon returning to the home link in its
dereigstration request. This MAY allow the MN to skip the
DHCPDISCOVER it otherwise needs to send to find its DHCP Server's
unicast address, and therefore can now send a DHCPREQUEST directly to
the DHCP Server.
This extension SHOULD NOT be included if the DHCP-ACK extension is
included in the registration reply.
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]
4.2.3 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 (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.
This extension SHOULD NOT be included if the DHCP-ACK extension is
included in the registration reply.
S. Glass Expires August, 2001 [page 13]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
4.2.4 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.
This extension SHOULD NOT be included if the DHCP-ACK extension is
included in the 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.3 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.
S. Glass Expires August, 2001 [page 14]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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.
4.4 Using Home Agents that don't Support Mobile IP DHCP Extensions
It is recommended that if a mobile node does not receive 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.
S. Glass Expires August, 2001 [page 15]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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 -------------
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
S. Glass Expires August, 2001 [page 16]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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, or it may obtain more than one home address on any link by
using multiple NAIs.
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
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.
S. Glass Expires August, 2001 [page 17]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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.
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 a DHCP Server for
this information, and instead allow the home agent to renew its lease
while it is away from its home link.
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.
S. Glass Expires August, 2001 [page 18]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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.
Appendix A: Use of IPv6 Address Autoconfigure
In IPv6, the address autoconfigure mechanism can be used by a node
booting on a link to obtain a link-local IPv6 address. On IPv6 links
where DHCP is not available, or where it is more desirable to use
address autoconfigure, the mobile node MUST still include an NAI
option in its binding update message with a Home Address options
indicating a zero IPv6 address, and SHOULD include a sub-option type
containing the interface-identifier the mobile node wishes the home
agent to use to obtain an IPv6 address. The home agent may then take
this and use it to generate the corressponding IPv6 address as it
would with any interface identifier, making sure to perform neighbor
solicitation to detect address conflicts, and returning the address in
a Home Address Option contained in a Binding Acknowledgement message.
If there is a conflict with the autoconfigured address, or if the
sub-option type is not included in the Binding Update message, the
Home Agent may generate a random number to server the same purpose,
again making sure the address is not in use on the mobile node's home
link.
Acknowledgements
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 August, 2001 [page 19]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
Working Group Address and Author's Name and Address
Comments should be sent to the mobileip mailing list:
mobile-ip@sunroof.eng.sun.com
or to the author:
Steven M. Glass Steven.Glass@sun.com
Sun Microsystems
1 Network Drive
Burlington, MA. 01803
Office: 1.888.555.9SUN
Fax: 1.781.442.1677
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 August, 2001 [page 20]
Internet Draft Mobile IP Agents as DHCP Proxies March, 2001
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.
Chair's Address
The Working Group can also 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: Raj.Patil@nokia.com EMail: QA3445@email.mot.com
Fax : +1 972-894-5349
S. Glass Expires August, 2001 [page 21]
