Network Working Group                                       K. Taniguchi
INTERNET DRAFT                                                   NEC USA
                                                              T. Nishida
                                                                 NEC USA
                                                            2 March 1998


                Subnet Configuration Option Set for DHCP
                <draft-ietf-dhcp-dyn-subnet-conf-02.txt>

Status of this Memo

   This document is an Internet-Draft. 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.''

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).



Abstract

   This subnet configuration option set provides subnet address
   assignment capability to DHCP[1,2] to be applied to both virtual
   subnet creation like as LIS[3], V-LAN and static subnet configuration
   for new deployed network.  This draft illustrates service models for
   subnet configuration, protocol design concept, protocol behavior and
   discussions.






. Introduction

   Subnetworks can be created dynamically owing to recent data link
   layer technology especially switching and wireless network. Since,



draft-ietf-dhcp-dyn-subnet-conf-02.txt                          [Page 1]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   using these technologies, we do not need a IP router function for
   segmenting IP subnetwork, subnet domain can easily create/delete in
   accordance with user's requirements.  Such typical applications are
   virtual LAN, VPN (virtual private network), CUG (Closed Users Group)
   and ad-hoc networks.  Users can overlay subnetworks freely on a
   single physical network for creating intranet and extranet.  Ubiquity
   of Internet results in easily (re)configurable netwoking. in the
   context of the current Internet, however, each subnet needs to be
   officially registered to the administrative NIC.  This hinders easy
   Internet access.  While several technologies have been proposed,
   e.g., NAT, IP masquerade, etc. to address this issues., each has some
   drawbacks, e.g., performance, scalability, etc.

   Internet engineers have been attacking to improve the network layer
   technology.  One of such challenges is an invention of a function
   which changes configuration of hosts, route and name space
   dynamically.  For example, DHCP assigns IP address.  Dynamic routing
   protocol like RIP detects link status change and gives the right
   route information.  Moreover, DNS are going to accept a dynamic
   record update by linking a DHCP server.  These technologies
   contribute easier configuration for a host connection and host
   movement.  This proposal adds another dimension of dynamic internet
   configuration in conjunction with virtual subnetworking technologies.
   A new option set, called DSCP (Dynamic Subnet Configuration by DHCP),
   which is an extension of DHCP, assigns subnet resources to a
   dynamically created subnetwork. This draft proposes service models
   for dynamic subnet resource configuration, to add new options in DHCP
   message format.

. Difference From Previous Draft

   In the Section 3, one new service model are added.  Section 6.6
   proposes the new message type to make identical subnet name over
   multiple clients.  Section 6.7 describes that how DSCP provides wider
   subnet address.  Section 6.8 illustrates that how DSCP provides
   multi-homed subnet address.  Finally, section 7. includes several
   discussion to make clear the current problems and possible solutions.

. Service Model

   There are four models to be considered; (1)administrator driven,
   (2)leader driven, (3)DHCP server driven and (4)router driven model.

   (1)An administrator driven model supports requirements of a network
   administrator who needs a new subnet address.  Then, an administrator
   invokes a DSCP client function.  The client negotiates with DSCP
   servers, and normally gets a set of new subnet address according to
   the administrator's request.  Then the administrator may manually



