[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                    Anthony McAuley
INTERNET-DRAFT                                                 Subir Das
Internet Engineering Task Force                   Telcordia Technologies
draft-ietf-dhc-enhance-requirements-00.txt                 Shinichi Baba
Date: March 8, 2000                                     Yasuro Shobatake
Expires: August, 2000                      Toshiba America Research Inc.



        Requirements for Extending DHCP into New Environments



Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of sections 10 of RFC 2026.

   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.



Abstract

   The Dynamic Host Configuration Protocol (DHCP) provides a widely
   deployed framework for host registration and configuration [DHC].
   DHCP, however, was designed only for fixed hosts on physically secure
   LANs. Other protocols fill some of the gap. PPP [PPP] is a good
   solution for many commercial service providers (where framing is
   needed). Mobile IP [MIP] is ideal for registering and configuring
   roaming users (when transparent address binding is needed). This
   still leaves many environments where there is no ideal solution,
   such as: roaming users who do not need transparent address binding



ITSUMO Group               Expires August 2000                 [Page 1]


Internet Draft       Requirements for Extending DHCP       March 3, 2000


   (e.g., a mobile web browser), and commercial service providers
   who want to support home networking with multiple nodes. This draft
   proposes DHCP as the best protocol to meet these new needs, because
   it leave open how (and whether) to provide other functions, such as
   framing (e.g., PPP), locating (e.g., Mobile IP in co-located mode),
   inter-domain AAA (e.g., [AAAR]), or address distribution (e.g.,
   [DAAP]). We describe and solicit feedback on seven new requirements
   that would be placed on DHCP to meet these needs.



1. Introduction

   Most future networks will use IP technology. To provide heterogeneity
   and flexibility, devices will likely access this IP-based network by
   directly sending IP packets. In such an environment it is natural to
   consider using IP-based protocols for user-network signaling, since
   they can be used across any wired or wireless access network.


1.1 Architecture

   Figure 1 shows a high level functional architecture of a future IP-
   based network, with both a fixed and a roaming clients attaching
   to various wired or wireless Access Networks.  We assume the client
   has at least one physical interface onto the access network, but
   can also have other physical and virtual interfaces. The access
   network, which may contain multiple Layer 2 nodes (such as hubs),
   connects to at least one Edge Router and Edge Agent (that may be
   co-located). The Regional Backbone connects all the Edge Routers in
   an administrative domain and the Global Internet interconnects all
   the regional networks.

   We assume the network may need to change client configuration of even
   fixed nodes at any time, but that typically clients keep the same
   configuration (e.g., IP address) while they are within a given access
   network. Micro mobility within the access network is handled at Layer
   2. Depending on how routing is done, the client may or may not need a
   new configuration when it moves to a new access network within the
   same domain (macro mobility) [CEL] [HAW]. We assume, however, that
   clients must be reconfigured when moving to a new domain (global
   mobility).









ITSUMO Group               Expires August 2000                 [Page 2]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



   . <---- DOMAIN 1 ----> .                    . <---- DOMAIN 2  ----> .
   .        +---------+   .  +--------------+  .    +---------+        .
   .        | Domain  |   .  | Inter-domain |  .    | Domain  |        .
   .        | Agent   |   .  | Agent        |  .    | Agent   |        .
   .        +---------+   .  +--------------+  .    +---------+        .
   .             |        .         |          .         |             .
   .           __|__      .       __|___       .       __|__           .
   .          /     \     .      /      \      .      /     \          .
   .         /       \    .     /        \     .     /       \         .
   .        / Regional\________/ Global   \_________/ Regional\        .
   .        \ Backbone/     .  \ Internet /  .      \ Backbone/        .
   .     ____\       /____   .  \        /  .    ____\       /____     .
   .    /     \_____/     \   .  \______/  .    /     \_____/     \    .
   .   /         |         \   .          .    /         |         \   .
   .  /          |          \   .        .    /          |          \  .
   .         +--------+          .       .          +--------+         .
   .      .. | Edge   | ..       .       .       .. | Edge   | ..      .
   .         | Router |          .       .          | Router |         .
   .         +--------+          .       .          +--------+         .
   .         .. |  | ..          .       .          .. |  | ..         .
   . +--------+ |  | +--------+  .       .  +--------+ |  | +--------+ .
   . | Edge   | |  | | Edge   |  .       .  | Edge   | |  | | Edge   | .
   . | Agent  | |  | | Agent  |  .       .  | Agent  | |  | | Agent  | .
   . +--------+ |  | +--------+  .       .  +--------+ |  | +--------+ .
   .  |         |  |         |   .       .   |         |  |         |  .
   .  | _____   |  |   _____ |   .       .   | _____   |  |   _____ |  .
   .  |/     \__|  |__/     \|   .       .   |/     \__|  |__/     \|  .
   .  /       \      /       \   .       .   /       \      /       \  .
   . / Access  \ .. / Access  \  .       .  / Access  \ .. / Access  \ .
   . \ Network /    \ Network /  .       .  \ Network /    \ Network / .
   .  \       /      \       /   .       .   \       /      \       /  .
   .   \_____/        \_____/    .       .    \_____/        \_____/   .
   .      |              |       .       .       |              |      .
          |              |                       |              |
     +---------+    +---------+      global          macro
     | Fixed   |    | Mobile  | ****************> *************>
     | Client  |    | Client  |     mobility        mobility
     +---------+    +---------+


   Figure 1: Functional Network Architecture









ITSUMO Group               Expires August 2000                 [Page 3]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



   Figure 1 is meant to be very general functional diagram. It does not,
   for example, specify where a Base Station (BS) is located. BSs could
   be within the access networks (Layer 2 BS) or in the Edge Router (IP
   BS). The Domain and Inter-Domain agents which perform functions such
   as registration and AAA, are shown as single boxes; but both could be
   implemented as multiple nodes (possibly in a hierarchical structure).


1.2 Functional Scope

   The functions needed to support users' accessing IP-based networks
   vary, depending on network, user, and application characteristics.
   Some basic functions include:
    o Registration: Users indicate their presence and their requirements
      to a network (e.g., give a user name [NAI]).
    o Configuration: Networks adapt nodes to the particular network
      characteristics (e.g., give an IP address).
    o Framing: Indicates the start and end of packets in a data stream.
    o Compression: Compress RTP/UDP/TCP/IP header and data over an
      access network.
    o Dynamic Address Binding: Allows corresponding nodes to locate
      users and allows continuous communication as the user moves among
      networks.

   This draft is concerned only with the first two functions, which we
   believe have a natural association (see Section 3.5). This draft
   considers only server based methods for registration and
   configuration within a single IP domain. The network servers are
   themselves configured with information such as an IP address pool;
   but, server configuration is beyond the scope of this draft. We
   assume each access network has at least one edge server (possibly
   co-located with the edge router), though it could be as simple as a
   relay agent.


1.3 Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [REQ].










ITSUMO Group               Expires August 2000                 [Page 4]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



1.4 Terminology

   This document uses the following terms:

   o "AAA"
     Authentication, authorization and accounting

   o "BOOTP"
      The Bootstrap Protocol (BOOTP) [BOO1] [BOO2].

   o "DHCP"
      The Dynamic Host Configuration Protocol (DHCP) used to configure
      Internet hosts.

   o "DHCP client"
      A DHCP client is an Internet host using DHCP to obtain
      configuration parameters such as a network address.

   o "DHCP relay agent"
      A relay agent is an Internet host that passes DHCP messages
      between DHCP clients and DHCP servers.

   o "DHCP server"
      A DHCP server is an Internet node that returns configuration
      parameters to DHCP clients.

   o "Domain Agent"
      An Internet node that provides a centralized service within a
      domain (e.g., DHCP server)

   o "Edge Router"
      An IP router connecting an IP subnet to other networks.

   o "Edge Agnet"
      An IP node (host or router) that is connected to an IP subnet and
      provides services (e.g., DHCP relay agent).

   o "Inter-domain Agent"
      An Internet node that provides services for a node anywhere in the
      Internet.

   o "NAI"
      Network Access Identifier of the form user@domain [NAI].







ITSUMO Group               Expires August 2000                 [Page 5]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



2 Registration and Configuration Protocols

   There are several TCP/IP protocol choices for performing registration
   and configuration:
    o The Point-to-Point Protocol (PPP).
    o The Mobile IP protocol (MIP).
    o The Dynamic Host Configuration Protocol (DHCP).


2.1 PPP

   Although its primary function is packet framing, PPP also provides
   well tested and widely deployed registration and configuration
   capabilities. PPP [PPP] clients sends registration information, such
   as login and password to an access concentrator on the Layer 2
   network to which the client is connected. The access concentrator can
   then either directly configure the client or use the Layer 2
   Tunneling Protocol [PPPL] to tunnel PPP packets to and from a server
   anywhere in the Internet. The powerful PPP registration and
   configuration capabilities are now even used when framing is not
   needed (e.g., PPPoE [PPPE]). The only cost is that it leaves some of
   the PPP framing overhead (2 bytes for framing, 2 bytes for CRC, up to
   4 other bytes, and bit or byte stuffing overhead).


2.2 Mobile IP

   Although its primary function is providing location service and
   continuous connectivity to roaming users, Mobile IP [MIP] [MIP6] also
   provides a flexible registration and configuration capabilities. The
   Mobile IP client sends registration information to a Foreign Agent
   [MIPA] [MIPC] [MIPD] [MIPN] [MIPS] [MIPT] on the Layer 2 network to
   which the client is connected. The Foreign Agent can then configure
   the client, after getting authorization from the user's Home Agent.
   The registration and configuration capabilities could be provided by
   Mobile IP for all roaming users, even when transparent binding is not
   needed (e.g., for web browsing) or may need alternative mechanisms
   (viz., SIP for real-time applications [SIP] [SIPM]). The only costs
   are: a) triangular routing, b) having to configure a permanent home
   address, and c) depending on a home network.










