DHCPv6 Options Support
This module describes the Dynamic Host Control Protocol Version 6 (DHCPv6) Relay Agent, DHCPv6 Interface-ID, Lightweight DHCPv6 Relay Agent (LRDA), and CAPWAP Access Controller DHCP Option 52 features.
This module consists of these sections:
Note For complete syntax and usage information for the switch commands used in this chapter, see publications at this location:
Cisco IOS Command Reference Guides for the Catalyst 4500 Series Switch
If a command is not in the Catalyst 4500 Series Switch Command Reference, you can locate it in the Cisco IOS library, at this location:
Cisco IOS Master Command List, All Releases
Information About DHCPv6 Options Support
DHCPv6 Relay Agent Overview
A DHCPv6 relay agent is any host that forwards DHCP packets between clients and servers. Relay agents are used to forward requests and replies between clients and servers when they are not on the same physical subnet.
A DHCPv6 relay agent, which may reside on the client’s link, is used to relay messages between the client and the server. The DHCPv6 relay agent operation is transparent to the client. A DHCPv6 client locates a DHCPv6 server using a reserved, link-scoped multicast address. For direct communication between the DHCPv6 client and the DHCPv6 server, both of them must be attached to the same link. However, in some situations where ease of management, economy, or scalability is a concern, it is desirable to allow a DHCPv6 client to send a message to a DHCPv6 server that is not connected to the same link.
DHCPv6 Relay Options: Remote-ID
The DHCPv6 Remote ID Option feature adds the remote identification (remote-ID) option to relayed (RELAY-FORWARD) DHCPv6 packets.
The remote-ID option provides information to the DHCPv6 server, which includes port information, the system’s DHCP Unique Identifier (DUID), and the virtual LAN (VLAN) ID. This information can be used to uniquely identify both the relay and the port on the relay through which the client packet arrived. The DHCPv6 server uses this information to select parameters specific to a particular user, host, or subscriber modem.
The addition of the remote-ID option to the RELAY-FORWARD packet occurs automatically and no user configuration is necessary.
The DHCPv6 server does not need to echo the remote-ID option in the RELAY-REPLY packet. The Internet Assigned Numbers Authority (IANA) has assigned the DHCPv6 option code 37 for the relay agent remote-ID option.
If the remote-ID option is included in the RELAY-REPLY packet, the option is removed from the packet before it is relayed to the client.
DHCPv6 Interface-ID
The interface-ID option is used by relay agents to decide which interface should be used when forwarding a RELAY-REPLY packet. If a relay agent receives a RELAY-REPLY message with an interface-ID option, the message is relayed to the client through the interface identified by the option.
The server must copy the interface-ID option from the RELAY-FORWARD message into the RELAY-REPLY message the server sends to the relay agent in response to the RELAY-FORWARD message. This option must not appear in any message except a RELAY-FORWARD or a RELAY-REPLY message.
Servers can use the interface-ID for parameter assignment policies. The interface-ID must be considered as an opaque value, with policies based on exact match only; that is, interface-ID must not be internally parsed by the server. The interface-ID value for an interface must be stable and remain unchanged, for example, after the relay agent is restarted; if the interface-ID changes, a server will not be able to use it reliably in parameter assignment policies.
Lightweight DHCPv6 Relay Agent
The Lightweight DHCPv6 Relay Agent feature allows relay agent information to be inserted by an access node that performs a link-layer bridging (non-routing) function. Lightweight DHCPv6 Relay Agent (LDRA) functionality can be implemented in existing access nodes, such as DSL access multiplexers (DSLAMs) and Ethernet switches, that do not support IPv6 control or routing functions. LDRA is used to insert relay-agent options in DHCPv6 message exchanges primarily to identify client-facing interfaces. LDRA functionality can be enabled on an interface and a VLAN.
An LDRA device or interface has the following features:
- Maintains interoperability with existing DHCPv6 relay agents and servers.
- Is functionally the equivalent of a Layer 2 relay agent, without routing capabilities.
Note LDRA is a device or interface on which LDRA functionality is configured.
Background
A variety of different link-layer network topologies exist for the aggregation of IPv6 nodes into one or more devices. In Layer 2 aggregation networks (IEEE 802.1D bridging or similar) that have many nodes on a single link, a DHCPv6 server or DHCP relay agent normally does not recognize how a DHCP client is attached to a network. LDRA allows relay-agent information, including the Interface-ID option, to be inserted by the access node so that the information may be used by the DHCPv6 server for client identification.
Interoperability between DHCPv6 Relay Agents and LDRA
DHCPv6 relay agents are used to forward DHCPv6 messages between a client and a server when the client and server are not on the same IPv6 link. A DHCPv6 relay agent also adds an interface ID option in the upstream DHCPv6 message (from client-to-server) to identify the interface on which the client is connected. This information is used by the DHCPv6 relay agent while forwarding the downstream DHCPv6 message to the DHCPv6 client. The DHCPv6 relay agent is implemented alongside the routing functionality on the common node.
To maintain interoperability with existing DHCP relays and servers, LDRA implements the same message types (RELAY-FORWARD and RELAY-REPLY) as a DHCPv6 relay agent. LDRA allows relay-agent information to be inserted by an access node that performs a link-layer bridging (that is, non-routing) function. The LDRA resides on the same IPv6 link as the client and a DHCPv6 relay agent or server.
LDRA for VLANs and Interfaces
You can configure LDRA on VLANs and interfaces. LDRA is not enabled by default. You must enable it on the VLAN or interface first.
In a typical deployment, a majority of the interfaces or ports on a device are client facing. In such a scenario, you can configure LDRA functionality on the VLAN. When you configure LDRA on a VLAN, the functionality is configured on all ports or interfaces within the VLAN. Instead of configuring LDRA functionality individually on interfaces and ports within a VLAN, you can configure LDRA on the entire VLAN. As a result, all ports or interfaces associated with the VLAN will be configured as client facing.
You can also configure LDRA functionality on a specific interface or port. An interface or port can be configured as client-facing trusted, client-facing untrusted, or server facing.
The LDRA configuration on a VLAN has to be configured as trusted or untrusted. An LDRA must implement a configuration setting for all client-facing interfaces, marking them as trusted or as untrusted.
By default, any interface that is configured as client facing will be configured as an untrusted interface. When a client-facing interface is deemed untrusted, LDRA will discard any message of type RELAY-FORWARD received from the client-facing interface.
CAPWAP Access Controller DHCPv6 Option
The Control And Provisioning of Wireless Access Points (CAPWAP) protocol allows lightweight access points to use DHCPv6 to discover a Wireless Controller to which it can connect. CAPWAP is a standard, interoperable protocol that enables a controller to manage a collection of wireless access points.
Wireless access points use the DHCPv6 option 52 (RFC 5417) to supply the IPv6 management interface addresses of the primary, secondary, and tertiary Wireless Controllers.
Both stateless and stateful DHCPv6 addressing modes are supported. In stateless mode, access points obtain IPv6 address using the Stateless Address AutoConfiguration (SLAAC), while additional network information (not obtained from router advertisements) is obtained from a DHCPv6 server. In stateful mode, access points obtain both IPv6 addressing and additional network information exclusively from the DHCPv6 server. In both modes, a DHCPv6 server is required to provide option 52 if Wireless Controller discovery using DHCPv6 is required.