Network Working Group K. Taniguchi INTERNET DRAFT NEC USA T. Nishida NEC USA 2 March 1998 Subnet Configuration Option Set for DHCP 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]