ITSUMO Group               Expires August 2000                 [Page 6]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



2.3 DHCP

   DHCP provides a well tested and widely deployed framework for passing
   configuration information to hosts [DHC]. A DHCP client in a host
   broadcasts a DISCOVER control message to the access network. A
   server picks up the message and either a) returns an OFFER message
   (server) or b) relays the message to a central DHCP server. DHCP is
   unique in that it:
    o Has no additional functions (e.g., framing or address binding).
    o Requires no client preconfiguration (e.g., for home addresses).
    o No overhead to data traffic (out-of-band signaling).
    o Allows nodes to go on and off without re-registration.
    o Allows a single network server per domain (using relay agents).

   DHCP is likely to continue to gain in popularity with recent
   enhancements, such as Server fail-over [DHCF], Load balancing [DHCB],
   Dynamic updating of DNS [DHCD], LDAP database management [DHCL], and
   Authentication [DHCA].


2.4 Choice

   PPP, Mobile IP and DHCP were designed for different environments.
   Thus, network designers select the registration and configuration
   protocol that best fits the types of access network and likely client
   applications. For example, networks using phone lines for access will
   typically use PPP; wireless providers supporting roaming TCP
   application, such as telnet and ftp, will use Mobile IP; and
   corporate networks will use DHCP.

   The open question is what registration and configuration protocol
   will be used in environments that do not fit into the PPP, Mobile IP,
   or DHCP assumptions? Examples of these environments are:
    o Commercial service providers who want to support flexible home
      networking.
    o Roaming users who either do not need transparent binding (e.g.,
      just web browsing) or prefer alternative mechanisms (e.g., SIP for
      real-time applications).
   PPP, Mobile IP and DHCP could all be adapted to better some or all of
   these environments. This draft proposes DHCP as the best protocol to
   meet these new needs, because it leave open how (and whether) to
   provide other functions, such as framing (e.g., PPP), locating (e.g.,
   Mobile IP in co-located mode), inter-domain AAA (e.g., [AAAR]), or
   address distribution (e.g., [DAAP]). We describe the new requirements
   that would be placed on DHCP in the next Section.





