idnits 2.17.1 draft-kurapati-dhc-l2ra-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 760. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 750. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o This document suggest new option which MAY be added by Layer 2 Relay Agents in DHCP message. If a server finds this new option included in a received message, the server MUST compute any hash function as if the option were NOT included in the message without changing the order of options. Whenever the server sends back this option to a relay agent, the server MUST not include this option in the computation of any hash function over the message. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2008) is 5916 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) -- Looks like a reference, but probably isn't: 'RFC2131' on line 542 -- Looks like a reference, but probably isn't: 'RFC2132' on line 542 == Unused Reference: '10' is defined on line 687, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '6') == Outdated reference: A later version (-06) exists of draft-ietf-dhc-l2ra-00 ** Downref: Normative reference to an Informational draft: draft-ietf-dhc-l2ra (ref. '7') Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group B. Joshi 3 Internet-Draft P. Kurapati 4 Expires: August 17, 2008 M. Kamath 5 Infosys Technologies Ltd. 6 S. De Cnodder 7 Alcatel-Lucent 8 February 14, 2008 10 Extensions to Layer 2 Relay Agent 11 draft-kurapati-dhc-l2ra-extensions-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 17, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 As per industry trends, Access Networks have been migrating from 45 traditional ATM based networks to Ethernet networks. In Ethernet 46 based access networks, Access Concentrators are typically configured 47 to act as a transparent bridge in Layer 2 mode. These Access 48 Concentrators also act as Layer 2 relay agents. Layer 2 Relay Agent 49 functionality does not provide means to avoid flooding of DHCP 50 messages and also needs to be extended to support DHCP LeaseQuery 51 This draft discusses these issues and provides solutions for the 52 same. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Enhancements in Layer 2 Relay Agent . . . . . . . . . . . . . 6 59 3.1. Reference Network . . . . . . . . . . . . . . . . . . . . 6 60 4. Uplink port . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent . . . . . 9 62 5.1. Protocol Extension Overview . . . . . . . . . . . . . . . 9 63 5.2. Protocol Extension Details . . . . . . . . . . . . . . . . 9 64 5.2.1. Generating DHCPLEASEQUERY Message . . . . . . . . . . 9 65 5.2.2. Handling DHCPLEASEQUERY Message in Layer 3 Relay 66 Agent . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5.2.3. Handling DHCPLEASEQUERY Message in DHCP Server . . . . 10 68 5.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent . . 10 69 5.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent . . 11 70 5.3. DHCPLEASEQUERY using Management IP address of Layer 2 71 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Prevention of flooding of DHCP replies from Layer 3 Relay 73 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6.1. Flooding of DHCP reply messages from Layer 3 Relay 75 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 6.1.1. Unicast-Address Sub-Option . . . . . . . . . . . . . . 13 77 6.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 78 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 15 79 6.2.1. Relay Agent Hardware Address option . . . . . . . . . 16 80 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 81 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 19 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 21 85 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 21 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 87 Intellectual Property and Copyright Statements . . . . . . . . . . 23 89 1. Introduction 91 DHCP Relay Agents eliminate the necessity of having a DHCP server on 92 each physical network. RFC 3046 [3] defines a new option 'Relay 93 Agent Information' which is added to DHCP messages by Relay Agents. 94 DHCP servers may use this option for IP address and other parameter 95 assignment policies. 97 In case of Layer 2 Access Networks, Access Concentrators typically 98 act as Layer 2 Relay Agents [7]. 100 This document proposes enhancements in Layer 2 Relay Agent [7] which 101 addresses issues like flooding between Layer 3 Relay Agent and Layer 102 2 Relay Agent and retrieving lease information from server using DHCP 103 leasequery mechanism. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [1]. 111 This document uses the following terms: 113 o "Access Concentrator" 115 An Access Concentrator is a router or switch at the broadband access 116 provider's edge of a public broadband access network. This document 117 assumes that the Access Concentrator acts as a Transparent Bridge and 118 includes the DHCP relay agent functionality. For example: In DSL 119 environment, this is typically known as DSLAM.(Digital Subscriber 120 Line Access Multiplexer) 122 o "DHCP client" 124 A DHCP client is an Internet host using DHCP to obtain configuration 125 parameters such as a network address. 127 o "Layer 3 Relay Agent" 129 A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap 130 Protocol (BOOTP) and DHCP messages between clients and servers 131 residing on different subnets, per RFC951 [8] and RFC1542[9]. 133 o "DHCP server" 135 A DHCP server is an Internet host that returns configuration 136 parameters to DHCP clients. 138 o "downstream" 140 Downstream is the direction from the edge network towards the DHCP 141 Clients. 143 o "Transparent Bridge" 145 A device which does bridging based on MAC learning principles. 146 Bridge learns the Source MAC of the incoming frames and updates a 147 table with MAC/Interface information. While forwarding data packets, 148 bridge looks at this table to find the outgoing interface. 150 o "upstream" 152 Upstream is the direction from the DHCP Clients towards the edge 153 network. 155 3. Enhancements in Layer 2 Relay Agent 157 This section looks at various enhancements possible in Layer 2 Relay 158 Agents. Following issues are seen in a typical Layer 2 Relay 159 Agent[7] deployments 161 o Broadcasting DHCP requests on all interfaces 163 A normal Layer 2 Relay Agent[7] would broadcast a DHCP request 164 message to all its interfaces except on which the message was 165 received. Because of this, a DHCP request message is received by 166 those devices which would not be interested in it. Configuring an 167 uplink port that leads to a Layer 3 Relay Agent or DHCP server can 168 solve this issue. Some of the existing implementations [Mostly in 169 xDSL Access Concentrators] already supports this. 171 o Recovering Lease Information from Server 173 A Layer 2 Relay Agent[7] may snoop DHCP messages and maintain the 174 lease information. This information is lost if the Layer 2 Relay 175 Agent reboots. RFC 4388 suggests Leasequery mechanism to get the 176 lease information from the server. This document extends the same 177 for Layer 2 Relay Agent. 179 o Layer 3 Relay Agent broadcasting DHCP replies 181 Layer 3 Relay Agents generally broadcast DHCP replies towards Layer 2 182 Relay Agents. This will be received by those devices which would not 183 be interested in it. In general, broadcasts should be avoided in 184 Layer 2 networks. A new sub-option in Relay Agent Information option 185 can be used to solve this issue. To avoid broadcasts in case of 186 replies to Leasequery, a new option is defined. 188 3.1. Reference Network 190 Following network configuration is used as a reference network to 191 explain the various issues and solutions in Layer 2 Networks. This 192 network configuration is a typical Ethernet Aggregated Access 193 Network. 195 +-------+ 196 +-----+ | | 197 |Host1|-------| | 198 +-----+ |Access | 199 |Concen-|-----...... 200 +-----+ |trator | . 201 |Host2|-------| #1 | . +------+ 202 +-----+ | | . | | 203 +-------+ ----| | +--------+ 204 Trusted Layer 2 | | | DHCP | 205 DHCP Relay Agents |IPEdge|--.....---| Server | 206 +-------+ | | +--------+ 207 +-----+ | | .----| | 208 |Host3|-------| | . | | 209 +-----+ |Access | . +------+ 210 |Concen-|-----...... Layer 3 211 +-----+ |trator | Relay Agent 212 |Host4|-------| #2 | 213 +-----+ | | 214 +-------+ 216 Figure 1 218 4. Uplink port 220 A Layer 2 Relay Agent broadcasts the DHCP request messages [Messages 221 which are broadcast by Clients] to all the interfaces within the same 222 broadcast domain except the interface on which it was received. This 223 leads to flooding of DHCP messages which is unnecessary. Hence there 224 is a need to identify an "Uplink Port", through which the DHCP 225 request messages could be relayed towards the DHCP server. The 226 uplink port SHOULD be a configurable parameter. 228 5. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent 230 5.1. Protocol Extension Overview 232 A Layer 2 Relay Agent [7] may want to maintain the information of 233 outgoing interface, MAC Address, IP address and Lease information for 234 each DHCP Client. This information [MAC-IP-Interface Binding] could 235 be used to prevent MAC/IP Spoofing attacks. It could also be used 236 for bridging frames. Maintain this information makes a Layer 2 Relay 237 Agent vulnerable to the same issue [location/lease information lost 238 when Layer 2 Relay Agent gets rebooted] which has been addressed in 239 RFC 4388 [5] for Layer 3 networks. This document extends mechanism 240 proposed in [5] to address this issue for layer 2 networks. 242 When Layer 2 Relay Agent needs to bridge a frame, it MAY refer to 243 location/lease information to verify the IP address or MAC address. 244 If the location/lease information is not available, it can query DHCP 245 server to obtain the lease/location information using DHCPLEASEQUERY 246 message. 248 A Layer 2 Relay Agent can generate a DHCPLEASEQUERY [Query by IP 249 address, MAC address, client identifier [10]] with all the fields 250 properly populated as defined in RFC 4388 [5]. 252 5.2. Protocol Extension Details 254 5.2.1. Generating DHCPLEASEQUERY Message 256 When a data packet is received from a host, Layer 2 Relay Agent [7] 257 may verify if it has location/lease information for the source IP 258 address or source MAC address of data packet received. Similarly 259 when Layer 2 Relay Agent receives a data packet from the uplink port, 260 it may verify location/lease information for the destination IP 261 address or destination MAC address of the data packet. A Layer 2 262 Relay Agent would typically generate DHCPLEASEQUERY message if the 263 location/lease information is not available for the corresponding IP 264 address or MAC address assuming that it has lost the location/lease 265 information during last reboot. The DHCPLEASEQUERY message uses the 266 DHCP message format as described in RFC 2131 [2], and uses message 267 number 10 in the DHCP Message Type option (option 53). The 268 DHCPLEASEQUERY message has the following pertinent message contents: 270 o "giaddr" field MUST NOT be set. Though RFC 4388 [5] mandates that 271 an Access Concentrator [in Layer 3 mode] 'MUST' set the "giaddr" 272 field, this document suggest that a Layer 2 Relay Agent acting as 273 Transparent Bridge must not set the "giaddr" field. 275 o The Parameter Request List option (option 55) MUST include the 276 Relay Agent Information option (option 82). 278 o All the other options in Parameter Request List option (option 55) 279 SHOULD be set as per the interest of the requester. The options 280 of interest are likely to be the IP Address Lease Time option 281 (option 51) and possibly the Vendor class identifier option 282 (option 60). 284 o Source IP address of the DHCPLEASEQUERY message MUST be set to 285 0.0.0.0. 287 o Destination IP address of the DHCPLEASEQUERY message MUST be set 288 to broadcast address 255.255.255.255. 290 o Destination MAC address of the DHCPLEASEQUERY message MUST be set 291 to FF:FF:FF:FF:FF:FF. 293 o Source MAC address of the DHCPLEASEQUERY message MUST be set to 294 the hardware address of the interface on which this request is 295 sent out. 297 All other fields in MAC header, IP header and DHCP header SHOULD be 298 set as per RFC 2131 [2]. Additional details concerning different 299 query types are same as defined in RFC 4388 [5]. 301 5.2.2. Handling DHCPLEASEQUERY Message in Layer 3 Relay Agent 303 A Layer 3 Relay Agent conforming to this document, MUST process the 304 DHCP LEASEQUERY message received on its downstream interface similar 305 to the other DHCP messages. 307 5.2.3. Handling DHCPLEASEQUERY Message in DHCP Server 309 While generating a DHCP reply for a DHCPLEASEQUERY message, if the 310 message type is DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN, it MUST echo 311 back the Relay Agent Information received in the DHCPLEASEQUERY 312 message. If the message type is DHCPLEASEACTIVE, DHCP server 313 prepares the message as described in RFC 4388 and ignores the Relay 314 Agent Information option received in the DHCPLEASEQUERY message. 316 This document does not propose any other changes to RFC 4388 [5] for 317 handling DHCPLEASEQUERY message in DHCP server. 319 5.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent 321 When Layer 3 Relay Agent receives a DHCP Reply message with message 322 type as DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN, it 323 must have a way to identify if it had generated the leasequery 324 message or it had relayed it for a Layer 2 Relay Agent. 326 When the DHCP Reply message is received, a Layer 3 Relay Agent may 327 use 'giaddr' or 'state information' to identify the outgoing 328 interface. 330 5.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent 332 5.2.5.1. Handling DHCPLEASEUNASSIGNED Reply Message 334 When a DHCPLEASEUNASSIGNED message is received by a Layer 2 Relay 335 Agent, it means that there is no active lease for the IP address 336 present in the DHCP server, but that a server does in fact manage 337 that IP address. Layer 2 Relay Agent SHOULD cache this information 338 for later use. 340 5.2.5.2. Handling DHCPLEASEUNKNOWN Reply Message 342 When a DHCPLEASEUNKNOWN message is received by Layer 2 Relay Agent, 343 it SHOULD cache this information but only for a short lifetime, 344 approximately for 5 minutes as suggested in RFC 4388 [5]. 346 5.2.5.3. Handling DHCPLEASEACTIVE Reply Message 348 When Layer 2 Relay Agent receives a DHCPLEASEACTIVE message, it MUST 349 update its location/lease information. 351 5.2.5.4. Handling multiple responses for DHCPLEASEQUERY Message 353 A Layer 3 Relay Agent can forward a DHCPLEASEQUERY request to more 354 than one DHCP server and so a Layer 2 Relay Agent may receive more 355 than one reply for a DHCPLEASEQUERY message. 357 A Layer 2 Relay Agent MUST be able to process multiple responses for 358 a DHCPLEASEQUERY message. For example: 360 o It should be able to ignore all other responses once it receives 361 DHCPLEASEACTIVE response from one of the DHCP server. 363 5.2.5.5. Handling No Response to the DHCPLEASEQUERY Message 365 This has been discussed in detail in RFC 4388 [5] and the same holds 366 good for this document as well. 368 5.2.5.6. Handling DHCPLEASEQUERY messages not belonging to Layer 2 369 Relay Agent 371 o Since Layer 3 Relay Agent can broadcast the reply of 372 DHCPLEASEQUERY message, it will be processed by all the Layer 2 373 Relay Agents connected to the same LAN. Using either Transaction 374 Id or Relay Agent Information Option, a Layer 2 Relay Agent should 375 be able to correctly identify if the DHCPLEASEQUERY response is 376 meant for itself. Responses which do not belong to an Access 377 Concentrator MUST be silently discarded. 379 o In a typical bridged network, multiple Layer 2 Relay Agents may 380 share the same LAN. As a DHCPLEASEQUERY message generated by a 381 Layer 2 Relay Agent is broadcast, it will be received by other 382 Layer 2 Relay Agents also. Layer 2 Relay Agents MUST silently 383 discard any DHCPLEASEQUERY message received from the uplink port. 385 5.3. DHCPLEASEQUERY using Management IP address of Layer 2 Relay Agent 387 Though rare, but if a Layer 2 Relay Agent allows the use of 388 Management IP address for communication with DHCP server, it can 389 generate DHCPLEASEQUERY message as described in RFC 4388 instead of 390 using the extension of DHCPLEASEQUERY message described in this 391 document. 393 6. Prevention of flooding of DHCP replies from Layer 3 Relay Agent 395 Figure 1 shows an example where each access concentrator adds the 396 relay agent information option containing the port information of the 397 host sending the DHCP messages. IP edge router relays these DHCP 398 messages to the server. 400 RFC 2131[2] defines the meaning of the broadcast flag in the flags 401 field: it indicates whether the client wishes to receive the 402 DHCPOFFER and DHCPACK message as a broadcast or a unicast from the 403 DHCP server or the DHCP relay agent. In the scenario of Figure 1, 404 this means that the IP edge router will broadcast the DHCPOFFER and 405 DHCPACK messages to all access concentrators if the broadcast flag is 406 set. Whether or not broadcast is used between the Layer 3 Relay 407 Agent and the trusted Layer 2 Relay Agents depends on the behavior of 408 the DHCP clients. However broadcasts in the aggregation network are 409 to be avoided. So it is preferred to always use unicast from the 410 Layer 3 DHCP relay agent to the trusted layer 2 DHCP relay agent. 411 Between the trusted layer 2 DHCP relay agent and the host, broadcast 412 flag has to be honored. 414 Even though the DHCP clients are not setting the broadcast flag, it 415 is still possible that the DHCPOFFER and DHCPACK messages from the 416 DHCP server are sent to all access concentrators. This is when the 417 access concentrator implements a MAC concentration or MAC translation 418 function. When such a MAC operation is performed, the access 419 concentrator replaces the source MAC address of all upstream frames 420 by another MAC address, for instance with its own MAC address. In 421 this case, the MAC addresses of the hosts will remain unknown in the 422 network between the trusted layer 2 DHCP relay agent and the Layer 3 423 DHCP relay agent. Hence all unicast messages sent by the Layer 3 424 DHCP relay agent using this MAC address will be flooded to all access 425 concentrators. 427 6.1. Flooding of DHCP reply messages from Layer 3 Relay Agent 429 To overcome these two previously mentioned problems, a new sub-option 430 'unicast-address' is defined for the Relay Agent Information option. 431 With this sub-option, the Layer 3 Relay Agent will always unicast the 432 messages towards the trusted Layer 2 Relay Agent with a hardware 433 address that is known in the network. 435 6.1.1. Unicast-Address Sub-Option 437 6.1.1.1. Unicast-Address Sub-Option Definition 439 The unicast-address sub-option of the relay-agent-information option 440 MAY be used by any trusted layer 2 DHCP relay agent such that the 441 Layer 3 relay agent unicasts the messages from the DHCP server with a 442 hardware address known in the network. The hardware address in the 443 unicast-address sub-option MUST be an address that can be used to 444 send unicast packets towards the client. 446 The format of the option is as follows: 448 SubOpt Len [Hardware address details] 449 +------+------+----------+-------------+ 450 | X | Len | htype(1) | hwaddr | 451 +------+------+----------+-------------+ 453 Figure 2 455 o 'X' is the sub-option code which needs to be allocated by IANA. 457 o 'Len' represents the length of the 'value' which includes both 458 htype and hwaddr fields 460 o "htype" represents Hardware type. See the 'ARP parameters' 461 maintained in the database referenced by Assigned numbers RFC 3232 462 [6]. 464 o "hwaddr" is the unicast hardware address. 466 6.1.1.2. Layer 3 Relay Agent Behavior 468 When Layer 3 DHCP Relay Agent receives a DHCP packet with unicast- 469 address sub-option added, it SHOULD unicast that message towards the 470 layer 2 DHCP relay agent with destination address set to the value 471 contained in the hwaddr field of the sub-option. A Layer 3 relay 472 agent that supports this option SHOULD ignore the broadcast flag if 473 this sub-option is present in the DHCP message. In the absence of 474 this sub-option a Layer 3 relay agent SHOULD behave as earlier and 475 forward the message as per the broadcast bit set in the message. 477 6.1.1.3. Layer 2 Relay Agent Behavior 479 The Layer 2 Relay Agent may add this sub-option only in the case when 480 the intermediate network elements do MAC learning ensuring that when 481 the Layer 3 relay agent unicasts the messages to this hardware 482 address, the messages will arrive at the same layer 2 DHCP relay 483 agent. The Layer 2 DHCP relay agent SHOULD still be able to receive 484 broadcast messages from the Layer 3 DHCP relay agent in order to 485 remain compatible with relay agents that do not support the unicast- 486 address sub-option. 488 Layer 2 DHCP relay agent MUST always process the broadcast flag as 489 described in [RFC2131]. This means that it is possible that the 490 layer 2 DHCP relay agents receive a unicast message from the Layer 3 491 DHCP relay agent, and that it has to forward it as a broadcast. It 492 is also possible that the unicast message stays unicast and that only 493 the destination MAC address has to be changed to the content of the 494 chaddr field. 496 If the layer 2 DHCP relay agent performs a MAC address concentration 497 function, it SHOULD add the unicast-address sub-option to all 498 upstream DHCP messages in order to avoid flooding of unknown 499 destination MAC addresses. On the other hand, if the layer 2 DHCP 500 relay agent acts as a bridge, it MAY add the unicast-address sub- 501 option only to the DHCPDISCOVER and DHCPREQUEST messages as these are 502 the only messages which may result in a downstream broadcast. 504 6.1.1.4. DHCP Server Behavior 506 Although rather unlikely, it is also possible that no Layer 3 DHCP 507 relay agent is configured in the network and that the DHCP server has 508 layer 2 connectivity with the trusted layer 2 DHCP relay agent. In 509 this case the DHCP server, supporting the unicast address option, 510 SHOULD act as a Layer 3 DHCP relay agent would do. 512 So if the DHCP server receives DHCP messages with giaddr set to zero 513 and a valid unicast-address sub-option, the DHCP server SHOULD ignore 514 the broadcast flag and unicast the DHCP messages to the hardware 515 address in the unicast-address sub-option. The DHCP Server SHOULD 516 also include this sub-option in the option 82 of its reply. 518 6.1.1.5. Example Scenarios 520 o The trusted layer 2 DHCP relay agent acts as a bridge. In such a 521 case, the layer 2 DHCP relay agent puts the MAC address in the 522 chaddr field of DHCP messages in the unicast-address sub-option. 523 The Layer 3 DHCP relay agent will then send the DHCPOFFER and 524 DHCPACK messages from the DHCP server as unicast to the layer 2 525 DHCP relay agent, which converts the message to broadcast if the 526 broadcast flag is set. 528 o The Layer 2 Relay Agent does MAC translation/concentration 529 function. In this case layer 2 DHCP relay agent adds unicast- 530 address sub-option which contains the MAC address that the Layer 2 531 DHCP Relay Agent is using for upstream frames. 533 6.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 Relay Agent 535 The above suboption would not work for reply message for a LEASEQUERY 536 request because the reply message type other than LEASEACTIVE for a 537 LEASEQUERY message will not have Relay Agent Information option. 538 This can be resolved by creating a new option which is echoed back by 539 the DHCP server in DHCP reply messages for a LEASEQUERY message. 541 This document need the definition of following new option for DHCP 542 packet beyond those defined by [RFC2131] and [RFC2132]. See also 543 Section 9, IANA Considerations. 545 6.2.1. Relay Agent Hardware Address option 547 "relay-agent-hwaddr" option allows a Layer 3 Relay agent to unicast a 548 DHCP reply for a DHCPLEASEQUERY message to the Layer 2 Relay Agent 549 which had generated the DHCPLEASEQUERY message. The code for this 550 option need to be allocated by IANA. 552 code [Hardware address details] 553 +------+------+------------+------------+ 554 | X | len | htype (1) | hwaddr | 555 +------+------+------------+------------+ 557 Figure 3 559 In the above option: 561 o 'X' need to be allocated by IANA. 563 o "len" field contains the length of the "Hardware address details" 564 and can be used to deduce length of "hwaddr" field. 566 o "htype" represents Hardware type. See the 'ARP parameters' 567 maintained in the database referenced by Assigned numbers RFC 568 3232[4]. 570 o "hwaddr" is Relay Agent hardware address. 572 6.2.1.1. Layer 2 Relay Agent Behavior 574 Layer 2 Relay agents which has the capability to receive a unicast 575 reply for DHCPLEASEQUERY message SHOULD add option "relay-agent- 576 hwaddr" in DHCPLEASEQUERY message. Option "relay-agent-hwaddr" 577 SHOULD be populated based on the interface on which this request is 578 sent out. 580 6.2.1.2. Layer 3 Relay Agent Behavior 582 While forwarding a reply for Lease Query request, a Layer 3 Relay 583 Agent MUST look for "relay-agent-hwaddr" option [code 'X'] in the 584 DHCP reply and if it finds this option, it SHOULD extract the 585 hardware address and use it to unicast the reply to the Layer 2 Relay 586 Agent. 588 DHCP reply message with message type 'DHCPLEASEACTIVE' can have Relay 589 Agent Information option which may have 'unicast-address' sub-option. 590 In such a case, both 'relay-agent-hwaddr' option and 'unicast- 591 address' sub-option MAY be present. A Layer 3 Relay Agent conforming 592 to this document MUST always prefer hardware address extracted from 593 'unicast-address' sub-option of Relay Agent Information option over 594 'relay-agent-hwaddr' option. 596 6.2.1.3. DHCP server Behavior 598 DHCP servers conforming to this document MUST echo the entire 599 contents of the "relay-agent-hwaddr" option [code 'X'] in the reply 600 for a DHCPLEASEQUERY request. DHCP servers SHALL NOT place the 601 echoed "relay-agent-hwaddr" option in the overloaded sname or file 602 fields. If a server is unable to copy a full "relay-agent-hwaddr" 603 option into a response, it SHALL send the response without the 604 "relay-agent-hwaddr" option, and SHOULD increment an error counter 605 for the situation. 607 DHCP Server MUST NOT add or echo back this option in any other DHCP 608 reply messages it generates. 610 7. Acknowledgments 612 Stig Venaas, Wojciech Dec, Richard Pruss and Andre Kostur provided 613 good feedback on this memo. A detailed discussion with Ted Lemon, 614 Andre Kostur on how a Layer 3 Relay Agent can unicast the various 615 DHCP replies to a Layer 2 Relay Agent was very helpful. 617 The authors would like to acknowledge Ludwig Pauwels and Paul 618 Reynders for their feedback on 'unicast-address' sub-option. Thanks 619 to Patrick Mensch who contributed for the initial version of the 620 document which had defined 'unicast-address' sub-option. 622 Description of authentication for DHCPLEASEQUERY messages in security 623 section are taken from RFC 4388. 625 8. Security Consideration 627 o Layer 3 Relay Agent that relays the DHCP message are essentially 628 DHCP clients for the purposes of the DHCP messages relayed by 629 Layer 2 Relay Agent. Layer 3 Relay Agent MUST relay a DHCP 630 message only when it comes from a trusted circuit. Thus, 631 RFC3118[4] is an appropriate mechanism for DHCP messages relayed 632 by Layer 2 Relay Agent. 634 o This document suggest new option which MAY be added by Layer 2 635 Relay Agents in DHCP message. If a server finds this new option 636 included in a received message, the server MUST compute any hash 637 function as if the option were NOT included in the message without 638 changing the order of options. Whenever the server sends back 639 this option to a relay agent, the server MUST not include this 640 option in the computation of any hash function over the message. 642 9. IANA Considerations 644 This document needs IANA to provide a unique number for the new 645 option to carry Hardware address of a Relay Agent. Please refer to 646 section 6.1 for more details. 648 This document also needs IANA to provide a unique number for the 649 following new suboptions in Relay Agent Information option [Option 650 82]: 652 o To carry the hardware address of a Relay Agent. Please refer to 653 section 6.2 for more details. 655 10. References 657 10.1. Normative Reference 659 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 660 Levels", BCP 14, RFC 2119, March 1997. 662 [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 663 March 1997. 665 [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 666 January 2001. 668 [4] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", 669 RFC 3118, June 2001. 671 [5] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol 672 (DHCP) Leasequery", RFC 4388, February 2006. 674 [6] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. 676 [7] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent Information", 677 draft draft-ietf-dhc-l2ra-00.txt, February 2008. 679 10.2. Informative Reference 681 [8] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", 682 RFC 951, September 1985. 684 [9] Wimer, W., "Clarifications and Extensions for the Bootstrap 685 Protocol", RFC 1542, October 1993. 687 [10] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 688 Extensions", RFC 2132, March 1997. 690 Authors' Addresses 692 Bharat Joshi 693 Infosys Technologies Ltd. 694 44 Electronics City, Hosur Road 695 Bangalore 560 100 696 India 698 Email: bharat_joshi@infosys.com 699 URI: http://www.infosys.com/ 701 Pavan Kurapati 702 Infosys Technologies Ltd. 703 44 Electronics City, Hosur Road 704 Bangalore 560 100 705 India 707 Email: pavan_kurapati@infosys.com 708 URI: http://www.infosys.com/ 710 Mukund Kamath 711 Infosys Technologies Ltd. 712 44 Electronics City, Hosur Road 713 Bangalore 560 100 714 India 716 Email: mukund_kamath@infosys.com 717 URI: http://www.infosys.com/ 719 Stefaan De Cnodder 720 Alcatel-Lucent 721 Francis Wellesplein 1, 722 B-2018 Antwerp 723 Belgium 725 Email: stefaan.de_cnodder@alcatel-lucent.be 726 URI: http://www.alcatel-lucent.com 728 Intellectual Property Statement 730 The IETF takes no position regarding the validity or scope of any 731 Intellectual Property Rights or other rights that might be claimed to 732 pertain to the implementation or use of the technology described in 733 this document or the extent to which any license under such rights 734 might or might not be available; nor does it represent that it has 735 made any independent effort to identify any such rights. Information 736 on the procedures with respect to rights in RFC documents can be 737 found in BCP 78 and BCP 79. 739 Copies of IPR disclosures made to the IETF Secretariat and any 740 assurances of licenses to be made available, or the result of an 741 attempt made to obtain a general license or permission for the use of 742 such proprietary rights by implementers or users of this 743 specification can be obtained from the IETF on-line IPR repository at 744 http://www.ietf.org/ipr. 746 The IETF invites any interested party to bring to its attention any 747 copyrights, patents or patent applications, or other proprietary 748 rights that may cover technology that may be required to implement 749 this standard. Please address the information to the IETF at 750 ietf-ipr@ietf.org. 752 Disclaimer of Validity 754 This document and the information contained herein are provided on an 755 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 756 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 757 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 758 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 759 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 760 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 762 Copyright Statement 764 Copyright (C) The IETF Trust (2008). This document is subject to the 765 rights, licenses and restrictions contained in BCP 78, and except as 766 set forth therein, the authors retain all their rights. 768 Acknowledgment 770 Funding for the RFC Editor function is currently provided by the 771 Internet Society.