draft-ietf-dhcp-dyn-subnet-conf-02.txt                          [Page 2]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   change the subnet table and configure router's IP address
   information.  In this model, the server only provides an available IP
   subnet address to the administrator and marks that address as
   reserved.

   (2)A leader driven model supports requirements of a leader of a
   specific group who may not be a network administrator and needs a new
   subnet address temporally for creating a new subnet.  A leader
   executes a DSCP client.  The client negotiates with DSCP servers to
   get a new IP subnet address.  The DSCP servers create a new IP host
   table to manage a leased subnet address space and prepare to accept
   DHCP requests from a host who wants to join the newly created IP
   subnet.  After that, hosts of members belonging to the same group
   join newly created IP subnet using DHCP.  The server allocates an IP
   address to those hosts.

   (3)A DHCP server driven model supports requirements of a DHCP server
   who needs a new IP subnet address.  The DHCP server as DSCP client
   requests a new IP subnet address and creates a new IP host address
   list for a new IP subnet address.  Then, the DHCP server leases an IP
   address in new IP subnet address space.

   Dial-up access of SOHO router with DHCP server function is an
   application of model (3).  A home or SOHO user who has home subnet
   can access an ISP by dial-up. A DSCP server in the ISP can provide
   subnet address to his/her subnet. Finally, all IP terminal, e.g. not
   only PC but also FAX, phone, TV, refrigerator and microwave can
   access the Internet.

   (4)A router driven model supports requirements of router plug-and-
   play.  When a router is connected to existing network and started
   without any administration information, the router can get an IP
   interface address by DHCP and could get the new IP subnet address for
   the other interface which have never been configured yet, and finally
   those interface could get IP host address for un-configured
   interfaces, if DSCP server and address space are available.

. Design Concept

   This proposal adopts an extension of DHCP rather than any invention
   of new protocol.

   Extending DHCP for DSCP has several advantages.  First, DHCP has
   already a temporary address leasing mechanism.  DHCP server also has
   already a temporary IP address management database.  DHCP client has
   already finite state machine to assign an unique IP resource in a
   multiple DHCP server environment.  Therefore, the cost of defining,
   developing and deploying protocol would be minimized.  Moreover, the



draft-ietf-dhcp-dyn-subnet-conf-02.txt                          [Page 3]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   existing network has a relay agent mechanism which is capable of
   supporting the DSCP function.

. Term Definition

5.1. DSCP This option set is absolutely for extension of DHCP and is NOT
   dedicated protocol.  But only for terminology to discuss here, the
   word DSCP is defined as DHCP extended with this option set.

5.2. Non-DSCP server/client and DSCP server/client

   During DSCP server/client deployment, DHCP servers/clients both which
   supports and which does not support DSCP would exist. To describe the
   difference clearly, non-DSCP server/client and DSCP server/client
   means DHCP server/client which does not support DSCP and which
   supports, respectively.

5.3. subnet address expiration time

   This is the expiration time of a subnet address leased by DSCP
   servers.  The subnet address expiration time must be later (longer)
   than all host address expiration time within the subnet address
   range.

5.4. subnet name

   In this document, all subnets must have an unique name.  The name is
   used to identify itself.  If DSCP server has enough address space, a
   client with the same subnet name can get the same subnet address
   again even after the expiration of leased time.

5.5. subnet address table

   In case of a fixed length subnet mask, each entry of the subnet
   address table has 6 fields: subnet address, subnet mask, broadcast
   address, lease status, subnet address expiration time, and subnet
   name.  The lease status is one of the following: FREE, RESERVED or
   OFFERED.

   In case of a variable length subnet mask, although the format of the
   subnet address table becomes more complex, its format is similar to
   that of a fixed subnet mask fixed.

. Protocol Description

6.1. Normal operation

   In this section, to simplify the protocol description, exceptional



draft-ietf-dhcp-dyn-subnet-conf-02.txt                          [Page 4]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   operations are not mentioned.  In a network with multiple DSCP
   servers, each server maintains a separate subnet address space.  In
   other words, multiple servers do not manage a specific subnet address
   at the same time.

   First, a client sends a DSCPDISCOVER message to servers.  To transmit
   the message, one or more relay agents may forward the message.  Or
   the client may use broadcast, multicast, or unicast.  (Since the
   transfer method is one of the interesting issues for this protocol
   architecture, this issue is discussed later.)

   A server searches an unused subnet address from its subnet address
   table.  If there are no unused subnet addresses, the server rejects
   the request silently, i.e., without any responses.  Otherwise, the
   server returns a DSCPOFFER message to the client.  If the client has
   specified a subnet mask, the server may select a subnet address which
   has the same subnet mask.  If the server has already leased a subnet
   address to a client which requested previously with an identical
   subnet name, the DSCP server should not send any DSCPOFFER messages.

   In receiving a DSCPOFFER message, the client may send a DSCPREQUEST
   message immediately to the responding server, or it may wait to
   receive another DSCPOFFER message for some amount of time, e.g.,
   several seconds, then it selects the best offer and sends a
   DSCPREQUEST message to that particular server.

   The server receiving a DSCPREQUEST message must immediately check
   whether the requested subnet address is available or not.  If it is
   still available, the server must reserve it and return a DSCPACK
   message to the requesting client.  Otherwise, the server must return
   a DSCPNACK message to the client.

   The client which receives a DSCPACK message, can use the subnet
   address.  The client which receives a DSCPNACK message may send a
   DSCPDISCOVER message again and repeat the whole operation.