ITSUMO Group               Expires August 2000                 [Page 7]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



3. Requirements for Extending DHCP into New Environments

   Though DHCP has many desirable features, the following requirements
   created by new environments are not fully met by DHCP:
     o R1 Rapid client configuration (milliseconds rather than seconds).
     o R2 Rapid client reconfiguration (independent of lease time).
     o R3 Efficient use of scarce wireless bandwidth.
     o R4 Allowing clients to be routers.
     o R5 Enhanced registration (e.g, user identification and security).
     o R6 Flexible proxies that can act as both relay or server.
     o R7 Allowing dynamic server and relay reconfiguration.
   This section gives a brief description and motivation for each new
   requirement.


3.1 Rapid configuration

   Configuration latency is critical to users roaming among wireless
   networks. A DHCP client accepts an OFFER by returning a REQUEST
   message to the server (which the server ACKS). The client, however,
   only configures its new address after checking that no other node on
   the subnet is using it. The DHCP specification [DHC] says a client
   SHOULD do ARP checking before an assigned address is used. This
   "in-line" checking results in long delay (typically 3-15 seconds)
   before communication can resume after a move; too long for many
   roaming users. While duplicate detection is desirable, it need not be
   part of the critical path. One possible alternative, for example,
   would be to have the server do ARP checking on addresses before they
   are requested.

   The goal is to get configuration in milliseconds (bounded mostly by
   by the speed of the access link) rather than seconds.


















