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 Agent
Notification for Prefix Delegation
The DHCPv6 relay
agent notification for prefix delegation allows the device working as a DHCPv6
relay agent to find prefix delegation options by reviewing the contents of a
DHCPv6 RELAY-REPLY packet that is relayed by the relay agent to the client.
When a prefix delegation option is found by the relay agent, the relay agent
extracts the information about the prefix that is being delegated and inserts
an IPv6 static route matching the prefix delegation information onto the relay
agent. Future packets destined to that prefix via relay will be forwarded based
on the information contained in the prefix delegation. The IPv6 static route is
then left in the routing table until the prefix delegation lease time expires
or the relay agent receives a release packet from the client releasing the
prefix delegation.
No user
configuration is required for this feature. Static route management is done
automatically by the relay agent.
IPv6 routes are
added when the relay agent relays a RELAY-REPLY packet, and IPv6 routes are
deleted when the prefix delegation lease time expires or the relay agent
receives a release message. An IPv6 static route in the routing table of the
relay agent can be updated when the prefix delegation lease time is extended.
The DHCP—DHCPv6
Relay Agent Notification for Prefix Delegation feature leaves a static IPv6
route on the routing table of the relay agent. The registered IPv6 address
allows unicast reverse packet forwarding (uRPF) to work by allowing the device
doing the reverse lookup to confirm that the IPv6 address on the relay agent is
not malformed or spoofed. The static route that remains in the routing table of
the relay agent can be redistributed to other routing protocols to advertise
the subnets to other nodes. Static routes will be removed when a DHCP_DECLINE
message is sent by the client.
DHCPv6 Relay Options:
Remote-ID for Gigabit Ethernet and Fast Ethernet Interfaces
The DHCPv6 Ethernet
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 DUID, and the 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 Relay Options: Reload
Persistent Interface ID
The DHCPv6
Relay—Reload Persistent Interface ID Option feature makes the interface ID
option persistent. The interface ID is used by relay agents to decide which
interface should be used to forward a RELAY-REPLY packet. A persistent
interface-ID option will not change if the device acting as a relay agent goes
offline during a reload or a power outage. When the device acting as a relay
agent returns online, it is possible that changes to the internal interface
index of the relay agent may have occurred in certain scenarios (such as, when
the relay agent reboots and the number of interfaces in the interface index
changes, or when the relay agents boot up and has more virtual interfaces than
it did before the reboot). This feature prevents such scenarios from causing
any problems.
This feature
changes the DHCPv6 interface-ID option to be expressed as the short form of the
interface name. The interface name as the DHCPv6 interface ID helps avoid
potential problems that could arise due to physical or logical interfaces
changing on the relay agent after a reload.
DHCPv6 Relay Chaining
DHCPv6 messages can
be relayed through multiple relay agents. This configuration is called
relay
chaining. A relay chaining configuration can be supported only when each
relay agent adds information to DHCPv6 messages before relaying them. The
information helps in relaying the DHCPv6 reply back to the DHCPv6 client
through the same path.
The delegated IPv6 prefix must be routable in order to be useful.
The actual DHCPv6 Prefix Delegation (PD) client may not be permitted to inject
routes into the delegating network. In service provider (SP) networks, for
example, an edge device typically acts as a DHCPv6 relay agent, and this edge
device often has the responsibility to maintain routes within the SP network
for clients’ PD bindings. In the event that DHCPv6 requests and responses are
relayed through a chain of DHCPv6 relays, there may be a need to introduce
appropriate routes (particularly with DHCPv6 PD) in the Forwarding Information
Base (FIB) so that routing is handled transparently.