6.2. Protocol architecture issues

6.2.1. Who manages new IP subnet address space?

   As described in section 2, there are two cases in a context of IP
   address management for a subnet number newly assigned; (1) A DSCP
   client requests DSCP server to manage the leased IP subnet address
   space as a leader driven model, (2) DSCP client undertakes management
   of the leased IP subnet address space as an administrator driven
   model and a DHCP server driven model.  For a purpose of definition of
   authority in IP address space in newly assigned subnet number, a new
   option is needed.



draft-ietf-dhcp-dyn-subnet-conf-02.txt                          [Page 5]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   This option is named "new subnet option." The option number is T.B.D.
   The length of this option is 1.  If the value of this option is 0,
   the server does not manage the new IP address space.  If it is 1, the
   server manages the new address space.  If it is another value, the
   server must treat those messages as error messages.

6.2.2. First message from a client

   Coping with any DSCP model mentioned in Section 2, a DSCP client is
   assumed to be assigned to a host address in advance, which is
   received via DHCP, manual configuration or other method.  Therefore,
   a DSCP client can unicast messages to a DSCP server if the client
   knows the server's address.  Otherwise it may send messages using
   either broadcast, anycast or multicast.

   The advantage of using unicast is to minimize the traffic.  The
   advantage of broadcast, multicast or anycast is that a client does
   not need to know the server's address.  And a relay agent supports
   the forwarding of the DSCP message to a server.

6.2.3. Subnet mask negotiation

   For simple implementation, a server maintains only a fixed length
   subnet mask.

   For efficiency of address space utilization, however, the variable
   network mask should be adopted.  In this case, a client may indicate
   its preferable subnet mask length by including subnet mask option
   into the DSCPDISCOVER message.  A server may negotiate the subnet
   mask length with the requesting client by changing the value of the
   option.  If the client accepts the offer, it sends DSCPREQUEST
   message.  Otherwise, the client selects another DSCPOFFER message
   with different subnet mask length.

   Accommodating both fixed and variable subnetwork, both DSCP server
   and client interpret subnet mask option as "peer's will."  A server
   may change it, and a client may reject it.

6.2.4. Server consistency

   DSCP uses a subnet name as identification of a particular subnet.  If
   new subnet address is requested, and if the subnet name has already
   reserved by another request, the server rejects the request.

   In multiple DSCP servers environment, a server need to know the other
   server's status, e.g., whether a subnet name is reserved, whether a
   subnet address has already leased.  Otherwise, inconsistency among
   servers may occur.



draft-ietf-dhcp-dyn-subnet-conf-02.txt                          [Page 6]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   To avoid such inconsistency accessing multiple servers, the simplest
   method is that the number of servers is limited by one for specified
   subnet name space.  This is not fault tolerant, however.  Another
   possible method is that servers strive for database synchronization
   for all requests.  This incurs servers' load.

   This issue will be resolved by further study.

6.3. Architecture of subnet address table

6.3.1. Table format

   Subnet address table must have at least the following entries.

   1. Subnet address (base)

   2. Subnet mask

   3. Broadcast address

   4. Leasing status (see below)

   5. Subnet address expiration date

   6. Subnet name (leasing currently or leased last time)

