Virtual Subnet Selection Options for DHCPv4 and DHCPv6

Abstract

This memo defines a DHCPv4 Virtual Subnet Selection (VSS) option, a DHCPv6 VSS option, and the DHCPv4 VSS and VSS-Control sub-options carried in the DHCPv4 Relay Agent Information option. These are intended for use by DHCP clients, relay agents, and proxy clients in situations where VSS information needs to be passed to the DHCP server for proper address or prefix allocation to take place. For the DHCPv4 option and Relay Agent Information sub-options, this memo documents and extends existing usage as per RFC 3942. This memo updates RFC 3046 regarding details relating to the copying of suboptions (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 has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6607.

Customizing DHCP Configuration on the Basis of Network Topology

“…This option is particularly useful when the relay agent needs to specify the subnet/link on which a DHCPv4 client resides, which is different from an IP address that can be used to communicate with the relay agent. The Virtual Subnet Selection (VSS) sub-option, specified in [RFC6607], can also be added by a relay agent to specify information in a VPN environment. In certain cases, it is useful for the client itself to specify the Virtual Subnet Selection option, e.g., when there are no relay agents involved during the VPN setup process.…”

“…The use case is the same as in DHCPv4: the relay agent inserts VSS options that can help the server to select the appropriate subnet with its address pool and associated configuration options. See [RFC6607] for details.…”

DHCPv4 Bulk Leasequery

“…In addition, any of the above queries can be qualified by the specification of a VPN-ID option [RFC6607] The use of TCP for the Bulk Leasequery protocol permits multiple messages to be sent from one end of the connection to the other without requiring a request/response paradigm as does UDP DHCPv4 [RFC2131]. The receiver needs to be able to determine the size of each message it receives.…”

“…Inclusion of a query-end-time option specifies that only IP address bindings that have changed on or before the time specified in the query-end-time option should be returned. [RFC6607] allows the requestor to specify a single VPN other than the default VPN. In addition, the VPN-ID option has been extended as part of this document to allow specification that all configured VPNs be searched in order to satisfy the query specified in the DHCPBULKLEASEQUERY.…”

“…If no VPN-ID option appears in the DHCPBULKLEASEQUERY, the default (global) VPN is used to satisfy the query. A VPN-ID option [RFC6607] value other than the wildcard value (254) allows the requestor to specify a single VPN other than the default VPN. In addition, the VPN-ID option has been extended as part of this document to allow specification of a type 254, which indicates that all configured VPNs be searched in order to satisfy the primary query.…”