idnits 2.17.1 draft-martel-bootp-mixedlinklayers-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 44: '...ver, and relay agents SHOULD adopt the...' RFC 2119 keyword, line 170: '...1542, the client MUST set the 'htype' ...' RFC 2119 keyword, line 176: '... The client MUST set the 'htype' ...' RFC 2119 keyword, line 203: '...IEEE 802.5 Token Ring network MUST set...' RFC 2119 keyword, line 206: '... MUST set 'htype' to 1....' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 31, 1997) is 9735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '5' is mentioned on line 212, but not defined ** Obsolete normative reference: RFC 1541 (ref. '2') (Obsoleted by RFC 2131) ** Obsolete normative reference: RFC 1700 (ref. '4') (Obsoleted by RFC 3232) Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Sam Martel 2 Cabletron Systems Inc. 4 Walt Wimer 5 FORE Systems Inc. 7 February 1997 9 This document EXPIRES on August 31, 1997 11 BOOTP and DHCP on Mixed Media Link-Layer Networks 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), 29 or ftp.isi.edu (US West Coast). 31 Abstract 33 RFCs 951 [1], 1541 [2], and 1542 [3] describe the interactions of 34 BOOTP [1] and DHCP [2] client, server, and relay agents. However, 35 further experience with these protocols has revealed the existence of 36 an interoperability issue. The issue occurs when a given IP subnet 37 is constructed over one link-layer network inter-connected by 38 translational bridges to other dissimilar link-layer networks. The 39 following information attempts to address this problem. 41 It is impossible for a BOOTP or DHCP client, server, or relay agent 42 to know in advance whether or not it will be operating in a mixed 43 media link-layer network environment. Given this fact, all BOOTP 44 and DHCP client, server, and relay agents SHOULD adopt the 45 recommendations defined in this memo. 47 Table of Contents 49 1. Introduction.....................................................2 50 1.1 Requirements....................................................2 51 1.2 Terminology.....................................................3 52 2. General Issues...................................................3 53 3. Client Behavior Extension........................................3 54 3.1 The 'htype' Field...............................................3 55 3.2 The 'chaddr' Field..............................................4 56 4. Relay Agent Behavior Extension...................................4 57 4.1 The 'htype' and 'chaddr' Fields.................................4 58 4.2 Additional Relay Agent Processes................................4 59 5. DHCP Server Behavior Extension...................................4 60 5.1 The 'htype' and 'chaddr' Fields.................................4 61 5.2 Additional Server Processes.....................................5 62 6. Examples.........................................................5 63 6.1 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet with a Relay.......5 64 6.2 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet without a Relay....6 66 1. Introduction 68 Some aspects of the BOOTP and DHCP protocols need additional 69 definition in order to expand compatibility with certain network 70 devices. RFCs 951, 1541, and 1542 do not adequately describe the 71 behavior of BOOTP server, client, and relay agent so as to ensure 72 compatibility with devices that provide layer 2 forwarding of BOOTP 73 and DHCP messages. The client, server, and relay agent need 74 additional behavior definition in order to strengthen the current 75 standards in these areas. The information in this memo attempts to 76 clarify the interaction of BOOTP client, server, and relay agent 77 in order to increase compatibility with devices which provide layer 2 78 forwarding. 80 Note: This document provides additional information to further define 81 the behavior of BOOTP and DHCP servers, clients, and relay agents as 82 defined in RFCs 951, 1541, and 1542 and should be considered an 83 extension of the original documents. 85 1.1 Requirements 87 In this memo, the words that are used to define the significance of 88 particular requirements are capitalized. These words are: 90 o "MUST" 92 This word or the adjective "REQUIRED" means that the item is an 93 absolute requirement of the specification. 95 o "MUST NOT" 97 This phrase means that the item is an absolute prohibition of 98 the specification. 100 o "SHOULD" 102 This word or the adjective "RECOMMENDED" means that there may 103 exist valid reasons in particular circumstances to ignore this 104 item, but the full implications should be understood and the 105 case carefully weighed before choosing a different course. 107 o "SHOULD NOT" 109 This phrase means that there may exist valid reasons in 110 particular circumstances when the listed behavior is 111 acceptable or even useful, but the full implications should be 112 understood and the case carefully weighed before implementing 113 any behavior described with this label. 115 o "MAY" 117 This word or the adjective "OPTIONAL" means that this item is 118 truly optional. One vendor may choose to include the item 119 because a particular marketplace requires it or because it 120 enhances the product, for example; another vendor may omit the 121 same item. 123 1.2 Terminology 125 This memo uses the following terms: 127 BOOTREQUEST 129 A BOOTP message sent from a BOOTP client to a BOOTP server 130 requesting configuration information. 132 BOOTREPLY 134 A BOOTP message sent from a BOOTP server to a BOOTP client 135 providing configuration information. 137 'htype' field 139 An 8 bit field contained in BOOTP and DHCP messages which 140 represents the client's link-layer network type as specified in 141 RFC 1700 [4], "Assigned Numbers", except where amended by this 142 document. 144 'chaddr' field 146 A 16 byte field contained in BOOTP and DHCP messages which 147 represents the link-layer address of the client. 149 2. General Issues 151 An interoperability issue concerning BOOTP and DHCP messages can 152 occur on networks which connect different link-layer technologies 153 through devices which provide only layer 2 forwarding. The issue can 154 occur when the client is located on a link-layer network that has a 155 different 'htype', as defined in the "Assigned Numbers" RFC, than 156 that of the server or relay agent. Primarily, this issue can occur 157 when the relay agent or server resides on an 'htype' link-layer 158 network of 1 while the client resides on an 'htype' link-layer 159 network of 6. The reverse situation can also pose potential 160 problems. 162 The key to ensuring proper operation revolves around the 2 fields in 163 BOOTP and DHCP messages known as the 'htype' and 'chaddr'. 164 Therefore, it is necessary to describe in detail how each element 165 should handle these fields and the information derived therefrom. 167 3. Client Behavior Extension 169 In addition to adhering to all applicable sections of RFCs 951, 1541, 170 and 1542, the client MUST set the 'htype' and 'chaddr' as directed in 171 sections 3.1 and 3.2 of this document for all BOOTP and DHCP messages 172 generated by the client. 174 3.1 The 'htype' Field 176 The client MUST set the 'htype' field in accordance with the 177 values defined in this document for the client's link-layer 178 network. 180 IMPORTANT NOTE: As of the date of publication of this 181 BOOTP/DHCP memo, the current Assigned Numbers document is 182 RFC 1700. RFC 1700 contains the following table (edited for 183 brevity): 185 Value Hardware Type (hrd) 186 ----- ------------------- 187 1 Ethernet (10Mb) 188 6 IEEE 802 Networks 190 The above table suggests that all IEEE 802 networks should use an 191 'htype' value of 6. However, this does not reflect actual 192 practice, and blindly following the above table will result in 193 serious interoperability problems. The table would be more 194 correctly represented as: 196 Value Hardware Type (hrd) 197 ----- ------------------- 198 1 IEEE canonical format (Ethernet, IEEE 802.3, FDDI canonical) 199 6 IEEE reverse canonical format (IEEE 802.5 Token Ring 200 Networks) 202 Actual practice dictates that BOOTP and DHCP clients which are 203 directly connected to an IEEE 802.5 Token Ring network MUST set 204 'htype' to 6, and BOOTP and DHCP clients which are directly 205 connected to a DIX Ethernet, IEEE 802.3 Ethernet, or FDDI network 206 MUST set 'htype' to 1. 208 3.2 The 'chaddr' Field 210 The bit ordering used for the link-level hardware addresses in 211 the 'chaddr' field MUST be the same as the ordering used for the 212 ARP protocol [5] on the client's link-level network (assuming ARP 213 is defined for that network). 215 4. Relay Agent Behavior Extension 217 In addition to adhering to all applicable sections of RFCs 951, 1541, 218 and 1542, the relay agent MUST adhere to the recommendations in 219 sections 4.1 and 4.2 of this document. 221 4.1 The 'htype' and 'chaddr' Fields 223 All relay agents MUST preserve the 'htype' and 'chaddr' fields of 224 all DHCP and BOOTP messages and forward as is. Preservation is 225 necessary in order to allow the final relay agent to properly 226 format a unicast response to the BOOTP client in accordance with 227 RFC 1542 and this document. 229 4.2 Additional Relay Agent Processes 231 The final relay agent MUST reference the BOOTREPLY 'htype' field 232 when building unicast BOOTREPLY messages. The relay agent MUST 233 compare the 'htype' contained in the BOOTREPLY message to the 234 'htype' of the relay agent's network interface from which the 235 outgoing BOOTREPLY message is about to be sent. It MUST then 236 perform any link-layer translation required in order to ensure the 237 appropriate form of the link-layer address is used in the 238 link-layer header of the outgoing BOOTREPLY message and/or 239 corresponding ARP table entries. 241 Note: The actual value of the 'chaddr' field within the outgoing 242 BOOTREPLY message MUST NOT be modified. 244 5. DHCP Server Behavior Extension 246 In addition to adhering to all applicable sections of RFCs 951, 1541, 247 and 1542, the server MUST adhere to the recommendations in sections 248 5.1 and 5.2 of this document. 250 5.1 The 'htype' and 'chaddr' Fields 252 The server MUST copy the 'htype' and 'chaddr' fields of all 253 BOOTREQUESTs to the corresponding BOOTREPLY. The server MUST do 254 this in order to allow the final relay agent to properly format a 255 unicast response to the BOOTP client in accordance with RFC 1541 256 and this document. 258 5.2 Additional Server Processes 260 The server MUST consider the 'htype' field when building unicast 261 BOOTREPLY messages. Therefore, the server must check the 'htype' 262 contained in the BOOTREPLY message and compare it to the 'htype' 263 of the server's link-layer interface. The server MUST perform any 264 translation required to ensure the correct form of the link-layer 265 address is used within the link-layer header of the BOOTREPLY 266 message and any ARP table entries. (The actual value of the 267 'chaddr' field within the outgoing BOOTREPLY message MUST NOT be 268 modified.) 270 6. Examples 272 6.1 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet with a Relay 274 -------- ---- ---------- ------- -------- 275 |BOOTP | / \ |Trans- | ETHERNET |BOOTP| ETHERNET |BOOTP | 276 |/DHCP |-|TOKEN |-|lational|----------|/DHCP|----------|/DHCP | 277 |Client| \RING/ |Switch | |RELAY| |SERVER| 278 -------- ---- ---------- ------- -------- 280 The Token Ring client's link-layer address, as represented in an 281 ARP message, is 00:00:B8:E1:D2:A3. Therefore, the client will 282 generate all DHCP and BOOTP messages with the 'htype' set to 6 and 283 the 'chaddr' set to 00:00:B8:E1:D2:A3. 285 The message will be received by the BOOTP/DHCP relay with the 286 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. The relay 287 will forward the message in accordance with RFC 1542, preserving 288 the 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. 290 The BOOTP/DHCP server will receive the BOOTREQUEST and process 291 the message in accordance with existing procedures preserving the 292 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. At this 293 point, the BOOTP/DHCP server determines that there is a relay 294 between the client and itself and will direct the BOOTREPLY to 295 the BOOTP/DHCP relay. 297 The BOOTP/DHCP relay will receive the BOOTREPLY and preserve the 298 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. It will check 299 to see if a broadcast or a unicast will be used to deliver the 300 message to the client. If a broadcast will be used, the relay 301 will process the message in accordance with existing procedures. 302 If a unicast will be used, the relay will need to translate the 303 link-layer address attained from the BOOTREPLY message 'chaddr' 304 field because its transmitting interface 'htype' is 1 and the 305 BOOTREPLY 'htype' is 6. The result is a link-layer address of 306 00:00:1D:87:4B:C5 being used to send the unicast to the client and 307 for any ARP table entry generated. It is important to note that, 308 in the BOOTREPLY, the 'chaddr' field remains set to 309 00:00:B8:E1:D2:A3 and the 'htype' remains set to 6. 311 The client will receive the BOOTREPLY and process it in 312 accordance with existing procedures. 314 NOTE: In this example, the client is on IEEE 802.5 Token Ring 315 while the server is on IEEE 802.3 Ethernet. However, a 316 translation would still be required if the server were located on 317 Token Ring and the client on Ethernet or FDDI. 319 6.2 IEEE 802.5 Token Ring to IEEE 802.3 Ethernet without a Relay 321 -------- ---- ---------- -------- 322 |BOOTP | / \ |Trans- | ETHERNET |BOOTP | 323 |/DHCP |-|TOKEN |-|lational|----------|/DHCP | 324 |Client| \RING/ |Switch | |SERVER| 325 -------- ---- ---------- -------- 327 The Token Ring client's link-layer address, as represented in an 328 ARP message, is 00:00:B8:E1:D2:A3. Therefore, the client will 329 generate all DHCP and BOOTP messages with the 'htype' set to 6 and 330 the 'chaddr' set to 00:00:B8:E1:D2:A3. 332 The BOOTP/DHCP server will receive the BOOTREQUEST and process 333 the message in accordance with existing procedures, preserving the 334 'htype' of 6 and the 'chaddr' of 00:00:B8:E1:D2:A3. At this 335 point, the BOOTP/DHCP server will determine that there is no relay 336 between the client and itself will itself determine whether a 337 broadcast or a unicast will be used for the BOOTREPLY. If a 338 broadcast will be used, the server will process the message in 339 accordance with the existing procedures. If a unicast will be 340 used, the server will need to translate the link-layer address 341 attained from the 'chaddr' field of the corresponding BOOTREQUEST 342 because it's transmitting interface 'htype' is 1 and the 343 BOOTREQUEST 'htype' is 6. The result is a link-layer address of 344 00:00:1D:87:4B:C5 being used to send the unicast to the client. 345 It is important to note that, in the BOOTREPLY, the 'chaddr' 346 field remains set to 00:00:B8:E1:D2:A3 and the 'htype' remains set 347 to 6. 349 The client will receive the BOOTREPLY and process it in 350 accordance with existing procedures. 352 NOTE: In this example, the client is on IEEE 802.5 Token Ring 353 while the server is on IEEE 802.3 Ethernet. However, a 354 translation would still be required if the server were located on 355 Token Ring and the client on Ethernet or FDDI. 357 References 359 [1] B. Croft, and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 360 Stanford University and Sun Microsystems, September 1985. 362 [2] R. Droms, "Dynamic Host Configuration Protocol", RFC 1541, 363 Bucknell University, October 1993. 365 [3] W. Wimer, "Clarifications and Extensions for the Bootstrap 366 Protocol", RFC 1542, Carnegie Mellon University, October 1993. 368 [4] J. Reynolds, and J. Postel, "Assigned Numbers", STD2, RFC 1700, 369 USC/Information Sciences Institute, October 1994. 371 Authors' Addresses 373 Sam Martel 374 Product Support Engineering 375 Cabletron Systems Inc. 376 PO Box 5005 377 Rochester, NH 03866-5005 379 Phone: (603) 332-9400 380 Fax: (603) 337-3710 381 Email: martel@ctron.com 383 Walt Wimer 384 Software Engineer 385 FORE Systems Inc. 386 Research Park 387 5800 Corporate Drive 388 Pittsburgh, PA 15237-5829 390 Phone: (412) 635-3387 391 Fax: (412) 635-3333 392 Email: wlw@fore.com