ITSUMO Group               Expires August 2000                 [Page 8]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



3.2 Rapid reconfiguration

   A recent draft [DHCR] has proposed a new DHCP FORCERENEW message
   that allows servers to force clients to immediately reconfigure.
   To enable rapid reconfiguration (e.g., when a roaming user moves into
   a new subnet or topology changes), clients must rapidly detect the
   server request. Today, DHCP clients typically go into sleep mode,
   not listening to DHCP messages until the lease is due for renewal.
   Clients can use external triggers, such as a layer 2 hand-off
   indication or an SNMP V3 request message, to jump DHCP into a new
   state. These triggers, however, may not always: a) be available,
   b) be standardized, c) have enough information. The information may
   help client to decide if it is in a new subnet or to get the location
   of a DHCP server (to prevent having to broadcast).

   The goal is to be able to rapidly reconfigure DHCP clients, at any
   time, without relying on external triggers.


3.3 Bandwidth Efficiency

   DHCP message overhead is considerably larger than needed, mainly
   because DHCP kept the same syntax as BOOTP [BOO1] [BOO2] [BOOD]. This
   was not a problem in the old paradigm where hosts connect to DHCP
   servers over high speed LANs; especially since DHCP overhead mainly
   occurs when a host first boots and DHCP adds nothing to normal packet
   communication overhead. The overhead is perhaps only a problem for
   roaming nodes using some wireless access networks. Depending on the
   size of the IP subnets, roaming users might need to reconfigure as
   fast as every few seconds. Depending on the speed and error rate of
   the wireless access networks, reducing DHCP message size could
   significantly improve bandwidth efficiency. (The error rate can be
   important since larger messages result in higher probability of loss,
   that increases latency and bandwidth needs.)

   The goal is to minimize DHCP message size, by reducing the size of
   individual DHCP messages and possibly by reducing the total number of
   messages.












ITSUMO Group               Expires August 2000                 [Page 9]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



3.4 Clients as Routers

   DHCP specification [DHC] says clients must be hosts and that it "is
   not intended for use in configuring routers." This was not a problem
   in the old paradigm, where routers were typically part of a
   hierarchical network that could be manually configured by a system's
   administrator. As the size and complexity of networks increase
   (e.g., with more small devices with low power wireless interfaces),
   routing functionality becomes desirable in places where manual
   configuration is not desirable. We are NOT proposing that DHCP be
   extended to simultaneously configure multiple router interfaces or
   to distribute address pools; only that DHCP could configure a single
   router interface over a subnet where there is a DHCP server (or
   relay). This would require no change in DHCP functionality; only a
   change in allowable application.

   The goal is to allow DHCP to configure hosts and routers.


3.5 Enhanced Registration

   Commercial service providers need a scalable way to identify and
   authenticate users. In addition they may need other registration
   information such as: a) the location of the client's AAA server
   (for inter-domain authentication [DHCZ], b) negotiate service
   requirements and costs, and c) trigger other services (possibly
   based on a user profile). Many of these features are now being
   defined for DHCP, but filling the missing needs would be helpful.
   We assume that DHCP itself only deals with intra-domain registration;
   a separate AAA protocol [AAAD] [AAAR] meets the inter-domain
   requirements.

   The registration and configuration could be done in separate
   protocols; however we believe integrating the two functions is
   desirable. First, it reduces the latency, since it requires only
   one round trip from the client to the network. Second, it forces
   users to register before they can be configured. Clearly, devious
   users could still configure themselves, but now they cannot use
   DHCP to do this.

   The goal is to allow DHCP to meet the registration needs of diverse
   service providers.








ITSUMO Group               Expires August 2000                 [Page 10]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



3.6 DHCP Proxies

   A DHCP client must either connect to a node acting as a DHCP server
   or connect to a DHCP relay. When a client first activates or moves
   into a new domain, DHCP message are best relayed to a central server
   (such as the Domain Agent in Figure 1); however, when users roaming
   among subnets within a domain DHCP message may best be handled
   locally. This would require no change in DHCP functionality; only a
   change in allowable application.

   The goal is to allow a subnet proxy to act as both a relay and
   server, depending on a client's status.


