RFC 6977 PROPOSED STANDARD DHCPV6 · RELAY · CONFIGURATION
DHCPv6 Reconfigure-Request: Triggering DHCPv6 Reconfiguration from Relay Agents
Lets a DHCPv6 relay agent tell the server that configuration changed, so the server can reconfigure clients.
RFC EDITOR
Boucadair, M. and X. Pougnard, "Triggering DHCPv6 Reconfiguration from Relay Agents", RFC 6977, DOI 10.17487/RFC6977, July 2013, <https://www.rfc-editor.org/info/rfc6977>.
BIBTEX
@misc{rfc6977,
series = {Request for Comments},
number = 6977,
howpublished = {RFC 6977},
publisher = {RFC Editor},
doi = {10.17487/RFC6977},
url = {https://www.rfc-editor.org/info/rfc6977},
author = {M. Boucadair and X. Pougnard},
title = {{Triggering DHCPv6 Reconfiguration from Relay Agents}},
pagetotal = 13,
year = 2013,
month = jul,
} RFC text
Contents
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 6977 X. Pougnard
Category: Standards Track France Telecom
ISSN: 2070-1721 July 2013
Triggering DHCPv6 Reconfiguration from Relay Agents
Abstract
This document defines two new DHCPv6 messages: Reconfigure-Request
and Reconfigure-Reply. The Reconfigure-Request message is sent by a
DHCPv6 relay agent to notify a DHCPv6 server about a configuration
information change, so that the DHCPv6 server can send a Reconfigure
message accordingly. The Reconfigure-Reply message is used by the
server to acknowledge the receipt of the Reconfigure-Request message.
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/rfc6977.
Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6
6. Detailed Specification . . . . . . . . . . . . . . . . . . . 6
6.1. Messages Format . . . . . . . . . . . . . . . . . . . . . 6
6.2. Messages Validation . . . . . . . . . . . . . . . . . . . 7
6.2.1. Reconfigure-Request . . . . . . . . . . . . . . . . . 7
6.2.2. Reconfigure-Reply . . . . . . . . . . . . . . . . . . 7
6.3. Creation and Transmission of a Reconfigure-Request . . . 7
6.4. Intermediate Relay Agents Behavior . . . . . . . . . . . 9
6.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 9
6.6. Receipt of a Reconfigure-Reply . . . . . . . . . . . . . 10
7. Rate-Limiting Considerations . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12
1. Introduction
This document specifies two new DHCPv6 messages [RFC3315]:
Reconfigure-Request and Reconfigure-Reply.
Section 3 describes a typical problem scenario encountered that
triggers the DHCPv6 server to issue a Reconfigure message when the
configuration data is supplied by the relay agent. This problem may
be encountered in other contexts. It is out of scope of this
document to list all these cases.
Section 4 describes the proposed solution that relies on the use of
Reconfigure-Request and Reconfigure-Reply messages. The Reconfigure-
Request message is sent by a DHCPv6 relay agent to notify a DHCPv6
server about a configuration-information change, so that the DHCPv6
server can send a Reconfigure message accordingly. The Reconfigure-
Reply message is used by the server to acknowledge the receipt of
Reconfigure-Request.
Section 5 specifies the Link Address Option used by the relay agent
to indicate the link on which the client is located to the server.
Section 6 provides the detailed specification of the procedure to
trigger Reconfigure messages by DHCPv6 relay agents.
2. 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 [RFC2119].
3. Problem Statement
For cases where the DHCPv6 relay agent possesses some information
that would be useful to the DHCPv6 client, [RFC6422] specifies a
mechanism whereby the DHCPv6 relay agent can provide such information
to the DHCPv6 server, which can, in turn, pass this information on to
the DHCP client. This is achieved by use of RSOO (Relay-Supplied
Options option), which carries configuration data to the DHCPv6
server. The data conveyed in an RSOO is then sent back by the DHCPv6
server to the requesting DHCPv6 client.
An example of RSOO usage is shown in Figure 1; only a subset of
exchanged DHCPv6 and RADIUS messages is represented. Figure 1 shows
a broadband network scenario in which the Network Access Server (NAS)
embeds a DHCPv6 relay agent.
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server |
| | | Relay)| | |
+-------+ +-------+ +-------+
| | |
|---Solicit---------------->| |
| |---Access-Request---------->|
|<--Access-Accept------------|
| (e.g., DS-Lite-Tunnel-Name)|
....
| +-------+
| |DHCPv6 |
| |Server |
| | |
| +-------+
| |
|---Relay-Forward----------->|
| (RSOO(OPTION_AFTR_NAME)) |
| |
| |<--Relay-Reply--------------|
|<--Advertise---------------| (e.g., OPTION_AFTR_NAME) |
| (e.g., OPTION_AFTR_NAME) |
....
Figure 1: An Example of the RSOO Usage
A configuration change may result in an exchange of CoA (Change-of-
Authorization) [RFC5176] messages between the NAS/DHCPv6 relay agent
and Dynamic Authorization Client (DAC) server as shown in Figure 2.
In this example, the NAS answers with a CoA-Ack message to notify the
DAC that the CoA-Request has been successfully handled.
Note that the change of the configuration in the DHCPv6 relay agent
can be triggered by any other out-of-band mechanism.
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server/|
| | | Relay)| | DAC |
+-------+ +-------+ +-------+
| | |
|<-----CoA-Request-----------|
|(e.g., DS-Lite-Tunnel-Name) |
|------CoA-Ack-------------->|
....
Figure 2: Change of Configuration
Whenever the configuration information sent by the DHCPv6 relay agent
to the DHCPv6 server changes, the DHCPv6 server has no means of
detecting the change so that it can send a Reconfigure message
accordingly. A solution is sketched in Section 4.
4. Solution Overview
To solve the problem described in Section 3, this document proposes a
new DHCP message called Reconfigure-Request. In the example depicted
in Figure 3, a Reconfigure-Request message is sent by the DHCPv6
relay agent to a DHCPv6 server as soon as the configuration data
conveyed in an RSOO has changed. Upon receipt of this message, and
if it is configured to support such a mode, the DHCPv6 server must
build Reconfigure-Reply and Reconfigure messages. Reconfigure-Reply
is used to acknowledge the receipt of Reconfigure-Request. The
Reconfigure message encapsulated in Relay-Reply is sent to the DHCPv6
relay, which in turn will forward the message to the appropriate
DHCPv6 client.
This setup assumes the relay has a record of the client, so that it
has enough information to send the Reconfigure-Request message to the
server. How the state is recorded in the relay is out of scope of
this document. For better resilience of the proposed solution, means
to recover state in the event of failure (e.g., use of stable
storage, DHCPv6 Bulk Leasequery [RFC5460]) need to be supported.
These state recovery solutions are not discussed in this document.
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server/|
| | | Relay)| | DAC |
+-------+ +-------+ +-------+
| | |
|<-----CoA-Request-----------|
|(e.g., DS-Lite-Tunnel-Name) |
| |
|------CoA-Ack-------------->|
....
| +-------+
| |DHCPv6 |
| |Server |
| | |
| +-------+
| |
|---Reconfigure-Request----->|
|<--Reconfigure-Reply--------|
| |
| |<--Relay-Reply -------------|
|<--Reconfigure-------------| (Reconfigure) |
| | |
....
Figure 3: Flow Example with Reconfigure-Request
The support of Reconfigure-Reply messages simplifies the
retransmission procedure of the relay as it provides an explicit
indication from the server (see Section 6.3 for more details). An
alternative approach is the relay monitors' Reconfigure messages
received from the server to conclude whether or not the Reconfigure-
Request was successfully handled. Nevertheless, this implicit
approach may fail to achieve its goals in some cases: for example,
the server accepts the request but it delays generating the
corresponding Reconfigure messages due to its rate-limiting policies,
the request was partially failed for some clients, etc. To avoid
useless reconfigure cycles (e.g., due to the loss of Reconfigure-
Reply messages), the approach adopted in this document allows the
relay to correct the content of a retransmitted Reconfigure-Request
based on some observed events (e.g., the client has retrieved the
updated configuration). If the relay has no client to be
reconfigured, it stops sending Reconfigure-Request messages.
The Reconfigure-Request message can also be used in scenarios other
than those that assume the use of RSOO. It is out of scope of this
document to describe all these scenarios.
5. Link Address Option
Figure 4 shows the format of the Link Address Option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LINK_ADDRESS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| link-address (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Message Format of Link Address Option
The description of the fields are as follows:
option-code: OPTION_LINK_ADDRESS (80)
option-len: 16 (octets)
link-address: An IPv6 address used by the server to identify the
link on which the client is located.
The Link Address Option is used by the relay agent to indicate to the
server the link on which the client is located. The relay agent MUST
use a link-address value that is equivalent to the value used when
relaying messages from the client to the server. Two link-address
values are said to be equivalent if both values are IPv6 addresses
that are on-link for the network link to which the client is
connected.
To defend against poor implementations that do not correctly evaluate
equivalence, the relay agent SHOULD use the same value that was sent
to the DHCPv6 server when relaying messages from the client to the
server, as in Section 20.1.1 of [RFC3315].
6. Detailed Specification
6.1. Messages Format
Two new message type codes are defined:
o RECONFIGURE-REQUEST (18)
o RECONFIGURE-REPLY (19)
Reconfigure-Request and Reconfigure-Reply use the same format as
defined in Section 6 of [RFC3315].
6.2. Messages Validation
6.2.1. Reconfigure-Request
Clients MUST silently discard any received Reconfigure-Request
messages.
Servers MUST discard any received Reconfigure-Request messages that
meet any of the following conditions:
o the message does not include a Client Identifier Option [RFC3315].
o the message does not include a Link Address Option (Section 5).
o the message includes a Server Identifier Option [RFC3315] but the
contents of the Server Identifier Option do not match the server's
identifier.
6.2.2. Reconfigure-Reply
Clients and servers MUST silently discard any received Reconfigure-
Reply messages.
The relay MUST silently discard any received Reconfigure-Reply
messages that meet any of the following conditions:
o the "transaction-id" field in the message does not match the value
used in the original message.
o the message does not include a Server Identifier Option.
o the message does not include a Status Code Option [RFC3315].
6.3. Creation and Transmission of a Reconfigure-Request
For any event (e.g., modification of the configuration information)
that requires the server to issue a Reconfigure message, the relay
agent determines the client(s) affected by the change and then builds
a Reconfigure-Request message: the relay agent sets the "msg-type"
field to RECONFIGURE-REQUEST, generates a transaction ID, and inserts
it in the "transaction-id" field.
The relay agent MUST include one or more Client Identifier Options
[RFC3315] and a Link Address Option (Section 5) so that the DHCPv6
server can identify the corresponding client and the link on which
the client is located.
The relay agent MAY include a Relay Identifier Option [RFC5460].
The relay agent MAY supply the updated configuration in the RSOO
[RFC6422]. The relay agent MAY supply a Reconfigure Message Option
to indicate which form of Reconfigure to use. The relay agent MAY
include any option (e.g., Interface Identifier [RFC3315]) that it
might insert when relaying a message received from a client.
When several clients on the same link are affected by a configuration
change, the relay MUST include several Client Identifier Options;
each of these options identifies a specific client. If including the
Client Identifier Options of all impacted clients exceeds the maximum
message size (see Section 7), the relay MUST generate several
Reconfigure-Request messages required to carry all Client Identifier
Options. Rate-limit considerations are discussed in Section 7.
The relay sets the destination address of the Reconfigure-Request
message to the IP address it would have sent a Relay-Forward message
(see Section 20 of [RFC3315]).
In case multiple servers are configured to the relay agent, several
Reconfigure-Request messages are to be built. The behavior of the
relay agent to disambiguate responses when multiple servers are
configured is implementation specific. For example, an
implementation may generate a distinct "transaction-id" per server
while another implementation may use the content of the "transaction-
id" field and the Server Identifier Option to disambiguate the
responses.
The relay transmits Reconfigure-Request messages according to
Section 14 of [RFC3315], using the following parameters:
IRT (Initial retransmission time): 1 sec
MRT (Maximum retransmission time): 10 secs
MRC (Maximum retransmission count): 5
MRD (Maximum retransmission duration): 0
The relay MAY remove clients from the client identifier list in
subsequent retransmissions, but MUST NOT add clients to the client
identifier list. This decision is local to the relay (e.g., it may
be based on observed events such as one or more clients were
reconfigured on their own).
The relay may receive Reconfigure encapsulated in Relay-Reply before
Reconfigure-Reply. The relay SHOULD NOT interpret it as if the
Reconfigure-Request was successfully handled by the server. The
relay SHOULD use Reconfigure-Reply, not the Reconfigure message, to
determine if the request was successful (see the discussion in
Section 4).
6.4. Intermediate Relay Agents Behavior
The relay agent MUST be configurable to accept or reject Reconfigure-
Request messages received from other relay agents. If no indication
is explicitly configured to the relay, the default behavior is to
accept Reconfigure-Request messages.
If the relay is configured not to allow Reconfigure-Request messages,
the relay MUST silently discard any Reconfigure-Request message it
receives. If the relay is configured to accept Reconfigure-Request
messages, these messages are relayed as specified in Section 20.1.1
of [RFC3315].
6.5. Server Behavior
The server MUST be configurable to accept or reject Reconfigure-
Request messages. If no indication is explicitly configured to the
server, the default behavior is to reject Reconfigure-Request
messages.
Upon receipt of a valid Reconfigure-Request message from a DHCPv6
relay agent (see Section 6.2), the server determines the client(s)
for which a Reconfigure message is to be sent.
The server constructs a Reconfigure-Reply message by setting the
"msg-type" field to RECONFIGURE-REPLY and copying the transaction ID
from the Reconfigure-Request message into the "transaction-id" field.
The server includes its server identifier in a Server Identifier
Option. The server MUST include a Status Code Option [RFC3315]
indicating whether the request has been successfully processed,
failed, or partially failed.
o If the server fails to process the request, the server MUST set
the Status Code Option to the appropriate status code (e.g.,
UnspecFail, NotAllowed, etc.). In particular,
* UnspecFail MUST be returned if the Reconfigure-Request message
is malformed.
* NotAllowed MUST be returned if the server is not configured to
allow Reconfigure-Request.
* NotConfigured MUST be returned if the server has no record of
the link [RFC5007].
o If the Reconfigure-Request is successfully validated, the server
MUST return a Status Code Option indicating "Success". In
addition, the server MUST include a list of all the Client
Identifier Options of the clients to which Reconfigure messages
will not be sent (e.g., the server has no record of the client or
the client did not negotiate for Reconfigure support). Note that
this means that "Success" will be returned even if Reconfigure
messages will not be sent to any of the clients.
If RSOO is supplied, the server might use its content to double check
whether a Reconfigure is required to be sent to the client. This
assumes the server stored the content of RSOO it used to generate the
configuration data sent to requesting clients.
The server might use the content of the Reconfigure Message Option
supplied by the relay agent to determine which form of Reconfigure to
use.
Then, the server MUST follow the procedure defined in Section 19.1 of
[RFC3315] to construct a Reconfigure message.
Rate-limit considerations are discussed in Section 7.
6.6. Receipt of a Reconfigure-Reply
Depending on the status code enclosed in a received Reconfigure-Reply
message, the relay may decide to terminate the request (e.g.,
NotAllowed, NotConfigured, and Success) or try a different corrected
Reconfigure-Request (e.g., UnspecFail).
When multiple servers are configured, the relay should expect to
receive several Reconfigure-Reply messages. As mentioned in
Section 6.3, the relay should be able to disambiguate these responses
and associate them with a given server. The relay agent assumes the
request is successfully handled for a client if there is at least one
Reconfigure-Reply message in which the corresponding Client
Identifier Option does not appear.
7. Rate-Limiting Considerations
The relay MUST rate-limit Reconfigure-Request messages to be sent to
the server. The relay MUST be configured with required rate-limit
parameters. The maximum Reconfigure-Request packet size SHOULD be
configurable and the default value MUST be 1280 octets.
The server MUST rate-limit Reconfigure messages triggered by
Reconfigure-Request messages. The server MUST be configured with
required rate-limit parameters.
8. IANA Considerations
IANA has assigned the following new DHCPv6 Message types in the
registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters:
RECONFIGURE-REQUEST
RECONFIGURE-REPLY
IANA has assigned the following new DHCPv6 Option Codes in the
registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters:
OPTION_LINK_ADDRESS
9. Security Considerations
Security considerations elaborated in [RFC3315] (in particular
Section 21.1) and [RFC6422] must be taken into account. In addition,
DHCPv6 servers MAY be configured to reject relayed Reconfigure-
Request messages or restrict relay chaining (see [RFC5007] for more
discussion about the rationale of this recommended behavior).
Section 6.5 specifies the error code to return when the server is
configured to reject Reconfigure-Request messages.
Relay agents SHOULD implement appropriate means to prevent using
Reconfigure-Request messages as a denial-of-service attack on the
DHCPv6 servers.
Because the Reconfigure-Request message provides a mechanism for
triggering the DHCPv6 Reconfigure message, and the DHCPv6 Reconfigure
message can raise security threats (e.g., to control the timing of a
DHCPv6 renewal), the DHCPv6 server MUST have some mechanism for
determining that the relay agent is a trusted entity. DHCPv6 servers
and relay agents MUST implement relay message authentication as
described in Section 21.1 of [RFC3315]. DHCPv6 servers MAY also
implement a control policy based on the content of a received Relay
Identifier Option [RFC5460]. Administrators are strongly advised to
configure one of these security mechanisms.
In an environment where the network connecting the relay agent to the
DHCPv6 server is physically secure and does not contain devices not
controlled by the server administrator, it may be sufficient to trust
the Relay Agent Identifier provided by the relay agent. In networks
where the security of the machines with access to the data path is
not under the control of the server administrator, IPsec [RFC4301] is
necessary to prevent spoofing of Reconfigure-Request messages.
DHCPv6 servers MUST silently discard Reconfigure-Request messages
originating from unknown relay agents.
10. Acknowledgements
Many thanks to R. Maglione, A. Kostur, G. Halwasia, C. Jacquenet, B.
Leiba, R. Sparks, A. Farrel, B. Claise, J. Jaeggli, and P. Resnick
for the comments and review.
Special thanks to T. Lemon, B. Volz, and T. Mrugalski who provided a
detailed review.
11. References
11.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., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC
6422, December 2011.
11.2. Informative References
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009.
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
Xavier Pougnard
France Telecom
Lannion
France
EMail: xavier.pougnard@orange.com
AI ELI5
On this page
PROBLEMWhen a relay agent supplies configuration data that later changes, the DHCPv6 server has no way to notice, so it never sends a Reconfigure message to the affected clients.
MECHANISMThe relay sends a new Reconfigure-Request message naming the affected clients and their link. The server acknowledges with a Reconfigure-Reply carrying a status code and then builds the Reconfigure messages.
WHY IT MATTERSA relay can now trigger reconfiguration itself, with retransmission, rate limiting and relay authentication to keep it safe. Servers reject these requests unless configured to accept them.
§3The Problem: Silent Configuration Changes
A DHCPv6 relay agent can pass configuration data to the server in the Relay-Supplied Options option (RSOO) defined in RFC 6422. The server then hands that data back to the requesting client. The RFC's example is a broadband network where the Network Access Server (NAS) embeds the relay agent and learns a DS-Lite tunnel name from a RADIUS server.
That data can change later. In the RFC's example, a Change-of-Authorization (CoA) exchange between the NAS and a Dynamic Authorization Client (DAC) server changes it (see RFC 5176); the text also notes that any other out-of-band mechanism could trigger such a change. The DHCPv6 server has no means of detecting the change, so it cannot send a Reconfigure message to the client.
The front desk learns new rules from head office, but the manager never hears about the change. So the manager never tells the guests.
§4The Solution: Reconfigure-Request and Reconfigure-Reply
The RFC defines two new DHCPv6 messages. A Reconfigure-Request is sent by the relay to the server as soon as the configuration data in an RSOO has changed. If the server is configured to support this mode, it builds a Reconfigure-Reply to acknowledge the request, and a normal Reconfigure message that travels to the client inside a Relay-Reply.
The relay must already have a record of the client. How it stores that state is out of scope, but the RFC says means to recover state after a failure (stable storage, or DHCPv6 Bulk Leasequery from RFC 5460) need to be supported.
The Reconfigure-Reply exists because the alternative is fragile. A relay could watch for Reconfigure messages instead, but a server might delay them because of rate limiting, or fail for only some clients. An explicit reply lets the relay retransmit a corrected request and stop when no clients remain to be reconfigured.
The helper sends a note and waits for a "got it" reply. Without the reply it would have to guess whether the manager did anything.
RADIUS Server / DACNAS (DHCPv6 relay)DHCPv6 ServerDHCPv6 Client
- CoA-RequestConfiguration changes, e.g. DS-Lite-Tunnel-Name.
- CoA-Ack
- Reconfigure-RequestNames the affected clients and the link.
- Reconfigure-ReplyCarries a Status Code Option.
- Relay-Reply (Reconfigure)
- Reconfigure
§5Message Types and the Link Address Option
Two message type codes are defined: RECONFIGURE-REQUEST (18) and RECONFIGURE-REPLY (19). Both use the same message format as in Section 6 of RFC 3315.
The new Link Address Option has option code OPTION_LINK_ADDRESS (80) and an option-len of 16 octets. It holds an IPv6 address that the server uses to identify the link where the client sits. The relay MUST use a value equivalent to the one it used when relaying the client's messages, meaning an address on-link for the client's network link. To guard against poor implementations, it SHOULD use the very same value it sent before.
The Link Address Option is like writing the street name on the note, so the manager knows which neighbourhood the guests live in.
- 18RECONFIGURE-REQUEST — Relay to server: configuration changed, please reconfigure these clients.
- 19RECONFIGURE-REPLY — Server to relay: acknowledges the request with a status code.
- 80OPTION_LINK_ADDRESS — Option holding an IPv6 address that identifies the client's link (16 octets).
§6How the Relay and Server Behave
Relay. After a change, the relay finds the affected clients, sets msg-type to RECONFIGURE-REQUEST and generates a transaction ID. It MUST include one or more Client Identifier Options and a Link Address Option. It MAY add a Relay Identifier Option, the updated configuration in an RSOO, a Reconfigure Message Option, and other options it would normally insert. If the client list would exceed the maximum message size, it MUST send several requests. With several servers configured, it builds one request per server.
Retransmission follows Section 14 of RFC 3315 with IRT 1 sec, MRT 10 secs, MRC 5 and MRD 0. The relay MAY drop clients from later retransmissions but MUST NOT add any. It SHOULD judge success by the Reconfigure-Reply, not by a Reconfigure message arriving first.
Server. A server MUST be configurable to accept or reject these requests, and the default is to reject. It copies the transaction ID into a Reconfigure-Reply, includes its Server Identifier Option and MUST include a Status Code Option. It then builds Reconfigure messages following Section 19.1 of RFC 3315.
Intermediate relays MUST be configurable to accept or reject Reconfigure-Request messages from other relays. The default is to accept.
The helper writes down who needs to know and where they live, and re-sends the note a few times if no reply comes. The manager only acts if the manager has been told that such notes are allowed.
§6.2Validation and Status Codes
A server MUST discard a Reconfigure-Request that lacks a Client Identifier Option, lacks a Link Address Option, or carries a Server Identifier Option that does not match its own. Clients silently discard any Reconfigure-Request, and clients and servers silently discard any Reconfigure-Reply. A relay discards a Reconfigure-Reply with a mismatched transaction ID, or one missing a Server Identifier Option or Status Code Option.
The Status Code in the reply tells the relay what happened:
UnspecFailMUST be returned if the request is malformed.NotAllowedMUST be returned if the server is not configured to allow Reconfigure-Request.NotConfiguredMUST be returned if the server has no record of the link.Successis returned if the request validates, along with a list of Client Identifier Options for clients that will not get a Reconfigure (for example, no record of the client or no Reconfigure support negotiated). Success can therefore be returned even if no client is reconfigured.
The relay may end its attempt on NotAllowed, NotConfigured or Success, or try a corrected request after UnspecFail. It treats a client as handled if at least one reply does not list that client.
The manager answers with a code: "fine," "not allowed," "I don't know that street," or "your note was garbled." The helper decides what to do next from that code.
§9Rate Limiting and Security
The relay MUST rate-limit Reconfigure-Request messages, and the maximum request size SHOULD be configurable with a default MUST of 1280 octets. The server MUST rate-limit the Reconfigure messages it sends because of these requests.
Because a Reconfigure can be abused, for example to control the timing of a DHCPv6 renewal, the server MUST have some way to decide that the relay is trusted. Servers and relays MUST implement relay message authentication as in Section 21.1 of RFC 3315, and servers MAY apply a policy based on the Relay Identifier Option. Where the path is not under the server administrator's control, IPsec is necessary to prevent spoofing. Servers MUST silently discard requests from unknown relay agents, and relays SHOULD guard against being used for denial-of-service attacks on servers.
The manager only listens to helpers it trusts, and nobody is allowed to send too many notes too fast.
§7References
[RFC2119]RFC 2119Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.March 1997[RFC3315]RFC 3315Droms, R., et al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.July 2003[RFC6422]RFC 6422Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, December 2011.December 2011[RFC4301]RFC 4301Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.December 2005[RFC5007]RFC 5007Brzozowski, J., et al., "DHCPv6 Leasequery", RFC 5007, September 2007.September 2007[RFC5176]RFC 5176Chiba, M., et al., "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.January 2008[RFC5460]RFC 5460Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.February 2009