6.3.2. Status of subnet address on server

   A subnet address in a subnet address table has three status.

   IDLE

   In idle status, no clients use the subnet address.

   OFFERED

   In offered status, DSCP server has received a DSCPDISCOVER message
   and sent a DSCPOFFER message including the subnet address. If a DSCP
   server receives DSCPDISCOVER message which has identical subnet name
   with "offered" status subnet from another clients, the DSCP server
   must returns same DSCPOFFER message. A DSCP server should not offer
   the subnet address in "offered" status to another requisition. A DSCP
   server must set timer, when it change the status of subnet address to
   "offered." The server stops the timer and changes the status to
   "reserved", when the server receives DSCPREQUEST message before the
   timer expires. When the timer expires, the server changes the status
   to "idle." In this status, subnet name field is specified.




draft-ietf-dhcp-dyn-subnet-conf-02.txt                          [Page 7]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   RESERVED

   In reserved status, the address has already been leased. In this
   status, the address must have subnet name and expiration time. The
   server must not lease this address to another requisition. Yet, the
   server may extend the expiration time, if the original requisition
   sends the DSCPREQUEST message.

6.4. DHCP server issue

   A DHCP server which has leased IP subnet address from a DSCP server
   must keep the following rules.

    * When T1 timer expires for subnet address, the DHCP server should
   extend its lease period as DSCP client.

    * If the subnet address is expired, the DHCP server must not lease
   any hosts address.

    * DHCP server must not lease host address with lease time longer
   than one of the subnet address.

    * Before releasing a subnet address, the DHCP server must make sure
   no host address in the subnet are used.

    * If lease time of the subnet address is infinite and the DHCP
   server would like to release the address, the server must stop
   releasing new host addresses first, wait until all host addresses
   becomes free, and then send DSCPRELEASE message to its DHCP server.

6.5. Subnet resource representation

   In case that DSCP server acts as DHCP server, the DSCP server needs
   information concerning about subnet resource, such as default router,
   DNS server, mail server, etc. Therefore, when the DSCP server creates
   a new subnet, the client must specify the subnet resource. There are
   two methods to implement simply this issue.

   The first one is that DSCP client specifies all resources in DHCP
   existing option. On receiving DSCPREQUEST message, the DSCP server
   remember the options in that message. After creating a new subnet,
   DSCP servers set those information on DHCP server.

   The second one is that newly created subnet shares another existing
   subnet resource. For these sake, the newly option "subnet resource
   inheritance" is defined. It includes a name of subnet whose resources
   are shared by a new subnet. If the specified subnet name does not
   exist, the DSCP server must treat that message as error.



draft-ietf-dhcp-dyn-subnet-conf-02.txt                          [Page 8]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


6.6. Identical name

6.6.1. Server view

   In the case that DHCP server received DHCPDISCOVER message which
   contains same client identifier option and same giaddr field with a
   client which had been served, the DHCP server may assume that the
   request comes from same client.  In the case of DSCP server with same
   client identifier option and same subnet name, the server may assume
   that the message is a request for same subnet address.  But in the
   case of DSCP server with different client identifier option and same
   subnet name, can the server assume the message is a request for same
   subnet address?

   There are some idea. The fist one is that same subnet name indicates
   same subnet. If so, how the server respond to the client for reserved
   address? Basically, the server should inform the client that the
   subnet address is reserved by other client with same subnet address.
   To do it, does new message type require to be defined, which is
   similar with DHCPINFORM but opposite direction message?

6.6.2. Client view

   From the view point of clients which belong same subnet, they desires
   to have identical subnet name to request subnet address.  How can
   they have it? That's problem.

   If it is assumed that a client does not have any configuration
   information, the client would not know the subnet name.  In this
   case, the client can generate subnet name automatically, based on
   hardware address or another hardware identical information.  In the
   case that there are another clients which know the subnet name on the
   same subnet, it looks good way to get the subnet name from the
   clients.  Therefore, does DSCP need client-client protocol?

