Virtual Subnet Selection Options for DHCPv4 and DHCPv6
updates
- rfc-3046 — DHCP Relay Agent Information Option
Extracted elements (28)
The VSS-Control sub-option was introduced because RFC 3046 requires DHCPv4 servers to copy all Relay Agent Information sub-options from request to reply, making it impossible for a relay agent to distinguish a server that blindly echoed the VSS sub-option from one that actually processed it. The zero-length VSS-Control sub-option is removed by a supporting server, providing an unambiguous signal.
This document updates RFC 3046 to add the clause 'except if otherwise specified in the definition of specific Relay Agent Information sub-options.' This change was necessary to make the VSS-Control sub-option mechanism legally coherent: a supporting server MUST NOT echo VSS-Control, which contradicts the prior blanket echo-all requirement.
When conflicting VSS information is received from multiple sources, the VSS information from the relay agent closest to the DHCP server takes precedence (VSS sub-option over VSS option in DHCPv4; outermost Relay-forward VSS option in DHCPv6). The rationale is that relay agents closer to the server are more trusted than the client or more distant relay agents.
A relay agent submitting a DHCP Leasequery request for an address on a non-default VPN SHOULD include the respective DHCPv4 or DHCPv6 VSS option (not a sub-option) in the Leasequery packet, since the relay agent in that context is acting as a direct DHCP client rather than as a relay.
Deploying DHCPv4 relay agents that emit VSS sub-options together with DHCPv4 servers that do not support the VSS sub-option SHOULD NOT be done, as such a combination will not operate correctly. The relay agent can detect this situation when the VSS-Control sub-option reappears in the server's reply.
A DHCPv4 relay agent that includes a VSS sub-option in the Relay Agent Information option MUST also include a VSS-Control sub-option in that same Relay Agent Information option. This pairing enables the relay agent to detect whether the server actually processed the VSS information.
A DHCPv4 server that supports the VSS sub-option MUST copy the VSS sub-option into the outgoing Relay Agent Information option and MUST NOT copy the VSS-Control sub-option into the outgoing Relay Agent Information option. If it does not honor the sub-option for any reason, it MUST NOT echo either sub-option.
A DHCPv6 client that includes a VSS option SHOULD place a single VSS option in the message at the same level as the Client Identifier option, and MUST NOT include different VSS options in the same DHCPv6 message.
DHCP relay agents and servers MUST support VPN assignment by the relay agent (the approach in Section 4.1). They SHOULD support VPN assignment by the DHCP server (Section 4.2) but SHOULD NOT be configured to operate with both approaches simultaneously.
DHCPv4 and DHCPv6 servers receiving a VSS option MUST return an instance of that option in the reply if the server successfully uses it to allocate an IP address. The server MUST NOT include the option if it is unable to support VSS or the requested VPN in particular.
If both the VSS sub-option and the VSS-Control sub-option appear in the reply from the DHCPv4 server, the relay agent MUST assume the server did not act on the VSS information. If only the VSS sub-option appears (without VSS-Control), the relay agent SHOULD assume the server acted successfully on the VSS sub-option.
If the relay agent cannot assign a DHCP client to the VPN specified by the DHCP server in a VSS sub-option or option (VPN assignment by server approach), it MUST drop the packet and not forward it to the DHCP client.
Servers that implement the VSS option and sub-option MUST by default disable use of the feature; it must be specifically enabled through configuration. Servers SHOULD also provide the ability to selectively enable VSS under restricted conditions (e.g., by client-id, subnet, or restricted VPN set).
VSS information MUST be included in every client message concerning any IP address on a VPN other than the global or default VPN. A client that does not receive its requested VSS option (or receives a different value) in a reply SHOULD drop the packet, since the allocated address will not be on the requested VPN.
When multiple VSS options or sub-options appear in a packet, all existing VSS options or sub-options MUST be replicated in the appropriate places in the response and MUST contain only the VSS information actually used by the server to allocate the IP address (excepting VSS-Control sub-options).
When Type 255 (global/default VPN) is used, there MUST NOT be any additional VSS information in the option or sub-option, and the length of the option or sub-option MUST be 1.
The DHCPv4 Virtual Subnet Selection (VSS) option (code 221) carries a Type byte followed by VSS information and is used by DHCP clients or proxies communicating VSS information directly to a DHCPv4 server. Minimum length is 1 octet (Type byte only). Option codes and length fields are each 1 octet.
The DHCPv4 VSS-Control sub-option (code 152) is a zero-length sub-option carried in the Relay Agent Information option. In a request it signals that a VSS sub-option is present; in a reply its presence indicates the DHCPv4 server did not understand or act on the VSS sub-option.
The DHCPv4 VSS sub-option (code 151) is carried inside the Relay Agent Information option (RFC 3046) and conveys VSS information from a relay agent to a DHCPv4 server. It shares the same Type-and-VSS-information payload format as the DHCPv4 option. Minimum length is 1 octet.
The DHCPv6 VSS option (OPTION_VSS, code 68) carries a Type byte and VSS information and may be included by either a DHCPv6 client or relay agent in Relay-forward messages (or directly in client messages). Minimum option length is 1 octet. Code and length fields are each 2 octets.
The VSS Type field selects the VSS information encoding: Type 0 = NVT ASCII VPN identifier (MUST NOT be null-terminated), Type 1 = RFC 2685 7-octet VPN-ID, Type 255 = global/default VPN (no additional VSS information; length MUST be 1). Types 2–254 are unassigned.
IANA assigned DHCPv4 option number 221 to the DHCPv4 VSS option, sub-option number 151 (from the DHCP Relay Agent Sub-options space) to the DHCPv4 VSS sub-option, sub-option number 152 to the DHCPv4 VSS-Control sub-option, and option code 68 to the DHCPv6 VSS option (from the DHCP Option Codes registry).
IANA created and maintains a new sub-registry entitled 'VSS Type Options' covering the 1-octet Type byte shared by all VSS options and sub-options. Assigned values: 0 = NVT ASCII VPN identifier, 1 = RFC 2685 VPN-ID, 2–254 = Unassigned, 255 = Global/default VPN. New values require IETF Review.
DHCPv4 relay agents should consider using the Authentication sub-option (RFC 4030) when employing VSS sub-options, and implementations should consider the DHCPv4 Authentication option (RFC 3118) to protect client access. DHCPv6 security threats are detailed in RFC 3315.
The VSS option enables a DHCP client to request IP addresses from any VPN, enabling a more complete address-pool exhaustion attack across multiple VPNs rather than just the client's local subnet. Servers should use information such as giaddr (DHCPv4) or the link address in Relay-forward DHCPv6 messages to detect and prevent such attacks.
The DHCPv4 VSS-Control sub-option has a 1-octet Code (152) and a 1-octet Length field whose value is always 0; it carries no data beyond those two bytes.
The DHCPv4 VSS option and VSS sub-option share an identical on-wire payload: a 1-octet Code field, a 1-octet Length field (minimum value 1), a 1-octet Type field, and a variable-length VSS Information field whose encoding depends on the Type value.
The DHCPv6 VSS option uses 2-octet Code (68) and 2-octet option-len fields, followed by a 1-octet Type field and variable-length VSS Information. The minimum option-len is 1 (Type byte only).