idnits 2.17.1 draft-kurapati-dhc-relay-chaining-dhcpv4-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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: There may be a network scenario when there are multiple Layer 2 Relay Agents configured between DHCP clients and Layer 3 Relay Agent. In this case, as described above, each Layer 2 Relay Agent MUST add 'Relay Agent Information' option and MUST not add 'peer-address' sub-option in it. A Layer 2 Relay Agent can use this Relay Agent Information option while relaying the DHCP Reply message back to the DHCP client. -- 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 (July 7, 2009) is 5407 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Option 82' is mentioned on line 366, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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: January 8, 2010 Infosys Technologies Ltd. 5 July 7, 2009 7 Relay Chaining in DHCPv4 8 draft-kurapati-dhc-relay-chaining-dhcpv4-02.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 8, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 DHCP Relay Agents eliminate the necessity of having a DHCP server on 47 each physical network. In certain network configurations, a DHCP 48 server may be multiple subnets away from the DHCP client and multiple 49 Relay Agents may be configured to relay DHCP messages to and from 50 DHCP client. Such configuration can be supported only when each 51 Relay Agent adds certain Information to DHCP messages before relaying 52 them. This additional information helps in relaying the DHCP reply 53 back to the DHCP client through the same path. This mechanism is 54 referred as Relay Chaining. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. New sub-options . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. peer-relay-agent-information Sub Option . . . . . . . . . 6 62 3.2. peer-address Sub Option . . . . . . . . . . . . . . . . . 6 63 4. Relay Chaining . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. Handling DHCP messages in Relay Agent . . . . . . . . . . 7 65 4.1.1. Handling Broadcast DHCP messages . . . . . . . . . . . 8 66 4.1.2. Handling Unicast DHCP messages . . . . . . . . . . . . 9 67 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 10 68 6. Special Scenarios . . . . . . . . . . . . . . . . . . . . . . 11 69 6.1. Multiple Layer 2 Relay Agents between DHCP client and 70 Layer 3 Relay Agent . . . . . . . . . . . . . . . . . . . 11 71 6.2. One or multiple Layer 2 Relay Agents between two Layer 72 3 Relay Agents . . . . . . . . . . . . . . . . . . . . . . 11 73 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 12 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14 77 9.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 In some network configurations, DHCP server and clients are separated 83 by multiple Relay Agents. One such case is the network configuration 84 where Access Concentrators operate in Transparent Bridging mode as 85 described in document [layer2-relay-agent]. In such configurations, 86 there are situations where each of those relay agents need to add 87 relay-agent-information to the DHCP messages received on its 88 downstream interface. Relay chaining support in DHCPv4 will help in 89 solving following problems: 91 o In some deployments, Layer 3 Relay Agent uses unnumbered 92 interfaces. When these Layer 3 Relay Agents are used along with 93 Layer 2 Relay agents as described in [layer2-relay-agent] , they 94 need to maintain internal states to identify the outgoing 95 interface. Maintaining state information for each packet will not 96 scale as number of DHCP clients increases. With Relay Chaining, 97 Layer 3 Relay Agent can add its own Relay Agent Information option 98 that can be used to identify the outgoing interface for DHCP reply 99 messages. 101 o When a network configuration supports multiple Layer 3 Relay 102 Agents between DHCP Clients and DHCP server, a DHCP message need 103 to be relayed through these Relay Agents to reach DHCP server or 104 DHCP Clients. This can not be supported with present mechanism. 106 This document describes the enhancements to Relay Agent functionality 107 when multiple Relay Agents are present between DHCP clients and 108 servers. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 This document uses the following terms: 118 o "Access Concentrator" 120 An Access Concentrator is a router or switch at the broadband access 121 provider's edge of a public broadband access network. This document 122 assumes that the Access Concentrator acts as a Transparent Bridge and 123 includes the DHCP relay agent functionality. For example: In DSL 124 environment, this is typically known as DSLAM.(Digital Subscriber 125 Line Access Multiplexer) 127 o "DHCP client" 129 A DHCP client is an Internet host using DHCP to obtain configuration 130 parameters such as a network address. 132 o "Layer 3 Relay Agent" 134 A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap 135 Protocol (BOOTP) and DHCP messages between clients and servers 136 residing on different subnets, per RFC951 [RFC951] and RFC1542 137 [RFC1542]. 139 o "DHCP server" 141 A DHCP server is an Internet host that returns configuration 142 parameters to DHCP clients. 144 o "downstream" 146 Downstream is the direction from the edge network towards the DHCP 147 Clients. 149 o "Transparent Bridge" 151 A device which does bridging based on MAC learning principles. 152 Bridge learns the Source MAC of the incoming frames and updates a 153 table with MAC/Interface information. While forwarding data packets, 154 bridge looks at this table to find the outgoing interface. 156 o "upstream" 157 Upstream is the direction from the DHCP Clients towards the edge 158 network. 160 o "Unnumbered Interfaces" 162 An interface with no IP address associated with it. IP packets 163 received on this interface will be processed like any other numbered 164 IP interface. It may use a local IP address of another interface 165 while forwarding packets. 167 3. New sub-options 169 The 'Relay Chaining in DHCPv4' requires the definition of following 170 new sub-options in Relay Agent Information [Option 82] option for 171 DHCP packet beyond those defined by RFC2131 [RFC2131] and RFC2132 172 [RFC2132]. See also Section 7, IANA Considerations. 174 3.1. peer-relay-agent-information Sub Option 176 This sub-option is defined under Relay Agent Information option 177 [Option 82]. A Relay Agent can use 'peer-relay-agent-information' 178 sub-option to store the Relay Agent Information option added by the 179 previous Relay Agent. The value field of this sub-option contains 180 the Relay Agent Information option present in the recevied DHCP 181 message. The new sub-option is as shown in the figure below: 183 SubOpt Len Value 184 +------+------+--------------------------+ 185 | X | Len | Option 82 of Previous RA | 186 +------+------+--------------------------+ 187 / \ 188 / \ 189 +------+-----+--------------------+ 190 | 82 | N | i1 | i2 | ... | iN | 191 +------+-----+--------------------+ 192 Code Len Relay Agent Information 194 Figure 1 196 3.2. peer-address Sub Option 198 'peer-address' sub-option is used to store the previous Relay Agent's 199 reachable IP address. It SHOULD be typically populated with the same 200 address as mentioned in the 'giaddr' field of the received message. 201 If there are multiple Relay Agents involved, this sub-option helps in 202 forwarding the reply back to the DHCP client through the same path. 203 The 'peer-address' sub-option is as follows: 205 SubOpt Len Sub-option Value 206 +--------+--------+--------------------------------+ 207 | X | 4 | Previous RA's Address (giaddr) | 208 +--------+--------+--------------------------------+ 210 Figure 2 212 4. Relay Chaining 214 Relay Chaining is defined as the mechanism where multiple Relay 215 Agents are involved in relaying a DHCP message between DHCP clients 216 and server. Each Relay Agent adds Relay Agent Information option to 217 the DHCP message as described below. The option of using relay 218 chaining mechanism MUST be configurable on Relay Agent in order to 219 provide compatibility to the previous solutions. 221 | 222 +-----+ | 223 |Host1|------+ 224 +-----+ | 225 | 226 +-----+ | 227 |Host2|------+ +--------+ 228 +-----+ | | | +--------+ +--------+ 229 +------| | | | | | 230 | | Relay | | Relay | | DHCP | 231 | | Agent |---..---| Agent |--..--| Server | 232 | | #1 | | #2 | | | 233 +-----+ +------| | | | +--------+ 234 |Host3|------+ | | +--------+ 235 +-----+ | +--------+ 236 | 237 +-----+ | 238 |Host4|------+ 239 +-----+ | 240 | 241 | 243 Figure 3 245 A typical network configuration where Relay Chaining is required is 246 depicted in Figure 3. In the above case, two Relay Agents are 247 involved. Relay Agent #1 does not know the DHCP server and so is 248 configured to reach Relay Agent #2 for all DHCP messages. Relay 249 Agent #2 knows how to reach DHCP server and so relays a DHCP message 250 directly to DHCP server. DHCP server generates the reply messages 251 and sends it to Relay Agent #2 which relays the same to Relay Agent 252 #1. 254 4.1. Handling DHCP messages in Relay Agent 255 4.1.1. Handling Broadcast DHCP messages 257 o When a Relay Agent receives a DHCP request message which does not 258 contain the Relay Agent Information option, it SHOULD add the 259 Relay Agent Information option (Option 82 as described in RFC 3046 260 [RFC3046]) and 'giaddr' field as it deems appropriate. It should 261 relay the DHCP message to the DHCP server or next Relay Agent. If 262 a Relay Agent is a Layer 2 relay agent, it MUST NOT populate the 263 'giaddr' field in the DHCP message and should process it as per 264 [layer2-relay-agent] 266 o When a Relay Agent receives a DHCP request message which contains 267 a Relay Agent Information option, it SHOULD add the Relay Agent 268 Information Option as it deems appropriate and also populate the 269 'peer-relay-agent-information' sub-option as described in section 270 3.1. 272 o If a DHCP message received by a Relay Agent has a non-zero 273 'giaddr' field, it MUST add 'peer-address' sub-option in the Relay 274 Agent Information option with the same IP address as described in 275 section 3.2. 277 o When a Relay Agent receives the reply message from the server, it 278 MAY verify the Relay Agent Information option and SHALL silently 279 discard the packet if it had not added the Relay Agent Information 280 option. A Relay Agent MUST remove the Relay Agent Information 281 option it had added and process the reply message as follows: 283 * A Relay Agent MUST look for 'peer-relay-agent-information' sub- 284 option in the Relay Agent Information option it had added and 285 if it finds this sub-option, it MUST extract the contents which 286 is the Option 82 of the previous Relay Agent. Before relaying 287 this message, it MUST append the Relay Agent Information option 288 of the previous Relay Agent as it is to the DHCP message. 289 Relay Agent MAY use the Relay Agent Information it had added, 290 to identify the outgoing interface. 292 * A Relay Agent MUST also look for 'peer-address' sub-option and 293 if it finds this sub-option, it must extract the IP address 294 from the sub-option. It MUST set this IP address as 'giaddr' 295 and relay the DHCP reply to this IP address. If this sub- 296 option is not available, it SHOULD broadcast the reply to the 297 outgoing interface. 299 4.1.2. Handling Unicast DHCP messages 301 As DHCP Clients unicast RENEW, RELEASE and INFORM messages directly 302 to the DHCP server, these messages are not intercepted by Relay 303 Agents and so these messages does not have any Relay Agent 304 Information options added to them. 306 Some existing Relay Agent implementations maintain lease/location 307 informations for each DHCP client. These implementations intercepts 308 unicast DHCP messages to keep the lease/location information updated. 309 So these Relay Agent adds Relay Agent Information option to unicast 310 DHCP messages as well. Relay Agents and DHCP server process them 311 similar to broadcast messages as described above in section 5.1.1. 313 5. DHCP Server Behavior 315 DHCP server would still find only one single Relay Agent Information 316 option [ Option 82 ] in the DHCP message which has been relayed by 317 multiple relay agents. 319 Some existing DHCP servers may use the Relay Agent Information option 320 to apply the IP Address and other parameter assignment policies. 321 These DHCP servers will have to employ recursive lookup algorithm to 322 find the relevant Option 82 [the Option 82 which was added by the 323 first Relay Agent]. Server MUST echo back the entire Option 82 as it 324 is. 326 6. Special Scenarios 328 6.1. Multiple Layer 2 Relay Agents between DHCP client and Layer 3 329 Relay Agent 331 There may be a network scenario when there are multiple Layer 2 Relay 332 Agents configured between DHCP clients and Layer 3 Relay Agent. In 333 this case, as described above, each Layer 2 Relay Agent MUST add 334 'Relay Agent Information' option and MUST not add 'peer-address' sub- 335 option in it. A Layer 2 Relay Agent can use this Relay Agent 336 Information option while relaying the DHCP Reply message back to the 337 DHCP client. 339 6.2. One or multiple Layer 2 Relay Agents between two Layer 3 Relay 340 Agents 342 There is a very rare possibility of one or multiple Layer 2 Relay 343 Agents being present between two Layer 3 Relay Agents. In this case, 344 all the DHCP messages exchanged between these two Layer 3 Relay 345 Agents would be unicast messages. Typically a Layer 2 Relay Agent 346 should snoop these DHCP messages only if it maintains Lease/Location 347 information as described in [layer2-relay-agent]. In such cases, 348 Layer 2 Relay Agents SHOULD add Relay Agent Information option as 349 described in section 4.1.1. 351 7. Security Consideration 353 o A Relay Agents relaying DHCP messages to another Relay Agent are 354 essentially DHCP clients for the DHCP messages. Thus, RFC3118 355 [RFC3118] is an appropriate mechanism for these DHCP messages. 357 o To restrict the number of Relay Agents in Relay Chaining, as 358 defined in RFC 1542 [RFC1542], a Relay Agent must silently discard 359 the DHCP message whose 'hops' field exceeds the value 16. A 360 network manager can use configuration option to set this threshold 361 to a smaller value. 363 8. IANA Considerations 365 This document needs IANA to provide a unique number for the following 366 new suboptions in Relay Agent Information option [Option 82]: 368 o To carry the peer relay agent information option. Please refer to 369 section 3.1 for more details. 371 o To carry the peer address. Please refer to section 3.2 for more 372 details. 374 9. References 376 9.1. Normative Reference 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, March 1997. 381 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 382 RFC 2131, March 1997. 384 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 385 RFC 3046, January 2001. 387 [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP 388 Messages", RFC 3118, June 2001. 390 [layer2-relay-agent] 391 Joshi, B. and P. Kurapati, "Layer 2 Relay Agent", 392 draft draft-ietf-dhc-l2ra-04.txt, February 2009. 394 9.2. Informative Reference 396 [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", 397 RFC 951, September 1985. 399 [RFC1542] Wimer, W., "Clarifications and Extensions for the 400 Bootstrap Protocol", RFC 1542, October 1993. 402 [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor 403 Extensions", RFC 2132, March 1997. 405 Authors' Addresses 407 Bharat Joshi 408 Infosys Technologies Ltd. 409 44 Electronics City, Hosur Road 410 Bangalore 560 100 411 India 413 Email: bharat_joshi@infosys.com 414 URI: http://www.infosys.com/ 416 Pavan Kurapati 417 Infosys Technologies Ltd. 418 44 Electronics City, Hosur Road 419 Bangalore 560 100 420 India 422 Email: pavan_kurapati@infosys.com 423 URI: http://www.infosys.com/