6.6.3. An idea

   To solve these two problems, a new DSCP message type called
   DSCPSTATUS is proposed.  Note that it is assumed that all DSCP
   clients belong to same subnet and are trying to configure a local
   port.  The clients which leases a subnet address for remote subnet is
   not assumed.  A DSCPSTATUS message includes the subnet name option,
   subnet address, subnet mask, server identifier option which is used
   to get subnet address and precedence.  The precedence is an integer
   and indicates administrative precedence of the the subnet name in the
   message.  If the subnet name is configured by an administrator, the
   value would be higher rather than one which is automatically
   generated based on hardware address.  Clients and servers can send a



draft-ietf-dhcp-dyn-subnet-conf-02.txt                          [Page 9]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   DSCPSTATUS message, but only client can receive it.

   When a client which does not have any configuration information boots
   up, the client would send DSCPDISCOVER message.  If a server detects
   the subnet in the DSCPDISCOVER message is reserved by another client,
   the server replies DSCPSTATUS message immediately.  If the client
   sends the DSCPDISCOVER message by broadcast or multicast, another
   clients could receive it.  The clients which receive the DSCPDISCOVER
   message check the precedence in the DSCPDISCOVER message, and compare
   it with the precedence of the subnet name which is stored in the
   memory of the clients.  If the precedence in the memory is higher
   than one of received message, the clients replies DSCPSTATUS message.

   A client which receives a DSCPSTATUS message compares the precedence
   in the message with one of the client owns.  If the precedence in the
   message is higher than owned one, the client ignores all DSCPOFFER
   messages and accepts subnet address and subnet mask in DSCPSTATUS
   messages.  Moreover, the client stores the subnet name and the
   precedence decreasing by 1 to prepare new neighbor clients'
   DSCPDISCOVER messages.

   A client which has never been beaten by any DSCPSTATUS message from
   other DSCP client is called an original subnet name holder.  A client
   which has accepted a DSCPSTATUS message is called a copied subnet
   name holder.  The reason why the client decreases the precedence
   value by 1 is to accept the subnet name change of original subnet
   name holder.  In the case that the original subnet name holder
   changed the subnet name, the precedence of original subnet name
   holder must be higher 1 than copied subnet name holder.  Therefore
   all copied subnet name holder can accept new name.

   In order to confirm the subnet name, an original subnet name holder
   frequently send DSCPSTATUS messages by broadcast so slowly that those
   message does not affect serious traffic damage to its subnet, for
   example 30 minutes or 1 hour interval.

   This idea provides the time continuously of subnet address and the
   methods to change the subnet name gently.

6.7. Wider subnet address

   In the case that a DHCP server which can work as DSCP client needs
   more address space for future requests of its clients, the DHCP
   server can try to borrow wider subnet address.  In this case, the
   DHCP server as DSCP client sends DSCPREQUEST message with wider
   subnet address and modified base address to fit new subnet address.

   The DSCP server which receives a DSCPREQUEST message with registered



draft-ietf-dhcp-dyn-subnet-conf-02.txt                         [Page 10]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   subnet name and wider subnet mask inspects subnet address table.  And
   if the address space is free, the server replies DSCPACK message.
   Otherwise, it replies DSCPNACK message.

6.8. Multi-homed subnet

   In the case that a DHCP server which can work as DSCP client needs
   more address space and failed to get wider subnet address space, it
   can try to borrow multi-homed subnet address.  To do it, it changes
   the subnet name slightly and sends DSCPDISCOVER message. The
   following procedure is identical with normal DSCP procedure to borrow
   a subnet address of a new DSCP client.

   The method how to change the subnet name slightly is not defined
   here.  To make clear the relation between multi-homed subnet space,
   explicit naming rule is to be defined.

. Discussion

7.1. DSCP message type option

   DHCP has 8 message types. Basically, this option set is also assumed
   to have same number of message types. There are three ways to present
   DSCP message type.

   The first one is to define dedicated DSCP message type option as DHCP
   message type option. It allows coexistence of non-DSCP server/client.
   When any non-DSCP server/client receives DSCP message, DHCP module of
   non-DSCP server/client can ignore the message because there are no
   DHCP message type. BOOTP module would also discard the message
   because there are no hardware address information, actually all 0s.

   The second one is to define DHCP message type option again to include
   DSCP messages types by undefined message codes. this does not
   increase the number of DHCP options, while some DHCP implementation
   may need to be modified.

   The third one is to define DSCP mode option. In this case, if a
   server or client finds this option in a message, they assume that the
   message is DSCP. Some DHCP implementations may be confused, if they
   receives this message.

   The first method is adopted in this document.

