idnits 2.17.00 (12 Aug 2021) /tmp/idnits38672/draft-ietf-dhc-dhcpv4-relay-encapsulation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 160 has weird spacing: '...y agent a rel...' -- The document date (July 11, 2011) is 3960 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) == Outdated reference: draft-ietf-dhc-relay-id-suboption has been published as RFC 6925 == Outdated reference: A later version (-06) exists of draft-ietf-dhc-l2ra-04 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc T. Lemon 3 Internet-Draft Nominum, Inc. 4 Intended status: Standards Track H. Deng 5 Expires: January 12, 2012 L. Huang 6 China Mobile 7 July 11, 2011 9 Relay Agent Encapsulation for DHCPv4 10 draft-ietf-dhc-dhcpv4-relay-encapsulation-01 12 Abstract 14 This document describes a general mechanism whereby DHCP relay agents 15 can encapsulate DHCP packets that they are forwarding in the 16 direction of DHCP servers, and decapsulate packets that they are 17 forwarding toward DHCP clients, so that more than one relay agent can 18 insert relay agent suboptions into the forwarding chain. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 12, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 6 58 2.1. RELAYFORWARD Message . . . . . . . . . . . . . . . . . . . 6 59 2.2. RELAYREPLY Message . . . . . . . . . . . . . . . . . . . . 6 60 2.3. Layer Two Address suboption . . . . . . . . . . . . . . . 6 61 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1. The fixed-length header . . . . . . . . . . . . . . . . . 8 63 3.2. Relay Segment . . . . . . . . . . . . . . . . . . . . . . 9 64 3.3. Encapsulation Segment . . . . . . . . . . . . . . . . . . 9 65 4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 9 66 4.1. Packet processing . . . . . . . . . . . . . . . . . . . . 10 67 4.1.1. Packets traveling toward DHCP servers . . . . . . . . 11 68 4.1.2. Packets traveling toward DHCP clients . . . . . . . . 11 69 4.1.3. Anti-spoofing . . . . . . . . . . . . . . . . . . . . 11 70 4.2. Constructing RELAYFORWARD messages . . . . . . . . . . . . 11 71 4.2.1. Initializing the fixed-length header . . . . . . . . . 11 72 4.2.2. Initializing the relay segment . . . . . . . . . . . . 12 73 4.2.3. Fixed header settings for RELAYFORWARD messages . . . 12 74 4.2.4. Fixed header settings for BOOTREQUEST messages . . . . 13 75 4.2.5. Initializing the encapsulation segment . . . . . . . . 13 76 4.3. Decapsulating RELAYREPLY messages . . . . . . . . . . . . 13 77 4.3.1. Processing relay agent suboptions . . . . . . . . . . 13 78 4.3.2. Constructing the decapsulated message . . . . . . . . 14 79 4.4. Retransmitting modified messages . . . . . . . . . . . . . 14 80 4.4.1. Layer two relay agents . . . . . . . . . . . . . . . . 14 81 4.4.1.1. Constructing the headers . . . . . . . . . . . . . 14 82 4.4.1.2. Forwarding the modified packet . . . . . . . . . . 15 83 4.4.2. Layer three relay agents . . . . . . . . . . . . . . . 15 84 4.4.2.1. Transmitting a decapsulated RELAYREPLY message . . 15 85 4.4.2.2. Transmitting a decapsulated BOOTREPLY message . . 16 86 4.4.2.3. Transmitting other messages . . . . . . . . . . . 16 87 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 16 88 5.1. Receiving RELAYFORWARD messages . . . . . . . . . . . . . 16 89 5.1.1. Decapsulation . . . . . . . . . . . . . . . . . . . . 16 90 5.1.2. Processing of decapsulated suboptions . . . . . . . . 16 91 5.1.3. Address allocation . . . . . . . . . . . . . . . . . . 17 92 5.1.3.1. Default link selection algorithm . . . . . . . . . 17 93 5.1.3.2. Other link selection algorithms . . . . . . . . . 18 94 5.2. Responding to RELAYFORWARD messages . . . . . . . . . . . 18 95 5.2.1. Constructing a RELAYREPLY encapsulation . . . . . . . 18 96 5.2.1.1. Constructing the relay segments . . . . . . . . . 19 97 5.2.1.2. Constructing the fixed-length header . . . . . . . 19 98 5.2.2. Transmission of RELAYREPLY messages . . . . . . . . . 19 99 5.3. Responding to messages other than RELAYFORWARD . . . . . . 20 100 6. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 20 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 105 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 108 1. Introduction 110 In some networking environments, it is useful to be able to configure 111 relay agents in a hierarchy, so that information from a relay agent 112 close to the client can be combined with information from one or more 113 relay agents closer to the server, particularly in cases where the 114 relay agents may be in separate administrative domains. 116 The current Relay Agent Information Option (RAIO) specification 117 [RFC3046] specifies that when a relay agent receives a packet 118 containing an RAIO, it must not add an RAIO. This prevents chaining 119 of RAIOs, and hence prohibits the hierarchical use case. 121 DHCP version 6 [RFC3315] provides a much cleaner technique for 122 providing RAIO suboptions to the DHCP server. Rather than appending 123 an information option to the DHCP client's message, the relay agent 124 encapsulates the DHCP client message in a new DHCP message which it 125 sends to the DHCP server along with any options it chooses to add to 126 provide information to the DHCP server. 128 This document specifies a mechanism for providing the same 129 functionality in DHCPv4. 131 1.1. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 1.2. Terminology 139 The following terms and acronyms are used in this document: 141 BOOTREPLY message Any DHCP or BOOTP message in which the 'op' 142 field is set to BOOTREPLY. 144 BOOTREQUEST message Any DHCP or BOOTP message in which the 'op' 145 field is set to BOOTREQUEST. 147 DHCP Dynamic Host Configuration Protocol Version 4 148 [RFC2131] 150 decapsulate the act of de-encapsulating DHCP packets being 151 relayed from DHCP servers or relay agents in 152 the direction of DHCP clients, according to 153 this specification. 155 encapsulate the act of encapsulating DHCP packets that are 156 being relayed from DHCP clients or relay agents 157 toward DHCP servers, according to the method 158 described in this specification. 160 encapsulating relay agent a relay agent that implements this 161 specification and is configured to encapsulate. 163 L2RA Layer 2 Relay Agent--a relay agent that doesn't 164 have an IP address reachable by the DHCP 165 server. 167 L3RA Layer 3 Relay Agent--a relay agent that has an 168 IP address reachable by the DHCP server. 170 option buffer the portion of the DHCP packet following the 171 magic cookie in the 'vend' field of the DHCP 172 Packet. 174 RAIO Relay Agent Information Option [RFC3046]. Also 175 commonly referred to as "Option 82." 177 RAIO suboption a DHCP suboption that has been defined for 178 encapsulation in the Relay Agent Information 179 Option 181 relay message a RELAYFORWARD or RELAYREPLY message. 183 RELAYFORWARD message Any DHCP or BOOTP message in which the 'op' 184 field is set to RELAYFORWARD. 186 RELAYREPLY message Any DHCP or BOOTP message in which the 'op' 187 field is set to RELAYREPLY. 189 silently discard in many places in this specification, the 190 implementation is required to silently discard 191 erroneous messages. What is meant by 'silently 192 discard' is that the implementation MUST NOT 193 send any ICMP message indicating that the 194 delivery was in error. It may be desirable for 195 the implementation to keep a count of messages 196 that have been discarded, either by message 197 type or by reason for discarding, or some 198 combination. Nothing in this specification 199 should be construed to forbid such data 200 collection. 202 2. Protocol Summary 204 This document specifies two new BOOTP message types: the RELAYFORWARD 205 message, and the RELAYREPLY message. These messages are analogous to 206 the Relay Forward and Relay Reply messages in DHCPv6 [RFC3315]. 208 Although this specification is generally aimed at DHCP 209 implementations, it is not specifically restricted to DHCP, and is 210 applicable to BOOTP in cases where the BOOTP server is a DHCP server 211 that implements this specification, or the less likely case that the 212 BOOTP server only supports the BOOTP protocol, but still implements 213 this specification. 215 In general, when the term "DHCP" appears in this specification, the 216 reader should not read this as intending to exclude BOOTP. 218 2.1. RELAYFORWARD Message 220 Conforming relay agents encapsulate messages being sent toward DHCP 221 servers in RELAYFORWARD messages. 223 2.2. RELAYREPLY Message 225 A conforming DHCP server encapsulates any message being sent toward a 226 DHCP client in a RELAYREPLY message, if the message being responded 227 to was encapsulated. 229 A conforming relay agent, when it receives a RELAYREPLY message, 230 decapsulates the message contained in the RELAYREPLY message and 231 sends it to the next relay or to the client. 233 2.3. Layer Two Address suboption 235 In cases where the closest relay agent to the client is an L2RA, but 236 where there is an L3RA on the path to the client, the DHCP server 237 will encode the link layer address that would normally go in the 238 chaddr field of the DHCP packet into a Layer Two Address suboption. 240 0 1 2 3 241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | SUBOPT_L2AS | length | htype | chaddr ... 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 The Layer Two Address suboption has four fields: 248 SUBOPT_L2AS One octet: the suboption code for the Layer Two Address 249 suboption (TBD). 251 length One octet: the length of the Layer Two Address suboption. 253 htype One octet: the type of the Layer Two Address suboption-- 254 corresponds to the 'htype' field in a non-relay DHCP or BOOTP 255 message. 257 chaddr One or more octets: the layer two address of the client, from 258 the 'chaddr' field of the DHCP or BOOTP message. 260 3. Encoding 262 RELAYFORWARD and RELAYREPLY messages are distinguished through the 263 use of the 'op' field of the DHCP packet. 265 In non-relay DHCP packets, the 'op' field either contains 266 BOOTREQUEST, for any DHCP message from the client to the server, or 267 BOOTREPLY, for any DHCP message from the server to the client. 269 This document defines two additional codes, RELAYFORWARD and 270 RELAYREPLY. Conforming DHCP servers and DHCP relay agents MUST 271 support these two new values for the 'op' field. DHCP clients should 272 never see either value. 274 +------+--------------+ 275 | code | meaning | 276 +------+--------------+ 277 | 1 | BOOTREQUEST | 278 | 2 | BOOTREPLY | 279 | 3 | RELAYFORWARD | 280 | 4 | RELAYREPLY | 281 +------+--------------+ 283 Values for the 'op' field 285 RELAYFORWARD and RELAYREPLY messages share only the 'op' field in 286 common with other DHCP and BOOTP messages. The remainder of the 287 message consists of a series of fixed-length fields followed by two 288 variable-length fields: the relay segment, and the encapsulated 289 message. 291 +-----+-----+-----+-----+ 292 | op | ep | padlen | 293 +-----+-----+-----+-----+ 294 | rslen | caplen | 295 +-----+-----+-----+-----+ 296 | aiaddr | 297 +-----+-----+-----+-----+ 298 . . 299 . relay segment . 300 . . 301 +-----------------------+ 302 . . 303 . encapsulated message . 304 . . 305 +-----------------------+ 307 3.1. The fixed-length header 309 The fixed-length header of the relay message contains a series of 310 fields that perform two purposes: to provide enough information that 311 the DHCP server can reconstruct the original packet sent by the DHCP 312 client, and to establish the lengths of the two variable-length 313 segments. 315 To satisfy the first of these requirements, two fields in the fixed- 316 length header report the amount of padding stripped from the client 317 message, if any, and whether or not an end option was stripped from 318 the client message. Except for a relay message that immediately 319 encapsulates a message from a DHCP client, these fields are always 320 zero. Using these two fields, the DHCP server can reconstruct the 321 client packet exactly, and this allows the DHCP server to validate 322 any signature [RFC3118] that may be present. 324 The fixed-length header consists of five fields: 326 op The BOOTP 'op' field, which, for a relay message, MUST contain the 327 RELAYFORWARD or RELAYREPLY code. 329 ep If an End option was present in the option buffer prior to 330 encapsulation, this field is set to 1; otherwise, it is set to 0. 331 This field is a single byte. 333 padlen The length of any padding that was removed from the option 334 buffer prior to encapsulation: two bytes in network byte order. 336 rslen The length of the relay segment: two byte in network byte 337 order. 339 caplen The length of the encapsulation segment: two byte in network 340 byte order. 342 aiaddr Relay agent IP address. 344 3.2. Relay Segment 346 The relay segment contains any RAIO suboptions that the encapsulating 347 agent (the relay agent or the DHCP server) wishes to send. End and 348 Pad options MUST NOT appear in the relay segment. 350 3.3. Encapsulation Segment 352 The encapsulation segment contains the entire DHCP message being 353 encapsulated, with four exceptions: 355 o The encapsulating agent MUST omit the IP and UDP headers, as well 356 as any layer two header, from the encapsulated message. 358 o The encapsulating agent MUST omit any options following the first 359 End option in the option buffer. These options are assumed to be 360 garbage, and are not covered by any signature [RFC3118]. 362 o The encapsulating MUST omit any Pad options present either at the 363 end of the option buffer, or prior to the first End option, that 364 are followed only by other Pad options or a single End option. 365 The encapsulating agent MUST record number of Pad options that 366 were omitted in the 'padlen' field of the message header. 368 o The encapsulating agent MUST omit the End option, if present. The 369 encapsulating agent MUST set the 'ep' field in the message header 370 to 1 if an End option was present in the option buffer, and to 371 zero if no End option was present. 373 These exceptions apply only to the option buffer. The encapsulating 374 agent MUST NOT modify the contents of the 'file' and 'sname' fields. 375 The encapsulating agent MUST NOT count End or Pad options that appear 376 in these fields. 378 4. DHCP Relay Agent Behavior 380 DHCP Relay agents implementing this specification MUST have a 381 configuration parameter controlling relay encapsulation. By default, 382 relay encapsulation MUST be disabled. 384 Relay agents with encapsulation disabled MUST NOT encapsulate. Relay 385 agents with encapsulation disabled MUST NOT decapsulate. 387 In any case where a relay agent implementing this specification does 388 not encapsulate or decapsulate, it MUST behave exactly as a relay 389 agent that does not implement this specification at all. 391 DHCP relay agents that are configured with encapsulation enabled, but 392 which have no agent-specific options to send to the DHCP server, MUST 393 encapsulate. Relay agents that are configured with encapsulation 394 enabled MUST decapsulate. 396 Layer two relay agents MUST silently discard any messages that 397 contains an IPsec authentication header [RFC4302]. This is because 398 they cannot modify such messages, but also cannot detect that a 399 message from the DHCP server is in response such messages, since the 400 response message might not contain an IPsec authentication header. 402 If a relay message would exceed the MTU of the outgoing interface, it 403 MUST be discarded, and an error condition SHOULD be logged. 405 4.1. Packet processing 407 Relay agents implementing this specification may receive packets 408 directed toward DHCP servers with a source port of 67 (BOOTPS). 409 Therefore, the source port cannot be used to determine whether the 410 packet is traveling toward a DHCP server or toward a DHCP client. 412 In order to determine whether a message is traveling toward a DHCP 413 client or toward a DHCP server, the relay agent must check the 'op' 414 field of the DHCP message. If the 'op' field is set to BOOTREQUEST 415 or RELAYFORWARD, the message is traveling toward a DHCP server. If 416 the 'op' field is set to BOOTREPLY or RELAYREPLY, the message is 417 traveling toward a DHCP client. At the time of the writing of this 418 specification, no other value is meaningful in the 'op' field. 420 Relay agents implementing this specification MUST NOT encapsulate or 421 decapsulate messages with other values in the 'op' field. It is 422 assumed that if meanings are defined for additional values, the 423 document that specifies the meaning of those values will update this 424 document; in the absence of such an update, the behavior specified 425 here will remain in effect. 427 Relay agents implementing this specification MAY differentiate 428 between DHCP and BOOTP messages. Under normal circumstances, BOOTP 429 and DHCP messages are forwarded to the same server, which should be 430 able to successfully decapsulate both DHCP and BOOTP messages. 431 However, some relay agents may send BOOTP and DHCP packets to 432 different servers; this document should not be construed to require 433 that such a relay agent should encapsulate all messages regardless of 434 protocol. 436 4.1.1. Packets traveling toward DHCP servers 438 Any DHCP or BOOTP packet with an 'op' value of BOOTREQUEST or 439 RELAYFORWARD is traveling toward a DHCP server. When a DHCP relay 440 agent that is configured to encapsulate receives such a packet, the 441 relay agent MUST encapsulate that packet into a RELAYFORWARD message 442 and send it to the address or addresses with which it is configured 443 to forward messages intended for DHCP servers. 445 4.1.2. Packets traveling toward DHCP clients 447 Any DHCP or BOOTP packet with an 'op' value of BOOTREPLY or 448 RELAYREPLY is traveling toward a DHCP client. When a DHCP relay 449 agent that is configured to encapsulate recieves a RELAYREPLY message 450 that is traveling toward a DHCP or BOOTP client, the relay agent MUST 451 decapsulate that message and forward the decapsulated message toward 452 the client. 454 4.1.3. Anti-spoofing 456 Because this specification allows for chaining of relay agent- 457 supplied information, it is now possible for a relay agent outside of 458 the trusted portion of a network to communicate relay agent 459 information to the DHCP server without preventing the legitimate 460 relay from communicating return path information to the DHCP server, 461 as is the case with RFC3046. 463 In order to prevent this sort of spoofing, relay agents implementing 464 this specification MUST be configurable to discard all RELAYFORWARD 465 messages that they receive. Administrators relying on a trusted 466 network architecture to control the flow of information to the DHCP 467 server SHOULD configure relay agents on the edge of their networks to 468 discard RELAYFORWARD messages. 470 4.2. Constructing RELAYFORWARD messages 472 4.2.1. Initializing the fixed-length header 474 The relay agent constructs the RELAYFORWARD message by constructing 475 the fixed-length header as specified in the earlier section titled 476 'Encoding'. The relay agent MUST set the 'op' field to a value of 477 RELAYFORWARD. 479 If the relay agent is not a layer two relay agent 481 [I-D.ietf-dhc-l2ra], it MUST store one of its own IP addresses in the 482 'aiaddr' field. This address MUST be a valid IP address that is 483 reachable by the next hop relay(s) or DHCP server(s) to which the 484 relay agent is configured to forward. 486 DHCP servers normally use the relay agent IP address to determine on 487 what link the DHCP client's IP address should be allocated. In some 488 cases, the value stored in the 'aiaddr' field will not be a valid IP 489 address on the link on which the source message was received. In 490 this case, the relay agent MUST include a link selection suboption 491 [RFC3527] that identifies that link in the relay segment. 493 If the relay agent is a layer two relay agent, it MAY include a link 494 selection suboption in the relay segment. 496 If the message being encapsulated is a BOOTREQUEST, L2RAs MUST store 497 a value of zero in the 'aiaddr' field. Otherwise, the L2RA MUST copy 498 the value of the 'aiaddr' field in the RELAYFORWARD message being 499 encapsulated into the 'aiaddr' field of the RELAYFORWARD message that 500 it generates. 502 The 'rslen' field depends on the length of the relay segment. The 503 'caplen', 'padlen' and 'ep' values in the fixed header are 504 initialized differently depending on whether the message being 505 encapsulated is a BOOTREQUEST or a RELAYFORWARD message. 507 4.2.2. Initializing the relay segment 509 Following the fixed header, the relay agent MUST append any RAIO 510 suboptions it wishes to send to the DHCP server; this is the 'relay 511 segment'. It MUST store the length of the relay segment in the 512 'rslen' field of the fixed header. 514 The relay agent SHOULD include a Relay Agent ID suboption 515 [I-D.ietf-dhc-relay-id-suboption] in the relay segment to identify 516 itself to the DHCP server. 518 4.2.3. Fixed header settings for RELAYFORWARD messages 520 If the message being encapsulated is a RELAYFORWARD message, the 521 relay agent MUST initialize the 'caplen' field of the fixed header to 522 the length of the source message, excluding any layer 2, IP and UDP 523 headers. It MUST append the contents of the message, again excluding 524 any layer 2, IP or UDP headers, to the new message. It MUST 525 initialize the 'ep' and 'padlen' fields in the fixed header of the 526 new message to zero. 528 4.2.4. Fixed header settings for BOOTREQUEST messages 530 If the message being encapsulated is a BOOTREQUEST message, the relay 531 agent determines the length of the encapsulation segment by scanning 532 forward across the option buffer of the source message, beginning 533 with the first option in the option buffer, until an End option is 534 reached, or the end of the buffer is reached. The difference between 535 the offset of this location in the message and the offset of the 536 first location following the UDP header of the message is the length 537 of the message to be relayed. 539 If an End option terminated the scan, the relay agent MUST set the 540 value of the 'ep' field in the fixed header to one. Otherwise, the 541 relay agent MUST set the value of the 'ep' field to zero. 543 The relay agent MUST count all of the Pad options that follow the 544 last option in the option buffer that is neither a Pad nor an End 545 option. The relay agent MUST store this count in the 'padlen' field 546 of the fixed header. 548 The relay agent MUST store the difference between the value stored in 549 'padlen' and the length of the message to be relayed in the 'caplen' 550 field of the fixed header. 552 4.2.5. Initializing the encapsulation segment 554 The relay agent MUST copy the portion of the message being 555 encapsulated that immediately follows the UDP header into the 556 RELAYFORWARD message being generated. The length of the data being 557 copied is the value that was stored in 'caplen'. 559 4.3. Decapsulating RELAYREPLY messages 561 To decapsulate a RELAYREPLY message, the relay agent creates a 562 decapsulated message, processes any RAIO suboptions it recognizes in 563 the relay segment, and forwards the decapsulated message to its 564 destination. 566 4.3.1. Processing relay agent suboptions 568 The suboptions parsed from the relay segment are processed by the 569 relay agent as specified in the Relay Agent Information Option 570 specification [RFC3046], as well as in any documents that define 571 suboptions to the Relay Agent Information Option. A current list of 572 DHCP Relay Agent suboptions and the documents that define them can be 573 located in the IANA protocol registry for Bootp and DHCP parameters, 574 in the section titled "DHCP Relay Agent Sub-Option Codes." 576 4.3.2. Constructing the decapsulated message 578 To construct a decapsulated message, the relay agent copies the 579 portion of the RELAYREPLY message following the relay segment, with a 580 length specified in the 'caplen' field of the fixed-length header, 581 into the new message. 583 4.4. Retransmitting modified messages 585 If the relay agent did not modify the message either by encapsulating 586 or decapsulating it, it retransmits the message according to existing 587 practice. 589 Otherwise, how the modified message is transmitted to its next 590 destination depends on two factors. First, is the relay agent that 591 modified the message a layer two [I-D.ietf-dhc-l2ra] relay agent or a 592 layer three [RFC1542] relay agent? Second, is the modified message a 593 BOOTREPLY message, a RELAYREPLY message, or some other message? 595 4.4.1. Layer two relay agents 597 There are two special aspects to the handling of relayed packets in 598 Layer Two Relay Agents (L2RAs). The first is the construction of the 599 layer two, IP and UDP headers on the packet. The second is how the 600 L2RA makes the forwarding decision. 602 4.4.1.1. Constructing the headers 604 The L2RA constructs the headers on the relayed packet by copying and, 605 as necessary, modifying the headers from the original packet. 607 If there is a layer two header, the L2RA MUST copy this header in 608 accordance with the needs of the particular layer two implementation 609 it is using. If the header contains a packet length field, the L2RA 610 MUST adjust the value in the packet length field. If the header 611 contains a non-secure integrity check such as a CRC or checksum that 612 covers the entire packet, the L2RA MUST recompute this value. 614 L2RA encapsulation in cases where the layer two contains a secure 615 integrity check must either construct a new integrity signature, or 616 else remove the integrity signature. If neither of these is 617 possible, the L2RA MUST silently discard the packet. 619 The L2RA MUST copy the IP header without modification except length 620 and checksum field which should be recomputed. If the IP header 621 contains any sort of secure integrity check on the packet, the L2RA 622 MUST silently discard the packet. 624 The L2RA MUST copy the UDP header and adjust the 'Length' field 625 [RFC0768]. If the contents of the 'Checksum' field are not zero, the 626 L2RA MUST compute a new checksum according to the algorithm specified 627 in User Datagram Protocol. [RFC0768] 629 4.4.1.2. Forwarding the modified packet 631 Ordinarily when a layer two device forwards a packet, it simply 632 copies that packet from the interface on which it was received and 633 transmits it, unchanged, on one or more interfaces other than that 634 interface. The mechanism used to choose which interfaces it forwards 635 the packet to is beyond the scope of this document. 637 Once a DHCP packet has been modified by the L2RA either as an 638 encapsulation or a decapsulation, the L2RA must forward it either 639 toward the DHCP server or the DHCP client. The implementation has 640 two options: transmit the packet as it would transmit any other 641 packet, or use its configuration and/or information in the relay 642 header to direct the packet out a particular interface. 644 The details of ordinary packet forwarding in devices that implement 645 L2RA is beyond the scope of this document. 647 When processing a RELAYREPLY message, the L2RA MAY use information in 648 the relay segment of the RELAYREPLY to determine on which network 649 interface the RELAYREPLY should be forwarded. 651 When processing any other message, the L2RA MAY use configuration 652 information to direct the packet out a specific port or ports that 653 have been marked as reaching DHCP servers. The L2RA MUST NOT forward 654 any packet on the interface on which it was received, even if that 655 interface is so marked. 657 4.4.2. Layer three relay agents 659 4.4.2.1. Transmitting a decapsulated RELAYREPLY message 661 When the decapsulated message is itself a RELAYREPLY message, the 662 relay agent MUST forward the decapsulated message to the IP address 663 specified in the 'aiaddr' field of the fixed-length header. 665 If the relay segment of the packet that was decapsulated contains a 666 Link Layer Address suboption, the relay agent MUST transmit the 667 packet to that link layer address without attempting to use Address 668 Resolution Protocol (ARP) to translate the address contained in 669 'aiaddr' to a layer two address. 671 4.4.2.2. Transmitting a decapsulated BOOTREPLY message 673 When transmitting a decapsulated BOOTREPLY message, the relay agent 674 transmits the message as specified in Bootstrap Protocol, Section 4 675 [RFC0951]. 677 4.4.2.3. Transmitting other messages 679 When transmitting RELAYFORWARD and BOOTREQUEST messages, the relay 680 agent simply sends the message to the IP address or addresses 681 configured as DHCP servers for that relay agent. 683 5. DHCP Server Behavior 685 A DHCP server which receives a RELAYREPLY message MUST silently 686 discard that message. 688 5.1. Receiving RELAYFORWARD messages 690 DHCP servers that implement this specification MUST decapsulate 691 RELAYFORWARD messages. 693 5.1.1. Decapsulation 695 By design, this specification supports multiple layers of 696 encapsulation. The DHCP server implementation therefore MUST 697 decapsulate each layer and retain the information in that layer, 698 organized so that the ordering of the encapsulation is available both 699 during packet processing, and when constructing the reply. 701 Aside from the necessity of handling an RAIO differently than an 702 encapsulation when constructing a RELAYREPLY message, DHCP servers 703 MUST NOT, by default, treat relay suboptions received in an RAIO any 704 differently than relay suboptions received in an encapsulation. 706 It is not the goal of this specification to define a particular 707 implementation strategy or data structure for representing the 708 encapsulation, so long as the ability to process the options and 709 suboptions as required below is preserved. Implementations MAY 710 provide means for addressing the contents of relay segments and of 711 the inner encapsulation segment in any convenient form, as long as it 712 conforms generally to the requirements of this document. 714 5.1.2. Processing of decapsulated suboptions 716 This section specifies requirements for the processing of 717 decapsulated relay suboptions in the default case, where no custom 718 processing has been specified. This should not be construed to 719 forbid implementations for providing mechanisms for customizing the 720 processing of these suboptions. 722 This document does not specify special handling for DHCP options. 723 Only the inner encapsulation--the encapsulation of the original 724 message sent from the client, which is done by the first 725 encapsulating relay--can ever contain DHCP Options; hence, whatever 726 normal mechanisms a DHCP server provides for processing these options 727 should suffice. 729 Some relay agent suboptions, such as the Relay Agent Subnet Selection 730 suboption [RFC3527], are intended to be processed by DHCP servers. 731 Others, like the Circuit ID and Remote ID [RFC3046] suboptions, were 732 not intended to be processed by the DHCP server, but are often used 733 by the DHCP server for identification purposes. 735 In cases where more than one relay agent sends the same suboption, 736 the DHCP server must either factor all such suboptions into its 737 processing, or choose one such suboption and use that exclusively for 738 processing. 740 By default, DHCP servers MUST use the outermost suboption (the one 741 added by the relay agent closest to the DHCP server) for every 742 suboption that was sent by more than one relay agent. 744 5.1.3. Address allocation 746 During normal processing, DHCP servers use a variety of data to 747 determine where the DHCP client is in the network topology. These 748 data are provided by relay agents. In the absence of any relay- 749 agent-provided topology data, the DHCP server assumes that the client 750 is connected to the link on which the message was received. 752 One datum used by DHCP servers in locating the client is the value of 753 the 'giaddr' field of the BOOTP header. This specification 754 eliminates the use of giaddr; hence, it cannot be used in the address 755 allocation decision. 757 The functionality provided by giaddr is replaced in this 758 specification by the 'aiaddr' field in the fixed-length relay header. 760 5.1.3.1. Default link selection algorithm 762 DHCP servers MUST implement a default algorithm for determining the 763 link to which the client is attached. This algorithm is to first 764 search the client message for a subnet selection option [RFC3011]. 766 The server next searches for link-identifying data in each 767 RELAYFORWARD encapsulation, starting from the inner most and ending 768 at the outermost, until a RELAYFORWARD is found that identifies the 769 client's location. 771 A RELAYFORWARD encapsulation contains link-identifying data if the 772 value of the 'aiaddr' field of the fixed-length header is not zero, 773 or if the relay segment contains a Link Selection suboption 774 [RFC3527]. 776 If a Link Selection suboption is present in the innermost 777 RELAYFORWARD message containing link-identifying data, the DHCP 778 server MUST use the contents of that option to identify the link to 779 which the client is connected. 781 Otherwise, if a Subnet Selection option was found in the client 782 message, the DHCP server MUST use the contents of that option to 783 identify the link to which the client is connected. 785 Otherwise, the DHCP server MUST use the contents of the 'aiaddr' 786 field in the RELAYFORWARD encapsulation that was identified as being 787 the innermost RELAYFORWARD containing link-identifying data. 789 5.1.3.2. Other link selection algorithms 791 DHCP servers implementing this specification MAY implement link 792 selection algorithms other than the one described in the preceding 793 section. DHCP servers MUST NOT use any link selection algorithm 794 other than the one described in the preceding section unless 795 specially configured to do so. 797 5.2. Responding to RELAYFORWARD messages 799 Once the DHCP server has processed the encapsulated message from the 800 DHCP client and constructed a response to the DHCP client, it 801 constructs a RELAYREPLY message and sends it toward the client. 803 5.2.1. Constructing a RELAYREPLY encapsulation 805 The server MUST encapsulate any response to a client message 806 contained in one or more RELAYFORWARD encapsulations in a set of 807 corresponding RELAYREPLY encapsulations. Each RELAYREPLY is nested 808 in the same way that the corresponding RELAYFORWARD was nested, so 809 that the innermost RELAYREPLY corresponds to the innermost 810 RELAYFORWARD, and the outermost RELAYREPLY corresponds to the 811 outermost RELAYFORWARD. 813 5.2.1.1. Constructing the relay segments 815 The server MUST copy every suboption that appeared in the relay 816 segment of the RELAYFORWARD encapsulation into corresponding outgoing 817 RELAYREPLY encapsulation's relay segment. The server SHOULD NOT 818 preserve the order of options from the incoming relay segment to the 819 outgoing relay segment. 821 If the message encapsulated by a particular RELAYREPLY encapsulation 822 is not a RELAYREPLY, or if the message encapsulated by that 823 RELAYREPLY is a RELAYREPLY, but the 'aiaddr' field of the fixed- 824 length header of the inner RELAYREPLY has a value of zero, the DHCP 825 server MUST include a Layer Two Address suboption in the relay 826 segment. The DHCP server MUST set the 'htype' field of the Layer Two 827 Address suboption to the value of 'htype' in the client message. The 828 DHCP server MUST set the 'chaddr' field in the Layer Two Address 829 suboption to the value of the 'chaddr' field in the client message. 831 5.2.1.2. Constructing the fixed-length header 833 The server MUST set the values of 'ep' and 'padlen' in the fixed- 834 length header to zero. The server MUST set the value of 'caplen' to 835 the length of the message encapsulated in the RELAYREPLY 836 encapsulation being constructed. The server MUST set the value of 837 'rslen' to the length of the relay segment of the RELAYREPLY 838 encapsulation being constructed. 840 If the message encapsulated in the RELAYREPLY being constructed is a 841 RELAYREPLY, and the 'aiaddr' field of the RELAYFORWARD encapsulation 842 corresponding to the inner RELAYREPLY is not zero, the DHCP server 843 MUST copy the value from that 'aiaddr' field to the 'aiaddr' field of 844 the RELAYREPLY being constructed. 846 Otherwise, if the BROADCAST bit in the 'flags' field of the inner 847 message is set to 1, or 'ciaddr' is zero and 'yiaddr' is also zero, 848 the DHCP server MUST set the value of 'aiaddr' to 255.255.255.255. 849 If 'ciaddr' is not zero, the DHCP server must copy that value to 850 'aiaddr'. If 'ciaddr' is zero and 'yiaddr' is not, the DHCP server 851 MUST copy the value of 'yiaddr' to 'aiaddr'. 853 5.2.2. Transmission of RELAYREPLY messages 855 If the value of 'aiaddr' in the outermost RELAYFORWARD encapsulation 856 to which the RELAYREPLY is a response is nonzero, the DHCP server 857 MUST transmit the RELAYREPLY to that IP address. 859 Otherwise, if 'ciaddr' and 'yiaddr' are both zero, or the BROADCAST 860 bit in the 'flags' field is set to 1, or the DHCP server 861 implementation is not able to perform the ARP-cache preloading trick 862 described in Bootstrap Protocol, Section 4 [RFC0951], the DHCP server 863 MUST broadcast the RELAYREPLY message to the 255.255.255.255 864 broadcast address. 866 Otherwise, the DHCP server MUST use the value of 'ciaddr', if 867 nonzero, or 'yiaddr', otherwise, as the destination address for the 868 message, and MUST preload its ARP cache (or otherwise arrange to 869 transmit the message without using ARP) to the layer two address 870 provided by the client in 'htype' and 'chaddr' and 'hlen'. 872 5.3. Responding to messages other than RELAYFORWARD 874 When a DHCP server constructs a response to a DHCP client message 875 that did not arrive encapsulated in a RELAYFORWARD message, the DHCP 876 server MUST NOT encapsulate the response in a RELAYREPLY message. 877 DHCP server implementors should be careful that their servers do not 878 respond to an incoming packet with RAIO from a non-conforming relay 879 agent with a RELAYREPLY message. 881 6. DHCP Client Behavior 883 A DHCP client that receives either a RELAYFORWARD message or a 884 RELAYREPLY message MUST silently discard that message. 886 7. Security Considerations 888 DHCP Relay Information Option [RFC3046] limits relay agent 889 information to a single relay agent, and provides some minimal anti- 890 spoofing. By supporting relay agent chaining, it is now possible for 891 a relay agent downstream of the trusted portion of a provider network 892 to communicate relay agent information options to a DHCP server. 894 This specification defines a much more robust spoofing rejection 895 mechanism, by allowing the administrator to configure the relay to 896 discard RELAYFORWARD messages originating from outside of the trusted 897 portion of the network. Administrators of networks that rely on this 898 trusted/untrusted configuration are encouraged to configure edge 899 relays to discard RELAYFORWARD messages. 901 In networks where trusted relay agents may be separated from the DHCP 902 server by transit networks that are not trusted, it is possible to 903 modify the message in transit. This possibility exists with normal 904 DHCP relays as well. Administrators of such networks should consider 905 using relay agent authentication [RFC4030] to prevent modification of 906 relay agent communications in transit. 908 8. IANA Considerations 910 We request that IANA assign one new suboption code from the registry 911 of DHCP Agent Sub-Option Codes maintained in 912 http://www.iana.org/assignments/bootp-dhcp-parameters. This 913 suboption code will be assigned to the Layer Two Address Suboption. 915 9. References 917 9.1. Normative References 919 [I-D.ietf-dhc-relay-id-suboption] 920 Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", 921 draft-ietf-dhc-relay-id-suboption-07 (work in progress), 922 July 2009. 924 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 925 August 1980. 927 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 928 September 1985. 930 [RFC1542] Wimer, W., "Clarifications and Extensions for the 931 Bootstrap Protocol", RFC 1542, October 1993. 933 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 934 Requirement Levels", BCP 14, RFC 2119, March 1997. 936 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 937 RFC 2131, March 1997. 939 [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", 940 RFC 3011, November 2000. 942 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 943 RFC 3046, January 2001. 945 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 946 Messages", RFC 3118, June 2001. 948 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 949 "Link Selection sub-option for the Relay Agent Information 950 Option for DHCPv4", RFC 3527, April 2003. 952 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 953 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 954 Option", RFC 4030, March 2005. 956 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 957 December 2005. 959 9.2. Informative References 961 [I-D.ietf-dhc-l2ra] 962 Joshi, B. and P. Kurapati, "Layer 2 Relay Agent 963 Information", draft-ietf-dhc-l2ra-04 (work in progress), 964 April 2009. 966 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 967 and M. Carney, "Dynamic Host Configuration Protocol for 968 IPv6 (DHCPv6)", RFC 3315, July 2003. 970 Authors' Addresses 972 Ted Lemon 973 Nominum, Inc. 974 2000 Seaport Blvd 975 Redwood City, CA 94063 976 USA 978 Phone: +1 650 381 6000 979 Email: mellon@nominum.com 981 Hui Deng 982 China Mobile 983 53A, Xibianmennei Ave. 984 Beijing, Xuanwu District 100053 985 China 987 Email: denghui@chinamobile.com 989 Lu Huang 990 China Mobile 991 53A, Xibianmennei Ave. 992 Xunwu District, Beijing 100053 993 China 995 Email: huanglu@chinamobile.com