Reconfigure Triggered by
DHCPv6 Relay AgentsFrance TelecomRennes35000Francemohamed.boucadair@orange.comFrance TelecomLannionFrancexavier.pougnard@orange.comDHC Working GroupThis document defines new DHCPv6 messages: Reconfigure-Request and
Reconfigure-Reply. 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. Reconfigure-Reply message is used by the server to
acknowledge the receipt of Reconfigure-Request.This document updates RFC 3315 and RFC 6422.This document specifies two new DHCPv6 messages : Reconfigure-Request and Reconfigure-Reply. describes a typical problem
encountered to trigger 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. describes the proposed solution which
relies on the use of Reconfigure-Request and Reconfigure-Reply messages.
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.
Reconfigure-Reply message is used by the server to acknowledge the
receipt of Reconfigure-Request. provides the detailed specification of
the procedure to trigger Reconfigure messages by DHCPv6 relay
agents.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 . updates the DHCPv6 specification with
a new feature to let a DHCPv6 relay agent communicate information
towards a DHCPv6 client, and which is not available at the DHCPv6
server. This is achieved owing to the 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 a RSOO context is shown in ;
only a subset of exchanged DHCPv6 and RADIUS messages is represented.
shows a broadband network scenario in which
the Network Access Server (NAS) embeds a DHCPv6 relay agent.The change of the configuration may result in an exchange of CoA
(Change-of-Authorization, ) messages
between the NAS/DHCPv6 relay agent and Dynamic Authorization Client
(DAC) server as shown in . In this example,
the NAS answers with a CoA-Ack message to notify the DAC the CoA-Request
is successfully handled.Note the change of the configuration in the DHCPv6 relay agent can be
triggered by any other out-of-band mechanism.Whenever the configuration information sent by the DHCPv6 relay agent
to the DHCPv6 server change, the DHCPv6 server has no means to detect
the change so that it can send a Reconfigure message accordingly. A
solution is sketched in .To solve the problem described in ,
this document proposes a new DHCP message called Reconfigure-Request. In
the example depicted in , 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
option have changed. Upon receipt of this message, and if it is
configured to support such mode, the DHCPv6 server must build
Reconfigure-Reply and Reconfigure messages. Reconfigure-Reply is used to
acknowledge the receipt of Reconfigure-Request. 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.
Furthermore, means to recover state in failure events must be supported,
but are not discussed in this document.The support of Reconfigure-Reply simplifies the retransmission
procedure of the relay as it provides an explicit indication from the
server (see for more details). An
alternative approach is the relay monitors Reconfigure messages received
from the server to conclude whether Reconfigure-Request was successfully
handled or not. Nevertheless, this implicit approach may fail to achieve
its goals in some cases: e.g., the server accepts the request but it
delays to generate 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), the approach adopted in this document allows the
relay to correct the content of a re-transmitted Reconfigure-Request
based on some observed events (e.g., the client has retrieved the
updated configuration). If the relay has no client to reconfigured, it
stops sending Reconfigure-Request messages.The Reconfigure-Request message can also be used in other scenarios
than those that assume the use of RSOO. It is out of scope of this
document to describe all these scenarios. shows the format of the Link Address
Option.The description of the fields are as follows:option-code: OPTION_LINK_ADDRESS (To be assigned by IANA, see
).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. 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
.Two new message type codes are defined:RECONFIGURE-REQUEST (To be assigned by IANA, see ).RECONFIGURE-REPLY (To be assigned by IANA, see ).RECONFIGURE-REQUEST and RECONFIGURE-REPLY use the same format as
defined in Section 6 of .Clients MUST silently discard any received RECONFIGURE-REQUEST
messages.Servers MUST discard any received RECONFIGURE-REQUEST messages
that meet any of the following conditions:the message does not include a Client Identifier Option .the message does not include a Link Address Option ().the message includes a Server Identifier Option but the contents of the Server
Identifier Option does not match the server's identifier.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:the "transaction-id" field in the message does not match the
value used in the original message.the message does not include a Server Identifier Option.the message does not include a Status Code Option .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
and a Link Address Option () 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 .The relay agent MAY supply the updated configuration in the RSOO
. 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 ) which 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 them identifies a specific client. If including
Client Identifier Options of all impacted clients exceeds the maximum
message size (see ), the relay MUST
generate several RECONFIGURE-REQUEST messages required to carry all
Client Identifier Options. Rate-limit considerations are discussed in
.The relay sets the destination address of the Reconfigure-Request
message to the IP address it would have sent a Relay-Forw message (see
Section 20 of ). 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 distinct "transaction-id"s 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 , using the following
parameters:When retransmission is required, the relay may decide to correct
the content of RECONFIGURE-REQUEST message it issues (e.g., update 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.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 to reject RECONFIGURE-REQUEST, the relay
MUST silently discard any RECONFIGURE-REQUEST it receives. If the
relay is configured to accept RECONFIGURE-REQUEST messages, these
messages are relayed as specified in Section
20.1.1 of.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 ), 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 indicating whether the request is
successfully processed, failed or partially failed. If the server fails to validate 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 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.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 MAY 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
configuration data sent to requesting clients.The server MAY 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 to construct a Reconfigure
message.Rate-limit considerations are discussed in .Depending on the status code enclosed in a received
RECONFIGURE-REPLY message, the relay may decide to terminate the
request or try a different corrected Reconfigure-Request.When multiple servers are configured, the relay should expect to
receive several Reconfigure-Reply messages. As mentioned in , 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 the
corresponding Client Identifier Option does not appear in at least one
Reconfigure-Reply message.The relay MUST rate-limit Reconfigure-Request messages to be sent to
the server. The relay MUST be configured with required rate-limit
parameters (i.e., the rate of Reconfigure-Request messages). 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 (i.e., the rate of Reconfigure
messages).IANA is requested to assign the following new DHCPv6 Message type in
the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters:RECONFIGURE-REQUESTRECONFIGURE-REPLYIANA is requested to assign the following new DHCPv6 Option Codes in
the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters:OPTION_LINK_ADDRESSSecurity considerations elaborated in
(in particular Section 21.1) and must be
taken into account. In addition, DHCPv6 servers MAY be configured to
reject relayed Reconfigure-Request messages or restrict relay chaining
(see for more discussion about the
rationale of this recommended behavior).
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 Reconfigure-Request message provides a mechanism for
triggering the DHCP Reconfigure message, and the DHCP Reconfigure
message can raise security threats (e.g., to control the timing of a
DHCP renewal), the DHCP server MUST have some mechanism for determining
that the relay agent is a trusted entity. A control policy based on the
content of received Relay Identifier Option MAY be enforced by the
DHCPv6 server. Reconfigure-Request messages originating from unknown
relay agents MUST be silently dropped.Many thanks to R. Maglione, A. Kostur, G. Halwasia and C. Jacquenet
for the comments and review.Special thanks to T. Lemon, B. Volz and T. Mrugalski who provided a
detailed review.