idnits 2.17.00 (12 Aug 2021) /tmp/idnits45508/draft-lemon-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 148 has weird spacing: '...psulate the a...' == Line 152 has weird spacing: '...psulate the a...' == Line 156 has weird spacing: '...y agent a rel...' == Line 165 has weird spacing: '... buffer the p...' == Line 171 has weird spacing: '...boption a DHC...' == (2 more instances...) -- The document date (September 30, 2010) is 4244 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 (~~), 9 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: April 3, 2011 China Mobile 6 September 30, 2010 8 Relay Agent Encapsulation for DHCPv4 9 draft-lemon-dhcpv4-relay-encapsulation-01 11 Abstract 13 This document describes a general mechanism whereby DHCP relay agents 14 can encapsulate DHCP packets that they are forwarding in the 15 direction of DHCP servers, and decapsulate packets that they they are 16 forwarding toward DHCP clients, so that more than one relay agent can 17 insert relay agent suboptions into the forwarding chain. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 3, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. RELAYFORWARD Message . . . . . . . . . . . . . . . . . . . 6 58 2.2. RELAYREPLY Message . . . . . . . . . . . . . . . . . . . . 6 59 2.3. Layer Two Address suboption . . . . . . . . . . . . . . . 6 60 3. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1. The fixed-length header . . . . . . . . . . . . . . . . . 8 62 3.2. Relay Segment . . . . . . . . . . . . . . . . . . . . . . 9 63 3.3. Encapsulation Segment . . . . . . . . . . . . . . . . . . 9 64 4. DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . 9 65 4.1. Packet processing . . . . . . . . . . . . . . . . . . . . 10 66 4.1.1. Packets traveling toward DHCP servers . . . . . . . . 11 67 4.1.2. Packets traveling toward DHCP clients . . . . . . . . 11 68 4.1.3. Anti-spoofing . . . . . . . . . . . . . . . . . . . . 11 69 4.2. Constructing RELAYFORWARD messages . . . . . . . . . . . . 11 70 4.2.1. Initializing the fixed-length header . . . . . . . . . 11 71 4.2.2. Initializing the relay segment . . . . . . . . . . . . 12 72 4.2.3. Fixed header settings for RELAYFORWARD messages . . . 12 73 4.2.4. Fixed header settings for BOOTREQUEST messages . . . . 12 74 4.2.5. Initializing the encapsulation segment . . . . . . . . 13 75 4.3. Decapsulating RELAYREPLY messages . . . . . . . . . . . . 13 76 4.3.1. Processing relay agent suboptions . . . . . . . . . . 13 77 4.3.2. Constructing the decapsulated message . . . . . . . . 13 78 4.4. Retransmitting modified messages . . . . . . . . . . . . . 14 79 4.4.1. Layer two relay agents . . . . . . . . . . . . . . . . 14 80 4.4.1.1. Constructing the headers . . . . . . . . . . . . . 14 81 4.4.1.2. Forwarding the modified packet . . . . . . . . . . 15 82 4.5. Layer Three Relay Agents . . . . . . . . . . . . . . . . . 15 83 4.5.1. Transmitting a decapsulated RELAYREPLY message . . . . 15 84 4.5.2. Transmitting a decapsulated BOOTREPLY message . . . . 15 85 4.5.3. Transmitting other messages . . . . . . . . . . . . . 16 86 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 16 87 5.1. Receiving RELAYFORWARD messages . . . . . . . . . . . . . 16 88 5.1.1. Decapsulation . . . . . . . . . . . . . . . . . . . . 16 89 5.1.2. Processing of decapsulated suboptions . . . . . . . . 16 90 5.1.3. Address allocation . . . . . . . . . . . . . . . . . . 17 91 5.1.3.1. Default link selection algorithm . . . . . . . . . 17 92 5.1.3.2. Other link selection algorithms . . . . . . . . . 18 93 5.2. Responding to RELAYFORWARD messages . . . . . . . . . . . 18 94 5.2.1. Constructing a RELAYREPLY encapsulation . . . . . . . 18 95 5.2.1.1. Constructing the relay segments . . . . . . . . . 18 96 5.2.1.2. Constructing the fixed-length header . . . . . . . 19 97 5.2.2. Transmission of RELAYREPLY messages . . . . . . . . . 19 98 5.3. Responding to messages other than RELAYFORWARD . . . . . . 20 99 6. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 20 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 104 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 107 1. Introduction 109 In some networking environments, it is useful to be able to configure 110 relay agents in a hierarchy, so that information from a relay agent 111 close to the client can be combined with information from one or more 112 relay agents closer to the server, particularly in cases where the 113 relay agents may be in separate administrative domains. 115 The current Relay Agent Information Option (RAIO) specification 116 [RFC3046] specifies that when a relay agent receives a packet 117 containing an RAIO, it must not add an RAIO. This prevents chaining 118 of RAIOs, and hence prohibits the hierarchical use case. 120 DHCP version 6 [RFC3315] provides a much cleaner technique for 121 providing RAIO suboptions to the DHCP server. Rather than appending 122 an information option to the DHCP client's message, the relay agent 123 encapsulates the DHCP client message in a new DHCP message which it 124 sends to the DHCP server along with any options it chooses to add to 125 provide information to the DHCP server. 127 This document specifies a mechanism for providing the same 128 functionality in DHCPv4. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 1.2. Terminology 138 The following terms and acronyms are used in this document: 140 BOOTREPLY message Any DHCP or BOOTP message in which the 'op' field 141 is set to BOOTREPLY. 143 BOOTREQUEST message Any DHCP or BOOTP message in which the 'op' 144 field is set to BOOTREQUEST. 146 DHCP Dynamic Host Configuration Protocol Version 4 [RFC2131] 148 decapsulate the act of de-encapsulating DHCP packets being relayed 149 from DHCP servers or relay agents in the direction of DHCP 150 clients, according to this specification. 152 encapsulate the act of encapsulating DHCP packets that are being 153 relayed from DHCP clients or relay agents toward DHCP servers, 154 according to the method described in this specification. 156 encapsulating relay agent a relay agent that implements this 157 specification and is configured to encapsulate. 159 L2RA Layer 2 Relay Agent--a relay agent that doesn't have an IP 160 address reachable by the DHCP server. 162 L3RA Layer 3 Relay Agent--a relay agent that has an IP address 163 reachable by the DHCP server. 165 option buffer the portion of the DHCP packet following the magic 166 cookie in the 'vend' field of the DHCP Packet. 168 RAIO Relay Agent Information Option [RFC3046]. Also commonly 169 referred to as "Option 82." 171 RAIO suboption a DHCP suboption that has been defined for 172 encapsulation in the Relay Agent Information Option 174 relay message a RELAYFORWARD or RELAYREPLY message. 176 RELAYFORWARD message Any DHCP or BOOTP message in which the 'op' 177 field is set to RELAYFORWARD. 179 RELAYREPLY message Any DHCP or BOOTP message in which the 'op' field 180 is set to RELAYREPLY. 182 silently discard in many places in this specification, the 183 implementation is required to silently discard erroneous messages. 184 What is meant by 'silently discard' is that the implementation 185 MUST NOT send any ICMP message indicating that the delivery was in 186 error. It may be desirable for the implementation to keep a count 187 of messages that have been discarded, either by message type or by 188 reason for discarding, or some combination. Nothing in this 189 specification should be construed to forbid such data collection. 191 2. Protocol Summary 193 This document specifies two new BOOTP message types: the RELAYFORWARD 194 message, and the RELAYREPLY message. These messages are analogous to 195 the Relay Forward and Relay Reply messages in DHCPv6 [RFC3315]. 197 Although this specification is generally aimed at DHCP 198 implementations, it is not specifically restricted to DHCP, and is 199 applicable to BOOTP in cases where the BOOTP server is a DHCP server 200 that implements this specification, or the less likely case that the 201 BOOTP server only supports the BOOTP protocol, but still implements 202 this specification. 204 In general, when the term "DHCP" appears in this specification, the 205 reader should not read this as intending to exclude BOOTP. 207 2.1. RELAYFORWARD Message 209 Conforming relay agents encapsulate messages being sent toward DHCP 210 servers in RELAYFORWARD messages. 212 2.2. RELAYREPLY Message 214 A conforming DHCP server encapsulates any message being sent toward a 215 DHCP client in a RELAYREPLY message, if the message being responded 216 to was encapsulated. 218 A conforming relay agent, when it receives a RELAYREPLY message, 219 decapsulates the message contained in the RELAYREPLY message and 220 sends it to the next relay or to the client. 222 2.3. Layer Two Address suboption 224 In cases where the closest relay agent to the client is an L2RA, but 225 where there is an L3RA on the path to the client, the DHCP server 226 will encode the link layer address that would normally go in the 227 chaddr field of the DHCP packet into a Layer Two Address suboption. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | SUBOPT_L2AS | length | htype | chaddr ... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 The Layer Two Address suboption has four fields: 237 SUBOPT_L2AS One octet: the suboption code for the Layer Two Address 238 suboption (TBD). 240 length One octet: the length of the Layer Two Address suboption. 242 htype One octet: the type of the Layer Two Address suboption-- 243 corresponds to the 'htype' field in a non-relay DHCP or BOOTP 244 message. 246 chaddr One or more octets: the layer two address of the client, from 247 the 'chaddr' field of the DHCP or BOOTP message. 249 3. Encoding 251 RELAYFORWARD and RELAYREPLY messages are distinguished through the 252 use of the 'op' field of the DHCP packet. 254 In non-relay DHCP packets, the 'op' field either contains 255 BOOTREQUEST, for any DHCP message from the client to the server, or 256 BOOTREPLY, for any DHCP message from the server to the client. 258 This document defines two additional codes, RELAYFORWARD and 259 RELAYREPLY. Conforming DHCP servers and DHCP relay agents MUST 260 support these two new values for the 'op' field. DHCP clients should 261 never see either value. 263 +------+--------------+ 264 | code | meaning | 265 +------+--------------+ 266 | 1 | BOOTREQUEST | 267 | 2 | BOOTREPLY | 268 | 3 | RELAYFORWARD | 269 | 4 | RELAYREPLY | 270 +------+--------------+ 272 Values for the 'op' field 274 RELAYFORWARD and RELAYREPLY messages share only the 'op' field in 275 common with other DHCP and BOOTP messages. The remainder of the 276 message consists of a series of fixed-length fields followed by two 277 variable-length fields: the relay segment, and the encapsulated 278 message. 280 +-----+-----+-----+-----+ 281 | op | ep | padlen | 282 +-----+-----+-----+-----+ 283 | rslen | caplen | 284 +-----+-----+-----+-----+ 285 | aiaddr | 286 +-----+-----+-----+-----+ 287 . . 288 . relay segment . 289 . . 290 +-----------------------+ 291 . . 292 . encapsulated message . 293 . . 294 +-----------------------+ 296 3.1. The fixed-length header 298 The fixed-length header of the relay message contains a series of 299 fields that perform two purposes: to provide enough information that 300 the DHCP server can reconstruct the original packet sent by the DHCP 301 client, and to establish the lengths of the two variable-length 302 segments. 304 To satisfy the first of these requirements, two fields in the fixed- 305 length header report the amount of padding stripped from the client 306 message, if any, and whether or not an end option was stripped from 307 the client message. Except for a relay message that immediately 308 encapsulates a message from a DHCP client, these fields are always 309 zero. Using these two fields, the DHCP server can reconstruct the 310 client packet exactly, and this allows the DHCP server to validate 311 any signature [RFC3118] that may be present. 313 The fixed-length header consists of five fields: 315 op The BOOTP 'op' field, which, for a relay message, MUST contain the 316 RELAYFORWARD or RELAYREPLY code. 318 ep If an End option was present in the option buffer prior to 319 encapsulation, this field is set to 1; otherwise, it is set to 0. 320 This field is a single byte. 322 padlen The length of any padding that was removed from the option 323 buffer prior to encapsulation: two bytes in network byte order. 325 rslen The length of the relay segment: two byte in network byte 326 order. 328 caplen The length of the encapsulation segment: two byte in network 329 byte order. 331 aiaddr Relay agent IP address. 333 3.2. Relay Segment 335 The relay segment contains any RAIO suboptions that the encapsulating 336 agent (the relay agent or the DHCP server) wishes to send. End and 337 Pad options MUST NOT appear within the relay segment. 339 3.3. Encapsulation Segment 341 The encapsulation segment contains the entire DHCP message being 342 encapsulated, with four exceptions: 344 o The encapsulating agent MUST omit the IP and UDP headers, as well 345 as any layer two header, from the encapsulated message. 347 o The encapsulating agent MUST omit any options following the first 348 End option in the option buffer. These options are assumed to be 349 garbage, and are not covered by any signature [RFC3118]. 351 o The encapsulating MUST omit any Pad options present either at the 352 end of the option buffer, or prior to the first End packet, that 353 are followed only by other Pad options or a single End option. 354 The encapsulating agent MUST record number of Pad options that 355 were omitted in the 'padlen' field of the message header. 357 o The encapsulating agent MUST omit the End option, if present. The 358 encapsulating agent MUST set the 'ep' field in the message header 359 to 1 if an End option was present in the option buffer, and to 360 zero if no End option was present. 362 These exceptions apply only to the option buffer. The encapsulating 363 agent MUST NOT modify the contents of the 'file' and 'sname' fields. 364 The encapsulating agent MUST NOT count End or Pad options that appear 365 in these fields. 367 4. DHCP Relay Agent Behavior 369 DHCP Relay agents implementing this specification MUST have a 370 configuration parameter controlling relay encapsulation. By default, 371 relay encapsulation MUST be disabled. 373 Relay agents with encapsulation disabled MUST NOT encapsulate. Relay 374 agents with encapsulation disabled MUST NOT decapsulate. 376 In any case where a relay agent implementing this specification does 377 not encapsulate or decapsulate, it MUST behave exactly as a relay 378 agent would that did not implement this specification at all. 380 DHCP relay agents that are configured with encapsulation enabled, but 381 which have no agent-specific options to send to the DHCP server, MUST 382 encapsulate. Relay agents that are configured with encapsulation 383 enabled MUST decapsulate. 385 Layer two relay agents MUST silently discard any messages that 386 contains an IPsec authentication header [RFC4302]. This is because 387 they cannot modify such packets, but also cannot detect that a 388 message from the DHCP server is in response such a message, since it 389 might not contain an IPsec authentication header. 391 4.1. Packet processing 393 Relay agents implementing this specification may receive packets 394 directed toward DHCP servers with a source port of 67 (BOOTPS). 395 Therefore, the source port cannot be used to determine whether the 396 packet is traveling toward a DHCP server or toward a DHCP client. 398 In order to determine whether a message is traveling toward a DHCP 399 client or toward a DHCP server, the relay agent must check the 'op' 400 field of the DHCP message. If the 'op' field is set to BOOTREQUEST 401 or RELAYFORWARD, the message is traveling toward a DHCP server. If 402 the 'op' field is set to BOOTREPLY or RELAYREPLY, the message is 403 traveling toward a DHCP client. At the time of the writing of this 404 specification, no other value is meaningful in the 'op' field. 406 Relay agents implementing this specification MUST NOT encapsulate or 407 decapsulate messages with other values in the 'op' field. It is 408 assumed that if meanings are defined for additional values, the 409 document that specifies the meaning of those values will update this 410 document; in the absence of such an update, the behavior specified 411 here will remain in effect. 413 Relay agents implementing this specification MAY differentiate 414 between DHCP and BOOTP messages. Under normal circumstances, BOOTP 415 and DHCP messages are forwarded to the same server, which should be 416 able to successfully decapsulate both DHCP and BOOTP messages. 417 However, some relay agents may send BOOTP and DHCP packets to 418 different servers; this document should not be construed to require 419 that such a relay agent should encapsulate all messages regardless of 420 protocol. 422 4.1.1. Packets traveling toward DHCP servers 424 Any DHCP or BOOTP packet with an 'op' value of BOOTREQUEST or 425 RELAYFORWARD is traveling toward a DHCP server. When a DHCP relay 426 agent that is configured to encapsulate receives such a packet, the 427 relay agent MUST encapsulate that packet into a RELAYFORWARD message 428 and send it to the address or addresses with which it is configured 429 to forward messages intended for DHCP servers. 431 4.1.2. Packets traveling toward DHCP clients 433 Any DHCP or BOOTP packet with an 'op' value of BOOTREPLY or 434 RELAYREPLY is traveling toward a DHCP client. When a DHCP relay 435 agent that is configured to encapsulate recieves a RELAYREPLY message 436 that is traveling toward a DHCP or BOOTP client, the relay agent MUST 437 decapsulate that message and forward the decapsulated message toward 438 the client. 440 4.1.3. Anti-spoofing 442 Because this specification allows for chaining of relay agent- 443 supplied information, it is now possible for a relay agent outside of 444 the trusted portion of a network to communicate relay agent 445 information to the DHCP server without preventing the legitimate 446 relay from communicating return path information to the DHCP server, 447 as is the case with RFC3046. 449 In order to prevent this sort of spoofing, relay agents implementing 450 this specification MUST be configurable to discard all RELAYFORWARD 451 messages that they receive. Administrators relying on a trusted 452 network architecture to control the flow of information to the DHCP 453 server SHOULD configure relay agents on the edge of their networks to 454 discard RELAYFORWARD messages. 456 4.2. Constructing RELAYFORWARD messages 458 4.2.1. Initializing the fixed-length header 460 The relay agent constructs the RELAYFORWARD message by constructing 461 the fixed-length header as specified in the earlier section titled 462 'Encoding'. The relay agent MUST set the 'op' field to a value of 463 RELAYFORWARD. 465 If the relay agent is not a layer two relay agent 466 [I-D.ietf-dhc-l2ra], it MUST store one of its own IP addresses in the 467 'aiaddr' field. This address MUST be a valid IP address that is 468 reachable by the next hop relay(s) or DHCP server(s) to which the 469 relay agent is configured to forward. 471 DHCP servers normally use the relay agent IP address to determine on 472 what link the DHCP client's IP address should be allocated. In some 473 cases, the value stored in the 'aiaddr' field will not be a valid IP 474 address on the link on which the source message was received. In 475 this case, the relay agent MUST include a link selection suboption 476 [RFC3527] that identifies that link in the relay segment. 478 If the relay agent is a layer two relay agent, it MAY include a link 479 selection suboption in the relay segment. 481 If the message being encapsulated is a BOOTREQUEST, L2RAs MUST store 482 a value of zero in the 'aiaddr' field. Otherwise, the L2RA MUST copy 483 the value of the 'aiaddr' field in the RELAYFORWARD message being 484 encapsulated into the 'aiaddr' field of the RELAYFORWARD message that 485 it generates. 487 The 'rslen' field depends on the length of the relay segment. The 488 'caplen', 'padlen' and 'ep' values in the fixed header are 489 initialized differently depending on whether the message being 490 encapsulated is a BOOTREQUEST or a RELAYFORWARD message. 492 4.2.2. Initializing the relay segment 494 Following the fixed header, the relay agent MUST append any RAIO 495 suboptions it wishes to send to the DHCP server; this is the 'relay 496 segment'. It MUST store the length of the relay segment in the 497 'rslen' field of the fixed header. 499 The relay agent SHOULD include a Relay Agent ID suboption 500 [I-D.ietf-dhc-relay-id-suboption] in the relay segment to identify 501 itself to the DHCP server. 503 4.2.3. Fixed header settings for RELAYFORWARD messages 505 If the message being encapsulated is a RELAYFORWARD message, the 506 relay agent MUST initialize the 'caplen' field of the fixed header to 507 the length of the source message, excluding any layer 2, IP and UDP 508 headers. It MUST append the contents of the message, again excluding 509 any layer 2, IP or UDP headers, to the new message. It MUST 510 initialize the 'ep' and 'padlen' fields in the fixed header of the 511 new message to zero. 513 4.2.4. Fixed header settings for BOOTREQUEST messages 515 If the message being encapsulated is a BOOTREQUEST message, the relay 516 agent determines the length of the encapsulation segment by scanning 517 forward across the option buffer of the source message, beginning 518 with the first option in the option buffer, until an End option is 519 reached, or the end of the buffer is reached. The difference between 520 the offset of this location in the message and the offset of the 521 first location following the UDP header of the message is the length 522 of the message to be relayed. 524 If an End option terminated the scan, the relay agent MUST set the 525 value of the 'ep' field in the fixed header to one. Otherwise, the 526 relay agent MUST set the value of the 'ep' field to zero. 528 The relay agent MUST count all of the Pad options that follow the 529 last option in the option buffer that is neither a Pad nor an End 530 option. The relay agent MUST store this count in the 'padlen' field 531 of the fixed header. 533 The relay agent MUST store the difference between the value stored in 534 'padlen' and the length of the message to be relayed in the 'caplen' 535 field of the fixed header. 537 4.2.5. Initializing the encapsulation segment 539 The relay agent MUST copy the portion of the message being 540 encapsulated that immediately follows the UDP header into the 541 RELAYFORWARD message being generated. The length of the data being 542 copied is the value that was stored in 'caplen'. 544 4.3. Decapsulating RELAYREPLY messages 546 To decapsulate a RELAYREPLY message, the relay agent creates a 547 decapsulated message, processes any RAIO suboptions it recognizes in 548 the relay segment, and forwards the decapsulated message to its 549 destination. 551 4.3.1. Processing relay agent suboptions 553 The suboptions parsed from the relay segment are processed by the 554 relay agent as specified in the Relay Agent Information Option 555 specification [RFC3046], as well as in any documents that define 556 suboptions to the Relay Agent Information Option. A current list of 557 DHCP Relay Agent suboptions and the documents that define them can be 558 located in the IANA protocol registry for Bootp and DHCP parameters, 559 in the section titled "DHCP Relay Agent Sub-Option Codes." 561 4.3.2. Constructing the decapsulated message 563 To construct a decapsulated message, the relay agent copies the 564 portion of the RELAYREPLY message following the relay segment, with a 565 length specified in the 'caplen' field of the fixed-length header, 566 into the new message. 568 4.4. Retransmitting modified messages 570 If the relay agent did not modify the message either by encapsulating 571 or decapsulating it, it retransmits the message according to existing 572 practice. 574 Otherwise, how the modified message is transmitted to its next 575 destination depends on two factors. First, is the relay agent that 576 modified the message a layer two [I-D.ietf-dhc-l2ra] relay agent or a 577 layer three [RFC1542] relay agent? Second, is the modified message a 578 BOOTREPLY message, a RELAYREPLY message, or some other message? 580 4.4.1. Layer two relay agents 582 There are two special aspects to the handling of relayed packets in 583 Layer Two Relay Agents (L2RAs). The first is the construction of the 584 layer two, IP and UDP headers on the packet. The second is how the 585 L2RA makes the forwarding decision. 587 4.4.1.1. Constructing the headers 589 The L2RA constructs the headers on the relayed packet by copying and, 590 as necessary, modifying the headers from the original packet. 592 If there is a layer two header, the L2RA MUST copy this header in 593 accordance with the needs of the particular layer two implementation 594 it is using. If the header contains a packet length field, the L2RA 595 MUST adjust the value in the packet length field. If the header 596 contains a non-secure integrity check such as a CRC or checksum that 597 covers the entire packet, the L2RA MUST recompute this value. 599 L2RA encapsulation in cases where the layer two contains a secure 600 integrity check must either construct a new integrity signature, or 601 else remove the integrity signature. If neither of these is 602 possible, the L2RA MUST silently discard the packet. 604 The L2RA MUST copy the IP header without modification. If the IP 605 header contains any sort of secure integrity check on the packet, the 606 L2RA MUST silently discard the packet. 608 The L2RA MUST copy the UDP header and adjust the 'Length' field 609 [RFC0768]. If the contents of the 'Checksum' field are not zero, the 610 L2RA MUST compute a new checksum according to the algorithm specified 611 in User Datagram Protocol. [RFC0768] 613 4.4.1.2. Forwarding the modified packet 615 Ordinarily when a layer two device forwards a packet, it simply 616 copies that packet from the interface on which it was received and 617 transmits it, unchanged, on one or more interfaces other than that 618 interface. The mechanism used to choose which interfaces it forwards 619 the packet to is beyond the scope of this document. 621 Once a DHCP packet has been modified by the L2RA either as an 622 encapsulation or a decapsulation, the L2RA must forward it either 623 toward the DHCP server or the DHCP client. The implementation has 624 two options: transmit the packet as it would transmit any other 625 packet, or use its configuration and/or information in the relay 626 header to direct the packet out a particular interface. 628 The details of ordinary packet forwarding in devices that implement 629 L2RA is beyond the scope of this document. 631 When processing a RELAYREPLY message, the L2RA MAY use information in 632 the relay segment of the RELAYREPLY to determine on which network 633 interface the RELAYREPLY should be forwarded. 635 When processing any other message, the L2RA MAY use configuration 636 information to direct the packet out a specific port or ports that 637 have been marked as reaching DHCP servers. The L2RA MUST NOT forward 638 any packet on the interface on which it was received, even if that 639 interface is so marked. 641 4.5. Layer Three Relay Agents 643 4.5.1. Transmitting a decapsulated RELAYREPLY message 645 When the decapsulated message is itself a RELAYREPLY message, the 646 relay agent MUST forward the decapsulated message to the IP address 647 specified in the 'aiaddr' field of the fixed-length header. 649 If the relay segment of the packet that was decapsulated contains a 650 Link Layer Address suboption, the relay agent MUST transmit the 651 packet to that link layer address without attempting to use Address 652 Resolution Protocol (ARP) to translate the address contained in 653 'aiaddr' to a layer two address. 655 4.5.2. Transmitting a decapsulated BOOTREPLY message 657 When transmitting a decapsulated BOOTREPLY message, the relay agent 658 transmits the message as specified in Bootstrap Protocol, Section 4 659 [RFC0951]. 661 4.5.3. Transmitting other messages 663 When transmitting RELAYFORWARD and BOOTREQUEST messages, the relay 664 agent simply sends the message to the IP address or addresses 665 configured as DHCP servers for that relay agent. 667 5. DHCP Server Behavior 669 A DHCP server which receives a RELAYREPLY message MUST silently 670 discard that message. 672 5.1. Receiving RELAYFORWARD messages 674 DHCP servers that implement this specification MUST decapsulate 675 RELAYFORWARD messages. 677 5.1.1. Decapsulation 679 By design, this specification supports multiple layers of 680 encapsulation. The DHCP server implementation therefore MUST 681 decapsulate each layer and retain the information in that layer, 682 organized so that the ordering of the encapsulation is available both 683 during packet processing, and when constructing the reply. 685 Aside from the necessity of handling an RAIO differently than an 686 encapsulation when constructing a RELAYREPLY message, DHCP servers 687 MUST NOT, by default, treat relay suboptions received in an RAIO any 688 differently than relay suboptions received in an encapsulation. 690 It is not the goal of this specification to define a particular 691 implementation strategy or data structure for representing the 692 encapsulation, so long as the ability to process the options and 693 suboptions as required below is preserved. Implementations MAY 694 provide means for addressing the contents of relay segments and of 695 the inner encapsulation segment in any convenient form, as long as it 696 conforms generally to the requirements of this document. 698 5.1.2. Processing of decapsulated suboptions 700 This section specifies requirements for the processing of 701 decapsulated relay suboptions in the default case, where no custom 702 processing has been specified. This should not be construed to 703 forbid implementations for providing mechanisms for customizing the 704 processing of these suboptions. 706 This document does not specify special handling for DHCP options. 707 Only the inner encapsulation--the encapsulation of the original 708 message sent from the client, which is done by the first 709 encapsulating relay--can ever contain DHCP Options; hence, whatever 710 normal mechanisms a DHCP server provides for processing these options 711 should suffice. 713 Some relay agent suboptions, such as the Relay Agent Subnet Selection 714 suboption [RFC3527], are intended to be processed by DHCP servers. 715 Others, like the Circuit ID and Remote ID [RFC3046] suboptions, were 716 not intended to be processed by the DHCP server, but are often used 717 by the DHCP server for identification purposes. 719 In cases where more than one relay agent sends the same suboption, 720 the DHCP server must either factor all such suboptions into its 721 processing, or choose one such suboption and use that exclusively for 722 processing. 724 By default, DHCP servers MUST use the outermost suboption (the one 725 added by the relay agent closest to the DHCP server) for every 726 suboption that was sent by more than one relay agent. 728 5.1.3. Address allocation 730 During normal processing, DHCP servers use a variety of data to 731 determine where the DHCP client is in the network topology. These 732 data are provided by relay agents. In the absence of any relay- 733 agent-provided topology data, the DHCP server assumes that the client 734 is connected to the link on which the message was received. 736 One datum used by DHCP servers in locating the client is the value of 737 the 'giaddr' field of the BOOTP header. This specification 738 eliminates the use of giaddr; hence, it cannot be used in the address 739 allocation decision. 741 The functionality provided by giaddr is replaced in this 742 specification by the 'aiaddr' field in the fixed-length relay header. 744 5.1.3.1. Default link selection algorithm 746 DHCP servers MUST implement a default algorithm for determining the 747 link to which the client is attached. This algorithm is to first 748 search the client message for a subnet selection option [RFC3011]. 750 The server next searches for link-identifying data in each 751 RELAYFORWARD encapsulation, starting from the inner most and ending 752 at the outermost, until a RELAYFORWARD is found that identifies the 753 client's location. 755 A RELAYFORWARD encapsulation contains link-identifying data if the 756 value of the 'aiaddr' field of the fixed-length header is not zero, 757 or if the relay segment contains a Link Selection suboption 758 [RFC3527]. 760 If a Link Selection suboption is present in the innermost 761 RELAYFORWARD message containing link-identifying data, the DHCP 762 server MUST use the contents of that option to identify the link to 763 which the client is connected. 765 Otherwise, if a Subnet Selection option was found in the client 766 message, the DHCP server MUST use the contents of that option to 767 identify the link to which the client is connected. 769 Otherwise, the DHCP server MUST use the contents of the 'aiaddr' 770 field in the RELAYFORWARD encapsulation that was identified as being 771 the innermost RELAYFORWARD containing link-identifying data. 773 5.1.3.2. Other link selection algorithms 775 DHCP servers implementing this specification MAY implement link 776 selection algorithms other than the one described in the preceding 777 section. DHCP servers MUST NOT use any link selection algorithm 778 other than the one described in the preceding section unless 779 specially configured to do so. 781 5.2. Responding to RELAYFORWARD messages 783 Once the DHCP server has processed the encapsulated message from the 784 DHCP client and constructed a response to the DHCP client, it 785 constructs a RELAYREPLY message and sends it to the next hop on the 786 way to the client. 788 5.2.1. Constructing a RELAYREPLY encapsulation 790 The server MUST encapsulate any response to a client message 791 contained in one or more RELAYFORWARD encapsulations in a set of 792 corresponding RELAYREPLY encapsulations. Each RELAYREPLY is nested 793 in the same way that the corresponding RELAYFORWARD was nested, so 794 that the innermost RELAYREPLY corresponds to the innermost 795 RELAYFORWARD, and the outermost RELAYREPLY corresponds to the 796 outermost RELAYFORWARD. 798 5.2.1.1. Constructing the relay segments 800 The server MUST copy every suboption that appeared in the relay 801 segment of the RELAYFORWARD encapsulation into corresponding outgoing 802 RELAYREPLY encapsulation's relay segment. The server SHOULD NOT 803 preserve the order of options from the incoming relay segment to the 804 outgoing relay segment. 806 If the message encapsulated by a particular RELAYREPLY encapsulation 807 is not a RELAYREPLY, or if the message encapsulated by that 808 RELAYREPLY is a RELAYREPLY, but the 'aiaddr' field of the fixed- 809 length header of the inner RELAYREPLY has a value of zero, the DHCP 810 server MUST include a Layer Two Address suboption in the relay 811 segment. The DHCP server MUST set the 'htype' field of the Layer Two 812 Address suboption to the value of 'htype' in the client message. The 813 DHCP server MUST set the 'chaddr' field in the Layer Two Address 814 suboption to the value of the 'chaddr' field in the client message. 816 5.2.1.2. Constructing the fixed-length header 818 The server MUST set the values of 'ep' and 'padlen' in the fixed- 819 length header to zero. The server MUST set the value of 'caplen' to 820 the length of the message encapsulated in the RELAYREPLY 821 encapsulation being constructed. The server MUST set the value of 822 'rslen' to the length of the relay segment of the RELAYREPLY 823 encapsulation being constructed. 825 If the message encapsulated in the RELAYREPLY being constructed is a 826 RELAYREPLY, and the 'aiaddr' field of the RELAYFORWARD encapsulation 827 corresponding to the inner RELAYREPLY is not zero, the DHCP server 828 MUST copy the value from that 'aiaddr' field to the 'aiaddr' field of 829 the RELAYREPLY being constructed. 831 Otherwise, if the BROADCAST bit in the 'flags' field of the inner 832 message is set to 1, or 'ciaddr' is zero and 'yiaddr' is also zero, 833 the DHCP server MUST set the value of 'aiaddr' to 255.255.255.255. 834 If 'ciaddr' is not zero, the DHCP server must copy that value to 835 'aiaddr'. If 'ciaddr' is zero and 'yiaddr' is not, the DHCP server 836 MUST copy the value of 'yiaddr' to 'aiaddr'. 838 5.2.2. Transmission of RELAYREPLY messages 840 If the value of 'aiaddr' in the outermost RELAYFORWARD encapsulation 841 to which the RELAYREPLY is a response is nonzero, the DHCP server 842 MUST transmit the RELAYREPLY to that IP address. 844 Otherwise, if 'ciaddr' and 'yiaddr' are both zero, or the BROADCAST 845 bit in the 'flags' field is set to 1, or the DHCP server 846 implementation is not able to perform the ARP-cache preloading trick 847 described in Bootstrap Protocol, Section 4 [RFC0951], the DHCP server 848 MUST broadcast the RELAYREPLY message to the 255.255.255.255 849 broadcast address. 851 Otherwise, the DHCP server MUST use the value of 'ciaddr', if 852 nonzero, or 'yiaddr', otherwise, as the destination address for the 853 message, and MUST preload its ARP cache (or otherwise arrange to 854 transmit the message without using ARP) to the layer two address 855 provided by the client in 'htype' and 'chaddr' and 'hlen'. 857 5.3. Responding to messages other than RELAYFORWARD 859 When a DHCP server constructs a response to a DHCP client message 860 that did not arrive encapsulated in a RELAYFORWARD message, the DHCP 861 server MUST NOT encapsulate the response in a RELAYREPLY message. 862 DHCP server implementors should be careful that their servers do not 863 respond to an incoming RAIO from a non-conforming relay agent with a 864 RELAYREPLY message. 866 6. DHCP Client Behavior 868 A DHCP client that receives either a RELAYFORWARD message or a 869 RELAYREPLY message MUST silently discard that message. 871 7. Security Considerations 873 DHCP Relay Information Option [RFC3046] limits relay agent 874 information to a single relay agent, and provides some minimal anti- 875 spoofing. By supporting relay agent chaining, it is now possible for 876 a relay agent downstream of the trusted portion of a provider network 877 to communicate relay agent information options to a DHCP server. 879 This specification defines a much more robust spoofing rejection 880 mechanism, by allowing the administrator to configure the relay to 881 discard RELAYFORWARD messages originating from outside of the trusted 882 portion of the network. Administrators of networks that rely on this 883 trusted/untrusted configuration are encouraged to configure edge 884 relays to discard RELAYFORWARD messages. 886 In networks where trusted relay agents may be separated from the DHCP 887 server by transit networks that are not trusted, it is possible to 888 modify the message in transit. This possibility exists with normal 889 DHCP relays as well. Administrators of such networks should consider 890 using relay agent authentication [RFC4030] to prevent modification of 891 relay agent communications in transit. 893 8. IANA Considerations 895 We request that IANA assign one new suboption code from the registry 896 of DHCP Agent Sub-Option Codes maintained in 897 http://www.iana.org/assignments/bootp-dhcp-parameters. This 898 suboption code will be assigned to the Layer Two Address Suboption. 900 9. References 902 9.1. Normative References 904 [I-D.ietf-dhc-relay-id-suboption] 905 Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", 906 draft-ietf-dhc-relay-id-suboption-07 (work in progress), 907 July 2009. 909 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 910 August 1980. 912 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 913 September 1985. 915 [RFC1542] Wimer, W., "Clarifications and Extensions for the 916 Bootstrap Protocol", RFC 1542, October 1993. 918 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 919 Requirement Levels", BCP 14, RFC 2119, March 1997. 921 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 922 RFC 2131, March 1997. 924 [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", 925 RFC 3011, November 2000. 927 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 928 RFC 3046, January 2001. 930 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 931 Messages", RFC 3118, June 2001. 933 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 934 "Link Selection sub-option for the Relay Agent Information 935 Option for DHCPv4", RFC 3527, April 2003. 937 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 938 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 939 Option", RFC 4030, March 2005. 941 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 942 December 2005. 944 9.2. Informative References 946 [I-D.ietf-dhc-l2ra] 947 Joshi, B. and P. Kurapati, "Layer 2 Relay Agent 948 Information", draft-ietf-dhc-l2ra-04 (work in progress), 949 April 2009. 951 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 952 and M. Carney, "Dynamic Host Configuration Protocol for 953 IPv6 (DHCPv6)", RFC 3315, July 2003. 955 Authors' Addresses 957 Ted Lemon 958 Nominum, Inc. 959 2000 Seaport Blvd 960 Redwood City, CA 94063 961 USA 963 Phone: +1 650 381 6000 964 Email: mellon@nominum.com 966 Hui Deng 967 China Mobile 968 53A, Xibianmennei Ave. 969 Beijing, Xuanwu District 100053 970 China 972 Email: denghui@chinamobile.com