idnits 2.17.1 draft-ietf-dhc-l2ra-06.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 -- 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 (January 25, 2012) is 4474 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2131' is defined on line 521, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC B. Joshi 3 Internet-Draft Infosys Ltd. 4 Intended status: Informational P. Kurapati 5 Expires: July 28, 2012 Juniper Networks 6 January 25, 2012 8 Layer 2 Relay Agent Information 9 draft-ietf-dhc-l2ra-06.txt 11 Abstract 13 In some networks, DHCP servers rely on Relay Agent Information option 14 appended by Relay Agents for IP address and other parameter 15 assignment policies. This works fine when end hosts are directly 16 connected to Relay Agents. In some network configurations, one or 17 more Layer 2 devices may reside between DHCP clients and Relay agent. 18 In these network scenarios, it is difficult to use the Relay Agent 19 Information option for IP address and other parameter assignment 20 policies effectively. So there is a need for the device that is 21 closest to the end hosts to append a Relay Agent Information option 22 in DHCP messages. These devices are typically known as Layer 2 Relay 23 Agents. 25 This document aims to describe the network scenarios where a Layer 2 26 Relay Agent is in use and also how it handles DHCP messages. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 28, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 4 65 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 5 66 4.1. DHCP server and client on same subnet . . . . . . . . . . 5 67 4.1.1. Client-server interaction . . . . . . . . . . . . . . 5 68 4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 7 69 4.2. Multiple DHCP server and Client on same subnet . . . . . . 7 70 4.2.1. Client-server interaction . . . . . . . . . . . . . . 8 71 4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 8 72 4.3. DHCP server on another subnet with one Layer 3 Relay 73 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.3.1. Client-server interaction . . . . . . . . . . . . . . 9 75 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 11 76 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 81 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 DHCP Relay Agents eliminate the necessity of having a DHCP server on 87 each physical network. Relay Agents populate the 'giaddr' field and 88 also append the 'Relay Agent Information' option to the DHCP 89 messages. DHCP servers use this option for IP address and other 90 parameter assignment policies. These DHCP Relay Agents are typically 91 an IP routing aware device and are referred as Layer 3 Relay Agents. 93 In some network configurations, there is a need for Layer 2 devices 94 to append the Relay Agent Information option as they are closer to 95 the end hosts. These Layer 2 devices are typically operating only as 96 bridges for the network and may not have an IPv4 address on the 97 network in question. Lacking a valid IPv4 source address, they 98 cannot relay packets directly to a DHCP server located on another 99 network. These Layer 2 devices append the Relay Agent Information 100 option and broadcast the DHCP message. A Layer 3 Relay Agent relays 101 it to the DHCP server. 103 This document provides information about where a Layer 2 Relay Agent 104 fits in and how it is used. This document also looks at various 105 network scenarios with Layer 2 Relay Agents and discusses various 106 issues caused by the introduction of Layer 2 Relay Agents. 108 2. Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 This document uses the following terms: 116 o "DHCP client" 118 A DHCP client is an Internet host using DHCP to obtain configuration 119 parameters such as a network address. 121 o "Layer 3 Relay Agent" 123 A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap 124 Protocol (BOOTP) and DHCP messages between clients and servers 125 residing on different subnets, per [RFC0951] and [RFC1542]. 127 o "BRAS" 129 BRAS or Broadband Remote Access Server is a network element which 130 acts as an aggregation device terminating end user sessions. BRAS is 131 usually the first IP edge device in a Layer 2 Access Network 132 architecture. 134 o "DHCP server" 136 A DHCP server is an Internet host that returns configuration 137 parameters to DHCP clients. 139 o "Unnumbered Interfaces" 141 An interface with no IP address associated with it. IP packets 142 generated from this interface may use a local loopback address which 143 may be shared with other unnumbered interfaces. 145 3. Need of Layer 2 Relay Agent 147 A Layer 2 device intercepts DHCP messages for the following reasons: 149 1. In some network deployments like xDSL, the subscriber aggregation 150 devices (also known as Access Concentrator or a DSLAM in case of 151 DSL) are configured to act as bridges. As these devices are 152 closest to the subscriber, they are in the best position to 153 provide a unique Relay Agent Information option to enforce 154 policies in the DHCP server. 156 2. In some network deployments, a Layer 2 device can append Relay 157 Agent Information in DHCP messages so that it can use this 158 information to forward the DHCP Replies to the specific port on 159 which the request was received. 161 3. In some networks, the Layer 2 Switch which is closest to the end 162 users, snoops the DHCP messages. These switches extract DHCP 163 Lease Information and use this information to install packet 164 filters. This helps in preventing Layer 2 and Layer 3 spoofing 165 attempts by the subscribers. A point to note here is that in 166 cases where switches maintain the Lease Information, they have to 167 intercept unicast DHCP messages as well to keep this information 168 up to date. 170 4. NOTE: Please send an email to the authors if you are aware of any 171 other functionality of Layer 2 Relay Agent. It will be helpful 172 in updating this list. This note will be removed before moving 173 this draft for IESG review. 175 4. Layer 2 Relay Agent in various network scenarios 177 This section describes the various network scenarios where a Layer 2 178 Relay Agent fits in. It also describes how it handles different DHCP 179 messages. 181 4.1. DHCP server and client on same subnet 183 In certain network configurations, a DHCP server may reside on the 184 same subnet as the DHCP clients. A Layer 2 aggregation device 185 resides between the DHCP clients and DHCP server. The following 186 points describe how this Layer 2 device handles various DHCP messages 187 if it acts as a Layer 2 Relay Agent. Figure 1 shows a typical 188 network setup. 190 +--------+ 191 | End | +--------+ | 192 | Host#1 +-----------| | | +-----------+ 193 +--------+ | Layer +-----| | | 194 | 2 | +-----| DHCP | 195 +--------+ | device | | | Server#1 | 196 | End +-----------| #1 | | +-----------+ 197 | Host#2 | +--------+ | 198 +--------+ | 199 | 200 +--------+ | 201 | End | +--------+ | 202 | Host#3 +-----------| | | 203 +--------+ | Layer +-----| 204 | 2 | | 205 +--------+ | device | | 206 | End +-----------| #2 | 207 | Host#n | +--------+ 208 +--------+ 210 Figure 1 212 4.1.1. Client-server interaction 214 The following summary of protocol message exchanges between clients 215 and DHCP servers describes how they are handled in a Layer 2 Relay 216 Agent. 218 1. The client (End Host #1) broadcasts a DHCPDISCOVER message on its 219 local physical subnet. Layer 2 Relay Agent #1 intercepts this 220 message, appends the Relay Agent Information option and 221 broadcasts it to all the ports except the one on which it was 222 received. The Relay Agent Information option could be created as 223 suggested in RFC 3046 [RFC3046]. The Layer 2 Relay Agent does 224 not set the 'giaddr' field. 226 2. Layer 2 device #2 would also receive this DHCPDISCOVER message 227 from Layer 2 device #1. If it is configured as Layer 2 Relay 228 Agent, it intercepts this message but does not append another 229 Relay Agent Information option to the message. It may discard 230 this message if it is coming from an untrusted entity. 231 Otherwise, it will broadcast this on all the ports except the one 232 on which the message was received. 234 3. The DHCP server responds with a DHCPOFFER message after applying 235 its local policies. It echoes back the Relay Agent Information 236 option in the DHCPOFFER message. The DHCP server can either 237 unicast the reply to the MAC address of End Host #1 or broadcast 238 the reply. If the reply is broadcast, the Layer 2 Relay Agent 239 intercepts this message and removes the Relay Agent Information 240 option. It identifies the outgoing port using the Relay Agent 241 Information option and forwards the message to the identified 242 interface. A Layer 2 Relay Agent may be configured to intercept 243 unicast DHCP messages. In such a case, the Layer 2 Relay Agent 244 intercepts unicast DHCP messages and handles them similar to 245 broadcast messages. 247 4. The same DHCPOFFER message will be received by Layer 2 Device #2. 248 If it is configured as Layer 2 Relay Agent, it broadcasts this 249 message normally without removing the Relay Agent option since it 250 had not added the same. A Layer 2 Relay Agent uses the Relay 251 Agent Information option to find out if it had appended it to the 252 request message. 254 5. The client receives this DHCPOFFER message and it broadcasts a 255 DHCPREQUEST message. Layer 2 Relay Agent #1 handles this message 256 similar to how it handles a DHCPDISCOVER message. 258 6. The server receives the DHCPREQUEST message from the client and 259 responds with a DHCPACK/DHCPNAK message. If DHCP server 260 broadcasts the DHCPACK message, Layer 2 Relay Agent processes it 261 similar to a DHCPOFFER message. If DHCP server unicasts the 262 DHCPACK message to the client, Layer 2 Relay agent intercepts the 263 same and processes the message similar to the broadcasted DHCPACK 264 message. 266 7. The Layer 2 Relay Agent processes a DHCPNAK messages similar to a 267 DHCPACK message. 269 8. The Layer 2 Relay Agent processes a DHCPDECLINE message similar 270 to a DHCPDISCOVER message. 272 9. The DHCP client can unicast some of the DHCP messages. The Layer 273 2 Relay Agent may or may not intercept these messages based on 274 internal configuration. If Layer 2 Relay Agents intercept these 275 messages, they append a Relay Agent Information option and 276 forward the message towards the DHCP server. They also intercept 277 the reply messages and remove the Relay Agent Information option 278 before forwarding them. 280 4.1.2. Issues due to introduction of Layer 2 Relay Agent 282 1. A DHCP server should be able to handle a DHCP message that 283 contains the Relay Agent Information option without 'giaddr' 284 field set in the message. Some existing DHCP server 285 implementations do not echo back the Relay Agent Information 286 option if giaddr is not set. This may lead to issues at Layer 2 287 Relay Agents as they will not be able to identify the outgoing 288 port correctly and would broadcast it to all ports. Some Layer 2 289 Relay Agents discard the reply messages if they do not find a 290 Relay Agent Information option in a DHCP reply. 292 2. There is a case when the DHCP client receives a unicast reply 293 message like DHCPACK with a Relay Agent Information option. This 294 can happen only when the DHCP server unicasts the DHCPACK message 295 and the Layer 2 Relay Agent is not configured to intercept 296 unicast messages. Most of the Layer 2 Relay Agents, that are 297 deployed today, are configured to intercept the unicast DHCP 298 messages and hence this behaviour may not be seen in the real 299 world deployments. 301 3. A DHCP server should be able to handle a unicast DHCP message 302 containing a Relay Agent Information option. Some existing DHCP 303 server implementations do not echo back the Relay Agent 304 Information option in responses to unicast messages. 306 4.2. Multiple DHCP server and Client on same subnet 308 In certain network scenarios, there could be multiple DHCP servers on 309 the same subnet. Figure 2 shows a typical network setup. 311 +--------+ 312 | End | +--------+ | 313 | Host#1 +-----------| | | +-----------+ 314 +--------+ | Layer +-----| | | 315 | 2 | +-----| DHCP | 316 +--------+ | device | | | Server#1 | 317 | End +-----------| #1 | | +-----------+ 318 | Host#2 | +--------+ | 319 +--------+ | 320 | +-----------+ 321 +--------+ | | DHCP | 322 | End | +--------+ |-----| Server #2 | 323 | Host#3 +-----------| | | | | 324 +--------+ | Layer +-----| +-----------+ 325 | 2 | | 326 +--------+ | device | 327 | End +-----------| #2 | 328 | Host#n | +--------+ 329 +--------+ 331 Figure 2 333 4.2.1. Client-server interaction 335 The message exchanges are the same as explained in 4.1.1. However, 336 due to the introduction of multiple DHCP servers the below additional 337 message exchange may happen. 339 1. When Host #1 sends DHCPDISCOVER, it will be received by both DHCP 340 Servers connected to Layer 2 Relay Agent #1 and both servers will 341 respond with a DHCPOFFER. So instead of one DHCPOFFER message, 342 the Layer 2 Relay Agent would receive two messages. The 343 processing of DHCP messages in the Layer 2 Relay Agents remains 344 the same. 346 4.2.2. Issues due to introduction of Layer 2 Relay Agent 348 1. Layer 2 relay agents which maintain persistent state, such as 349 updating filters or client registration, must be prepared to 350 handle potentially conflicting responses from different DHCP 351 Servers. Some Layer 2 relay agents may use "the most recent DHCP 352 packet" to update this persistent state but this may not 353 necessarily reflect the actual state of the client. The above is 354 possible when two DHCP servers acknowledge the request of a DHCP 355 client with the same address but different lease times. In this 356 case, if the relay agent selects the server reply with the 357 shorter lease time, it would expire its state possibly before the 358 client even has a chance to renew it. Therefore, Layer 2 relay 359 agents SHOULD select the longest lease time of two conflicting 360 but similar replies, by discarding replies that shorten the lease 361 time. 363 2. Other issues are the same as described in section 4.1.2. 365 4.3. DHCP server on another subnet with one Layer 3 Relay Agent 367 In certain network scenarios, there could be a Layer 3 Relay Agent 368 which relays the DHCP messages from one subnet to a DHCP server on 369 another subnet and vice versa. In typical deployments, the Access 370 Concentrator acts as Layer 2 Relay Agent and the IP edge device (BRAS 371 or IP Services Switch) acts as Layer 3 Relay Agent. 373 +--------+ 374 | End | +--------+ | | 375 | Host#1 +--------| | | +-----------+ | 376 +--------+ | Layer +-----| | | | 377 | 2 | +--| Layer 3 |----| 378 +--------+ | device | | | Relay | | 379 | End +--------| #1 | | | Agent #1 | | 380 | Host#2 | +--------+ | +-----------+ | +---------+ 381 +--------+ | | | | 382 | +--| DHCP | 383 +--------+ | | | Server | 384 | End | +--------+ | | | #1 | 385 | Host#3 +--------| | | +---------+ 386 +--------+ | Layer +-----| 387 | 2 | | 388 +--------+ | device | | 389 | End +--------| #2 + 390 | Host#n | +--------+ 391 +--------+ 393 Figure 3 395 4.3.1. Client-server interaction 397 As far as DHCP message processing is concerned, the presence of Layer 398 3 Relay Agents is transparent to Layer 2 Relay Agents. So all the 399 messages are handled in the same way as defined in section 4.1.1 for 400 the Layer 2 Relay Agent. 402 The Layer 3 Relay Agents are configured to trust/untrust an entity 403 based on specific criteria (For example : VLAN/interface on which the 404 message was received). If the DHCP message coming from the client 405 has a relay agent option present, the Layer 3 Relay Agent checks if 406 it is coming in on a trusted interface. If it is coming from a 407 trusted interface, it will set the 'giaddr' field to one of the local 408 interface addresses and unicasts it to the configured server(s). If 409 the message is coming from an untrusted interface, the Layer 3 Relay 410 Agent discards the message. 412 Typical message processing in this scenario is given below. 414 1. When the client sends a DHCPDISCOVER message, the Layer 2 Relay 415 Agent forwards it as described in section 4.1.1. The Layer 3 416 Relay Agent receives this message and finds that it contains a 417 Relay Agent Information option. It verifies whether the message 418 is from a trusted entity or not. If it is from a trusted entity, 419 the Layer 2 Relay Agent populates the 'giaddr' field as it deems 420 appropriate and relays the message to the DHCP server. 422 2. The DHCP Server processes the message in the same way as 423 described in section 4.1 and unicasts the DHCPOFFER to the Layer 424 3 Relay Agent on the address specified in the 'giaddr' field. 426 3. The Layer 3 Relay Agent processes the DHCPOFFER and identifies 427 the outgoing interface. It resets the 'giaddr' field and 428 broadcasts the message on the identified outgoing interface. 430 4. The client receives the DHCPOFFER and generates a DHCPREQUEST 431 message. The Layer 2 Relay Agent processes it as described in 432 section 4.1.1. The Layer 3 Relay Agent receives the DHCPREQUEST 433 message and processes it similar to the DHCPDISCOVER message 434 described in step #1. 436 5. The DHCP Server processes the DHCPREQUEST and unicasts the DHCP 437 ACK message to the layer 3 Relay Agent if the 'broadcast' flag is 438 set, or directly to the client if the 'broadcast' flag is not 439 set. If the Layer 3 Relay Agent receives this message, it 440 processes it similar to the DHCPOFFER as described in step #3. 442 6. In the case of unicast messages (For example: DHCPREQUEST in case 443 of DHCPRENEW), a Layer 3 Relay Agent may or may not intercept the 444 message. If it intercepts a unicast DHCP request message, it 445 populates the 'giaddr' field and relays the message to the DHCP 446 server. When the DHCP server sends a reply for this request 447 message, it resets the 'giaddr' field, identifies the outgoing 448 interface, and forwards the reply on the identified interface. 450 4.3.2. Issues due to introduction of Layer 2 Relay Agent 452 Though the processing of DHCP messages remains the same in Layer 2 453 Relay Agents, we see some more issues when a Layer 3 Relay Agent is 454 present to relay the DHCP messages to the DHCP server. 456 1. When a Layer 2 Relay Agent is configured to intercept unicast 457 messages as well, it appends a Relay Agent Information option 458 before forwarding the request message. A Layer 3 Relay Agent may 459 not intercept these unicast messages. Due to this, a DHCP server 460 may not echo back the Relay Agent Information option because the 461 'giaddr' field is not populated. 463 2. Existing Layer 3 Relay Agents populate the 'giaddr' field with 464 the IP address of the interface on which the request was 465 received. This helps the Layer 3 Relay Agent to identify the 466 outgoing interface for the DHCP replies. In some cases, a Layer 467 3 Relay Agent may use unnumbered interfaces. In this case, it 468 has to use a system wide IP address to populate the 'giaddr' 469 field. Due to this, it becomes difficult to identify the correct 470 outgoing interface for the messages received from the DHCP 471 server. In these cases, some existing Layer 3 Relay Agent 472 implementations maintain an internal state for each DHCP message 473 and use this state to identify the outgoing interface. 475 3. The DHCP server uses certain parameters to differentiate the 476 RENEW and REBIND state of a client. A DHCPREQUEST without 477 'giaddr' and the Relay Agent Information option is treated as 478 RENEW request while DHCPREQUEST with 'giaddr' and Relay Agent 479 Information option is treated as REBIND request. In a network 480 configuration where both Layer 2 Relay Agent and Layer 3 Relay 481 Agent are configured to intercept the unicast DHCP messages, the 482 DHCP server will receive RENEW request with Relay Agent 483 Information option and 'giaddr' field set. Since REBIND request 484 will also have Relay Agent Information option and 'giaddr' field 485 set, it becomes difficult for the DHCP server to differentiate 486 between RENEW and REBIND requests. 488 5. Acknowledgements 490 This document is the result of a discussion on DHC WG mailing list. 491 Thanks to David W. Hankins and Michael Wacker for providing inputs on 492 some of the existing implementations. Thanks to Ted Lemon, Mukund 493 Kamath, Alfred Hoenes, Ramesh and Stefaan De Cnodder for reviewing 494 the draft and providing valuable suggestions. 496 6. Security Considerations 498 o A Layer 2 Relay Agent should always be configured to identify a 499 trustable entity so that it appends a Relay Agent Information 500 option to a DHCP message coming from a trustable entity and 501 forwards it. If a DHCP message is received from a non-trustable 502 entity, the Layer 2 Relay Agent should discard it and may report 503 to the administrator. 505 o The introduction of Layer 2 Relay Agents does not introduce any 506 new security issues. Security issues pertaining to Relay Agents 507 in general apply to Layer 2 Relay Agents as well. 509 7. IANA Considerations 511 This document does not introduce any new namespaces for the IANA to 512 manage and does not request any new code point assignments. 514 8. References 516 8.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, March 1997. 521 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 522 RFC 2131, March 1997. 524 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 525 RFC 3046, January 2001. 527 8.2. Informative Reference 529 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 530 September 1985. 532 [RFC1542] Wimer, W., "Clarifications and Extensions for the 533 Bootstrap Protocol", RFC 1542, October 1993. 535 Authors' Addresses 537 Bharat Joshi 538 Infosys Ltd. 539 44 Electronics City, Hosur Road 540 Bangalore 560 100 541 India 543 Email: bharat_joshi@infosys.com 544 URI: http://www.infosys.com/ 546 Pavan Kurapati 547 Juniper Networks 548 Embassy Prime Buildings, C.V. Raman Nagar 549 Bangalore 560 093 550 India 552 Email: kurapati@juniper.net 553 URI: http://www.juniper.net/