RFC 6607
Virtual Subnet Selection Options for DHCPv4 and DHCPv6
Internet Engineering Task Force (IETF) 🎀 RFC 6607: Virtual Subnet Selection Options for DHCPv4 and DHCPv6 💖
Okay bestie, let's get into it. ✨ This one is RFC 6607, published in April 2012 as a Standards Track document. It was written by K. Kinnear, R. Johnson, and M. Stapp, all from Cisco Systems. 🦋 It's an IETF document, the ISSN is 2070-1721, and it Updates: 3046, which means it changes the rules from RFC 3046 about copying sub-options. 💅 It doesn't obsolete anything, so no drama there. 🫶
Abstract
So here's the tea. 🍓 This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, a DHCPv6 VSS option, and the DHCPv4 VSS and VSS-Control sub-options that ride inside the DHCPv4 Relay Agent Information option. 🌸 These are meant for DHCP clients, relay agents, and proxy clients in situations where VSS info has to reach the DHCP server so it can allocate the right address or prefix. 💜 For the DHCPv4 option and the Relay Agent Information sub-options, this memo writes down and extends how people are already using them, as described in RFC 3942. 🧚 It also updates RFC 3046 about copying sub-options (see Section 8). 🔥
Status of This Memo
This is an Internet Standards Track document. 🌈
This document is a product of the Internet Engineering Task Force (IETF). ✨ It represents the consensus of the IETF community. 💖 It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). 👑 For more on Internet Standards, check Section 2 of RFC 5741. 🎀
Info about the current status of this document, any errata, and how to give feedback can be found at:
http://www.rfc-editor.org/info/rfc6607
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🦋
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. 💅 Please review these carefully, because they describe your rights and restrictions. 🫶 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. 🌸
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. 😭 The people controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. 🙈 So unless you get an adequate license from them, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it either, except to format it for publication as an RFC or to translate it into languages other than English. 💜
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Virtual Subnet Selection Options and Sub-Options: Definitions ...6
3.1. DHCPv4 Virtual Subnet Selection Option .....................6
3.2. DHCPv4 Virtual Subnet Selection Sub-Option .................6
3.3. DHCPv4 Virtual Subnet Selection Control Sub-Option .........7
3.4. DHCPv6 Virtual Subnet Selection Option .....................7
3.5. Virtual Subnet Selection Type and Information ..............8
4. Overview of Virtual Subnet Selection Usage ......................8
4.1. VPN Assignment by the DHCP Relay Agent .....................9
4.2. VPN Assignment by the DHCP Server .........................12
4.3. Required Support ..........................................14
4.4. Alternative VPN Assignment Approaches .....................14
5. Relay Agent Behavior ...........................................15
5.1. VPN Assignment by the DHCP Server .........................16
5.2. DHCP Leasequery ...........................................17
6. Client Behavior ................................................17
7. Server Behavior ................................................19
7.1. Returning the DHCPv4 or DHCPv6 Option .....................20
7.2. Returning the DHCPv4 Sub-Option ...........................20
7.3. Making Sense of Conflicting VSS Information ...............21
8. Update to RFC 3046 .............................................22
9. Security Considerations ........................................22
10. IANA Considerations ...........................................23
11. Acknowledgments ...............................................24
12. References ....................................................25
12.1. Normative References .....................................25
12.2. Informative References ...................................251. Introduction ✨
There's a growing use of Virtual Private Network (VPN) configurations, and it's coming from everywhere. 🌍 Individual client systems need to look like they're on the home corporate network even when they're traveling, and ISPs provide extranet connectivity for customer companies, etc. 💼 In some of these cases the DHCP server needs to know which VPN (also called a "Virtual Subnet Selector" or "VSS" in this document) an address, and other resources, should come from. 🎀
This memo defines a DHCPv4 VSS option, a DHCPv6 VSS option, and two VSS sub-options carried in the DHCPv4 Relay Agent Information option. 🦋 These are for DHCP clients, relay agents, and proxy clients in situations where VSS info needs to reach the DHCP server for proper address or prefix allocation. 💖 If the receiving DHCP server understands the VSS option or sub-options, it can use that info together with other info to pick the subnet for the address, along with things like DNS server, default router, and so on. 🧚
If the allocation goes through a DHCPv4 relay, the Relay Agent Information sub-options defined here should be included. 🌸 Sometimes, though, an IP address is being requested by a DHCPv4 proxy on behalf of a client (which might get its address through a different protocol). 🙈 In that case, the VSS info about the client needs to go in as a DHCPv4 option. 💅
If the allocation goes through a DHCPv6 relay, the DHCPv6 VSS option defined in this document should be included in the Relay-forward and Relay-reply messages going between the DHCPv6 relay and server. 🫶 Sometimes addresses or prefixes are requested by a DHCPv6 proxy on behalf of a client. 🌈 In that case the client itself has to supply the VSS info using the DHCPv6 VSS option in the messages it sends to the DHCPv6 server. ✨
In the rest of this document, whenever a DHCPv6 address is mentioned, the same info applies to DHCPv6 prefix delegation [RFC3633] too. 👑
Also, whenever the rest of the doc says "VSS sub-option," it means the VSS sub-option carried in the DHCPv4 Relay Agent Information option. 💜
2. Terminology 📚
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🔥
This document uses the following terms: 🎀
- DHCP client 🦋 A DHCP client is a host using DHCP to obtain configuration parameters such as a network address.
- DHCP proxy 💖 A DHCP proxy is a DHCP client that acquires IP addresses not for its own use but on behalf of another entity. 🧚 There are a variety of ways a DHCP proxy can hand the addresses it acquires over to the other entities that need them. 🌸
- DHCP relay agent 💅 A DHCP relay agent is an agent that transfers BOOTP and DHCP messages between clients and servers residing on different subnets, per [RFC951], [RFC1542], and [RFC3315]. 🫶
- DHCP server 🌈 A DHCP server is a host that returns configuration parameters to DHCP clients. ✨
- DHCPv4 option 👑 A DHCPv4 option is an option used to implement a capability defined by the DHCPv4 RFCs ([RFC2131] [RFC2132]). 💜 This option has one-octet code and size fields. 🔥
- DHCPv4 sub-option 🎀 As used in this document, a DHCPv4 sub-option refers to a sub-option of the Relay Agent Information option [RFC3046]. 🦋 This sub-option has one-octet code and size fields. 💖
- DHCPv6 option 🧚 A DHCPv6 option is an option used to implement a capability defined by the DHCPv6 RFC [RFC3315]. 🌸 This option has two-octet code and size fields. 🙈
- Global VPN 💅 This term means the address being described belongs to the set of addresses that are not part of any VPN, meaning the normal address space DHCP operates on. 🫶 This includes private addresses, like the 10.x.x.x addresses and other private subnets that aren't routed on the open Internet. 🌈
- NVT ASCII identifier ✨ A Network Virtual Terminal (NVT) identifier is an identifier containing only characters from the ASCII repertoire and using the Network Virtual Terminal encoding (see Appendix B of [RFC5198]). 👑
- VSS information 💜 VSS information provides information about a VPN that's needed to allocate an address to a DHCP client on that VPN, and also needed to forward a DHCP reply packet to a DHCP client on that VPN. 🔥
- VPN 🎀 This term refers to a virtual private network. 🦋 A VPN appears to the client to be a private network. 💖
- VPN identifier 🧚 The VPN-ID is defined by [RFC2685] to be a sequence of 7 octets. 🌸
3. Virtual Subnet Selection Options and Sub-Options: Definitions 🎀
The VSS options and sub-options contain a generalized way to specify the VSS information about a VPN. 💅 There are two options and two sub-options defined in this section. 🫶 The actual VSS information is identical for both options and for one of the two sub-options. 🌈
3.1. DHCPv4 Virtual Subnet Selection Option 🦋
The format of the option is shown below. 💖
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Type | VSS Info. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Code 🧚 The option code (221).
- Length 🌸 The option length, minimum 1 octet.
- Type and VSS Information 🙈 See Section 3.5.
3.2. DHCPv4 Virtual Subnet Selection Sub-Option 💅
This is a sub-option of the Relay Agent Information option [RFC3046]. 🫶 The format of the sub-option is shown below. 🌈
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Type | VSS Info. ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Code ✨ The sub-option code (151).
- Length 👑 The sub-option length, minimum 1 octet.
- Type and VSS Information 💜 See Section 3.5.
To be continued in part 2! 🔮 Stay tuned, bestie, because we're only getting started with sections 3.3 onward. 💖
3.3. DHCPv4 Virtual Subnet Selection Control Sub-Option ✨
okay so this one is a sub-option that lives inside the Relay Agent Information option [RFC3046] 💅. Here's the layout:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code: the sub-option code, which is 152 🔥Length: the sub-option length, which is 0
This one only shows up in the DHCPv4 Relay Agent Information option 🫶. In a DHCP request, it's basically saying "heads up, a DHCPv4 VSS sub-option is also in this Relay Agent Information option." In a DHCP reply, if it shows up in the Relay Agent Information option, it means the DHCP server didn't understand any DHCPv4 VSS sub-option that's also in that option 💀.
3.4. DHCPv6 Virtual Subnet Selection Option 🦋
the DHCPv6 VSS option looks like this 👑. A client or relay agent (or both!) may include it 💜.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_VSS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | VSS Information ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+option-code:OPTION_VSS(68) 🌸option-len: the number of octets in the option, minimum 1- Type and VSS Information: see Section 3.5
3.5. Virtual Subnet Selection Type and Information 💖
every (sub-)option we've covered that carries VSS information uses the same payload: a Type value plus the VSS information, like so 🍓
Type VSS Information Format
------------------------------------------------------------
0 Network Virtual Terminal (NVT) ASCII VPN identifier
1 RFC 2685 VPN-ID
2-254 Unassigned
255 Global, default VPN- Type 0 -- Network Virtual Terminal (NVT) ASCII VPN identifier: the VSS information is an NVT ASCII string. It MUST NOT be terminated with a zero byte 🙈
- Type 1 -- RFC 2685 VPN-ID: the VSS information is an RFC 2685 VPN-ID [RFC2685], which is 7 octets long 🧚
- Type 255 -- Global, default VPN: there's no explicit VSS information here. This just means the option points at the normal, global, default address space. In this case, there MUST NOT be any VSS information in the VSS option or sub-option, and the length of the option or sub-option MUST be 1 👑
All other values of the Type field are unassigned. Don't use them, bestie 🚫
4. Overview of Virtual Subnet Selection Usage 🌈
at the highest level, the VSS option or sub-option decides which VPN a DHCP client should get its IP address on ✨. The rest of the discussion is basically about figuring out that VPN. This affects the relay agent, because it has to make sure DHCP packets going to and coming from the client flow over the correct VPN 🛸. It also affects the DHCP server, because the server is the one deciding which IP address space the allocation comes from 💅.
A DHCP server has some IP address space in its configuration that it hands out to DHCP clients 🎀. These allocations are usually for a limited time, so the client gets a lease on its address. When there's no VPN information at all, the address space is the global or default VPN that's used across the whole Internet 🌍. When a DHCP server deals with VPN information, each VPN creates a brand new address space inside the server, separate from the global or default one 🦋. A server that supports the VSS option or sub-option can therefore allocate IP addresses from multiple different VPNs. That means the DHCP server must be prepared to configure multiple different address spaces (one per distinct VPN) and allocate IP addresses from each of them 🫶.
These address spaces are usually independent. The same IP address (the same string of bytes) could go to one client in the global, default VPN and to a totally different client in another VPN, and nobody's confused 😭. The clients have different addresses in practice, even though the bytes match, because the IPv4 or IPv6 address is qualified by its VPN 💜.
So a VSS option or sub-option is basically a way of saying "use this VPN, not the global or default one" 🔥. That raises the big question: who decides which VPN a DHCP client should be using? 🤔
There are three entities that can put a VSS option or sub-option into a DHCPv4 packet or DHCPv6 message: the DHCP client, a relay agent, or a DHCPv4 or DHCPv6 server 👑. Technically every one of them could add a different VSS option or sub-option to every request or response, but that's not typical and it's not all that useful 💀. There are two known paradigms for using the VSS option or sub-option, and we'll get into them below 🧚
4.1. VPN Assignment by the DHCP Relay Agent ✨
okay so the usual move with VSS is that the relay agent is the one who knows which VPN the DHCP client is on 🌸. The client itself has no clue which VPN it's vibing on, not in this approach 🙈. The relay agent is basically the bouncer 💅, mediating access between the VPN the client lives on and the DHCP server. It adds two DHCPv4 Relay Agent Information sub-options (one VSS sub-option and one VSS-Control sub-option) into the Relay Agent Information option, or a DHCPv6 VSS option into the Relay-forward message of every request it forwards from the client. The server reads the DHCPv6 VSS option or DHCPv4 VSS sub-option to figure out the client's VPN, then uses that info to pick the address space in its config to hand out an IP address from. iconic, right? 😭
When a DHCPv4 relay agent puts a VSS sub-option into the Relay Agent Information option, it MUST also insert a VSS-Control sub-option into that same option 🔥. This lets everyone check whether the DHCPv4 server actually processed the VSS info the relay sent. If the DHCPv4 server supports the VSS capabilities in this document, it removes the VSS-Control sub-option from the Relay Agent Information option it sends back to the relay agent. See Section 5 for more info 🎀.
In this approach, the relay agent might also send a VSS option or sub-option in a DHCPv4 or DHCPv6 Leasequery request [RFC4388] [RFC5007]. In that case it uses the VSS option in the Leasequery request to select the correct address space for the Leasequery. So the relay agent is acting like a DHCP client from a leasequery point of view, but it's not the same thing as a client sending VSS in a normal address allocation request, like a DHCPDISCOVER 🦋.
Only one relay agent mediates the VPN access between the client and the server here. That relay agent is the one that inserts the VSS information into the request packet, and it's also the one that removes it before forwarding the response packet 🫶.
The diagram below shows an example of a DHCPv4 client, DHCPv4 relay agent, and DHCPv4 server. The DHCPv6 situation is similar but uses the DHCPv6 VSS option.
DHCPv4
DHCPv4 Relay DHCPv4
Client Agent Server
| | |
| >--DHCPDISCOVER--> | |
| on VPN "abc" | |
| | >--DHCPDISCOVER----> |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | VSS-Control |
| | |
| | <----DHCPOFFER-----< |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | |
| <---DHCPOFFER----< | |
| on VPN "abc" | |
| | |
| >--DHCPREQUEST---> | |
| on VPN "abc" | |
| | >--DHCPREQUEST-----> |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | VSS-Control |
| | |
| | <----DHCPACK-------< |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | |
| <---DHCPACK------< | |
| on VPN "abc" | |
| | |
... ... ...
Figure 4.1-1: DHCPv4 - Relay Agent Knows VPNThe DHCP server knows it should respond to VPN information given in a VSS option or sub-option. It's also configured with the appropriate VPN address spaces to serve the expected client requirements. So in this common approach, the DHCP client knows nothing about VPN access 💜. The relay agent has been configured somehow to figure out the client's VPN and send that along in a VSS option or sub-option. The DHCP server then responds to the VPN the relay agent specified. There's no conflict between entities trying to specify different VSS information, because each entity knows its role through policy or configuration outside this document 👑.
If any misconfiguration exists, it SHOULD result in a DHCP client being unable to acquire an IP address. For instance, a relay agent that supports VPN access SHOULD couple transmission of VSS options or sub-options to the configuration of VPN support, and it shouldn't allow one without the other 💀. Hmm, the same, let me write it properly:
If any misconfiguration exists, it SHOULD result in a DHCP client being unable to acquire an IP address. For instance, a relay agent that supports VPN access SHOULD couple transmission of VSS options or sub-options to the configuration of VPN support, and not allow one without the other 💀.
It's important that the relay agent and DHCP server both support the VSS option and sub-options (for DHCPv4) or the VSS option (for DHCPv6). Deploying DHCPv4 relay agents that support and emit VSS sub-options alongside DHCPv4 servers that don't support the VSS option or sub-option as defined in this document SHOULD NOT be done, because that ensemble won't operate correctly 🙅♀️. If this does happen, the relay agent can still detect the problem, since the VSS-Control sub-option will show up in the packets it receives from the DHCPv4 server, which means the server didn't effectively process the VSS sub-option. The relay agent can then issue appropriate diagnostic messages 🧚.
4.2. VPN Assignment by the DHCP Server 🌈
In this approach, the DHCP server is configured in some way to know which VPN a particular DHCP client should get access to. In this case the server includes the VSS sub-option in the Relay Agent Information option for DHCPv4, or the VSS option in the Relay-reply message for DHCPv6. The relay agent responsible for mediating VPN access uses that info to select the correct VPN for the DHCP client. In the unusual event that more than one relay agent is involved in this transaction, some external configuration or policy would be needed to tell the DHCPv6 server which Relay-reply message gets the VSS option 🍓.
Once the relay agent has placed the DHCP client into the proper VPN, it SHOULD begin including VSS information in requests that it forwards to the DHCP server. Since this info doesn't conflict with the DHCP server's idea of the proper VPN for the client, everything works correctly ✨.
The diagram below shows this approach using DHCPv4. The DHCPv6 situation is similar but uses the DHCPv6 VSS option instead.
DHCPv4
DHCPv4 Relay DHCPv4
Client Agent Server
| | |
| >--DHCPDISCOVER--> | |
| on unknown VPN | |
| | >--DHCPDISCOVER----> |
| | |
| | <----DHCPOFFER-----< |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | |
| <---DHCPOFFER----< | |
| on VPN "abc" | |
| | |
| >--DHCPREQUEST---> | |
| on VPN "abc" | |
| | >--DHCPREQUEST-----> |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | VSS-Control |
| | |
| | <----DHCPACK-------< |
| | Relay Agent Info: |
| | VSS type 0:"abc" |
| | |
| <---DHCPACK------< | |
| on VPN "abc" | |
| | |
| | |
... ... ...
Figure 4.2-1: DHCPv4 - DHCPv4 Server Knows VPNHere the DHCP client is still totally unaware of any VPN stuff 🦋. This time, though, the DHCP server knows the client's VPN, and the relay agent responds to the VSS info the server specifies. Same as the last approach, each entity knows its role through something outside this document, and no two entities try to specify conflicting VSS info 🫶.
It's important that both the relay agent and the DHCP server support the VSS option and sub-options (for DHCPv4) and the VSS option (for DHCPv6). Deploying and configuring VPN support in one element but not the other is not a practical approach 🙈.
4.3. Required Support 👑
DHCP relay agents and servers MUST support the approach discussed in Section 4.1. DHCP relay agents and servers SHOULD support the approach discussed in Section 4.2. DHCP relay agents and servers SHOULD NOT be configured to operate with both approaches simultaneously 💅.
4.4. Alternative VPN Assignment Approaches
okay so there are literally so many other setups you could build 🧚 like multiple relay agents each stuffing VSS info into different Relay-forward messages, or relay agent VSS info clashing with client VSS info, or DHCP server VSS info fighting with both the relay agent and the client 😭 BUT these don't really come up as useful today, so nailing down exactly how to settle every single one of these fights probably won't be worth it if they ever become practical 💅
Everyone needs to know their role. Right now the VSS option and sub-option only work if each entity knows the part it plays with VPN data 🫶 The client, the relay agent (or agents), and the server all SHOULD know, through some policy or configuration outside the scope of this document, whether they're the one specifying VPN information using the VSS option or sub-option, whether they're supposed to respond to VSS information another entity specified, or whether they should just ignore any VSS information they happen to see.
Some simple conflict-resolution ideas are discussed below, in the hopes they'll cover the easy cases that might pop up from situations we haven't imagined yet 🦋 But for more complex situations, or simple ones where the right conflict-resolution strategy is different from what's in this document, a document describing the usage situations and appropriate conflict-resolution strategies SHOULD be created and submitted for discussion and approval 👑
5. Relay Agent Behavior 🎀
Implementers MAY provide a policy or configuration capability to enable or disable VSS support.
A relay agent that receives a DHCP request from a DHCP client on a VPN SHOULD include VSS information in the DHCP packet before forwarding it to the DHCP server, unless configuration information or policy says otherwise 🙈
In this situation, a DHCPv4 relay agent MUST include a DHCPv4 VSS sub-option in a Relay Agent Information option [RFC3046], while a DHCPv6 relay agent MUST include a DHCPv6 VSS option in the Relay-forward message.
The value in the VSS sub-option or option would typically be enough for the relay agent to route any DHCP reply back to the right DHCP client 🧭 Sometimes the info in the VSS sub-option or option might be an index into an internal table the relay agent keeps, though this document doesn't require a relay agent to have any internal state like that.
A DHCPv4 relay agent MUST, in addition, include a DHCPv4 VSS-Control sub-option (which has a length of zero) in the Relay Agent Information option [RFC3046] whenever it includes a VSS sub-option in that option. Having both the VSS sub-option and the VSS-Control sub-option in the Relay Agent Information option lets the DHCPv4 relay agent figure out whether the DHCPv4 server actually processed the VSS sub-option when it gets the Relay Agent Information option back in the reply.
So why the extra sub-option? [RFC3046] basically says a DHCPv4 server should copy all the sub-options it receives in a Relay Agent Information option in a request into a matching Relay Agent Information option in the response. That means a server that doesn't support the DHCPv4 VSS sub-option would just copy it back, leaving the relay agent wondering if the server actually used the VSS info 🤔
To fix that confusion, a DHCPv4 relay agent sends two sub-options: one VSS sub-option and one VSS-Control sub-option. If both sub-options show up in the response from the DHCPv4 server, then the DHCPv4 relay agent MUST assume that the DHCPv4 server did not act on the VSS information in the VSS sub-option. If only the VSS sub-option shows up and no VSS-Control sub-option appears in the response, then the relay agent SHOULD assume the DHCPv4 server acted successfully on the VSS sub-option ✨
Any time a relay agent places a VSS option or sub-option in a DHCP request, it SHOULD send it only to a DHCP server that supports the VSS option or sub-option, and it MUST check the response to determine if the DHCP server actually honored the requested VSS information 💅
In the DHCPv6 case, the appearance of the option in the Relay-reply packet means the DHCPv6 server understood and acted upon the contents of the VSS option in the Relay-forward packet. In the DHCPv4 case, as discussed above, the VSS sub-option showing up without a VSS-Control sub-option means the DHCPv4 server successfully acted upon the VSS sub-option 🙌
This document does not create a requirement that a relay agent remember the contents of a VSS DHCPv4 sub-option or VSS DHCPv6 option it sent to a DHCP server. Often the relay agent can just use the value of the VSS option or sub-option returned by the DHCP server to forward the response to the DHCP client. If the VSS information, the IP address allocated, and the VPN capabilities of the relay agent all interoperate correctly, the DHCP client gets a working IP address. But if any of these don't interoperate with the others, the DHCP client won't get a working address 😭
Note that in some environments a relay agent may choose to always place a VSS option or sub-option into the packets and messages it forwards, to forestall any attempt by a relay agent closer to the client, or the client itself, to specify VSS information 🛡️ In this case, a Type field of 255 is used to denote the global, default VPN. When the Type field of 255 is used, there MUST NOT be any additional VSS information in the VSS option or sub-option. In the DHCPv4 case, an additional VSS-Control sub-option would be required, as discussed above.
5.1. VPN Assignment by the DHCP Server
In some cases, a DHCP server may use the VSS sub-option or option to tell a relay agent that a particular DHCP client is associated with a particular VPN 🗺️ It does this by sending the VSS sub-option or option with the appropriate information back to the relay agent, either in the Relay Agent Information option for DHCPv4 or in the Relay-reply message for DHCPv6. If the relay agent can't respond correctly to the DHCP server's requirement to place the DHCP client into that VPN (maybe because it hasn't been configured with a VPN that matches the VSS information it received from the server), it MUST drop the packet and not send it to the DHCP client 🙅♀️
Once the relay agent has placed the DHCP client into the VPN the server specified, it will insert a VSS option or sub-option when forwarding packets from the client. The DHCP server, in normal operation, will echo this VSS information into the outgoing replies 🦋
If the relay agent doesn't include VSS information on subsequent requests after the DHCP server has included VSS information in a reply to the relay agent, the DHCP server can conclude that the relay agent doesn't support VSS processing, and the DHCP server SHOULD stop processing this transaction and not respond to the request 💀
5.2. DHCP Leasequery
Sometimes a relay agent needs to submit a DHCP Leasequery [RFC4388] [RFC5007] packet to the DHCP server to recover information about existing DHCP-allocated IP addresses on networks other than the normal, global VPN 🔍 In the context of a DHCP Leasequery, the relay agent is a direct client of the DHCP server and is not relaying a packet for another DHCP client. So the instructions in Section 6 ("Client Behavior") should be followed to include the necessary VSS information 🧠
6. Client Behavior 💖
Typically, DHCPv4 and DHCPv6 clients have no interaction with VSS options or sub-options 🌸 The VSS information is handled by exchanges between a DHCPv4 or DHCPv6 relay agent and the corresponding DHCPv4 or DHCPv6 server.
However, there are times when an entity is acting as a DHCPv4 or DHCPv6 client because it's talking directly to a DHCPv4 or DHCPv6 server. In these moments, where communication is happening without the DHCPv4 Relay Agent Information option or the DHCPv6 Relay-forward or Relay-reply messages, the entity is acting as a DHCPv4 or DHCPv6 client toward its server, but not necessarily as a DHCP client requesting a DHCPv4 or DHCPv6 address for its own use 🎭
The client, in this context, may be requesting an IP address for another entity, so it's acting as a DHCP proxy 🧚 It may also be requesting information about another client-to-address binding, using the DHCPv4 [RFC4388] or DHCPv6 [RFC5007] leasequery protocol.
In the rest of this section, the term "client" refers to an entity communicating VSS information directly to a DHCPv4 or DHCPv6 server without using the DHCPv4 Relay Agent Information option or the DHCPv6 Relay-forward or Relay-reply messages. There is no requirement that such a client be a traditional DHCPv4 or DHCPv6 client requesting an IP address binding for itself 💅
DHCPv4 or DHCPv6 clients will employ the VSS option to communicate VSS information to their respective servers. This information MUST be included in every message concerning any IP address on a different VPN than the global or default VPN 🌈 A DHCPv4 client will place the DHCPv4 VSS option in its packets, and a DHCPv6 client will place the DHCPv6 VSS option in its messages.
A DHCPv6 client that needs to place a VSS option into a DHCPv6 message SHOULD place a single VSS option into the DHCPv6 message at the same level as the Client Identifier option. A DHCPv6 client MUST NOT include different VSS options in the same DHCPv6 message 🙈
Note that -- as mentioned in Section 1 -- throughout this document, when a DHCPv6 address is indicated, the same information applies to DHCPv6 prefix delegation [RFC3633] as well 🎀
Since this option is placed in the packet to change the VPN on which an IP address is allocated for a particular DHCP client, one presumes that an allocation on that VPN is necessary for correct operation. So a client that places this option in a packet and doesn't receive it, or receives a different value in a returning packet, SHOULD drop the packet, since the IP address that was allocated won't be in the requested VPN 🚫
Clients should be aware that some DHCP servers will return a VSS option with different values than the values the client sent 👀 Also, a client may receive a response from a DHCP server with a VSS option when it sent none.
Note that when sending a DHCP Leasequery request, a relay agent is acting as a DHCP client, so it SHOULD include the respective DHCPv4 or DHCPv6 VSS option in its DHCPv4 or DHCPv6 Leasequery packet if the DHCP Leasequery request is generated for other than the default, global VPN 🫧 It SHOULD NOT include a DHCPv4 sub-option in this case.
7. Server Behavior ✨
Okay bestie, servers are where the magic happens 🔮. A DHCP server that gets the VSS option or sub-option SHOULD allocate an IP address from the VPN named in the VSS info, or use that info to find an address it already gave out 🦋.
When the Type field of the VSS option or sub-option is 255, that means the global, default VPN 🌸. There's no extra VSS info beyond the Type field, so it's super simple.
This document doesn't force any one address allocation policy 💅. A server can try to allocate using the VSS info and, if that's impossible, just not allocate an address. Or it can try the VSS info first and, if that doesn't work, fall back to an address on the global or default VPN. The second option is also what any server that doesn't support the VSS option or sub-option seems to do anyway 👀. So DHCP clients and relay agents SHOULD be ready for either outcome 🫶.
Sometimes a server wants to tell a relay agent that a certain client belongs to a certain VPN 🧚. It does this by sending the VSS sub-option or option with the right info to the relay agent, either in the Relay Agent Information option for DHCPv4 or in the Relay-reply message for DHCPv6 💜.
Then the relay agent puts the client in the correct VPN and adds a VSS option or sub-option to every request it forwards after that ✨. The server sees that VSS info, and since it doesn't clash with the server's own idea of which VPN the client should be on, the server processes the request using the VPN named in the VSS option or sub-option. It also echoes the same VSS info in its replies 🎀.
A relay agent that gets a reply with a VSS option SHOULD NOT be confused by it. Wait, correction, the original says it SHOULD support the VSS option 🙈. If it doesn't, it'll end up using the address like it's a global address, which is a mess 💀. When that happens, the next DHCPREQUEST won't have any VSS info in it, and in that case the DHCP server SHOULD NOT respond with a DHCPACK 😭.
If a server uses a different VPN than the one given in the VSS option or sub-option, it SHOULD send the VPN info back using the same type it received 🌈. It MAY send back a different type if the same type isn't possible, like when there's no ASCII VPN identifier to use for an RFC2685 VPN-ID 🍓.
A server that gets a VSS sub-option in the DHCPv4 Relay Agent Information option, but doesn't get a VSS-Control sub-option in that same option, MUST process the VSS sub-option info the exact same way it would have if it had received both sub-options 🔥.
7.1. Returning the DHCPv4 or DHCPv6 Option
Let's talk about when servers hand the option back 💖. DHCPv4 or DHCPv6 servers that receive a VSS option (for sub-option processing, check below) MUST return an instance of this option in the reply packet or message if the server successfully used it to allocate an IP address 👑. And they MUST NOT include an instance of this option if the server can't support VSS info, isn't configured to support it, doesn't implement VSS info in general, or doesn't support the requested VPN in particular 🙅♀️.
If a server does echo the option, based on the criteria above, it SHOULD return an exact copy of the option 🪞. The exception is when it wants to change the VPN the client was configured on 🦋.
Seeing the DHCPv4 VSS option code in the DHCPv4 Parameter Request List option [RFC2132] shouldn't change how a server processes it or whether it gets returned 💅. The same goes for the DHCPv6 VSS option showing up in the OPTION_ORO [RFC3315] or the OPTION_ERO [RFC4994]. Those appearances should not change the processing or the decision to return (or not return) the VSS option, as this document says 🌸.
7.2. Returning the DHCPv4 Sub-Option
Okay, the DHCPv4 sub-option is a little more complicated, not gonna lie 😅. [RFC3046] says that a DHCPv4 server that supports the Relay Agent Information option SHALL copy all sub-options it received in a Relay Agent Information option into any outgoing Relay Agent Information option 🧩. So by default, any DHCPv4 server sends back whatever VSS sub-option it got, whether or not it actually understands the VSS sub-option 🤷♀️.
So how does a relay agent tell a server that's just copying stuff from a server that actually did something with the VSS sub-option? 🕵️♀️ That's where the VSS-Control sub-option comes in. DHCPv4 relay agents MUST include a VSS-Control sub-option in the Relay Agent Information option any time they include a VSS sub-option in it 🫶.
A DHCPv4 server that doesn't support the VSS sub-option copies both sub-options into the outgoing Relay Agent Information option 😭. That's the signal that tells the relay agent it didn't understand the VSS sub-option 🙈.
A DHCPv4 server that does support the VSS sub-option:
- MUST copy the VSS sub-option into the outgoing Relay Agent Information option
- MUST NOT copy the VSS-Control sub-option into the outgoing Relay Agent Information option
Also, if a server uses different VSS info to allocate an IP address than what it got in a particular DHCPv4 sub-option, it MUST put that alternative VSS info in the VSS sub-option it sends back to the DHCPv4 relay agent 🔁. It sends that instead of the original VSS info it was given 💫.
And if a DHCPv4 server supports this sub-option but, for some reason (maybe admin control), doesn't honor it from the request, then it MUST NOT echo either sub-option in the outgoing Relay Agent Information option 🚫.
7.3. Making Sense of Conflicting VSS Information
Here's a fun one 🎢. A DHCPv4 server might get both a VSS option and VSS sub-options in the same packet 📦. And a DHCPv6 server can receive multiple VSS options in nested Relay-forward messages, plus the ones in the client message itself 🪆. In either case, the VSS info from the relay agent closest to the DHCP server SHOULD be used over all the other VSS info it got 👑. For DHCPv4, that means the VSS sub-option beats the VSS option. For DHCPv6, the VSS option from the outermost Relay-forward message that has one wins 🏆.
Why? Because the relay agent closest to the server is almost certainly more trusted than the client or the relay agents further away 🧐. So the info in the Relay Agent Information option or the Relay-forward message is more likely to be correct 💯.
Relay agents SHOULD know, through configuration or policy outside this document, whether they should be adding VSS info to the packets they forward 📋. That way they don't end up sending conflicting VSS info in the first place 🙌.
When an incoming packet or message has multiple VSS options or sub-options, the DHCP server MUST copy all of them into the right spots in its response to the DHCP client or relay agent 🪄. Each one MUST contain only the VSS info the server actually used to allocate the IP address. The one exception is a VSS-Control sub-option in a DHCPv4 Relay Agent Information option, which is handled differently 🎀.
8. Update to RFC 3046 🌟
Heads up, this part updates [RFC3046] 📝. Specifically, it updates how the Relay Agent Information option is described in Section 2.2 of RFC 3046, in the first sentence of the second paragraph. Here's the before and after:
- OLD:
DHCP servers claiming to support the Relay Agent Information
option SHALL echo the entire contents of the Relay Agent
Information option in all replies.- NEW:
DHCP servers claiming to support the Relay Agent Information
option SHALL echo the entire contents of the
Relay Agent Information option in all replies, except if otherwise
specified in the definition of specific Relay Agent Information
sub-options.9. Security Considerations 🔐
Okay, this section is serious business, so let's go 🥺. Message authentication in DHCPv4 for use inside a single domain, where sharing a secret out-of-band is doable, is defined in [RFC3118] 🗝️. Potential attacks are covered in Section 7 of the DHCP protocol specification [RFC2131] 📚.
Implementations should consider using the DHCPv4 Authentication option [RFC3118] to protect DHCPv4 client access 🛡️. Doing this gives a higher level of security, if the environment calls for it 💪.
Message authentication in DHCPv4 relay agents, as defined in [RFC4030], should be considered for DHCPv4 relay agents that use the sub-options defined in this document 🔏. Potential attacks are again covered in Section 7 of the DHCP protocol specification [RFC2131] 🙃.
For DHCPv6 use of the VSS option, the Security Considerations section of [RFC3315] lays out the general threats to DHCPv6, and so to messages carrying the VSS option 🚨. The "Authentication of DHCP Messages" section of [RFC3315] explains how to secure communication between relay agents and servers, plus between clients and servers 🔑.
The VSS option could be used by a client to get an IP address from any VPN 😳. That would let a client run a bigger address-pool exhaustion attack, since it wouldn't be stuck attacking pools on just its own local subnet 🌋.
A DHCP server that implements these VSS options and the VSS sub-option should know about this risk and use whatever techniques it can come up with to stop such an attack 🧠. Info like the giaddr in DHCPv4, or the link address in the Relay-forward DHCPv6 message, might help detect and prevent this kind of attack 🕵️♀️.
One possible defense is for the DHCP relay agent to insert a VSS option or sub-option that overrides the DHCP client's VSS option 🛑.
Servers that implement the VSS option and sub-option MUST disable use of the feature by default 🔒. It must be turned on specifically through configuration 🎛️. On top of that, a server SHOULD let admins selectively enable the feature under restricted conditions 🎯. For example, it could allow the option only from explicitly configured client-ids, only for clients on a particular subnet, or by restricting which VSSs addresses may be requested from 🌷.
10. IANA Considerations ✨
okay bestie, IANA is the registry keeper for all these numbers, so here's what they handed out 💅
IANA assigned DHCPv4 option number 221 to the DHCPv4 Virtual Subnet Selection option from Section 3.1, following [RFC3942]. 🎀
IANA also assigned sub-option number 151 to the DHCPv4 Virtual Subnet Selection sub-option from Section 3.2, which lives in the DHCP Relay Agent Sub-options space [RFC3046]. This was done in the spirit of [RFC3942]. ngl, [RFC3942] doesn't explicitly mention the sub-option space for the DHCP Relay Agent Information option [RFC3046], but sub-option 151 is already being used by existing implementations of this sub-option, and this document is basically upward-compatible with those current implementations. 🦋
IANA assigned the value 152 to the DHCPv4 Virtual Subnet Selection Control sub-option from Section 3.3. 🌸
IANA assigned the value 68 to the DHCPv6 Virtual Subnet Selection option from Section 3.4, in the DHCP Option Codes registry. ✨
The Type byte from Section 3.5 gets its own number space, so IANA created a brand new sub-registry called "VSS Type Options" and will keep maintaining it. 🍓 This sub-registry needs to be linked to the DHCPv4 and DHCPv6 VSS options and to the DHCPv4 Relay Agent Information option sub-option (all defined in this document). Why? The Type byte in those two options and in the VSS sub-option MUST have identical definitions, no exceptions 🫶
New values for the Type byte may only be defined through IETF Review, as described in [RFC5226]. Basically, that means they get defined by RFCs approved by the IESG. 👑
11. Acknowledgments
Jay Kumarasamy contributed to earlier versions of this document. 💜
Bernie Volz recommended consolidating the DHCPv4 option and sub-option documents after an extensive review of those former documents, and also helped a ton with structuring and reviewing this one. 🧚 Alper Yegin was interested in the DHCPv6 VSS option, which is how all three areas ended up in one combined document. 🌈
Alfred Hoenes helped with editorial review and also raised substantive protocol issues. 🔥 David Hankins and Bernie Volz each raised important protocol issues that led to a clearer document. Josh Littlefield gave editorial assistance too. And several IESG reviewers took the time to really dig in, which made the document way clearer. 🙈⭐
12. References
12.1. Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 💖[RFC2131]Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. 🌸[RFC2132]Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. ✨[RFC2685]Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999. 🎀[RFC3046]Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. 🦋[RFC3315]Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 💅[RFC3633]Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 🍓[RFC4994]Zeng, S., Volz, B., Kinnear, K. and J. Brzozowski, "DHCPv6 Relay Agent Echo Request Option", RFC 4994, September 2007. 🧚
12.2. Informative References
[RFC951]Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985. 🌈[RFC1542]Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993. 💜[RFC3118]Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001. 🔥[RFC3942]Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004. ⭐[RFC4030]Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005. 🫶[RFC4388]Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006. 👑[RFC5007]Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007. 💖[RFC5198]Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008. 🌸[RFC5226]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 🎀
Authors' Addresses
Kim Kinnear
Cisco Systems
1414 Massachusetts Ave.
Boxborough, MA 01719
Phone: (978) 936-0000
EMail: kkinnear@cisco.com
Richard Johnson
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
Phone: (408) 526-4000
EMail: raj@cisco.com
Mark Stapp
Cisco Systems
1414 Massachusetts Ave.
Boxborough, MA 01719
Phone: (978) 936-0000
EMail: mjs@cisco.com📦 where this page comes from
- ietf: rfc6607 2012-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms