idnits 2.17.1 draft-ietf-dhc-vpn-option-09.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 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 897. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 903. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3942]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 8, 2008) is 5763 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 5226 (Obsoleted by RFC 8126) Summary: 4 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: January 8, 2009 Jay Kumarasamy 6 Cisco Systems 7 July 8, 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 January 8, 2009 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 [RFC3942]. 52 Table of Contents 54 1. Introduction................................................. 2 55 2. Terminology.................................................. 3 56 3. Virtual Subnet Selection Option and Sub-Option Definitions... 5 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..................... 6 60 3.4. Virtual Subnet Selection Type and Information.............. 6 61 4. Overview of Virtual Subnet Selection Usage................... 7 62 5. Relay Agent Behavior......................................... 10 63 5.1. VPN assignment by the DHCP server.......................... 11 64 5.2. DHCP Leasequery............................................ 12 65 6. Client Behavior.............................................. 12 66 7. Server Behavior.............................................. 13 67 7.1. Returning the DHCPv4 or DHCPv6 Option...................... 14 68 7.2. Returning the DHCPv4 Sub-Option............................ 14 69 7.3. Making sense of conflicting VSS information................ 15 70 8. Security..................................................... 15 71 9. IANA Considerations.......................................... 16 72 10. Acknowledgments............................................. 17 73 11. Normative References........................................ 17 74 12. Informative References...................................... 18 75 13. Authors' Addresses.......................................... 18 76 14. Full Copyright Statement.................................... 19 77 15. Intellectual Property....................................... 20 78 16. Acknowledgment.............................................. 20 80 1. Introduction 82 There is a growing use of Virtual Private Network (VPN) 83 configurations. The growth comes from many areas; individual client 84 systems needing to appear to be on the home corporate network even 85 when traveling, ISPs providing extranet connectivity for customer 86 companies, etc. In some of these cases there is a need for the DHCP 87 server to know the VPN (hereafter called a "Virtual Subnet Selector" 88 or "VSS") from which an address, and other resources, should be 89 allocated. 91 This memo defines a Virtual Subnet Selection (VSS) option for DHCPv4 92 and DHCPv6, and a DHCPv4 relay-agent-information sub-option. These 93 are intended for use by DHCP clients, relay agents, and proxy clients 94 in situations where VSS information needs to be passed to the DHCP 95 server for proper address or prefix allocation to take place. If the 96 receiving DHCP server understands the VSS option or sub-option, this 97 information may be used in conjunction with other information in 98 determining the subnet on which to select an address as well as other 99 information such as DNS server, default router, etc. 101 If the allocation is being done through a DHCPv4 relay, then the 102 relay sub-option defined here should be included. In some cases, 103 however an IP address is being sought by a DHCPv4 proxy on behalf of 104 a client (which may be assigned the address via a different 105 protocol). In this case, there is a need to include VSS information 106 relating to the client as a DHCPv4 option. 108 If the allocation is being done through a DHCPv6 relay, then the 109 DHCPv6 VSS option defined in this document should be included in the 110 Relay-forward and Relay-reply message going between the DHCPv6 relay 111 and server. In some cases, addresses or prefixes are being sought 112 for by a DHCPv6 proxy on behalf of a client. In this case, there is 113 a need for the client itself to supply the VSS information using the 114 DHCPv6 VSS option in the messages that it sends to the DHCPv6 server. 116 In the remaining text of this document, when a DHCPv6 address is 117 indicated the same information applies to DHCPv6 Prefix Delegation 118 [RFC3633] as well. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 This document uses the following terms: 128 o "DHCP client" 130 A DHCP client is a host using DHCP to obtain configuration 131 parameters such as a network address. 133 o "DHCP relay agent" 135 A DHCP relay agent is a third-party agent that transfers BOOTP 136 and DHCP messages between clients and servers residing on 137 different subnets, per [RFC951] and [RFC1542]. 139 o "DHCP server" 141 A DHCP server is a host that returns configuration parameters to 142 DHCP clients. 144 o "DHCPv4 option" 146 An option or used to implement a capability defined by the 147 DHCPv4 RFCs [RFC2131][RFC2132]. These options have one octet 148 code and size bytes. 150 o "DHCPv4 sub-option" 152 As used in this document, a DHCPv4 sub-option refers to a sub- 153 option of the relay-agent-information option [RFC3046]. These 154 sub-options have one octet code and size bytes. 156 o "DHCPv6 option" 158 An option used to implement a capability defined by the DHCPv6 159 RFC [RFC3315]. These options have two octet code and size 160 bytes. 162 o "downstream" 164 Downstream is the direction from the access concentrator towards 165 the subscriber. 167 o "upstream" 169 Upstream is the direction from the subscriber towards the access 170 concentrator. 172 o "VSS information" 174 Information about a VPN necessary to allocate an address to a 175 DHCP client on that VPN and necessary to forward a DHCP reply 176 packet to a DHCP client on that VPN. 178 o "VPN" 180 Virtual private network. A network which appears to the client 181 to be a private network. 183 o "VPN Identifier" 185 The VPN-ID is defined by [RFC2685] to be a sequence of 7 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 [RFC3046]. 213 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 [RFC2685], 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. Overview of Virtual Subnet Selection Usage 282 At the highest level, the VSS option or sub-option determines the VPN 283 on which a DHCP client is supposed to receive an IP address. How the 284 option or sub-option is entered and processed is discussed below, but 285 the point of all of the discussion is to determine the VPN on which 286 the DHCP client resides. This will affect a relay agent, in that it 287 will have to ensure that the packets sent to and received from the 288 DHCP client flow over the correct VPN. This will affect the DHCP 289 server in that it determines the IP address space used for the IP 290 address allocation. 292 A DHCP server has as part of its configuration some IP address space 293 from which it allocates IP addresses to DHCP clients. These 294 allocations are typically for a limited time, and thus the DHCP 295 client gets a lease on the IP address. In the absence of any VPN 296 information, the IP address space is in the global or default VPN 297 used throughout the Internet. When a DHCP server deals with VPN 298 information, each VPN defines a new address space inside the server, 299 one distinct from the global or default IP address space. A server 300 which supports the VSS option or sub-option thereby supports 301 allocation of IP addresses from multiple different VPNs. Supporting 302 IP address allocation from multiple different VPNs means that the 303 DHCP server must be prepared to configure multiple different address 304 spaces (one per distinct VPN) and allocate IP addresses from these 305 different address spaces. 307 These address spaces are typically independent, so that the same IP 308 address could be allocated to one client in the global, default VPN, 309 and to a different client residing in a different VPN. There is no 310 conflict in this allocation, since the clients have essentially 311 different IP addresses. The IPv4 or IPv6 address is qualified by the 312 VPN. 314 Thus a VSS option or sub-option is a way of signaling the use of a 315 VPN other than the global or default VPN. The next question is: who 316 decides what VPN a DHCP client should be using? 318 There are three entities which can either insert a VSS option or 319 sub-option into a DHCPv4 packet or DHCPv6 message; a DHCP client, a 320 relay agent, or a DHCPv4 or DHCPv6 server. While all of these 321 entities could include a different VSS option or sub-option in every 322 request or response, this situation is neither typical nor useful. 323 There are two known paradigms for use of the VSS option or sub- 324 option, which are discussed below. 326 The typical use of the VSS option or sub-option is for the relay 327 agent to know the VPN on which the DHCP client is operating. The 328 DHCP client itself does not, in this scenario, know the VPN on which 329 it resides. The relay agent is responsible for mediating the access 330 between the VPN on which the DHCP client resides and the DHCP server. 331 In this situation, the relay agent will insert a VSS sub-option into 332 the relay-agent-information option (for DHCPv4) or a VSS option the 333 Relay-forward message (for DHCPv6) of every request it forwards from 334 the DHCP client. The server will use the VSS option or sub-option to 335 determine the VPN on which the client resides, and use that VPN 336 information to select the address space within its configuration from 337 which to allocate an IP address to the DHCP client. 339 In this scenario, the relay agent might also send in either a DHCPv4 340 or DHCPv6 Leasequery request, but in this case, it would use the VSS 341 option in the Leasequery request to select the correct address space 342 for the Leasequery. In this scenario, the relay agent would be 343 acting as a DHCP client from a Leasequery standpoint, but it would 344 not be as if a DHCP client were sending in a VSS option in a standard 345 DHCP address allocation request, say a DHCPDISCOVER. 347 In this scenario, only one relay agent would mediate the VPN access 348 for the DHCP client to the DHCP server, and it would be the relay 349 agent which inserts the VSS information into the packet and would 350 remove it prior to forwarding the packet on. 352 The DHCP server would know that it should respond to VPN information 353 specified in a VSS option or sub-option, and it would be configured 354 with appropriate VPN address spaces to service the projected client 355 requirements. Thus, in this common scenario, the DHCP client knows 356 nothing of any VPN access, the relay agent has been configured in 357 some way that allows it to determine the VPN of the DHCP client and 358 transmit that using a VSS option or sub-option to the DHCP server, 359 and the DHCP server responds to the VPN specified by the relay agent. 360 There is no conflict between different entities trying to specify 361 different VSS information -- each entity knows its role through 362 policy or configuration external to this document. 364 In the second scenario, the DHCP server would be configured in some 365 way to know the VPN on which a particular DHCP client should be given 366 access. The DHCP server would in this case include the VSS sub- 367 option in the relay-agent-information option for DHCPv4 or the VSS 368 option in the Relay-reply message for DHCPv6. The relay agent 369 responsible for mediating VPN access would use this information to 370 select the correct VPN for the DHCP client. In the event that there 371 were more than one relay agent involved in this transaction, some 372 external configuration or policy would be needed to inform the DHCPv6 373 server into which Relay-reply message the VSS option should go. 375 Once the relay agent has placed the DHCP client into the proper VPN, 376 it SHOULD begin including VSS information in requests that it 377 forwards to the DHCP server. Since this information does not 378 conflict with the DHCP server's idea of the proper VPN for the 379 client, everything works correctly. 381 In this second scenario, the DHCP client is again unaware of any VPN 382 activity. In this case, however, the DHCP server knows the VPN for 383 the client, and the relay agent responds to the VSS information 384 specified by the DHCP server. Similar to the first scenario, each 385 entity knows its role through a means external to this document and 386 no two entities try to specify VSS information in conflict. 388 There are many other scenarios which can be created with multiple 389 relay agents each inserting VSS information into different Relay- 390 forward messages, relay agent VSS information conflicting with client 391 VSS information, or DHCP server VSS information conflicting with 392 relay agent and client VSS information. Since these scenarios do not 393 describe situations that are useful today, specifying precisely how 394 to resolve all of these conflicts is unlikely to be valuable in the 395 event that these scenarios actually become practical in the future. 397 The current use of the VSS option and sub-option require that each 398 entity knows the part that it plays in dealing with VPN data. Each 399 entity -- client, relay agent or agents, and server -- SHOULD know 400 through some policy or configuration beyond the scope of this 401 document whether it is responsible for specifying VPN information 402 using the VSS option or sub-option or responsible for responding to 403 VSS information specified by another entity, or simply ignoring any 404 VSS information which it might see. 406 Some simple conflict resolution approaches are discussed below, in 407 the hopes that they will cover simple cases that may arise from 408 scenarios beyond those envisioned today. However, for more complex 409 scenarios, or simple scenarios where appropriate conflict resolution 410 strategies differ from those discussed in this document, a document 411 detailing the usage scenarios and appropriate conflict resolution 412 strategies SHOULD be created and submitted for discussion and 413 approval. 415 5. Relay Agent Behavior 417 A relay agent which receives a DHCP request from a DHCP client on a 418 VPN SHOULD include Virtual Subnet Selection information in the DHCP 419 packet prior to forwarding the packet on to the DHCP server unless 420 inhibited from doing so by configuration information or policy to the 421 contrary. 423 A DHCPv4 relay agent SHOULD include a DHCPv4 VSS sub-option in a 424 relay-agent-information option [RFC3046], while a DHCPv6 relay agent 425 SHOULD include a DHCPv6 VSS option in the Relay-forward message. 427 The value placed in the Virtual Subnet Selection sub-option or option 428 SHOULD be sufficient for the relay agent to properly route any DHCP 429 reply packet returned from the DHCP server to the DHCP client for 430 which it is destined. 432 Since this option or sub-option is placed in the packet in order to 433 specify the VPN on which an IP address is allocated for a particular 434 DHCP client, one presumes that an allocation on that VPN is necessary 435 for correct operation. If this presumption is correct, then a relay 436 agent which places this option in a packet and doesn't receive it (or 437 receives a different value than that sent to the server) in the 438 returning packet should drop the packet since the IP address that was 439 allocated will not be in the correct VPN. If an IP address that is 440 not on the requested VPN is not required, then the relay agent is 441 free to accept the IP address that is not on the VPN that was 442 requested. 444 The converse, however, is more complicated. In the DHCPv6 case, the 445 appearance of the option in the Relay-reply packet does indeed 446 indicate that the DHCPv6 server understood and acted upon the 447 contents of the VSS option in the Relay-forward packet. In the 448 DHCPv4 case, however, the appearance of the sub-option in the relay- 449 agent-information option received by the relay agent does not 450 necessarily indicate that the DHCPv4 server even understood, let 451 alone acted correctly upon, the VSS sub-option that it received. 453 The reason is that [RFC3046] specifies that a DHCPv4 server which 454 supports the relay-agent-information option SHALL copy all sub- 455 options received in a relay-agent-information option into any 456 outgoing relay-agent-information option. Because of these 457 requirements, even a DHCPv4 server which doesn't implement support 458 for Virtual Subnet Selection sub-option will almost certainly copy it 459 into the outgoing relay-agent-information option. This means that 460 the appearance of the Virtual Subnet Selection sub-option in a 461 relay-agent-information option doesn't indicate support for the 462 Virtual Subnet Selection sub-option. 464 There are only two pieces of information which can be determined from 465 the appearance or lack of appearance of the DHCPv4 Virtual Subnet 466 Selection sub-option in a relay-agent-information option received by 467 a relay agent from a DHCPv4 server. First, if the Virtual Subnet 468 Selection sub-option does not appear, then the server was able to 469 support this sub-option but chose not to do so. Second, if the 470 Virtual Subnet Selection sub-option appears and has a different value 471 than the one originally included in the relay-agent-information 472 option, then the DHCP server was able to support this sub-option and 473 allocated an address using different VSS information than was 474 originally provided by the relay agent. 476 Thus, if a DHCPv4 relay agent has a requirement to determine if the 477 address allocated by a DHCPv4 server is on a particular VPN, it must 478 use some other approach than the appearance of the VSS sub-option in 479 the reply packet to make this determination. 481 This document does not create a requirement that a relay agent 482 remember the contents of a VSS DHCPv4 sub-option or VSS DHCPv6 option 483 sent to a DHCP server. In many cases, the relay agent may simply use 484 the value of the VSS returned by the DHCP server to forward the 485 response to the DHCP client. If the VSS information, the IP address 486 allocated, and the VPN capabilities of the relay agent all 487 interoperate correctly, then the DHCP client will receive a working 488 IP address. Alternatively, if any of these items don't interoperate 489 with the others, the DHCP client will not receive a working address. 491 Note that in some environments a relay agent may choose to always 492 place a VSS option or sub-option into packets and messages that it 493 forwards in order to forestall any attempt by a downstream relay 494 agent or client to specify VSS information. In this case, a type 495 field of 255 is used to denote the global, default VPN. When the 496 type field of 255 is used, there MUST NOT be any additional VSS 497 Information in the VSS option. 499 5.1. VPN assignment by the DHCP server 501 In some cases, a DHCP server may use the Virtual Subnet Selection 502 sub-option or option to inform a relay agent that a particular DHCP 503 client is associated with a particular VPN. It does this by sending 504 the Virtual Subnet Selection sub-option or option with the 505 appropriate information to the relay agent in the relay-agent- 506 information option for DHCPv4 or the Relay-reply message in DHCPv6. 507 If the relay agent is unable to honor the DHCP server's requirement 508 to place the DHCP client into that VPN it MUST drop the packet and 509 not send it to the DHCP client. 511 In this situation, once the relay agent has placed the DHCP client 512 into the VPN specified by the DHCP server, it will send in a VSS 513 option or sub-option when forwarding packets from the client. The 514 DHCP server in normal operation will echo this VSS information into 515 the outgoing replies. 517 5.2. DHCP Leasequery 519 Sometimes a relay-agent needs to submit a DHCP Leasequery [RFC4388] 520 [RFC5007] packet to the DHCP server in order to recover information 521 about existing DHCP allocated IP addresses on other than the normal, 522 global VPN. In the context of a DHCP Leasequery the relay agent is a 523 direct client of the DHCP server and is not relaying a packet for 524 another DHCP client. Thus, the instructions in Section 6 on Client 525 Behavior should be followed to include the necessary VSS information. 527 6. Client Behavior 529 A DHCPv4 or DHCPv6 client will employ the VSS option to communicate 530 VSS information to their respective servers. This information MUST 531 be included in every message concerning any IP address on a different 532 VPN than the global or default VPN. A DHCPv4 client will place the 533 DHCPv4 VSS option in its packets, and a DHCPv6 client will place the 534 DHCPv6 VSS option in its messages. 536 A DHCPv6 client that needs to place a VSS option into a DHCPv6 537 message SHOULD place a single VSS option into the DHCPv6 message at 538 the same level as the Client Identifier option. A DHCPv6 client MUST 539 NOT include different VSS options in the same DHCPv6 message. 541 Note that, as mentioned in Section 1, throughout this document when a 542 DHCPv6 address is indicated the same information applies to DHCPv6 543 Prefix Delegation [RFC3633] as well. 545 Since this option is placed in the packet in order to change the VPN 546 on which an IP address is allocated for a particular DHCP client, one 547 presumes that an allocation on that VPN is necessary for correct 548 operation. If this presumption is correct, then a client which 549 places this option in a packet and doesn't receive it or receives a 550 different value in the returning packet should drop the packet since 551 the IP address that was allocated will not be in the correct VPN. If 552 an IP address that is not on the requested VPN is not required, then 553 the client is free to accept the IP address that is not on the VPN 554 that the was requested. 556 Clients should be aware that some DHCP servers will return a VSS 557 option with different values than that which was sent in. In 558 addition, a client may receive a response from a DHCP server with a 559 VSS option when none was sent in by the Client. 561 Note that when sending a DHCP Leasequery request, a relay agent is 562 acting as a DHCP client and so it should include the respective 563 DHCPv4 or DHCPv6 VSS option in its DHCPv4 or DHCPv6 Leasequery packet 564 if the DHCP Leasequery request is generated for other than the 565 default, global VPN. It should not include a DHCPv4 sub-option in 566 this case. 568 7. Server Behavior 570 A DHCP server receiving the VSS option or sub-option SHOULD allocate 571 an IP address (or use the VSS information to access an already 572 allocated IP address) from the VPN specified by the included VSS 573 information. 575 In the case where the type field of the VSS option or sub-option is 576 255, the VSS option denotes the global, default VPN. In this case, 577 there is no explicit VSS information beyond the type field. 579 This document does not prescribe any particular address allocation 580 policy. A DHCP server may choose to attempt to allocate an address 581 using the VSS information and, if this is impossible, to not allocate 582 an address. Alternatively, a DHCP server may choose to attempt 583 address allocation based on the VSS information and, if that is not 584 possible, it may fall back to allocating an address on the global or 585 default VPN. This, of course, is also the apparent behavior of any 586 DHCP server which doesn't implement support for the VSS option and 587 sub-option. Thus, DHCP clients and relay agents SHOULD be prepared 588 for either of these alternatives. 590 In some cases, a DHCP server may use the Virtual Subnet Selection 591 sub-option or option to inform a relay agent that a particular DHCP 592 client is associated with a particular VPN. It does this by sending 593 the Virtual Subnet Selection sub-option or option with the 594 appropriate information to the relay agent in the relay-agent- 595 information option for DHCPv4 or the Relay-reply message in DHCPv6. 597 In this situation, the relay agent will place the client in the 598 proper VPN, and then it will send in a VSS option or sub-option in 599 subsequent forwarded requests. The DHCP server will see this VSS 600 information and since it doesn't conflict in any way with the 601 server's notion of the VPN on which the client is supposed to reside, 602 it will process the requests based on the VPN specified in the VSS 603 option or sub-option, and echo the same VSS information in the 604 outgoing replies. 606 In a similar manner, a DHCP server may use the Virtual Subnet 607 Selection option to inform a DHCP client that the address (or 608 addresses) it allocated for the client is on a particular VPN. 610 In either case above, care should be taken to ensure that a client or 611 relay agent receiving a reply containing a VSS option will correctly 612 understand the VSS option. Otherwise, the client or relay agent will 613 end up using the address as though it were a global address. 615 7.1. Returning the DHCPv4 or DHCPv6 Option 617 DHCPv4 or DHCPv6 servers receiving a VSS option (for sub-option 618 processing, see below) MUST return an instance of this option in the 619 reply packet or message if the server successfully uses this option 620 to allocate an IP address, and it MUST NOT include an instance of 621 this option if the server was unable to or not configured to support 622 the requested VPN. 624 If they echo the option (based on the criteria above), servers SHOULD 625 return the an exact copy of the option unless they desire to change 626 the VPN on which a client was configured. 628 7.2. Returning the DHCPv4 Sub-Option 630 The case of the DHCPv4 sub-option is a bit more complicated. Note 631 that [RFC3046] specifies that a DHCPv4 server which supports the 632 relay-agent-information option SHALL copy all sub-options received in 633 a relay-agent-information option into any outgoing relay-agent- 634 information option. Thus, the default behavior for any DHCPv4 server 635 is to return any VSS sub-option received to the relay agent whether 636 or not the DHCPv4 server understand the VSS sub-option. A server 637 which implements the VSS sub-option MUST include the VSS sub-option 638 in the relay-agent-information option in the reply packet if it 639 successfully acted upon the VSS information in the incoming VSS sub- 640 option. 642 Moreover, if a server uses different VSS information to allocate an 643 IP address than it receives in a particular DHCPv4 sub-option, it 644 MUST include that alternative VSS information in a sub-option that it 645 returns to the DHCPv4 relay agent. 647 If a DHCPv4 server supports this sub-option and for some reason 648 (perhaps administrative control) does not honor this sub-option from 649 the request then it MUST NOT echo this sub-option in the outgoing 650 relay-agent-information option. 652 Note that the appearance of the VSS sub-option in a reply packet from 653 a DHCPv4 server to a relay-agent does not communicate any useful 654 information about whether or not the server used the VSS sub-option 655 in its processing. However, the absence of a VSS sub-option in a 656 reply from a DHCPv4 server when a VSS sub-option was included in a 657 request to the DHCPv4 server is significant, and means that the 658 server did not use the VSS information present in the sub-option in 659 its processing. 661 7.3. Making sense of conflicting VSS information 663 It is possible for a DHCPv4 server to receive both a VSS option and a 664 VSS sub-option in the same packet. Likewise, a DHCPv6 server can 665 receive multiple VSS options in nested Relay-forward messages as well 666 as in the client message itself. In either of these cases, the VSS 667 information from the relay agent closest to the DHCP server SHOULD be 668 used in preference to all other VSS information received. In the 669 DHCPv4 case, this means that the VSS sub-option takes precedence over 670 the VSS option, and in the DHCPv6 case, this means that the VSS 671 option from the outer-most Relay-forward message in which a VSS 672 option appears takes precedence. 674 The reasoning behind this approach is that the relay-agent closer to 675 the DHCP server is almost certainly more trusted than the DHCP client 676 or more distant relay agents, and therefore information in the 677 relay-agent-information option or the Relay-forward message is more 678 likely to be correct. 680 In general, relay agents SHOULD be aware through configuration or 681 policy external to this document whether or not they should be 682 including VSS information in packets that they forward and so there 683 should not be conflicts among relay agent specified VSS information. 685 In these situations where multiple VSS option or sub-options appear 686 in the incoming packet or message, when constructing the response to 687 be sent to the DHCP client or relay agent, all existing VSS options 688 or sub-options MUST be replicated in the appropriate places in the 689 response and MUST contain the VSS information that was used by the 690 DHCP server to allocate the IP address. 692 8. Security 694 Message authentication in DHCPv4 for intradomain use where the out- 695 of-band exchange of a shared secret is feasible is defined in 696 [RFC3118]. Potential exposures to attack are discussed in section 7 697 of the DHCP protocol specification in [RFC2131]. 699 Implementations should consider using the DHCPv4 Authentication 700 option [RFC3118] to protect DHCPv4 client access in order to provide 701 a higher level of security if it is deemed necessary in their 702 environment. 704 Message authentication in DHCPv4 relay agents as defined in [RFC4030] 705 should be considered for DHCPv4 relay agents employing this sub- 706 option. Potential exposures to attack are discussed in section 7 of 707 the DHCP protocol specification in [RFC2131]. 709 For DHCPv6 use of the VSS option, the "Security Considerations" 710 section of [RFC3315] details the general threats to DHCPv6, and thus 711 to messages using the VSS option. The "Authentication of DHCP 712 Messages" section of [RFC3315] describes securing communication 713 between relay agents and servers, as well as clients and servers. 715 The VSS option could be used by a client in order to obtain an IP 716 address from a VPN other than the one where it should. This option 717 would allow a client to perform a more complete address-pool 718 exhaustion attack since the client would no longer be restricted to 719 attacking address-pools on just its local subnet. 721 A DHCP server that implements these options and sub-option should be 722 aware of this possibility and use whatever techniques that can be 723 devised to prevent such an attack. Information such as the giaddr in 724 DHCPv4 or link address in the Relay-forward DHCPv6 message might be 725 used to detect and prevent this sort of attack. 727 One possible defense would be for the DHCP relay to insert a VSS 728 option or sub-option to override the DHCP client's VSS option. 730 Servers that implement the VSS option and sub-option MUST by default 731 disable use of the feature; it must specifically be enabled through 732 configuration. Moreover, a server SHOULD provide the ability to 733 selectively enable use of the feature under restricted conditions, 734 e.g., by enabling use of the option only from explicitly configured 735 client-ids, enabling its use only by clients on a particular subnet, 736 or restricting the VSSs from which addresses may be requested. 738 9. IANA Considerations 740 IANA is requested to assign DHCPv4 option number 221 for the DHCPv4 741 VSS option defined in Section 3.1, in accordance with [RFC3942]. 743 IANA is requested to assign sub-option number 151 for the DHCPv4 744 sub-option defined in Section 3.2 from the DHCP Relay Agent Sub- 745 options space [RFC3046], in accordance with the spirit of [RFC3942]. 746 While [RFC3942] doesn't explicitly mention the sub-option space for 747 the DHCP Relay Agent Information option [RFC3046], sub-option 151 is 748 already in use by existing implementations of this sub-option and the 749 current draft is essentially compatible with these current 750 implementations. 752 IANA has assigned the value of TBD for the DHCPv6 VSS option defined 753 in Section 3.3. 755 While the type byte defined in Section 3.4 defines a number space 756 that could be managed by IANA, expansion of this number space is not 757 anticipated and so creation of a registry of these numbers is not 758 required by this document. In the event that additional values for 759 the type byte are defined in subsequent documents, IANA should at 760 that time create a registry for these type bytes. New values for the 761 type byte may only be defined by IETF Consensus, as described in 762 [RFC5226]. Basically, this means that they are defined by RFCs 763 approved by the IESG. 765 10. Acknowledgments 767 Bernie Volz recommended consolidation of the DHCPv4 option and sub- 768 option drafts after extensive review of the former drafts, and 769 provided valuable assistance in structuring and reviewing this 770 document. Alper Yegin expressed interest in the DHCPv6 VSS option, 771 resulting in this combined draft covering all three areas. 773 11. Normative References 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", RFC 2119, March 1997. 778 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 779 March 1997. 781 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 782 Extensions", RFC 2132, March 1997. 784 [RFC2685] Fox, B., Gleeson, B., "Virtual Private Networks 785 Identifier", RFC 2685, September 1999. 787 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 788 3046, January 2001. 790 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and 791 M. Carney, "Dynamic Host Configuration Protocol for IPv6 792 (DHCPv6)", RFC 3315, July 2003. 794 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 795 Host Configuration Protocol (DHCP) version 6", RFC 3633, December 796 2003. 798 12. Informative References 800 [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 801 September 1985. 803 [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap 804 Protocol", RFC 1542, October 1993. 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", RFC 2119, March 1997. 809 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 810 Messages", RFC 3118, June 2001. 812 [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration 813 Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004. 815 [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for 816 the Dynamic Host Configuration Protocol (DHCP) Relay Agent 817 Option", RFC 4030, March 2005. 819 [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration 820 Protocol (DHCP) Leasequery", RFC 4388, February 2006. 822 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 823 Leasequery", RFC 5007, September 2007. 825 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 826 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 828 13. Authors' Addresses 830 Kim Kinnear 831 Cisco Systems 832 1414 Massachusetts Ave. 833 Boxborough, Massachusetts 01719 835 Phone: (978) 936-0000 837 EMail: kkinnear@cisco.com 838 Richard Johnson 839 Cisco Systems 840 170 W. Tasman Dr. 841 San Jose, CA 95134 843 Phone: (408) 526-4000 845 EMail: raj@cisco.com 847 Mark Stapp 848 Cisco Systems 849 1414 Massachusetts Ave. 850 Boxborough, Massachusetts 01719 852 Phone: (978) 936-0000 854 EMail: mjs@cisco.com 856 Jay Kumarasamy 857 Cisco Systems 858 170 W. Tasman Dr. 859 San Jose, CA 95134 861 Phone: (408) 526-4000 863 EMail: jayk@cisco.com 865 14. Full Copyright Statement 867 Copyright (C) The IETF Trust (2008). 869 This document is subject to the rights, licenses and restrictions 870 contained in BCP 78, and except as set forth therein, the authors 871 retain all their rights. 873 This document and the information contained herein are provided on an 874 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 875 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 876 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 877 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 878 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 879 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 881 15. Intellectual Property 883 The IETF takes no position regarding the validity or scope of any 884 Intellectual Property Rights or other rights that might be claimed to 885 pertain to the implementation or use of the technology described in 886 this document or the extent to which any license under such rights 887 might or might not be available; nor does it represent that it has 888 made any independent effort to identify any such rights. Information 889 on the procedures with respect to rights in RFC documents can be 890 found in BCP 78 and BCP 79. 892 Copies of IPR disclosures made to the IETF Secretariat and any 893 assurances of licenses to be made available, or the result of an 894 attempt made to obtain a general license or permission for the use of 895 such proprietary rights by implementers or users of this 896 specification can be obtained from the IETF on-line IPR repository at 897 http://www.ietf.org/ipr. 899 The IETF invites any interested party to bring to its attention any 900 copyrights, patents or patent applications, or other proprietary 901 rights that may cover technology that may be required to implement 902 this standard. Please address the information to the IETF at 903 ietf-ipr@ietf.org. 905 16. Acknowledgment 907 Funding for the RFC Editor function is provided by the IETF 908 Administrative Support Activity (IASA).