idnits 2.17.1 draft-ietf-dhc-dhcpv4-relay-encapsulation-00.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 159 has weird spacing: '...y agent a rel...' -- The document date (October 16, 2010) is 4940 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: A later version (-13) exists of draft-ietf-dhc-relay-id-suboption-07 == 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: April 19, 2011 China Mobile 6 October 16, 2010 8 Relay Agent Encapsulation for DHCPv4 9 draft-ietf-dhc-dhcpv4-relay-encapsulation-00 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 19, 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 . . . . . . . . . . . . . . . . . . . . . . . 6 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' 141 field 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 147 [RFC2131] 149 decapsulate the act of de-encapsulating DHCP packets being 150 relayed from DHCP servers or relay agents in 151 the direction of DHCP clients, according to 152 this specification. 154 encapsulate the act of encapsulating DHCP packets that are 155 being relayed from DHCP clients or relay agents 156 toward DHCP servers, according to the method 157 described in this specification. 159 encapsulating relay agent a relay agent that implements this 160 specification and is configured to encapsulate. 162 L2RA Layer 2 Relay Agent--a relay agent that doesn't 163 have an IP address reachable by the DHCP 164 server. 166 L3RA Layer 3 Relay Agent--a relay agent that has an 167 IP address reachable by the DHCP server. 169 option buffer the portion of the DHCP packet following the 170 magic cookie in the 'vend' field of the DHCP 171 Packet. 173 RAIO Relay Agent Information Option [RFC3046]. Also 174 commonly referred to as "Option 82." 176 RAIO suboption a DHCP suboption that has been defined for 177 encapsulation in the Relay Agent Information 178 Option 180 relay message a RELAYFORWARD or RELAYREPLY message. 182 RELAYFORWARD message Any DHCP or BOOTP message in which the 'op' 183 field is set to RELAYFORWARD. 185 RELAYREPLY message Any DHCP or BOOTP message in which the 'op' 186 field is set to RELAYREPLY. 188 silently discard in many places in this specification, the 189 implementation is required to silently discard 190 erroneous messages. What is meant by 'silently 191 discard' is that the implementation MUST NOT 192 send any ICMP message indicating that the 193 delivery was in error. It may be desirable for 194 the implementation to keep a count of messages 195 that have been discarded, either by message 196 type or by reason for discarding, or some 197 combination. Nothing in this specification 198 should be construed to forbid such data 199 collection. 201 2. Protocol Summary 203 This document specifies two new BOOTP message types: the RELAYFORWARD 204 message, and the RELAYREPLY message. These messages are analogous to 205 the Relay Forward and Relay Reply messages in DHCPv6 [RFC3315]. 207 Although this specification is generally aimed at DHCP 208 implementations, it is not specifically restricted to DHCP, and is 209 applicable to BOOTP in cases where the BOOTP server is a DHCP server 210 that implements this specification, or the less likely case that the 211 BOOTP server only supports the BOOTP protocol, but still implements 212 this specification. 214 In general, when the term "DHCP" appears in this specification, the 215 reader should not read this as intending to exclude BOOTP. 217 2.1. RELAYFORWARD Message 219 Conforming relay agents encapsulate messages being sent toward DHCP 220 servers in RELAYFORWARD messages. 222 2.2. RELAYREPLY Message 224 A conforming DHCP server encapsulates any message being sent toward a 225 DHCP client in a RELAYREPLY message, if the message being responded 226 to was encapsulated. 228 A conforming relay agent, when it receives a RELAYREPLY message, 229 decapsulates the message contained in the RELAYREPLY message and 230 sends it to the next relay or to the client. 232 2.3. Layer Two Address suboption 234 In cases where the closest relay agent to the client is an L2RA, but 235 where there is an L3RA on the path to the client, the DHCP server 236 will encode the link layer address that would normally go in the 237 chaddr field of the DHCP packet into a Layer Two Address suboption. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | SUBOPT_L2AS | length | htype | chaddr ... 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 The Layer Two Address suboption has four fields: 247 SUBOPT_L2AS One octet: the suboption code for the Layer Two Address 248 suboption (TBD). 250 length One octet: the length of the Layer Two Address suboption. 252 htype One octet: the type of the Layer Two Address suboption-- 253 corresponds to the 'htype' field in a non-relay DHCP or BOOTP 254 message. 256 chaddr One or more octets: the layer two address of the client, from 257 the 'chaddr' field of the DHCP or BOOTP message. 259 3. Encoding 261 RELAYFORWARD and RELAYREPLY messages are distinguished through the 262 use of the 'op' field of the DHCP packet. 264 In non-relay DHCP packets, the 'op' field either contains 265 BOOTREQUEST, for any DHCP message from the client to the server, or 266 BOOTREPLY, for any DHCP message from the server to the client. 268 This document defines two additional codes, RELAYFORWARD and 269 RELAYREPLY. Conforming DHCP servers and DHCP relay agents MUST 270 support these two new values for the 'op' field. DHCP clients should 271 never see either value. 273 +------+--------------+ 274 | code | meaning | 275 +------+--------------+ 276 | 1 | BOOTREQUEST | 277 | 2 | BOOTREPLY | 278 | 3 | RELAYFORWARD | 279 | 4 | RELAYREPLY | 280 +------+--------------+ 282 Values for the 'op' field 284 RELAYFORWARD and RELAYREPLY messages share only the 'op' field in 285 common with other DHCP and BOOTP messages. The remainder of the 286 message consists of a series of fixed-length fields followed by two 287 variable-length fields: the relay segment, and the encapsulated 288 message. 290 +-----+-----+-----+-----+ 291 | op | ep | padlen | 292 +-----+-----+-----+-----+ 293 | rslen | caplen | 294 +-----+-----+-----+-----+ 295 | aiaddr | 296 +-----+-----+-----+-----+ 297 . . 298 . relay segment . 299 . . 300 +-----------------------+ 301 . . 302 . encapsulated message . 303 . . 304 +-----------------------+ 306 3.1. The fixed-length header 308 The fixed-length header of the relay message contains a series of 309 fields that perform two purposes: to provide enough information that 310 the DHCP server can reconstruct the original packet sent by the DHCP 311 client, and to establish the lengths of the two variable-length 312 segments. 314 To satisfy the first of these requirements, two fields in the fixed- 315 length header report the amount of padding stripped from the client 316 message, if any, and whether or not an end option was stripped from 317 the client message. Except for a relay message that immediately 318 encapsulates a message from a DHCP client, these fields are always 319 zero. Using these two fields, the DHCP server can reconstruct the 320 client packet exactly, and this allows the DHCP server to validate 321 any signature [RFC3118] that may be present. 323 The fixed-length header consists of five fields: 325 op The BOOTP 'op' field, which, for a relay message, MUST contain the 326 RELAYFORWARD or RELAYREPLY code. 328 ep If an End option was present in the option buffer prior to 329 encapsulation, this field is set to 1; otherwise, it is set to 0. 330 This field is a single byte. 332 padlen The length of any padding that was removed from the option 333 buffer prior to encapsulation: two bytes in network byte order. 335 rslen The length of the relay segment: two byte in network byte 336 order. 338 caplen The length of the encapsulation segment: two byte in network 339 byte order. 341 aiaddr Relay agent IP address. 343 3.2. Relay Segment 345 The relay segment contains any RAIO suboptions that the encapsulating 346 agent (the relay agent or the DHCP server) wishes to send. End and 347 Pad options MUST NOT appear within the relay segment. 349 3.3. Encapsulation Segment 351 The encapsulation segment contains the entire DHCP message being 352 encapsulated, with four exceptions: 354 o The encapsulating agent MUST omit the IP and UDP headers, as well 355 as any layer two header, from the encapsulated message. 357 o The encapsulating agent MUST omit any options following the first 358 End option in the option buffer. These options are assumed to be 359 garbage, and are not covered by any signature [RFC3118]. 361 o The encapsulating MUST omit any Pad options present either at the 362 end of the option buffer, or prior to the first End packet, that 363 are followed only by other Pad options or a single End option. 364 The encapsulating agent MUST record number of Pad options that 365 were omitted in the 'padlen' field of the message header. 367 o The encapsulating agent MUST omit the End option, if present. The 368 encapsulating agent MUST set the 'ep' field in the message header 369 to 1 if an End option was present in the option buffer, and to 370 zero if no End option was present. 372 These exceptions apply only to the option buffer. The encapsulating 373 agent MUST NOT modify the contents of the 'file' and 'sname' fields. 374 The encapsulating agent MUST NOT count End or Pad options that appear 375 in these fields. 377 4. DHCP Relay Agent Behavior 379 DHCP Relay agents implementing this specification MUST have a 380 configuration parameter controlling relay encapsulation. By default, 381 relay encapsulation MUST be disabled. 383 Relay agents with encapsulation disabled MUST NOT encapsulate. Relay 384 agents with encapsulation disabled MUST NOT decapsulate. 386 In any case where a relay agent implementing this specification does 387 not encapsulate or decapsulate, it MUST behave exactly as a relay 388 agent would that did not implement this specification at all. 390 DHCP relay agents that are configured with encapsulation enabled, but 391 which have no agent-specific options to send to the DHCP server, MUST 392 encapsulate. Relay agents that are configured with encapsulation 393 enabled MUST decapsulate. 395 Layer two relay agents MUST silently discard any messages that 396 contains an IPsec authentication header [RFC4302]. This is because 397 they cannot modify such packets, but also cannot detect that a 398 message from the DHCP server is in response such a message, since it 399 might not contain an IPsec authentication header. 401 4.1. Packet processing 403 Relay agents implementing this specification may receive packets 404 directed toward DHCP servers with a source port of 67 (BOOTPS). 405 Therefore, the source port cannot be used to determine whether the 406 packet is traveling toward a DHCP server or toward a DHCP client. 408 In order to determine whether a message is traveling toward a DHCP 409 client or toward a DHCP server, the relay agent must check the 'op' 410 field of the DHCP message. If the 'op' field is set to BOOTREQUEST 411 or RELAYFORWARD, the message is traveling toward a DHCP server. If 412 the 'op' field is set to BOOTREPLY or RELAYREPLY, the message is 413 traveling toward a DHCP client. At the time of the writing of this 414 specification, no other value is meaningful in the 'op' field. 416 Relay agents implementing this specification MUST NOT encapsulate or 417 decapsulate messages with other values in the 'op' field. It is 418 assumed that if meanings are defined for additional values, the 419 document that specifies the meaning of those values will update this 420 document; in the absence of such an update, the behavior specified 421 here will remain in effect. 423 Relay agents implementing this specification MAY differentiate 424 between DHCP and BOOTP messages. Under normal circumstances, BOOTP 425 and DHCP messages are forwarded to the same server, which should be 426 able to successfully decapsulate both DHCP and BOOTP messages. 427 However, some relay agents may send BOOTP and DHCP packets to 428 different servers; this document should not be construed to require 429 that such a relay agent should encapsulate all messages regardless of 430 protocol. 432 4.1.1. Packets traveling toward DHCP servers 434 Any DHCP or BOOTP packet with an 'op' value of BOOTREQUEST or 435 RELAYFORWARD is traveling toward a DHCP server. When a DHCP relay 436 agent that is configured to encapsulate receives such a packet, the 437 relay agent MUST encapsulate that packet into a RELAYFORWARD message 438 and send it to the address or addresses with which it is configured 439 to forward messages intended for DHCP servers. 441 4.1.2. Packets traveling toward DHCP clients 443 Any DHCP or BOOTP packet with an 'op' value of BOOTREPLY or 444 RELAYREPLY is traveling toward a DHCP client. When a DHCP relay 445 agent that is configured to encapsulate recieves a RELAYREPLY message 446 that is traveling toward a DHCP or BOOTP client, the relay agent MUST 447 decapsulate that message and forward the decapsulated message toward 448 the client. 450 4.1.3. Anti-spoofing 452 Because this specification allows for chaining of relay agent- 453 supplied information, it is now possible for a relay agent outside of 454 the trusted portion of a network to communicate relay agent 455 information to the DHCP server without preventing the legitimate 456 relay from communicating return path information to the DHCP server, 457 as is the case with RFC3046. 459 In order to prevent this sort of spoofing, relay agents implementing 460 this specification MUST be configurable to discard all RELAYFORWARD 461 messages that they receive. Administrators relying on a trusted 462 network architecture to control the flow of information to the DHCP 463 server SHOULD configure relay agents on the edge of their networks to 464 discard RELAYFORWARD messages. 466 4.2. Constructing RELAYFORWARD messages 468 4.2.1. Initializing the fixed-length header 470 The relay agent constructs the RELAYFORWARD message by constructing 471 the fixed-length header as specified in the earlier section titled 472 'Encoding'. The relay agent MUST set the 'op' field to a value of 473 RELAYFORWARD. 475 If the relay agent is not a layer two relay agent 476 [I-D.ietf-dhc-l2ra], it MUST store one of its own IP addresses in the 477 'aiaddr' field. This address MUST be a valid IP address that is 478 reachable by the next hop relay(s) or DHCP server(s) to which the 479 relay agent is configured to forward. 481 DHCP servers normally use the relay agent IP address to determine on 482 what link the DHCP client's IP address should be allocated. In some 483 cases, the value stored in the 'aiaddr' field will not be a valid IP 484 address on the link on which the source message was received. In 485 this case, the relay agent MUST include a link selection suboption 486 [RFC3527] that identifies that link in the relay segment. 488 If the relay agent is a layer two relay agent, it MAY include a link 489 selection suboption in the relay segment. 491 If the message being encapsulated is a BOOTREQUEST, L2RAs MUST store 492 a value of zero in the 'aiaddr' field. Otherwise, the L2RA MUST copy 493 the value of the 'aiaddr' field in the RELAYFORWARD message being 494 encapsulated into the 'aiaddr' field of the RELAYFORWARD message that 495 it generates. 497 The 'rslen' field depends on the length of the relay segment. The 498 'caplen', 'padlen' and 'ep' values in the fixed header are 499 initialized differently depending on whether the message being 500 encapsulated is a BOOTREQUEST or a RELAYFORWARD message. 502 4.2.2. Initializing the relay segment 504 Following the fixed header, the relay agent MUST append any RAIO 505 suboptions it wishes to send to the DHCP server; this is the 'relay 506 segment'. It MUST store the length of the relay segment in the 507 'rslen' field of the fixed header. 509 The relay agent SHOULD include a Relay Agent ID suboption 510 [I-D.ietf-dhc-relay-id-suboption] in the relay segment to identify 511 itself to the DHCP server. 513 4.2.3. Fixed header settings for RELAYFORWARD messages 515 If the message being encapsulated is a RELAYFORWARD message, the 516 relay agent MUST initialize the 'caplen' field of the fixed header to 517 the length of the source message, excluding any layer 2, IP and UDP 518 headers. It MUST append the contents of the message, again excluding 519 any layer 2, IP or UDP headers, to the new message. It MUST 520 initialize the 'ep' and 'padlen' fields in the fixed header of the 521 new message to zero. 523 4.2.4. Fixed header settings for BOOTREQUEST messages 525 If the message being encapsulated is a BOOTREQUEST message, the relay 526 agent determines the length of the encapsulation segment by scanning 527 forward across the option buffer of the source message, beginning 528 with the first option in the option buffer, until an End option is 529 reached, or the end of the buffer is reached. The difference between 530 the offset of this location in the message and the offset of the 531 first location following the UDP header of the message is the length 532 of the message to be relayed. 534 If an End option terminated the scan, the relay agent MUST set the 535 value of the 'ep' field in the fixed header to one. Otherwise, the 536 relay agent MUST set the value of the 'ep' field to zero. 538 The relay agent MUST count all of the Pad options that follow the 539 last option in the option buffer that is neither a Pad nor an End 540 option. The relay agent MUST store this count in the 'padlen' field 541 of the fixed header. 543 The relay agent MUST store the difference between the value stored in 544 'padlen' and the length of the message to be relayed in the 'caplen' 545 field of the fixed header. 547 4.2.5. Initializing the encapsulation segment 549 The relay agent MUST copy the portion of the message being 550 encapsulated that immediately follows the UDP header into the 551 RELAYFORWARD message being generated. The length of the data being 552 copied is the value that was stored in 'caplen'. 554 4.3. Decapsulating RELAYREPLY messages 556 To decapsulate a RELAYREPLY message, the relay agent creates a 557 decapsulated message, processes any RAIO suboptions it recognizes in 558 the relay segment, and forwards the decapsulated message to its 559 destination. 561 4.3.1. Processing relay agent suboptions 563 The suboptions parsed from the relay segment are processed by the 564 relay agent as specified in the Relay Agent Information Option 565 specification [RFC3046], as well as in any documents that define 566 suboptions to the Relay Agent Information Option. A current list of 567 DHCP Relay Agent suboptions and the documents that define them can be 568 located in the IANA protocol registry for Bootp and DHCP parameters, 569 in the section titled "DHCP Relay Agent Sub-Option Codes." 571 4.3.2. Constructing the decapsulated message 573 To construct a decapsulated message, the relay agent copies the 574 portion of the RELAYREPLY message following the relay segment, with a 575 length specified in the 'caplen' field of the fixed-length header, 576 into the new message. 578 4.4. Retransmitting modified messages 580 If the relay agent did not modify the message either by encapsulating 581 or decapsulating it, it retransmits the message according to existing 582 practice. 584 Otherwise, how the modified message is transmitted to its next 585 destination depends on two factors. First, is the relay agent that 586 modified the message a layer two [I-D.ietf-dhc-l2ra] relay agent or a 587 layer three [RFC1542] relay agent? Second, is the modified message a 588 BOOTREPLY message, a RELAYREPLY message, or some other message? 590 4.4.1. Layer two relay agents 592 There are two special aspects to the handling of relayed packets in 593 Layer Two Relay Agents (L2RAs). The first is the construction of the 594 layer two, IP and UDP headers on the packet. The second is how the 595 L2RA makes the forwarding decision. 597 4.4.1.1. Constructing the headers 599 The L2RA constructs the headers on the relayed packet by copying and, 600 as necessary, modifying the headers from the original packet. 602 If there is a layer two header, the L2RA MUST copy this header in 603 accordance with the needs of the particular layer two implementation 604 it is using. If the header contains a packet length field, the L2RA 605 MUST adjust the value in the packet length field. If the header 606 contains a non-secure integrity check such as a CRC or checksum that 607 covers the entire packet, the L2RA MUST recompute this value. 609 L2RA encapsulation in cases where the layer two contains a secure 610 integrity check must either construct a new integrity signature, or 611 else remove the integrity signature. If neither of these is 612 possible, the L2RA MUST silently discard the packet. 614 The L2RA MUST copy the IP header without modification. If the IP 615 header contains any sort of secure integrity check on the packet, the 616 L2RA MUST silently discard the packet. 618 The L2RA MUST copy the UDP header and adjust the 'Length' field 619 [RFC0768]. If the contents of the 'Checksum' field are not zero, the 620 L2RA MUST compute a new checksum according to the algorithm specified 621 in User Datagram Protocol. [RFC0768] 623 4.4.1.2. Forwarding the modified packet 625 Ordinarily when a layer two device forwards a packet, it simply 626 copies that packet from the interface on which it was received and 627 transmits it, unchanged, on one or more interfaces other than that 628 interface. The mechanism used to choose which interfaces it forwards 629 the packet to is beyond the scope of this document. 631 Once a DHCP packet has been modified by the L2RA either as an 632 encapsulation or a decapsulation, the L2RA must forward it either 633 toward the DHCP server or the DHCP client. The implementation has 634 two options: transmit the packet as it would transmit any other 635 packet, or use its configuration and/or information in the relay 636 header to direct the packet out a particular interface. 638 The details of ordinary packet forwarding in devices that implement 639 L2RA is beyond the scope of this document. 641 When processing a RELAYREPLY message, the L2RA MAY use information in 642 the relay segment of the RELAYREPLY to determine on which network 643 interface the RELAYREPLY should be forwarded. 645 When processing any other message, the L2RA MAY use configuration 646 information to direct the packet out a specific port or ports that 647 have been marked as reaching DHCP servers. The L2RA MUST NOT forward 648 any packet on the interface on which it was received, even if that 649 interface is so marked. 651 4.5. Layer Three Relay Agents 653 4.5.1. Transmitting a decapsulated RELAYREPLY message 655 When the decapsulated message is itself a RELAYREPLY message, the 656 relay agent MUST forward the decapsulated message to the IP address 657 specified in the 'aiaddr' field of the fixed-length header. 659 If the relay segment of the packet that was decapsulated contains a 660 Link Layer Address suboption, the relay agent MUST transmit the 661 packet to that link layer address without attempting to use Address 662 Resolution Protocol (ARP) to translate the address contained in 663 'aiaddr' to a layer two address. 665 4.5.2. Transmitting a decapsulated BOOTREPLY message 667 When transmitting a decapsulated BOOTREPLY message, the relay agent 668 transmits the message as specified in Bootstrap Protocol, Section 4 669 [RFC0951]. 671 4.5.3. Transmitting other messages 673 When transmitting RELAYFORWARD and BOOTREQUEST messages, the relay 674 agent simply sends the message to the IP address or addresses 675 configured as DHCP servers for that relay agent. 677 5. DHCP Server Behavior 679 A DHCP server which receives a RELAYREPLY message MUST silently 680 discard that message. 682 5.1. Receiving RELAYFORWARD messages 684 DHCP servers that implement this specification MUST decapsulate 685 RELAYFORWARD messages. 687 5.1.1. Decapsulation 689 By design, this specification supports multiple layers of 690 encapsulation. The DHCP server implementation therefore MUST 691 decapsulate each layer and retain the information in that layer, 692 organized so that the ordering of the encapsulation is available both 693 during packet processing, and when constructing the reply. 695 Aside from the necessity of handling an RAIO differently than an 696 encapsulation when constructing a RELAYREPLY message, DHCP servers 697 MUST NOT, by default, treat relay suboptions received in an RAIO any 698 differently than relay suboptions received in an encapsulation. 700 It is not the goal of this specification to define a particular 701 implementation strategy or data structure for representing the 702 encapsulation, so long as the ability to process the options and 703 suboptions as required below is preserved. Implementations MAY 704 provide means for addressing the contents of relay segments and of 705 the inner encapsulation segment in any convenient form, as long as it 706 conforms generally to the requirements of this document. 708 5.1.2. Processing of decapsulated suboptions 710 This section specifies requirements for the processing of 711 decapsulated relay suboptions in the default case, where no custom 712 processing has been specified. This should not be construed to 713 forbid implementations for providing mechanisms for customizing the 714 processing of these suboptions. 716 This document does not specify special handling for DHCP options. 717 Only the inner encapsulation--the encapsulation of the original 718 message sent from the client, which is done by the first 719 encapsulating relay--can ever contain DHCP Options; hence, whatever 720 normal mechanisms a DHCP server provides for processing these options 721 should suffice. 723 Some relay agent suboptions, such as the Relay Agent Subnet Selection 724 suboption [RFC3527], are intended to be processed by DHCP servers. 725 Others, like the Circuit ID and Remote ID [RFC3046] suboptions, were 726 not intended to be processed by the DHCP server, but are often used 727 by the DHCP server for identification purposes. 729 In cases where more than one relay agent sends the same suboption, 730 the DHCP server must either factor all such suboptions into its 731 processing, or choose one such suboption and use that exclusively for 732 processing. 734 By default, DHCP servers MUST use the outermost suboption (the one 735 added by the relay agent closest to the DHCP server) for every 736 suboption that was sent by more than one relay agent. 738 5.1.3. Address allocation 740 During normal processing, DHCP servers use a variety of data to 741 determine where the DHCP client is in the network topology. These 742 data are provided by relay agents. In the absence of any relay- 743 agent-provided topology data, the DHCP server assumes that the client 744 is connected to the link on which the message was received. 746 One datum used by DHCP servers in locating the client is the value of 747 the 'giaddr' field of the BOOTP header. This specification 748 eliminates the use of giaddr; hence, it cannot be used in the address 749 allocation decision. 751 The functionality provided by giaddr is replaced in this 752 specification by the 'aiaddr' field in the fixed-length relay header. 754 5.1.3.1. Default link selection algorithm 756 DHCP servers MUST implement a default algorithm for determining the 757 link to which the client is attached. This algorithm is to first 758 search the client message for a subnet selection option [RFC3011]. 760 The server next searches for link-identifying data in each 761 RELAYFORWARD encapsulation, starting from the inner most and ending 762 at the outermost, until a RELAYFORWARD is found that identifies the 763 client's location. 765 A RELAYFORWARD encapsulation contains link-identifying data if the 766 value of the 'aiaddr' field of the fixed-length header is not zero, 767 or if the relay segment contains a Link Selection suboption 768 [RFC3527]. 770 If a Link Selection suboption is present in the innermost 771 RELAYFORWARD message containing link-identifying data, the DHCP 772 server MUST use the contents of that option to identify the link to 773 which the client is connected. 775 Otherwise, if a Subnet Selection option was found in the client 776 message, the DHCP server MUST use the contents of that option to 777 identify the link to which the client is connected. 779 Otherwise, the DHCP server MUST use the contents of the 'aiaddr' 780 field in the RELAYFORWARD encapsulation that was identified as being 781 the innermost RELAYFORWARD containing link-identifying data. 783 5.1.3.2. Other link selection algorithms 785 DHCP servers implementing this specification MAY implement link 786 selection algorithms other than the one described in the preceding 787 section. DHCP servers MUST NOT use any link selection algorithm 788 other than the one described in the preceding section unless 789 specially configured to do so. 791 5.2. Responding to RELAYFORWARD messages 793 Once the DHCP server has processed the encapsulated message from the 794 DHCP client and constructed a response to the DHCP client, it 795 constructs a RELAYREPLY message and sends it to the next hop on the 796 way to the client. 798 5.2.1. Constructing a RELAYREPLY encapsulation 800 The server MUST encapsulate any response to a client message 801 contained in one or more RELAYFORWARD encapsulations in a set of 802 corresponding RELAYREPLY encapsulations. Each RELAYREPLY is nested 803 in the same way that the corresponding RELAYFORWARD was nested, so 804 that the innermost RELAYREPLY corresponds to the innermost 805 RELAYFORWARD, and the outermost RELAYREPLY corresponds to the 806 outermost RELAYFORWARD. 808 5.2.1.1. Constructing the relay segments 810 The server MUST copy every suboption that appeared in the relay 811 segment of the RELAYFORWARD encapsulation into corresponding outgoing 812 RELAYREPLY encapsulation's relay segment. The server SHOULD NOT 813 preserve the order of options from the incoming relay segment to the 814 outgoing relay segment. 816 If the message encapsulated by a particular RELAYREPLY encapsulation 817 is not a RELAYREPLY, or if the message encapsulated by that 818 RELAYREPLY is a RELAYREPLY, but the 'aiaddr' field of the fixed- 819 length header of the inner RELAYREPLY has a value of zero, the DHCP 820 server MUST include a Layer Two Address suboption in the relay 821 segment. The DHCP server MUST set the 'htype' field of the Layer Two 822 Address suboption to the value of 'htype' in the client message. The 823 DHCP server MUST set the 'chaddr' field in the Layer Two Address 824 suboption to the value of the 'chaddr' field in the client message. 826 5.2.1.2. Constructing the fixed-length header 828 The server MUST set the values of 'ep' and 'padlen' in the fixed- 829 length header to zero. The server MUST set the value of 'caplen' to 830 the length of the message encapsulated in the RELAYREPLY 831 encapsulation being constructed. The server MUST set the value of 832 'rslen' to the length of the relay segment of the RELAYREPLY 833 encapsulation being constructed. 835 If the message encapsulated in the RELAYREPLY being constructed is a 836 RELAYREPLY, and the 'aiaddr' field of the RELAYFORWARD encapsulation 837 corresponding to the inner RELAYREPLY is not zero, the DHCP server 838 MUST copy the value from that 'aiaddr' field to the 'aiaddr' field of 839 the RELAYREPLY being constructed. 841 Otherwise, if the BROADCAST bit in the 'flags' field of the inner 842 message is set to 1, or 'ciaddr' is zero and 'yiaddr' is also zero, 843 the DHCP server MUST set the value of 'aiaddr' to 255.255.255.255. 844 If 'ciaddr' is not zero, the DHCP server must copy that value to 845 'aiaddr'. If 'ciaddr' is zero and 'yiaddr' is not, the DHCP server 846 MUST copy the value of 'yiaddr' to 'aiaddr'. 848 5.2.2. Transmission of RELAYREPLY messages 850 If the value of 'aiaddr' in the outermost RELAYFORWARD encapsulation 851 to which the RELAYREPLY is a response is nonzero, the DHCP server 852 MUST transmit the RELAYREPLY to that IP address. 854 Otherwise, if 'ciaddr' and 'yiaddr' are both zero, or the BROADCAST 855 bit in the 'flags' field is set to 1, or the DHCP server 856 implementation is not able to perform the ARP-cache preloading trick 857 described in Bootstrap Protocol, Section 4 [RFC0951], the DHCP server 858 MUST broadcast the RELAYREPLY message to the 255.255.255.255 859 broadcast address. 861 Otherwise, the DHCP server MUST use the value of 'ciaddr', if 862 nonzero, or 'yiaddr', otherwise, as the destination address for the 863 message, and MUST preload its ARP cache (or otherwise arrange to 864 transmit the message without using ARP) to the layer two address 865 provided by the client in 'htype' and 'chaddr' and 'hlen'. 867 5.3. Responding to messages other than RELAYFORWARD 869 When a DHCP server constructs a response to a DHCP client message 870 that did not arrive encapsulated in a RELAYFORWARD message, the DHCP 871 server MUST NOT encapsulate the response in a RELAYREPLY message. 872 DHCP server implementors should be careful that their servers do not 873 respond to an incoming RAIO from a non-conforming relay agent with a 874 RELAYREPLY message. 876 6. DHCP Client Behavior 878 A DHCP client that receives either a RELAYFORWARD message or a 879 RELAYREPLY message MUST silently discard that message. 881 7. Security Considerations 883 DHCP Relay Information Option [RFC3046] limits relay agent 884 information to a single relay agent, and provides some minimal anti- 885 spoofing. By supporting relay agent chaining, it is now possible for 886 a relay agent downstream of the trusted portion of a provider network 887 to communicate relay agent information options to a DHCP server. 889 This specification defines a much more robust spoofing rejection 890 mechanism, by allowing the administrator to configure the relay to 891 discard RELAYFORWARD messages originating from outside of the trusted 892 portion of the network. Administrators of networks that rely on this 893 trusted/untrusted configuration are encouraged to configure edge 894 relays to discard RELAYFORWARD messages. 896 In networks where trusted relay agents may be separated from the DHCP 897 server by transit networks that are not trusted, it is possible to 898 modify the message in transit. This possibility exists with normal 899 DHCP relays as well. Administrators of such networks should consider 900 using relay agent authentication [RFC4030] to prevent modification of 901 relay agent communications in transit. 903 8. IANA Considerations 905 We request that IANA assign one new suboption code from the registry 906 of DHCP Agent Sub-Option Codes maintained in 907 http://www.iana.org/assignments/bootp-dhcp-parameters. This 908 suboption code will be assigned to the Layer Two Address Suboption. 910 9. References 912 9.1. Normative References 914 [I-D.ietf-dhc-relay-id-suboption] 915 Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", 916 draft-ietf-dhc-relay-id-suboption-07 (work in progress), 917 July 2009. 919 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 920 August 1980. 922 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 923 September 1985. 925 [RFC1542] Wimer, W., "Clarifications and Extensions for the 926 Bootstrap Protocol", RFC 1542, October 1993. 928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 929 Requirement Levels", BCP 14, RFC 2119, March 1997. 931 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 932 RFC 2131, March 1997. 934 [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", 935 RFC 3011, November 2000. 937 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 938 RFC 3046, January 2001. 940 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 941 Messages", RFC 3118, June 2001. 943 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 944 "Link Selection sub-option for the Relay Agent Information 945 Option for DHCPv4", RFC 3527, April 2003. 947 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 948 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 949 Option", RFC 4030, March 2005. 951 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 952 December 2005. 954 9.2. Informative References 956 [I-D.ietf-dhc-l2ra] 957 Joshi, B. and P. Kurapati, "Layer 2 Relay Agent 958 Information", draft-ietf-dhc-l2ra-04 (work in progress), 959 April 2009. 961 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 962 and M. Carney, "Dynamic Host Configuration Protocol for 963 IPv6 (DHCPv6)", RFC 3315, July 2003. 965 Authors' Addresses 967 Ted Lemon 968 Nominum, Inc. 969 2000 Seaport Blvd 970 Redwood City, CA 94063 971 USA 973 Phone: +1 650 381 6000 974 Email: mellon@nominum.com 976 Hui Deng 977 China Mobile 978 53A, Xibianmennei Ave. 979 Beijing, Xuanwu District 100053 980 China 982 Email: denghui@chinamobile.com