NETWORK Working Group Cuneyt Akinlar INTERNET-DRAFT David Braun Category: Informational Sarit Mukherjee draft-akinlar-zeroconf-minidhcp-option-00.txt> Panasonic Research March 5 2000 Mini-DHCP Election Option for DHCP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. The distribution of this memo is unlimited. It is filed as <draft- akinlar-zeroconf-minidhcp-option-00.txt>, and expires August 5, 2000. Please send comments to the authors. Abstract This drafts defines a new DHCP option for electing a primary mini- DHCP server from among multiple mini-DHCP servers running on a subnet in multi-router zeroconf networks. Conventions 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 [7]. 1. Introduction Zero Configuration (Zeroconf) Networks are a particular class of TCP/IP networks that may be established in the home, in small offices or even for an adhoc purpose. Zeroconf networks do not have and should not Akinlar, Braun, Mukherjee Informational [Page 1]
INTERNET-DRAFT Mini-DHCP Election Option for DHCP March 2000 be expected to have user configurable network infrastructure such as DHCP, DNS and other administered services. This is because typical Zeroconf network users neither have the skill nor desire to configure, administer, or manage a network. [1]. To auto-configure hosts in multi-segment zeroconf networks connected by a single router, [2] suggests the implementation of a mini-DHCP server at the router. The mini-DHCP server MUST automatically allocate /24 scopes out of the 192.168/16 prefix reserved for private addressing [3], with a unique /24 prefix allocated to each interface. Hosts on each segment are configured by the DHCP protocol [4-5] from the mini-DHCP server serving the interface. [2] defines the behaviour of a mini-DHCP server as follows: A mini- DHCP server MUST NOT be active on an interface if there is already another DHCP server active on that interface. In order to detect the presence of a DHCP server on interfaces that have not been configured as BOOTP relay agents, a router running a mini-DHCP server MUST send out periodic DHCPDISCOVER requests on each interface with the should-I- autoconfig flag set. If the DHCPDISCOVER is responded to (either with a DHCPOFFER or with a never-autoconfig response), the router MUST NOT provide DHCP service on that interface. Similarly, if the router running a mini-DHCP server hears a DHCPOFFER, DHCPACK or DHCPNAK on an interface, then it MUST NOT provide DHCP service on that interface. That is, if the mini-DHCP receives a DHCP-server initiated message on an interface, it shuts itself OFF on that interface and does not provide DHCP service. The above scheme works fine for multi-segment zeroconf networks connected by a single router. In multi-router zeroconf networks however, there is a problem. +---------------------------+ | Non-Zeroconf Network | +------------+--------------+ | +--------+-------+ *******************| Gateway |************************ * Zeroconf Network +-+--------------+ * * | * * | * * *********** *********** * * * R1 * * R2 * * * +---+ * * * * +---+ * * | A |-----*1(X) 3(Z)*--------------*1(Z) 3(W)*------| E | * * +---+ * * | * * +---+ * * * 2(Y) * +---+ * 2(V) * * * *********** | C | *********** * Akinlar, Braun, Mukherjee Informational [Page 2]
INTERNET-DRAFT Mini-DHCP Election Option for DHCP March 2000 * | +---+ | * * +---+ +---+ * * | B | | D | * * +---+ +---+ * * * ************************************************************* Figure 1: A zeroconf network with 2 routers and a gateway Figure 1 shows a zeroconf network consisting of 2 routers, R1 and R2. When a router boots up, it will allocate a 192.168.x/24 subnet number to each of its interfaces and start running mini-DHCP as described in [2]. The mini-DHCP will run fine on interfaces 1, 2 of R1 and 2, 3 of R2 as there is no other mini-DHCP server on the segments. But on the shared segment between R1 and R2, there are 2 mini-DHCP servers: One mini-DHCP server running at R1 and serving interface 3(DHCP13), and the other running at R2 and serving its interface 1 (DHCP21). Since the default behaviour of a mini-DHCP is to shut itself OFF on an interface when it gets a DHCP-server initated message, it is possible that both mini-DHCPs will shut themselves OFF at the same time depending on the timing of the DHCP messages. Although we want both mini-DHCP servers to shut themselves OFF if there is an administered DHCP-server on the segment, we want all but one mini-DHCP server to shut itself OFF when there are other mini-DHCP servers but no administered DHCP server on the segment. The DHCP that does not shut itself OFF will configure the hosts on the shared segment. This draft proposes a new DHCP option to be used by mini-DHCP servers running at zeroconf routers to elect a primary mini-DHCP server on the fly. 2. Mini-DHCP Election Option Definition The mini-DHCP Election option is a DHCP option that contains a "KEY" uniquely identifying a mini-DHCP server. This "KEY" is used for primary mini-DHCP election. The format of the option is: Code Len Key +-----+----+----+----+----+----+----+----+----+----+----+-----+ | TBD | 10 | K1 | K2 | K3 | K4 | K5 | K6 | K7 | K8 | K9 | K10 | +-----+----+----+----+----+----+----+----+----+----+----+-----+ A mini-DHCP server MUST include this option in ALL server initiated messages. DHCP server initiated messages are DHCPOFFER, DHCPACK, DHCPNAK[5], and DHCPFORCERENEW[6]. When a mini-DHCP server gets a server initiated message that includes this option, it will make a decision as to whether it should shut itself OFF on that interface or continue Akinlar, Braun, Mukherjee Informational [Page 3]
INTERNET-DRAFT Mini-DHCP Election Option for DHCP March 2000 running based on its key and the key included in the message. The 10 byte key is interpretted as follows: K1: The number of hosts already configured by the mini-DHCP server. K2: The hardware type of the interface. K3-K10: The hardware address of the interface. For example, if the mini-DHCP has already configured 16 hosts and is serving an Ethernet interface whose hardware address is 00:00:C0:85:96:C6, then the mini-DHCP's 10 byte key on that interface will be in hex format: KEY= 10:Ethernet HW Type:00:C0:85:96:C6:0:0. The algorithm that a mini-DHCP uses to decide if it should shut itself OFF on an interface when it receives a DHCP packet with this option is the following ("mine." refers to the mini-DHCP's key and "message." refers to the key in the message): if ( mine.K1 < message.K1 || ( ( mine.K1 == message.K1 ) && ( mine.K2-K10 < message.K2-K10 ) ) then Shut the mini-DHCP OFF on the interface. Send DHCPFORCERENEW message to all hosts that I configured. Configure the IP address of the interface from the primary mini- DHCP server. endif The mini-DHCP shuts itself OFF if the other one has configured more hosts. The idea is to reconfigure as small number of hosts as possible. So, the mini-DHCP server which configured more hosts becomes the primary. In case of a tie, the one with the bigger key wins. When a mini-DHCP shuts itself OFF, it configures its IP address from the current primary mini-DHCP server by issuing a DHCPDISCOVER. It also sends out a FORCERENEW message to all the clients that it has configured so that they can re-configure themselves from the new primary mini-DHCP server. 3. References [1] M. Hatting, Zeroconf Requirements, draft-ietf-zeroconf-reqts-02.txt, Jan. 2000. A work in progress. [2] Auto-Addressing in Multi-segment Networks, http://www.ietf.org/internet-drafts/draft-aboba-zeroconf- multi-00.txt, October 6, 1999, Bernard Aboba. A work in progress. [3] D. Karrenberg, et al, Address Allocation for Private Internets, Akinlar, Braun, Mukherjee Informational [Page 4]
INTERNET-DRAFT Mini-DHCP Election Option for DHCP March 2000 RFC 1918, Feb 1996. [4] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [5] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [6] Peter De Schrijver. Dynamic host configuration : DHCP reconfigure extension, draft-schrijvp-dhcpv4-reconfigure-00.txt, June 1999. A work in progress. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 4. Authors' Addresses Cuneyt Akinlar Panasonic Research 2 Research Way Princeton NJ 08540 Phone: +1 (609) 734-7356 EMail: akinlar@research.panasonic.com David Braun Panasonic Research 2 Research Way Princeton NJ 08540 Phone: +1 (609) 734-7322 EMail: braun@research.panasonic.com Sarit Mukherjee Panasonic Research 2 Research Way Princeton NJ 08540 Phone: +1 (609) 734-7347 EMail: sarit@research.panasonic.com Akinlar, Braun, Mukherjee Informational [Page 5]