idnits 2.17.1 draft-ietf-dhc-vpn-option-08.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 723. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 734. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 747. 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 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 (February 22, 2008) is 5906 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc Working Group Kim Kinnear 3 Internet Draft Richard Johnson 4 Intended Status: Standards Track Mark Stapp 5 Expires: August 22, 2008 Jay Kumarasamy 6 Cisco Systems 7 February 22, 2008 9 Virtual Subnet Selection Options for DHCPv4 and DHCPv6 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 22, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 44 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These 45 are intended for use by DHCP clients, relay agents, and proxy clients 46 in situations where VSS information needs to be passed to the DHCP 47 server for proper address or prefix allocation to take place. 49 For the DHCPv4 option and relay-agent-information sub-option, this 50 memo documents existing usage as per RFC 3942. 52 Table of Contents 54 1. Introduction................................................. 2 55 2. Terminology.................................................. 3 56 3. Virtual Subnet Selection Option and Sub-Option Definitions... 4 57 3.1. DHCPv4 Virtual Subnet Selection Option..................... 5 58 3.2. DHCPv4 Virtual Subnet Selection Sub-Option................. 5 59 3.3. DHCPv6 Virtual Subnet Selection Option..................... 5 60 3.4. Virtual Subnet Selection Type and Information.............. 6 61 4. Relay Agent Behavior......................................... 7 62 4.1. VPN assignment by the DHCP server.......................... 8 63 4.2. DHCP Leasequery............................................ 9 64 5. Client Behavior.............................................. 9 65 6. Server Behavior.............................................. 10 66 6.1. Returning the DHCPv4 or DHCPv6 Option...................... 11 67 6.2. Returning the DHCPv4 Sub-Option............................ 11 68 6.3. Making sense of conflicting VSS information................ 12 69 7. Security..................................................... 12 70 8. IANA Considerations.......................................... 13 71 9. Acknowledgments.............................................. 14 72 10. Normative References........................................ 14 73 11. Informative References...................................... 14 74 12. Authors' Addresses.......................................... 15 75 13. Full Copyright Statement.................................... 16 76 14. Intellectual Property....................................... 16 77 15. Acknowledgment.............................................. 17 79 1. Introduction 81 There is a growing use of Virtual Private Network (VPN) 82 configurations. The growth comes from many areas; individual client 83 systems needing to appear to be on the home corporate network even 84 when traveling, ISPs providing extranet connectivity for customer 85 companies, etc. In some of these cases there is a need for the DHCP 86 server to know the VPN (hereafter called a "Virtual Subnet Selector" 87 or "VSS") from which an address, and other resources, should be 88 allocated. 90 This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 91 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These 92 are intended for use by DHCP clients, relay agents, and proxy clients 93 in situations where VSS information needs to be passed to the DHCP 94 server for proper address or prefix allocation to take place. If the 95 receiving DHCP server understands the VSS option or sub-option, this 96 information may be used in conjunction with other information in 97 determining the subnet on which to select an address as well as other 98 information such as DNS server, default router, etc. 100 If the allocation is being done through a DHCPv4 relay, then the 101 relay sub-option defined here should be included. In some cases, 102 however an IP address is being sought by a DHCPv4 proxy on behalf of 103 a client (which may be assigned the address via a different 104 protocol). In this case, there is a need to include VSS information 105 relating to the client as a DHCPv4 option. 107 If the allocation is being done through a DHCPv6 relay, then the 108 DHCPv6 VSS option defined in this document should be included in the 109 Relay-forward and Relay-reply message going between the DHCPv6 relay 110 and server. In some cases, addresses or prefixes are being sought 111 for by a DHCPv6 proxy on behalf of a client. In this case, there is 112 a need for the client itself to supply the VSS information using the 113 DHCPv6 VSS option in the messages that it sends to the DHCPv6 server. 115 In the remaining text of this document, when a DHCPv6 address is 116 indicated the same information applies to DHCPv6 Prefix Delegation 117 [RFC 3633] as well. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC 2119]. 125 This document uses the following terms: 127 o "DHCP client" 129 A DHCP client is a host using DHCP to obtain configuration 130 parameters such as a network address. 132 o "DHCP relay agent" 134 A DHCP relay agent is a third-party agent that transfers BOOTP 135 and DHCP messages between clients and servers residing on 136 different subnets, per [RFC 951] and [RFC 1542]. 138 o "DHCP server" 140 A DHCP server is a host that returns configuration parameters to 141 DHCP clients. 143 o "DHCPv4 option" 145 An option or used to implement a capability defined by the 146 DHCPv4 RFCs [RFC 2131][RFC 2132]. These options have one octet 147 code and size bytes. 149 o "DHCPv4 sub-option" 151 As used in this document, a DHCPv4 sub-option refers to a sub- 152 option of the relay-agent-information option [RFC 3046]. These 153 sub-options have one octet code and size bytes. 155 o "DHCPv6 option" 157 An option used to implement a capability defined by the DHCPv6 158 RFC [RFC 3315]. These options have two octet code and size 159 bytes. 161 o "downstream" 163 Downstream is the direction from the access concentrator towards 164 the subscriber. 166 o "upstream" 168 Upstream is the direction from the subscriber towards the access 169 concentrator. 171 o "VSS information" 173 Information about a VPN necessary to allocate an address to a 174 DHCP client on that VPN and necessary to forward a DHCP reply 175 packet to a DHCP client on that VPN. 177 o "VPN" 179 Virtual private network. A network which appears to the client 180 to be a private network. 182 o "VPN Identifier" 184 The VPN-ID is defined by [RFC 2685] to be a sequence of 7 185 octets. 187 3. Virtual Subnet Selection Option and Sub-Option Definitions 189 The Virtual Subnet Selection options and sub-option contains a 190 generalized way to specify the VSS information about a VPN. There 191 are two options and one sub-option defined in this section. The 192 actual VSS information is identical in each. 194 3.1. DHCPv4 Virtual Subnet Selection Option 196 The format of the option is: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Code | Length | Type | VSS Info ... 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Code The option code (221). 206 Length The option length, minimum 1 octets. 208 Type and VSS Information -- see Section 3.4 210 3.2. DHCPv4 Virtual Subnet Selection Sub-Option 212 This is a sub-option of the relay-agent-information option [RFC 213 3046]. The format of the sub-option is: 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Code | Length | Type | VSS Info. ... 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Code The sub-option code (151). 223 Length The option length, minimum 1 octets. 225 Type and VSS Information -- see Section 3.4 227 3.3. DHCPv6 Virtual Subnet Selection Option 229 The format of the DHCPv6 Virtual Subnet Selection option is shown 230 below. This option may be included by a client or relay-agent (or 231 both). 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | OPTION_VSS | option-len | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type | VSS Information ... | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 option-code OPTION_VSS (TBD). 243 option-len The number of octets in the option, minimum 1. 245 Type and VSS Information -- see Section 3.4 247 3.4. Virtual Subnet Selection Type and Information 249 All of the (sub)options defined above carry identical payloads, 250 consisting of a type and additional VSS information as follows: 252 Type VSS Information format: 254 0 NVT ASCII VPN identifier 255 1 RFC2685 VPN-ID 256 2-254 Not Allowed 257 255 Global, default VPN. 259 o Type 0 -- NVT ASCII VPN identifier 261 Indicates that the VSS information consists of a NVT ASCII string. 262 It MUST NOT be terminated with a zero byte. 264 o Type 1 -- RFC2685 VPN-ID 266 Indicates that the VSS information consists of an RFC2685 VPN-ID 267 [RFC 2685], which is defined to be 7 octets in length. 269 o Type 255 -- Global, default VPN 271 Indicates that there is no explicit, non-default VSS information 272 but rather that this option references the normal, global, default 273 address space. In this case, there MUST NOT be any VSS Information 274 and the length of the VSS option MUST be 1. 276 All other values of the Type field are invalid as of this memo and a 277 VSS option with a Type field containing any value other than zero 278 (0), one (1), or 255 SHOULD be ignored. 280 4. Relay Agent Behavior 282 A relay agent which receives a DHCP request from a DHCP client on a 283 VPN should include Virtual Subnet Selection information in the DHCP 284 packet prior to forwarding the packet on to the DHCP server. 286 A DHCPv4 relay agent SHOULD include a DHCPv4 VSS sub-option in a 287 relay-agent-information option [RFC 3046], while a DHCPv6 relay agent 288 SHOULD include a DHCPv6 VSS option in the Relay-forward message. 290 The value placed in the Virtual Subnet Selection sub-option or option 291 SHOULD be sufficient for the relay agent to properly route any DHCP 292 reply packet returned from the DHCP server to the DHCP client for 293 which it is destined. 295 Since this option or sub-option is placed in the packet in order to 296 change the VPN on which an IP address is allocated for a particular 297 DHCP client, one presumes that an allocation on that VPN is necessary 298 for correct operation. If this presumption is correct, then a relay 299 agent which places this option in a packet and doesn't receive it (or 300 receives a different value than that sent to the server) in the 301 returning packet should drop the packet since the IP address that was 302 allocated will not be in the correct VPN. If an IP address that is 303 not on the requested VPN is not required, then the relay agent is 304 free to accept the IP address that is not on the VPN that was 305 requested. 307 The converse, however, is more complicated. In the DHCPv6 case, the 308 appearance of the option in the Rely-reply packet does indeed 309 indicate that the DHCPv6 server understood and acted upon the 310 contents of the VSS option in the Relay-forward packet. In the 311 DHCPv4 case, however, the appearance of the sub-option in the relay- 312 agent-information option received by the relay agent does not 313 necessarily indicate that the DHCPv4 server even understood, let 314 alone acted correctly upon, the VSS sub-option that it received. 316 The reason is that [RFC 3046] specifies that a DHCPv4 server which 317 supports the relay-agent-information option SHALL copy all sub- 318 options received in a relay-agent-information option into any 319 outgoing relay-agent-information option. Because of these 320 requirements, even a DHCPv4 server which doesn't implement support 321 for Virtual Subnet Selection sub-option will almost certainly copy it 322 into the outgoing relay-agent-information option. This means that 323 the appearance of the Virtual Subnet Selection sub-option in a 324 relay-agent-information option doesn't indicate support for the 325 Virtual Subnet Selection sub-option. 327 There are only two pieces of information which can be determined from 328 the appearance or lack of appearance of the DHCPv4 Virtual Subnet 329 Selection sub-option in a relay-agent-information option received by 330 a relay agent from a DHCPv4 server. First, if the Virtual Subnet 331 Selection sub-option does not appear, then the server was able to 332 support this sub-option but chose not to do so. Second, if the 333 Virtual Subnet Selection sub-option appears and has a different value 334 than the one originally included in the relay-agent-information 335 option, then the DHCP server was able to support this sub-option and 336 allocated an address using different VSS information than was 337 originally provided by the relay agent. 339 Thus, if a DHCPv4 relay agent has a requirement to determine if the 340 address allocated by a DHCPv4 server is on a particular VPN, it must 341 use some other approach than the appearance of the VSS sub-option in 342 the reply packet to make this determination. 344 This document does not create a requirement that a relay agent 345 remember the contents of a VSS DHCPv4 sub-option or VSS DHCPv6 option 346 sent to a DHCP server. In many cases, the relay agent may simply use 347 the value of the VSS returned by the DHCP server to forward the 348 response to the DHCP client. If the VSS information, the IP address 349 allocated, and the VPN capabilities of the relay agent all 350 interoperate correctly, then the DHCP client will receive a working 351 IP address. Alternatively, if any of these items don't interoperate 352 with the others, the DHCP client will not receive a working address. 354 Note that in some environments a relay agent may choose to always 355 place a VSS option or sub-option into packets and messages that it 356 forwards in order to forestall any attempt by a downstream relay 357 agent or client to specify VSS information. In this case, a type 358 field of 255 is used to denote the global, default VPN. When the 359 type field of 255 is used, there MUST NOT be any additional VSS 360 Information in the VSS option. 362 4.1. VPN assignment by the DHCP server 364 In some cases, a DHCP server may use the Virtual Subnet Selection 365 sub-option or option to inform a relay agent that a particular DHCP 366 client is associated with a particular VPN. It does this by sending 367 the Virtual Subnet Selection sub-option or option with the 368 appropriate information to the relay agent in the relay-agent- 369 information option for DHCPv4 or the Relay-reply message in DHCPv6. 370 If the relay agent is unable to honor the DHCP server's requirement 371 to place the DHCP client into that VPN it MUST drop the packet and 372 not send it to the DHCP client. 374 4.2. DHCP Leasequery 376 Sometimes a relay-agent needs to submit a DHCP Leasequery [RFC 4388] 377 [RFC 5007] packet to the DHCP server in order to recover information 378 about existing DHCP allocated IP addresses on other than the normal, 379 global VPN. In the context of a DHCP Leasequery the relay agent is a 380 direct client of the DHCP server and is not relaying a packet for 381 another DHCP client. Thus, the instructions in Section 5 on Client 382 Behavior should be followed to include the necessary VSS information. 384 5. Client Behavior 386 A DHCPv4 or DHCPv6 client will employ the VSS option to communicate 387 VSS information to their respective servers. This information MUST 388 be included in every message concerning any IP address on a different 389 VPN than the global or default VPN. A DHCPv4 client will place the 390 DHCPv4 VSS option in its packets, and a DHCPv6 client will place the 391 DHCPv6 VSS option in its messages. 393 A DHCPv6 client that needs to place a VSS option into a DHCPv6 394 message SHOULD place a single VSS option into the DHCPv6 message at 395 the same level as the Client Identifier option. A DHCPv6 client MUST 396 NOT include different VSS options in the same DHCPv6 message. 398 Note that, as mentioned in Section 1, throughout this document when a 399 DHCPv6 address is indicated the same information applies to DHCPv6 400 Prefix Delegation [RFC 3633] as well. 402 Since this option is placed in the packet in order to change the VPN 403 on which an IP address is allocated for a particular DHCP client, one 404 presumes that an allocation on that VPN is necessary for correct 405 operation. If this presumption is correct, then a client which 406 places this option in a packet and doesn't receive it or receives a 407 different value in the returning packet should drop the packet since 408 the IP address that was allocated will not be in the correct VPN. If 409 an IP address that is not on the requested VPN is not required, then 410 the client is free to accept the IP address that is not on the VPN 411 that the was requested. 413 Client's should be aware that some DHCP servers will return a VSS 414 option with different values than that which was sent in. In 415 addition, a client may receive a response from a DHCP server with a 416 VSS option when none was sent in by the Client. 418 Note that when sending a DHCP Leasequery request, a relay agent is 419 acting as a DHCP client and so it should include the respective 420 DHCPv4 or DHCPv6 VSS option in its DHCPv4 or DHCPv6 Leasequery packet 421 if the DHCP Leasequery request is generated for other than the 422 default, global VPN. It should not include a DHCPv4 sub-option in 423 this case. 425 6. Server Behavior 427 A DHCP server receiving the VSS option or sub-option SHOULD allocate 428 an IP address (or use the VSS information to access an already 429 allocated IP address) from the VPN specified by the included VSS 430 information. 432 In the case where the type field of the VSS option or sub-option is 433 255, the VSS option denotes the global, default VPN. In this case, 434 there is no explicit VSS information beyond the type field. 436 This document does not prescribe any particular address allocation 437 policy. A DHCP server may choose to attempt to allocate an address 438 using the VSS information and, if this is impossible, to not allocate 439 an address. Alternatively, a DHCP server may choose to attempt 440 address allocation based on the VSS information and, if that is not 441 possible, it may fall back to allocating an address on the global or 442 default VPN. This, of course, is also the apparent behavior of any 443 DHCP server which doesn't implement support for the VSS option and 444 sub-option. Thus, DHCP clients and relay agents SHOULD be prepared 445 for either of these alternatives. 447 In some cases, a DHCP server may use the Virtual Subnet Selection 448 sub-option or option to inform a relay agent that a particular DHCP 449 client is associated with a particular VPN. It does this by sending 450 the Virtual Subnet Selection sub-option or option with the 451 appropriate information to the relay agent in the relay-agent- 452 information option for DHCPv4 or the Relay-reply message in DHCPv6. 454 In a similar manner, a DHCP server may use the Virtual Subnet 455 Selection option to inform a DHCP client that the address (or 456 addresses) it allocated for the client is on a particular VPN. 458 In either case above, care should be taken to ensure that a client or 459 relay agent receiving a reply containing a VSS option will correctly 460 understand the VSS option. Otherwise, the client or relay agent will 461 end up using the address as though it were a global address. 463 6.1. Returning the DHCPv4 or DHCPv6 Option 465 DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option 466 processing, see below) MUST return an instance of this option in the 467 reply packet or message if the server successfully uses this option 468 to allocate an IP address, and it MUST NOT include an instance of 469 this option if the server was unable to or not configured to support 470 the requested VPN. 472 If they echo the option (based on the criteria above), servers SHOULD 473 return the an exact copy of the option unless they desire to change 474 the VPN on which a client was configured. 476 6.2. Returning the DHCPv4 Sub-Option 478 The case of the DHCPv4 sub-option is a bit more complicated. Note 479 that [RFC 3046] specifies that a DHCPv4 server which supports the 480 relay-agent-information option SHALL copy all sub-options received in 481 a relay-agent-information option into any outgoing relay-agent- 482 information option. Thus, the default behavior for any DHCPv4 server 483 is to return any VSS sub-option received to the relay agent whether 484 or not the DHCPv4 server understand the VSS sub-option. A server 485 which implements the VSS sub-option MUST include the VSS sub-option 486 in the relay-agent-information option in the reply packet if it 487 successfully acted upon the VSS information in the incoming VSS sub- 488 option. 490 Moreover, if a server uses different VSS information to allocate an 491 IP address than it receives in a particular DHCPv4 sub-option, it 492 MUST include that alternative VSS information in a sub-option that it 493 returns to the DHCPv4 relay agent. 495 If a DHCPv4 server supports this sub-option and for some reason 496 (perhaps administrative control) does not honor this sub-option from 497 the request then it MUST NOT echo this sub-option in the outgoing 498 relay-agent-information option. 500 Note that the appearance of the VSS sub-option in a reply packet from 501 a DHCPv4 server to a relay-agent does not communicate any useful 502 information about whether or not the server used the VSS sub-option 503 in its processing. However, the absence of a VSS sub-option in a 504 reply from a DHCPv4 server when a VSS sub-option was included in a 505 request to the DHCPv4 server is significant, and means that the 506 server did not use the VSS information present in the sub-option in 507 its processing. 509 6.3. Making sense of conflicting VSS information 511 It is possible for a DHCPv4 server to receive both a VSS option and a 512 VSS sub-option in the same packet. Likewise, a DHCPv6 server can 513 receive multiple VSS options in nested Relay-forward messages as well 514 as in the client message itself. In either of these cases, the VSS 515 information from the relay agent closest to the DHCP server SHOULD be 516 used in preference to all other VSS information received. In the 517 DHCPv4 case, this means that the VSS sub-option takes precedence over 518 the VSS option, and in the DHCPv6 case, this means that the VSS 519 option from the outer-most Relay-forward message in which a VSS 520 option appears takes precedence. 522 The reasoning behind this approach is that the relay-agent closer to 523 the DHCP server is almost certainly more trusted than the DHCP client 524 or more distant relay agents, and therefore information in the 525 relay-agent-information option or the Relay-forward message is more 526 likely to be correct. 528 In these situations where multiple VSS option or sub-options appear 529 in the incoming packet or message, when constructing the response to 530 be sent to the DHCP client or relay agent, all existing VSS options 531 or sub-options MUST be replicated in the appropriate places in the 532 response and MUST contain the VSS information that was used by the 533 DHCP server to allocate the IP address. 535 7. Security 537 Message authentication in DHCPv4 for intradomain use where the out- 538 of-band exchange of a shared secret is feasible is defined in [RFC 539 3118]. Potential exposures to attack are discussed in section 7 of 540 the DHCP protocol specification in [RFC 2131]. 542 Implementations should consider using the DHCPv4 Authentication 543 option [RFC 3118] to protect DHCPv4 client access in order to provide 544 a higher level of security if it is deemed necessary in their 545 environment. 547 Message authentication in DHCPv4 relay agents as defined in 548 [RFC 4030] should be considered for DHCPv4 relay agents employing 549 this sub-option. Potential exposures to attack are discussed in 550 section 7 of the DHCP protocol specification in [RFC 2131]. 552 For DHCPv6 use of the VSS option, the "Security Considerations" 553 section of [RFC 3315] details the general threats to DHCPv6, and thus 554 to messages using the VSS option. The "Authentication of DHCP 555 Messages" section of [RFC 3315] describes securing communication 556 between relay agents and servers, as well as clients and servers. 558 The VSS option could be used by a client in order to obtain an IP 559 address from a VPN other than the one where it should. This option 560 would allow a client to perform a more complete address-pool 561 exhaustion attack since the client would no longer be restricted to 562 attacking address-pools on just its local subnet. 564 A DHCP server that implements these options and sub-option should be 565 aware of this possibility and use whatever techniques that can be 566 devised to prevent such an attack. Information such as the giaddr in 567 DHCPv4 or link address in the Relay-forward DHCPv6 message might be 568 used to detect and prevent this sort of attack. 570 One possible defense would be for the DHCP relay to insert a VSS 571 option or sub-option to override the DHCP client's VSS option. 573 Servers that implement the VSS option and sub-option MUST by default 574 disable use of the feature; it must specifically be enabled through 575 configuration. Moreover, a server SHOULD provide the ability to 576 selectively enable use of the feature under restricted conditions, 577 e.g., by enabling use of the option only from explicitly configured 578 client-ids, enabling its use only by clients on a particular subnet, 579 or restricting the VSSs from which addresses may be requested. 581 8. IANA Considerations 583 IANA is requested to assign DHCPv4 option number 221 for the DHCPv4 584 VSS option defined in Section 3.1, in accordance with [RFC 3942]. 586 IANA is requested to assign sub-option number 151 for the DHCPv4 587 sub-option defined in Section 3.2 from the DHCP Relay Agent Sub- 588 options space [RFC 3046], in accordance with the spirit of [RFC 589 3942]. While [RFC 3942] doesn't explicitly mention the sub-option 590 space for the DHCP Relay Agent Information option [RFC 3046], sub- 591 option 151 is already in use by existing implementations of this 592 sub-option and the current draft is essentially compatible with these 593 current implementations. 595 IANA has assigned the value of TBD for the DHCPv6 VSS option defined 596 in Section 3.3. 598 While the type byte defined in Section 3.4 defines a number space 599 that could be managed by IANA, expansion of this number space is not 600 anticipated and so creation of a registry of these numbers is not 601 required by this document. In the event that additional values for 602 the type byte are defined in subsequent documents, IANA should at 603 that time create a registry for these type bytes. New values for the 604 type byte may only be defined by IETF Consensus, as described in 605 [RFC 2434]. Basically, this means that they are defined by RFCs 606 approved by the IESG. 608 9. Acknowledgments 610 Bernie Volz recommended consolidation of the DHCPv4 option and sub- 611 option drafts after extensive review of the former drafts, and 612 provided valuable assistance in structuring and reviewing this 613 document. Alper Yegin expressed interest in the DHCPv6 VSS option, 614 resulting in this combined draft covering all three areas. 616 10. Normative References 618 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", RFC 2119, March 1997. 621 [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 622 2131, March 1997. 624 [RFC 2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 625 Extensions", RFC 2132, March 1997. 627 [RFC 2685] Fox, B., Gleeson, B., "Virtual Private Networks 628 Identifier", RFC 2685, September 1999. 630 [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 631 3046, January 2001. 633 [RFC 3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 634 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 635 (DHCPv6)", RFC 3315, July 2003. 637 [RFC 3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 638 Host Configuration Protocol (DHCP) version 6", RFC 3633, December 639 2003. 641 11. Informative References 643 [RFC 951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 644 September 1985. 646 [RFC 1542] Wimer, W., "Clarifications and Extensions for the 647 Bootstrap Protol", RFC 1542, October 1993. 649 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 650 Requirement Levels", RFC 2119, March 1997. 652 [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 653 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 654 1998. 656 [RFC 3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 657 Messages", RFC 3118, June 2001. 659 [RFC 3942] Volz, B., "Reclassifying Dynamic Host Configuration 660 Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004. 662 [RFC 4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 663 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 664 Option", RFC 4030, March 2005. 666 [RFC 4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 667 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 669 [RFC 5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 670 "DHCPv6 Leasequery", RFC 5007, September 2007. 672 12. Authors' Addresses 674 Kim Kinnear 675 Cisco Systems 676 1414 Massachusetts Ave. 677 Boxborough, Massachusetts 01719 679 Phone: (978) 936-0000 681 EMail: kkinnear@cisco.com 683 Richard Johnson 684 Cisco Systems 685 170 W. Tasman Dr. 686 San Jose, CA 95134 688 Phone: (408) 526-4000 690 EMail: raj@cisco.com 692 Mark Stapp 693 Cisco Systems 694 1414 Massachusetts Ave. 695 Boxborough, Massachusetts 01719 696 Phone: (978) 936-0000 698 EMail: mjs@cisco.com 700 Jay Kumarasamy 701 Cisco Systems 702 170 W. Tasman Dr. 703 San Jose, CA 95134 705 Phone: (408) 526-4000 707 EMail: jayk@cisco.com 709 13. Full Copyright Statement 711 Copyright (C) The IETF Trust (2008). 713 This document is subject to the rights, licenses and restrictions 714 contained in BCP 78, and except as set forth therein, the authors 715 retain all their rights. 717 This document and the information contained herein are provided on an 718 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 719 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 720 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 721 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 722 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 723 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 725 14. Intellectual Property 727 The IETF takes no position regarding the validity or scope of any 728 Intellectual Property Rights or other rights that might be claimed to 729 pertain to the implementation or use of the technology described in 730 this document or the extent to which any license under such rights 731 might or might not be available; nor does it represent that it has 732 made any independent effort to identify any such rights. Information 733 on the procedures with respect to rights in RFC documents can be 734 found in BCP 78 and BCP 79. 736 Copies of IPR disclosures made to the IETF Secretariat and any 737 assurances of licenses to be made available, or the result of an 738 attempt made to obtain a general license or permission for the use of 739 such proprietary rights by implementers or users of this 740 specification can be obtained from the IETF on-line IPR repository at 741 http://www.ietf.org/ipr. 743 The IETF invites any interested party to bring to its attention any 744 copyrights, patents or patent applications, or other proprietary 745 rights that may cover technology that may be required to implement 746 this standard. Please address the information to the IETF at 747 ietf-ipr@ietf.org. 749 15. Acknowledgment 751 Funding for the RFC Editor function is provided by the IETF 752 Administrative Support Activity (IASA).