Lightweight DHCPv6 Relay Agent
How a plain Layer 2 switch can tag DHCPv6 requests with the port they came from, without being a router.
Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, <https://www.rfc-editor.org/info/rfc6221>.
@misc{rfc6221,
series = {Request for Comments},
number = 6221,
howpublished = {RFC 6221},
publisher = {RFC Editor},
doi = {10.17487/RFC6221},
url = {https://www.rfc-editor.org/info/rfc6221},
author = {D. Miles and S. Ooghe and W. Dec and S. Krishnan and A. Kavanagh},
title = {{Lightweight DHCPv6 Relay Agent}},
pagetotal = 17,
year = 2011,
month = may,
} RFC text
Contents
Internet Engineering Task Force (IETF) D. Miles, Ed.
Request for Comments: 6221 S. Ooghe
Updates: 3315 Alcatel-Lucent
Category: Standards Track W. Dec
ISSN: 2070-1721 Cisco Systems
S. Krishnan
A. Kavanagh
Ericsson
May 2011
Lightweight DHCPv6 Relay Agent
Abstract
This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that
is used to insert relay agent options in DHCPv6 message exchanges
identifying client-facing interfaces. The LDRA can be implemented in
existing access nodes (such as Digital Subscriber Link Access
Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6
control or routing functions.
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/rfc6221.
Copyright Notice
Copyright (c) 2011 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 of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. Background ......................................................3
3. Terminology .....................................................3
4. Server Considerations ...........................................5
5. Message Format ..................................................5
5.1. Relay-Forward Message ......................................5
5.2. Relay-Reply Message ........................................6
5.3. Mandatory DHCP Options .....................................6
5.3.1. Relay-Message Option ................................6
5.3.2. Interface-ID Option .................................6
6. Agent Behaviour .................................................7
6.1. Relaying a Client Message ..................................7
6.1.1. Client Message Validation ...........................8
6.1.2. Trusted and Untrusted Interfaces ....................8
6.2. Relaying a Relay-Reply Message from the Network ............8
7. Network Topology ................................................9
7.1. Client and Server on Same Link .............................9
7.2. Client and Server behind Relay Agent ......................11
7.3. Relay Agent in Front of LDRA ..............................12
8. Contributors ...................................................15
9. Security Considerations ........................................15
10. References ....................................................15
10.1. Normative References .....................................15
10.2. Informative References ...................................16
1. Introduction
DHCPv6 Relay Agents [RFC3315] are deployed to forward DHCPv6 messages
between clients and servers when they are not on the same IPv6 link
and are often implemented alongside a routing function in a common
node. A Lightweight DHCPv6 Relay Agent (LDRA) allows Relay Agent
Information to be inserted by an access node that performs a link-
layer bridging (i.e., non-routing) function. An LDRA resides on the
same IPv6 link as the client and a DHCPv6 Relay Agent or server, and
is functionally the equivalent of the Layer 2 Relay Agent proposed
for DHCPv4 operation in [L2RA].
Unlike a DHCPv6 Relay Agent specified in [RFC3315], an LDRA does not
implement any IPv6 control functions (e.g., ICMPv6) or have any
routing capability in the node.
1.1. Requirements Language
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].
2. Background
A variety of different link-layer network topologies exist for the
aggregation of IPv6 nodes into one or more routers. 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 would
normally be unaware of how a DHCP client is attached to the network.
The LDRA allows Relay Agent Information, including the Interface-ID
option [RFC3315], to be inserted by the access node so that it may be
used by the DHCPv6 server for client identification. A typical
application in a broadband service provider could be equivalent to a
Layer 2 DHCP Relay Agent as described in the Broadband Forum TR-101
report [TR-101] and in [L2RA].
3. Terminology
Access Node A device that combines many interfaces onto
one link. An access node is not IP-aware
in the data path.
Address An IP layer identifier for an interface or
set of interfaces.
Client-facing An interface on the access node that
carries traffic towards the DHCPv6 client.
Host A non-routing IPv6 node that is
participating in a DHCPv6 message exchange.
IP Internet Protocol Version 6 (IPv6).
LDRA Lightweight DHCPv6 Relay Agent.
Lightweight Relay Agent A function on the access node that
intercepts DHCP messages between clients
and servers. The function exists as a bump
in the wire on the IP link.
Link A communication facility or medium over
which nodes can communicate at the link
layer.
Link-local address An IP address having only local scope,
indicated by having the address prefix
fe80::/10, that can be used to reach
neighbouring nodes attached to the same
link. Every interface has a link-local
address.
Network-facing An interface on the access node that
carries traffic towards the DHCPv6
server(s).
Node A device that implements IPv6.
Router A node that forwards packets not directly
addressed to itself.
Relay Agent A node that acts as an intermediary to
deliver DHCP messages between clients and
servers and being on the same link as the
client.
Unspecified address An IPv6 address that is comprised entirely
of zeros.
4. Server Considerations
This document updates the behaviour specified in Section 11 of DHCP
for IPv6 [RFC3315]. RFC 3315 states, in part:
If the server receives the message from a forwarding relay agent,
then the client is on the same link as the one to which the
interface, identified by the link-address field in the message
from the relay agent, is attached.
DHCP server implementations conforming to this specification MUST,
for the purposes of address selection, ignore any link-address field
whose value is zero. In the above text from RFC 3315, "link-address"
refers to both the link-address field of the Relay-Forward message,
and the link-address fields in any Relay-Forward messages that may be
nested within the Relay-Forward message.
5. Message Format
The Lightweight DHCPv6 Relay Agent (LDRA) exchanges DHCP messages
between clients and servers using the message formats established in
[RFC3315].
To maintain interoperability with existing DHCP relays and servers,
the message format is unchanged from [RFC3315]. The LDRA implements
the same message types as a normal DHCPv6 Relay Agent. They are:
o Relay-Forward Messages
o Relay-Reply Messages
5.1. Relay-Forward Message
The Relay-Forward message is created by any DHCPv6 Relay Agent,
including an LDRA, to forward messages between clients and servers or
other relay agents. These messages are built as specified in
[RFC3315].
The Relay-Forward message contains relay agent parameters that
identify the client-facing interface on which any reply messages
should be forwarded. These parameters are link-address, peer-
address, and Interface-ID. The link-address parameter MUST be set to
the unspecified address. The peer-address parameter MUST be set as
specified in Section 6.1. The Interface-ID Relay Agent option MUST
be included in the Relay-Forward message. The LDRA MAY insert
additional relay agent options.
5.2. Relay-Reply Message
The Relay-Reply message is constructed by a DHCPv6 server to send
parameters to a DHCP client when a relay agent is present between the
server and the client. The Relay-Reply message may be sent after an
initial Relay-Forward message as the parameters link-address, peer-
address, and Interface-ID, as well as the relay agent's IP address,
are learnt from the Relay-Forward message.
The server MUST include the Interface-ID option in the Relay-Reply
Message to indicate to the LDRA the interface on which the
decapsulated message should be forwarded.
5.3. Mandatory DHCP Options
Parameters are exchanged between the DHCP client, Relay Agent, and
server through the use of DHCP options. There is a set of mandatory
DHCP options that MUST be included by the LDRA in all Relay-Forward
messages. These are the:
o Relay-Message Option
o Interface-ID Option
5.3.1. Relay-Message Option
A DHCPv6 Relay Agent relays messages between clients and servers or
other relay agents through Relay-Forward and Relay-Reply message
types. The original client DHCP message (i.e., the packet payload,
excluding UDP and IP headers) is encapsulated in a Relay Message
option [RFC3315].
If a Relay-Message would exceed the MTU of the outgoing interface, it
MUST be discarded, and an error condition SHOULD be logged.
5.3.2. Interface-ID Option
The LDRA MUST include the Interface-ID option [RFC3315] in all Relay-
Forward messages. When an LDRA receives a Relay-Reply message with
an Interface-ID option present and link-address unspecified, the LDRA
MUST relay the decapsulated message to the client on the interface
identified in the Interface-ID option.
Servers MAY use the Interface-ID for parameter assignment policies.
The format of the Interface-ID is outside the scope of this
contribution. The Interface-ID SHOULD be considered an opaque value;
i.e., the server SHOULD NOT try to parse the contents of the
Interface-ID option. The LDRA SHOULD use the same Interface-ID value
for a given interface, and this value SHOULD be retained across
restarts. This is because if the Interface-ID changes, a server will
not be able to use it reliably in parameter assignment policies.
6. Agent Behaviour
The LDRA MUST have each of its interfaces configured as either
client-facing or network-facing. The LDRA uses the notion of client-
facing and network-facing interfaces to process DHCPv6 messages.
6.1. Relaying a Client Message
The LDRA MUST intercept and process all IP traffic received on any
client-facing interface that has:
o destination IP address set to All_DHCP_Relay_Agents_and_Servers
(ff02::1:2);
o protocol type UDP; and
o destination port 547.
The LDRA MUST also prevent the original message from being forwarded
on the network-facing interface.
The lightweight relay agent adds any other options it is configured
or required to include in the Relay-Forward message. The LDRA MUST
set the link-address field of the Relay-Forward message to the
Unspecified Address (::) and MUST include the Interface-ID option in
all DHCP Relay-Forward messages.
If the message received on the client-facing interface is a Relay-
Forward message, the LDRA MUST set the hop-count field in the newly
created Relay-Forward message to the value of the hop-count field in
the received message, incremented by 1 as specified in [RFC3315].
The LDRA MUST copy the IP destination and link-layer destination
addresses from the client-originated message into the IP destination
address and link-layer destination address of the Relay-Forward
message.
The LDRA MUST copy the IP source address from the client-originated
message into the peer-address field of the Relay-Forward message.
The LDRA MUST copy the link-layer source address from the client-
originated message into the link-layer source address of the Relay-
Forward message.
6.1.1. Client Message Validation
On receipt of a DHCP message on a client-facing interface, the LDRA
MUST discard a message if it is of one of the following message
types:
o ADVERTISE (2)
o REPLY (7)
o RECONFIGURE (10)
o RELAY-REPL (13)
Options contained in the DHCPv6 message MUST NOT be validated by the
LDRA, making it the responsibility of the DHCP server to check
message option validity and allow new options to be introduced
without changes on the LDRA.
6.1.2. Trusted and Untrusted Interfaces
In [RFC3046], DHCPv4 Relay Agents had their client-facing interfaces
set to "trusted" and "untrusted". An LDRA MUST implement a
configuration setting for all client-facing interfaces, marking them
either as trusted or as untrusted. This setting SHOULD be
configurable per interface. When a client-facing interface is deemed
untrusted, the LDRA MUST discard any message of type RELAY-FORW (12)
received from the client-facing interface.
6.2. Relaying a Relay-Reply Message from the Network
The LDRA MUST intercept and process all IP traffic received on the
network-facing interface that has:
o a link-local scoped source address;
o a link-local scoped destination address;
o protocol type UDP; and
o destination port 547
An LDRA MUST inspect the DHCP message type and only forward Relay-
Reply messages. Other DHCP message types MUST be silently discarded.
The Relay-Reply message is considered valid by the LDRA if it passes
the validity checks to be performed by a relay agent per [RFC3315]
and
- the Interface-ID option is present, and the value corresponds to a
valid interface in the access node;
- the Relay-Reply peer-address and the destination IP address are
identical, and it is a link-local scoped address when no IP
address is configured on the LDRA; and
- the link-address is the Unspecified Address when no IP address is
configured on the LDRA.
If the Relay-Reply message is valid, the LDRA copies the peer-address
into the destination IP address field. The LDRA SHOULD forward the
packet to the correct client-facing interface using the destination
link-layer (Media Access Control (MAC)) address or the Interface-ID
in the Relay-Reply. The LDRA SHOULD NOT retransmit the packet on any
other interface. The contents of the Relay Message option are put
into an IP/UDP packet and then forwarded to the client.
The LDRA MUST copy the link-layer and IP source address from the
Relay-Reply message into the IP/UDP packet that is forwarded to the
client.
7. Network Topology
The LDRA intercepts any DHCPv6 message received on client-facing
interfaces with the traffic pattern specified in Section 6.1. The
LDRA MUST NOT forward the original client message to a network-facing
interface; it MUST process the message and add the appropriate Relay-
Forward options as described in previous sections.
7.1. Client and Server on Same Link
The access node acts as a bridge; it has no information about any IP
prefixes that are valid on the link. Thus, a server should consider
address and parameter assignment as if the client DHCP message were
not relayed.
+--------+
Client -------| |
| Access |
Client -------| Node |-----+
| (LDRA) | |
Client -------| | |
+--------+ |
| +--------+
|------| Server |
| +--------+
+--------+ |
Client -------| | |
| Access | |
Client -------| Node |-----+
| (LDRA) |
Client -------| |
+--------+
<--------- IPv6 Link -------->
For example, if a client sent a DHCP Solicit message that was relayed
by the LDRA to the server, the server would receive the following
Relay-Forward message from the LDRA:
src-ip: client link-local address
dst-ip: All_DHCP_Relay_Agents_and_Servers
msg-type: RELAY-FORW
hop-count: 0
link-address: Unspecified_Address
peer-address: client link-local address
Interface-ID Option:
interface-id: LDRA-inserted interface-id
Relay-Message Option, which contains:
msg-type: SOLICIT
Solicit Message Options: <from client>
7.2. Client and Server behind Relay Agent
The client and server are on different IPv6 links, separated by one
or more relay agents that will typically act as a router. The LDRA
will send Relay-Forward messages upstream towards the second relay
agent, which in turn will process the messages.
+--------+
Client -------| |
| Access |
Client -------| Node |-----+
| (LDRA) | |
Client -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
Client -------| | |
| Access | |
Client -------| Node |-----+
| (LDRA) |
Client -------| |
+--------+
<------- IPv6 Link A -------> <--IPv6 Link B-->
For example, if a client sent a DHCP Solicit message that was relayed
by the LDRA to another relay agent and then to the server, the server
would receive the following Relay-Forward message from the LDRA:
src-ip: relayB
dst-ip: server
msg-type: RELAY-FORW
hop-count: 1
link-address: relayB address from link A
peer-address: client link-local address
Relay-Message Option, which contains:
msg-type: RELAY-FORW
hop-count: 0
link-address: Unspecified_Address
peer-address: client link-local address
Interface-ID Option:
interface-id: LDRA-inserted interface-id
Relay-Message Option, which contains:
msg-type: SOLICIT
Solicit Message Options: <from client>
7.3. Relay Agent in Front of LDRA
The client and server are on different IPv6 links, separated by one
or more relay agents that will typically act as a router, and there
is an [RFC3315] Relay Agent on the client-facing interface of the
LDRA. The LDRA will send Relay-Forward messages upstream towards the
second relay agent, which in turn will process the messages.
+--------+
RelayC -------| |
| Access |
RelayC -------| Node |-----+
| (LDRA) | |
RelayC -------| | |
+--------+ |
| +--------+ +--------+
|------| RelayB |-------| Server |
| +--------+ +--------+
+--------+ |
RelayC -------| | |
| Access | |
RelayC -------| Node |-----+
| (LDRA) |
RelayC -------| |
+--------+
<------- IPv6 Link A -------> <--IPv6 Link B-->
For example, if a client sent a DHCP Solicit message that was relayed
by RelayC and the LDRA to another relay agent, RelayB, and then to
the server, the server would receive the following Relay-Forward
message:
src-ip: relayB
dst-ip: server
msg-type: RELAY-FORW
hop-count: 2
link-address: relayB address from link A
peer-address: relayC
Relay-Message Option, which contains:
msg-type: RELAY-FORW
hop-count: 1
link-address: Unspecified_Address
peer-address: relayC
Interface-ID Option:
interface-id: LDRA-inserted interface-id
Relay-Message Option, which contains:
msg-type: RELAY-FORW
hop-count: 0
link-address: global or Unspecified_Address
peer-address: end client address
Interface-ID Option: (if required)
interface-id: relayC-inserted Interface-ID
Relay-Message Option, which contains:
msg-type: SOLICIT
Solicit Message Options: <from end client>
8. Contributors
The authors would like to thank the following for their support:
Lieven Levrau, Alastair Johnson, Robert Haylock, Mickey Vucic, Ludwig
Pauwels, Fernando Cuervo, John Kaippallimalil, Fredrik Garneij,
Alfred Hoenes, Ted Lemon, Tatuya Jinmei, David Hankins, and Ralph
Droms.
Comments are solicited and should be addressed to the DHC WG mailing
list (dhcwg@ietf.org) and/or the authors.
9. Security Considerations
The security issues pertaining to DHCPv6 Relay Agents as specified in
Section 23 of [RFC3315] are also applicable to LDRAs. The LDRA
SHOULD implement some form of rate-limiting on client-originated
traffic in order to prevent excessive process utilisation. The
traffic to be rate-limited can be easily identified since the LDRA
listens only to client-originated IPv6 traffic sent to the
All_DHCPv6_Servers_and_Relay_Agents address on UDP port 547 and does
not process any other client-originated traffic. As DHCP is session-
oriented, messages in excess of the rate-limit may be silently
discarded.
The hop-count-based determination of the trustworthiness of the LDRA
can be easily defeated by a rogue relay agent on the network-facing
interface of the LDRA.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
10.2. Informative References
[L2RA] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent
Information", Work in Progress, April 2011.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL
Aggregation", Technical Report TR-101, April 2006.
Authors' Addresses
David Miles (editor)
Alcatel-Lucent
L3 / 215 Spring St.
Melbourne, Victoria 3000
Australia
Phone: +61 3 9664 3308
EMail: david.miles@alcatel-lucent.com
Sven Ooghe
Alcatel-Lucent
Copernicuslaan 50
2018 Antwerp,
Belgium
EMail: sven.ooghe@alcatel-lucent.com
Wojciech Dec
Cisco Systems
Haarlerberdweg 13-19
1101 CH Amsterdam,
The Netherlands
EMail: wdec@cisco.com
Suresh Krishnan
Ericsson
8400 Blvd. Decarie
Town of Mount Royal, Quebec
Canada
EMail: suresh.krishnan@ericsson.com
Alan Kavanagh
Ericsson
8400 Blvd. Decarie
Town of Mount Royal, Quebec
Canada
EMail: alan.kavanagh@ericsson.com
AI ELI5
On this page
§1Why a Lightweight Relay Agent
A normal DHCPv6 relay agent, as defined in RFC 3315, forwards messages between clients and servers that are not on the same IPv6 link. It is usually built into a router.
The Lightweight DHCPv6 Relay Agent (LDRA) is for access nodes that only bridge at the link layer, such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches. An LDRA sits on the same IPv6 link as the client and as a DHCPv6 relay agent or server. It does not implement IPv6 control functions such as ICMPv6, and it has no routing capability.
The RFC says it is functionally the equivalent of the Layer 2 Relay Agent proposed for DHCPv4. It also notes a typical use in a broadband service provider network.
Some network boxes only pass traffic along and are not smart enough to be routers. This document lets even those simple boxes add a little note to each request.
§2The Problem on Aggregation Networks
Many access networks aggregate IPv6 nodes into one or more routers using IEEE 802.1D bridging or something similar. Many nodes share a single link, so a DHCPv6 server or relay agent would normally be unaware of how a given client is attached.
The LDRA fixes that by inserting Relay Agent Information, including the Interface-ID option from RFC 3315, so the server can use it to identify the client.
The document defines a few terms. A client-facing interface carries traffic towards the DHCPv6 client. A network-facing interface carries traffic towards the DHCPv6 server or servers. The access node combines many interfaces onto one link and is not IP-aware in the data path.
When lots of computers share one wire, the server cannot tell which plug each one is in. The LDRA writes down the plug number for it.
§5Message Formats and Mandatory Options
The LDRA does not invent new messages. To stay interoperable with existing relays and servers, the message format is unchanged from RFC 3315, and the LDRA uses the same two relay message types: Relay-Forward and Relay-Reply.
In a Relay-Forward message built by an LDRA, the link-address MUST be the unspecified address, the peer-address is set as described in the agent behaviour, and the Interface-ID option MUST be included. The LDRA MAY add other relay agent options.
Every Relay-Forward message from an LDRA MUST carry two options. The Relay-Message option holds the original client DHCP message (the payload without the UDP and IP headers). If the result would exceed the MTU of the outgoing interface, it MUST be discarded and an error condition SHOULD be logged.
The Interface-ID option identifies the client-facing interface. The server MUST include it in a Relay-Reply so the LDRA knows where to send the decapsulated message. Its format is outside the scope of the RFC and it SHOULD be treated as an opaque value, which the server SHOULD NOT try to parse. The LDRA SHOULD use the same value for a given interface and SHOULD retain it across restarts, because a changing value would break server assignment policies.
The LDRA puts the original request in an envelope and writes the door number on the outside. The reply comes back with the same door number, so the LDRA knows where to deliver it.
§6How the Agent Behaves
Every interface of an LDRA MUST be configured as either client-facing or network-facing.
For client messages, the LDRA MUST intercept all traffic arriving on a client-facing interface that is sent to ff02::1:2 (All_DHCP_Relay_Agents_and_Servers), uses UDP and has destination port 547. It MUST stop the original message from being forwarded on the network-facing interface. It sets link-address to :: and includes the Interface-ID. If the message it received was already a Relay-Forward message, it sets the new hop-count to the received hop-count plus 1. It copies the client's IP source address into the peer-address field, and it copies the destination and source addresses from the client message into the Relay-Forward message.
The LDRA MUST discard client-side messages of type ADVERTISE (2), REPLY (7), RECONFIGURE (10) and RELAY-REPL (13), since a client never sends those. It MUST NOT validate the options inside the message, leaving that to the server so new options can be introduced without changing the LDRA.
For replies, the LDRA intercepts UDP traffic on the network-facing interface with link-local source and destination addresses and destination port 547, and forwards only Relay-Reply messages. The reply is valid if it passes the usual relay checks and the Interface-ID is present and matches a valid interface. The LDRA unwraps the Relay Message option and forwards it to the client, and SHOULD NOT retransmit it on any other interface.
The LDRA catches every request from a client, wraps it with the door number, and sends it on. When a reply comes back, it unwraps it and hands it only to the right door.
- 2ADVERTISE — Discarded when received on a client-facing interface.
- 7REPLY — Discarded when received on a client-facing interface.
- 10RECONFIGURE — Discarded when received on a client-facing interface.
- 13RELAY-REPL — Discarded when received on a client-facing interface.
- 12RELAY-FORW — Discarded from client-facing interfaces that are untrusted.
§7Network Topologies
The RFC walks through three layouts and shows what the server would receive for a Solicit message in each.
Client and server on the same link. The access node acts as a bridge and knows nothing about IP prefixes on the link, so the server should treat address and parameter assignment as if the message were not relayed. To support this, DHCP servers conforming to the RFC MUST ignore a link-address value of zero for address selection. This is the change the RFC makes to RFC 3315, Section 11. The server sees a Relay-Forward message with hop-count 0 and the LDRA-inserted interface-id.
Client and server behind another relay agent. The LDRA sends Relay-Forward messages upstream to a second relay agent (RelayB). The server receives an outer Relay-Forward with hop-count 1 that contains the LDRA's Relay-Forward with hop-count 0.
A relay agent in front of the LDRA. An RFC 3315 relay agent (RelayC) sits on the client-facing side. The server receives three nested Relay-Forward messages, with hop-counts 2, 1 and 0, around the original Solicit.
Sometimes there is one helper between you and the server, and sometimes there are several. Each helper adds its own envelope, so the server opens the envelopes one by one.
- RelayB Relay-Forward hop-count 2
- LDRA Relay-Forward hop-count 1, Interface-ID inserted by LDRA
- RelayC Relay-Forward hop-count 0
- SOLICIT from end client
- RelayC Relay-Forward hop-count 0
- LDRA Relay-Forward hop-count 1, Interface-ID inserted by LDRA
§8Trust and Security
An LDRA MUST have a setting for every client-facing interface that marks it trusted or untrusted, and this SHOULD be configurable per interface. If an interface is untrusted, the LDRA MUST discard any RELAY-FORW (12) message received from it. This stops a client from pretending to be a relay agent.
The security issues of RFC 3315 relay agents also apply to LDRAs. The LDRA SHOULD apply some form of rate-limiting on client-originated traffic to prevent excessive processing load. It can identify the traffic easily, since it only listens to client traffic sent to the DHCP servers and relay agents address on UDP port 547. Messages above the rate limit may be silently discarded.
The RFC also warns that hop-count-based judgement of whether an LDRA can be trusted can easily be defeated by a rogue relay agent on the network-facing interface.
The LDRA should not believe a plug that claims to be a helper, and it should not get swamped if someone sends too many requests. Even so, a fake helper on the server side of the box could still fool it.