3.7 Dynamically changing server (and relay) parameters

   In some networks it may be desirable to dynamically change the
   preconfigured information in DHCP servers (and relay agents). For
   example, the address-pool may change if a topology change occurs
   [DAAP]. While DHCP should have nothing to do with updating
   address-pools, it should be able to handle dynamic changes in this
   information. If an external application changed the information,
   DHCP should gracefully handle the change (e.g., it may immediately
   update all its clients). This would require no change in DHCP
   protocol, only that: a) there is a common configuration framework
   (e.g., [DHCL]), and b) that DHCP servers and relay agents allow
   dynamic changes in preconfigured information.

   The goal is to allow dynamic modification of DHCP server (and relay)
   configured parameters, such as the address-pool, by an external
   entity.



















ITSUMO Group               Expires August 2000                 [Page 11]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



4 Discussion

   The purpose of this draft is to stimulate discussion and solicit
   feedback on enhancing DHCP into new environments. These environments
   include roaming users who do not need transparent address binding
   (e.g., a mobile web browser) or commercial service providers whose
   access network provides framing (e.g., a cable access network).
   Given the large paradigm shift created by these new environments, it
   is an open question on how to achieve these changes. At the highest
   level we could slowly enhance DHCP, while maintaining backwards
   compatibility. A more radical approach would be the creation of a
   sister protocol such as DRCP [DRCP]. We have not given specific
   approaches or mechanisms here, except as examples, because we
   initially want to focus on the requirements.



5. Acknowledgments

   The authors acknowledge the contributions of other members of the
   ITSUMO (Internet Technologies Supporting Universal Mobile Operation)
   team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta, D. Famolari,
   S. Madhani, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff) and
   Toshiba America Research Incorporated (T. Kodama). Also thanks to
   Steve Gonczi of Process Software for his helpful suggestions.

   The initial ideas came out of a project on complete network
   autoconfiguration within a domain [DAAP], funded by the U.S. Army
   Research Laboratory (ARL) under the Advanced Telecommunications and
   Information Distribution Research Program (ATIRP) Consortium.



6. References

   [AAAD] P. Calhoun and A. Rubens, "DIAMETER Base Protocol," Internet
          draft, Work in Progress, Nov 1998.

   [AAAR] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote
          Authentication Dial in User Service (RADIUS)," Request for
          Comments 2138, Apr 1997.

   [BOO1] B. Croft & J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
          Stanford and SUN Microsystems, September 1985.

   [BOO2] Wimer, W., "Clarifications and Extensions for the Bootstrap
          Protocol", RFC 1542, Carnegie Mellon University, October 1993.



ITSUMO Group               Expires August 2000                 [Page 12]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



   [BOOD] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
          Bucknell University, October 1993.

   [CEL]  Valko, A., Campbell, A. and Gomez, J.: "Cellular IP", Internet
          draft, <draft-valko-cellularip-00.txt>, Work in progress,
          November 1998.

   [DAAP] A. McAuley and K. Manousakis, "Self-Configuring Networks."
          To appear Proc. of 4'th Advanced Telecommunications and
          Information Distribution Research (ATIRP) Conference,
          University of Maryland, March 2000.

   [DHC]  R. Droms, "Dynamic Host Configuration Protocol," Request for
          Comments 2131, Mar 1997.

   [DHCA] R. Droms, W. Arbaugh, "Authentication for DHCP Messages",
          <draft-ietf-dhc-authentication-12.txt>, Work in progress,
          October 1999.

   [DHCB] B. Volz, S. Gonczi, T. Lemon, R. Stevens, "DHC load balancing
          algorithm," <draft-ietf-dhc-loadb-00.txt>, Work in progress,
          October 1999.

   [DHCD] Y. Rekhter, M. Stapp, "Interaction between DHCP and DNS,"
          <draft-ietf-dhc-dhcp-dns-10.txt>, Work in progress, June 1999.

   [DHCL] A. Bennett, B. Volz, A. Westerinen, "DHCP Schema for LDAP,"
          <draft-ietf-dhc-schema-00.txt>, Work in progress, June 1999.

   [DHCF] R. Droms, K. Kinnear, M. Stapp, B. Volz, S. Gonczi, G. Rabil,
          M. Dooley, A. Kapur, "DHCP Failover Protocol,"
          <draft-ietf-dhc-failover-05.txt>, Work in progress,
          October 1999.

   [DHCR] P. De Schrijver, Y. T'Joens, C. Hublet, "Dynamic host
          configuration : DHCP reconfigure extension,"
          <draft-ietf-dhcpv4-reconfigure-01.txt>, Work in progress,
          March 2000.

   [DHCZ] S. Das, A. McAuley, S.Baba, and Y.Shobatake, "Authentication,
          Authorization, and Accounting Requirements for Roaming Nodes
          using DHCP," <draft-ietf-dhc-aaa-reqs-00.txt>, Work in
          Progress, March 2000.

   [DRCP] A. McAuley, S. Das, S.Baba, and Y.Shobatake, "Dynamic
          Registration and Configuration Protocol (DRCP),"
          <draft-itsumo-drcp-00.txt>, Work in Progress, October 1999.