7.2. Leased IP subnet address representation

   Originally, DHCP has two important fields to represent leased host
   address, ciaddr field in common header and requested IP address



draft-ietf-dhcp-dyn-subnet-conf-02.txt                         [Page 11]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


   option.  In same idea, DSCP could use same field and option to
   represent leased IP subnet address.

   Another idea is to define dedicated option for leased IP subnet
   address representation.  The merit of this method is less impact to
   existing non-DSCP server/client.  Especially, in the case of
   DSCPREQUEST message with filled ciaddr field is sent by broadcast to
   extend lease time, non-DSCP server might return DHCPNAK message,
   because of subnet address range, actually reserved for subnet
   address.  But this possibility would be very low or zero, since
   DSCPREQUEST message would be sent by unicast.  Moreover, the server
   would be identified by siaddr, so non-DSCP server would discard the
   message immediately.

   Since it is assumed that all non-DSCP server/client ignores all DSCP
   messages, the former method is applied.

7.3. DSCPDECLINE message

   DHCPDECLINE message is defined as client to server indicating network
   address is already used.  The DHCP client can detect duplicated host
   addresses by ARP, if the host which use same address is alive. In the
   case of DSCP, how the client could detect duplicated subnet
   addresses?

   Generally, it is not so easy.  But there are some special cases to
   detect it easily.  The first case is that like a router, which works
   as DSCP client, detects that multiple ports of itself uses same IP
   subnet address.  Another possibility is detection by dynamic routing
   protocol.  Some routing protocol can figure out the network topology
   and could detect the duplicated subnet address.  But it might be not
   so easy to run dynamic routing protocol with dynamically assigned
   subnet address.

   Anyway, DSCPDECLINE message should be defined for same multiple port
   address and future technique.

7.4. Name operation

   Is the function to change the subnet name which has been registered
   into DSCP server? To do it, should new option 'old subnet name' be
   defined?

7.5. Option set format

   Currently there are several options proposed by this document
   including this section 'Discussion'.




draft-ietf-dhcp-dyn-subnet-conf-02.txt                         [Page 12]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


     Subnet name option
     DSCP message type
     New subnet option
     Subnet resource inheritance option
     Subnet name precedence option

   Should these option be defined as separated option or as integrated
   option like as encapsulated vender specific information?

. Future Work

   Our next step for this project is to specify protocol specification
   based on this idea, of course with considering all feed-backs.
   Therefore, all comments, questions and requests are welcome.

. Security Considerations

   Current DHCP does not have function for security.

   DSCP security adopts the same security functionalities as DHCP.  In
   addition, some authentication and/or encryption mechanisms might be
   necessary.  The detail is further study.



Reference

   [] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
   1997.

   [] Alexander, S., Droms, R., "BOOTP Vendor Information Extensions",
   RFC 2132, March 1997.

   [] Laubach, L., "Classical IP over ATM", RFC1577, January 1994.

Author's Address

     Kunihiro Taniguchi

     CCRL,
     NEC USA Inc.
     110 Rio Robles,
     San Jose, CA 95134

     Phone: (408) 943-3031

     EMail: taniguti@ccrl.sj.nec.com




draft-ietf-dhcp-dyn-subnet-conf-02.txt                         [Page 13]

 
DRAFT            Dynamic Subnet Configuration Protocol      2 March 1998


     Takeshi Nishida

     CCRL,
     NEC USA Inc.
     110 Rio Robles,
     San Jose, CA 95134

     Phone: (408) 943-3030

     EMail: nishida@ccrl.sj.nec.com









































draft-ietf-dhcp-dyn-subnet-conf-02.txt                         [Page 14]