Internet Draft Sam Martel <draft-martel-bootp-mixedlinklayers-00.txt> Cabletron Systems Inc. Walt Wimer FORE Systems Inc. February 1997 This document EXPIRES on August 31, 1997 BOOTP and DHCP on Mixed Media Link-Layer Networks 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 learn the current status of any Internet-draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract RFCs 951 [1], 1541 [2], and 1542 [3] describe the interactions of BOOTP [1] and DHCP [2] client, server, and relay agents. However, further experience with these protocols has revealed the existence of an interoperability issue. The issue occurs when a given IP subnet is constructed over one link-layer network inter-connected by translational bridges to other dissimilar link-layer networks. The following information attempts to address this problem. It is impossible for a BOOTP or DHCP client, server, or relay agent to know in advance whether or not it will be operating in a mixed media link-layer network environment. Given this fact, all BOOTP and DHCP client, server, and relay agents SHOULD adopt the recommendations defined in this memo. Martel, Wimer [Page 1]
INTERNET-DRAFT MIXED LINK-LAYER BOOTP/DHCP Expires August 1997 Table of Contents 1. Introduction.....................................................2 1.1 Requirements....................................................2 1.2 Terminology.....................................................3 2. General Issues...................................................3 3. Client Behavior Extension........................................3 3.1 The 'htype' Field...............................................3 3.2 The 'chaddr' Field..............................................4 4. Relay Agent Behavior Extension...................................4 4.1 The 'htype' and 'chaddr' Fields.................................4 4.2 Additional Relay Agent Processes................................4 5. DHCP Server Behavior Extension...................................4 5.1 The 'htype' and 'chaddr' Fields.................................4 5.2 Additional Server Processes.....................................5 6. Examples.........................................................5 6.1 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet with a Relay.......5 6.2 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet without a Relay....6 1. Introduction Some aspects of the BOOTP and DHCP protocols need additional definition in order to expand compatibility with certain network devices. RFCs 951, 1541, and 1542 do not adequately describe the behavior of BOOTP server, client, and relay agent so as to ensure compatibility with devices that provide layer 2 forwarding of BOOTP and DHCP messages. The client, server, and relay agent need additional behavior definition in order to strengthen the current standards in these areas. The information in this memo attempts to clarify the interaction of BOOTP client, server, and relay agent in order to increase compatibility with devices which provide layer 2 forwarding. Note: This document provides additional information to further define the behavior of BOOTP and DHCP servers, clients, and relay agents as defined in RFCs 951, 1541, and 1542 and should be considered an extension of the original documents. 1.1 Requirements In this memo, the words that are used to define the significance of particular requirements are capitalized. These words are: o "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification. o "MUST NOT" This phrase means that the item is an absolute prohibition of the specification. Martel, Wimer [Page 2]
INTERNET-DRAFT MIXED LINK-LAYER BOOTP/DHCP Expires August 1997 o "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. o "SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. o "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 1.2 Terminology This memo uses the following terms: BOOTREQUEST A BOOTP message sent from a BOOTP client to a BOOTP server requesting configuration information. BOOTREPLY A BOOTP message sent from a BOOTP server to a BOOTP client providing configuration information. 'htype' field An 8 bit field contained in BOOTP and DHCP messages which represents the client's link-layer network type as specified in RFC 1700 [4], "Assigned Numbers", except where amended by this document. 'chaddr' field A 16 byte field contained in BOOTP and DHCP messages which represents the link-layer address of the client. Martel, Wimer [Page 3]
INTERNET-DRAFT MIXED LINK-LAYER BOOTP/DHCP Expires August 1997 2. General Issues An interoperability issue concerning BOOTP and DHCP messages can occur on networks which connect different link-layer technologies through devices which provide only layer 2 forwarding. The issue can occur when the client is located on a link-layer network that has a different 'htype', as defined in the "Assigned Numbers" RFC, than that of the server or relay agent. Primarily, this issue can occur when the relay agent or server resides on an 'htype' link-layer network of 1 while the client resides on an 'htype' link-layer network of 6. The reverse situation can also pose potential problems. The key to ensuring proper operation revolves around the 2 fields in BOOTP and DHCP messages known as the 'htype' and 'chaddr'. Therefore, it is necessary to describe in detail how each element should handle these fields and the information derived therefrom. 3. Client Behavior Extension In addition to adhering to all applicable sections of RFCs 951, 1541, and 1542, the client MUST set the 'htype' and 'chaddr' as directed in sections 3.1 and 3.2 of this document for all BOOTP and DHCP messages generated by the client. 3.1 The 'htype' Field The client MUST set the 'htype' field in accordance with the values defined in this document for the client's link-layer network. IMPORTANT NOTE: As of the date of publication of this BOOTP/DHCP memo, the current Assigned Numbers document is RFC 1700. RFC 1700 contains the following table (edited for brevity): Value Hardware Type (hrd) ----- ------------------- 1 Ethernet (10Mb) 6 IEEE 802 Networks The above table suggests that all IEEE 802 networks should use an 'htype' value of 6. However, this does not reflect actual practice, and blindly following the above table will result in serious interoperability problems. The table would be more correctly represented as: Value Hardware Type (hrd) ----- ------------------- 1 IEEE canonical format (Ethernet, IEEE 802.3, FDDI canonical) 6 IEEE reverse canonical format (IEEE 802.5 Token Ring Networks) Martel, Wimer [Page 4]
INTERNET-DRAFT MIXED LINK-LAYER BOOTP/DHCP Expires August 1997 Actual practice dictates that BOOTP and DHCP clients which are directly connected to an IEEE 802.5 Token Ring network MUST set 'htype' to 6, and BOOTP and DHCP clients which are directly connected to a DIX Ethernet, IEEE 802.3 Ethernet, or FDDI network MUST set 'htype' to 1. 3.2 The 'chaddr' Field The bit ordering used for the link-level hardware addresses in the 'chaddr' field MUST be the same as the ordering used for the ARP protocol [5] on the client's link-level network (assuming ARP is defined for that network). 4. Relay Agent Behavior Extension In addition to adhering to all applicable sections of RFCs 951, 1541, and 1542, the relay agent MUST adhere to the recommendations in sections 4.1 and 4.2 of this document. 4.1 The 'htype' and 'chaddr' Fields All relay agents MUST preserve the 'htype' and 'chaddr' fields of all DHCP and BOOTP messages and forward as is. Preservation is necessary in order to allow the final relay agent to properly format a unicast response to the BOOTP client in accordance with RFC 1542 and this document. 4.2 Additional Relay Agent Processes The final relay agent MUST reference the BOOTREPLY 'htype' field when building unicast BOOTREPLY messages. The relay agent MUST compare the 'htype' contained in the BOOTREPLY message to the 'htype' of the relay agent's network interface from which the outgoing BOOTREPLY message is about to be sent. It MUST then perform any link-layer translation required in order to ensure the appropriate form of the link-layer address is used in the link-layer header of the outgoing BOOTREPLY message and/or corresponding ARP table entries. Note: The actual value of the 'chaddr' field within the outgoing BOOTREPLY message MUST NOT be modified. 5. DHCP Server Behavior Extension In addition to adhering to all applicable sections of RFCs 951, 1541, and 1542, the server MUST adhere to the recommendations in sections 5.1 and 5.2 of this document. 5.1 The 'htype' and 'chaddr' Fields The server MUST copy the 'htype' and 'chaddr' fields of all BOOTREQUESTs to the corresponding BOOTREPLY. The server MUST do Martel, Wimer [Page 5]
INTERNET-DRAFT MIXED LINK-LAYER BOOTP/DHCP Expires August 1997 this in order to allow the final relay agent to properly format a unicast response to the BOOTP client in accordance with RFC 1541 and this document. 5.2 Additional Server Processes The server MUST consider the 'htype' field when building unicast BOOTREPLY messages. Therefore, the server must check the 'htype' contained in the BOOTREPLY message and compare it to the 'htype' of the server's link-layer interface. The server MUST perform any translation required to ensure the correct form of the link-layer address is used within the link-layer header of the BOOTREPLY message and any ARP table entries. (The actual value of the 'chaddr' field within the outgoing BOOTREPLY message MUST NOT be modified.) 6. Examples 6.1 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet with a Relay -------- ---- ---------- ------- -------- |BOOTP | / \ |Trans- | ETHERNET |BOOTP| ETHERNET |BOOTP | |/DHCP |-|TOKEN |-|lational|----------|/DHCP|----------|/DHCP | |Client| \RING/ |Switch | |RELAY| |SERVER| -------- ---- ---------- ------- -------- The Token Ring client's link-layer address, as represented in an ARP message, is 00:00:B8:E1:D2:A3. Therefore, the client will generate all DHCP and BOOTP messages with the 'htype' set to 6 and the 'chaddr' set to 00:00:B8:E1:D2:A3. The message will be received by the BOOTP/DHCP relay with the 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. The relay will forward the message in accordance with RFC 1542, preserving the 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. The BOOTP/DHCP server will receive the BOOTREQUEST and process the message in accordance with existing procedures preserving the 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. At this point, the BOOTP/DHCP server determines that there is a relay between the client and itself and will direct the BOOTREPLY to the BOOTP/DHCP relay. The BOOTP/DHCP relay will receive the BOOTREPLY and preserve the 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. It will check to see if a broadcast or a unicast will be used to deliver the message to the client. If a broadcast will be used, the relay will process the message in accordance with existing procedures. If a unicast will be used, the relay will need to translate the link-layer address attained from the BOOTREPLY message 'chaddr' field because its transmitting interface 'htype' is 1 and the BOOTREPLY 'htype' is 6. The result is a link-layer address of Martel, Wimer [Page 6]
INTERNET-DRAFT MIXED LINK-LAYER BOOTP/DHCP Expires August 1997 00:00:1D:87:4B:C5 being used to send the unicast to the client and for any ARP table entry generated. It is important to note that, in the BOOTREPLY, the 'chaddr' field remains set to 00:00:B8:E1:D2:A3 and the 'htype' remains set to 6. The client will receive the BOOTREPLY and process it in accordance with existing procedures. NOTE: In this example, the client is on IEEE 802.5 Token Ring while the server is on IEEE 802.3 Ethernet. However, a translation would still be required if the server were located on Token Ring and the client on Ethernet or FDDI. 6.2 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet without a Relay -------- ---- ---------- -------- |BOOTP | / \ |Trans- | ETHERNET |BOOTP | |/DHCP |-|TOKEN |-|lational|----------|/DHCP | |Client| \RING/ |Switch | |SERVER| -------- ---- ---------- -------- The Token Ring client's link-layer address, as represented in an ARP message, is 00:00:B8:E1:D2:A3. Therefore, the client will generate all DHCP and BOOTP messages with the 'htype' set to 6 and the 'chaddr' set to 00:00:B8:E1:D2:A3. The BOOTP/DHCP server will receive the BOOTREQUEST and process the message in accordance with existing procedures, preserving the 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. At this point, the BOOTP/DHCP server will determine that there is no relay between the client and itself will itself determine whether a broadcast or a unicast will be used for the BOOTREPLY. If a broadcast will be used, the server will process the message in accordance with the existing procedures. If a unicast will be used, the server will need to translate the link-layer address attained from the 'chaddr' field of the corresponding BOOTREQUEST because it's transmitting interface 'htype' is 1 and the BOOTREQUEST 'htype' is 6. The result is a link-layer address of 00:00:1D:87:4B:C5 being used to send the unicast to the client. It is important to note that, in the BOOTREPLY, the 'chaddr' field remains set to 00:00:B8:E1:D2:A3 and the 'htype' remains set to 6. The client will receive the BOOTREPLY and process it in accordance with existing procedures. NOTE: In this example, the client is on IEEE 802.5 Token Ring while the server is on IEEE 802.3 Ethernet. However, a translation would still be required if the server were located on Token Ring and the client on Ethernet or FDDI. Martel, Wimer [Page 7]
INTERNET-DRAFT MIXED LINK-LAYER BOOTP/DHCP Expires August 1997 References [1] B. Croft, and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, Stanford University and Sun Microsystems, September 1985. [2] R. Droms, "Dynamic Host Configuration Protocol", RFC 1541, Bucknell University, October 1993. [3] W. Wimer, "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, Carnegie Mellon University, October 1993. [4] J. Reynolds, and J. Postel, "Assigned Numbers", STD2, RFC 1700, USC/Information Sciences Institute, October 1994. Authors' Addresses Sam Martel Product Support Engineering Cabletron Systems Inc. PO Box 5005 Rochester, NH 03866-5005 Phone: (603) 332-9400 Fax: (603) 337-3710 Email: martel@ctron.com Walt Wimer Software Engineer FORE Systems Inc. Research Park 5800 Corporate Drive Pittsburgh, PA 15237-5829 Phone: (412) 635-3387 Fax: (412) 635-3333 Email: wlw@fore.com Martel, Wimer [Page 8]