ITSUMO Group               Expires August 2000                 [Page 13]


Internet Draft       Requirements for Extending DHCP       March 3, 2000



   [HAW]  R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP micro-
          mobility support using HAWAII",
          <draft-ramjee-micro-mobility-hawaii-00.txt>, Work in progress,
          June 1999.

   [MIP]  C. Perkins, "IP Mobility Support", RFC 2002, October 1996.

   [MIP6] D. Johnson and C. Perkins, "Mobility Support in IPv6,"
          <draft-ietf-mobileip-ipv6-09.txt>, Work in Progress, Oct 1999.

   [MIPA] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
          Authorization, and Accounting Requirements,"
          <draft-ietf-mobileip-aaa-reqs-00.txt>, Work in progress,
          October 1999.

   [MIPC] E. Gustafsson, A. Jonsson, E. Hubbard, J. Malmkvist, A. Roos,
          "Requirements on Mobile IP from a Cellular Perspective,"
          <draft-ietf-mobileip-cellular-requirements-01.txt>, Work in
          progress, June 1999.

   [MIPD] P. Calhoun and C.E. Perkins, "DIAMETER Mobile IP Extensions,"
          Internet draft, Work in Progress, Nov 1998.

   [MIPN] P. Calhoun and C.E. Perkins, "Mobile IP Network Access
          Identifier Extension," <draft-ietf-mobileip-mn-nai-05.txt>
          Work in progress, October 1999.

   [MIPS] B. Patil, R. Narayanan & E. Qaddoura, "Security Requirements/
          Implementaion Guidelines for Mobile IP using IP security"
          Internet draft, Work in Progress, June,1999.

   [MIPT] Tom Hiller, et al. "3G Wireless Data Provider Architecture
          Using Mobile IP and AAA," <draft-hiller-3gwireless-00.txt>,
          Internet draft, Work in progress, October 1999.

   [NAI]  B. Aboba and M. A. Beadles, "The network access identifier,"
          RFC 2486, January 1999.

   [PPP]  W. Simpson, "The Point to Point Protocol (PPP),: Internet STD
          51, July 1994.

   [PPPE] L. Mamakos, et al., "Method for Transmitting PPP Over Ethernet
          (PPPoE)," RFC 2516, February 1999.

   [PPPL] W. Townsley, et al, "Layer Two Tunneling Protocol L2TP," RFC
          2661, August 1999.




ITSUMO Group               Expires August 2000                 [Page 14]


Internet Draft       Requirements for Extending DHCP       March 3, 2000


   [REQ]  S. Bradner, "Key words for use in RFCs to Indicate Requirement
          Levels," RFC-2119, March 1997.

   [SIP]  M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
          Session Initiation Protocol," RFC 2543, March 1999.

   [SIPM] E. Wedlund and H. Schulzrinne, "Mobility Support using SIP",
          Proc. of second ACM International Workshop on Wireless
          Mobile Multimedia (WOWMOM'99), pp 76-82, August, 1999.



7. Authors' Addresses

   Anthony J. McAuley
   MCC 1C235B, Telcordia
   445 South Street, Morristown, NJ 07960
   Phone: +1 973 829 4698
   email: mcauley@research.telcordia.com


   Subir Das
   MCC 1D210R, Telcordia
   445 South Street, Morristown, NJ 07960
   Phone: +1 973 829 4959
   email: subir@research.telcordia.com


   Shinichi Baba
   Toshiba America Research Inc.
   P.O. Box 136 Convent Station, NJ 07961-0136
   Phone: +1 973 829 4759
   email: sbaba@tari.toshiba.com


   Yasuro Shobatake
   Toshiba America Research Inc.
   P.O. Box 136 Convent Station, NJ 07961-0136
   Phone: +1 973 829 3951
   email: yasuro.shobatake@toshiba.co.jp











ITSUMO Group               Expires August 2000                 [Page 15]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/