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.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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?
8. 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.
9. 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
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[2] Alexander, S., Droms, R., "BOOTP Vendor Information Extensions",
RFC 2132, March 1997.
[3] 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]
