draft-ietf-dhc-triggered-reconfigure-06.txt   draft-ietf-dhc-triggered-reconfigure-07.txt 
DHC Working Group M. Boucadair DHC Working Group M. Boucadair
Internet-Draft X. Pougnard Internet-Draft X. Pougnard
Intended status: Standards Track France Telecom Intended status: Standards Track France Telecom
Expires: November 07, 2013 May 06, 2013 Expires: November 16, 2013 May 15, 2013
Reconfigure Triggered by DHCPv6 Relay Agents Reconfigure Triggered by DHCPv6 Relay Agents
draft-ietf-dhc-triggered-reconfigure-06 draft-ietf-dhc-triggered-reconfigure-07
Abstract Abstract
This document defines new DHCPv6 messages: Reconfigure-Request and This document defines new DHCPv6 messages: Reconfigure-Request and
Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6 Reconfigure-Reply. Reconfigure-Request message is sent by a DHCPv6
relay agent to notify a DHCPv6 server about a configuration relay agent to notify a DHCPv6 server about a configuration
information change, so that the DHCPv6 server can send a Reconfigure information change, so that the DHCPv6 server can send a Reconfigure
message accordingly. Reconfigure-Reply message is used by the server message accordingly. Reconfigure-Reply message is used by the server
to acknowledge the receipt of Reconfigure-Request. to acknowledge the receipt of Reconfigure-Request.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 07, 2013. This Internet-Draft will expire on November 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6 5. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6
6. Detailed Specification . . . . . . . . . . . . . . . . . . . 7 6. Detailed Specification . . . . . . . . . . . . . . . . . . . 7
6.1. Messages Format . . . . . . . . . . . . . . . . . . . . . 7 6.1. Messages Format . . . . . . . . . . . . . . . . . . . . . 7
6.2. Messages Validation . . . . . . . . . . . . . . . . . . . 7 6.2. Messages Validation . . . . . . . . . . . . . . . . . . . 7
6.2.1. RECONFIGURE-REQUEST . . . . . . . . . . . . . . . . . 7 6.2.1. RECONFIGURE-REQUEST . . . . . . . . . . . . . . . . . 7
6.2.2. RECONFIGURE-REPLY . . . . . . . . . . . . . . . . . . 7 6.2.2. RECONFIGURE-REPLY . . . . . . . . . . . . . . . . . . 7
6.3. Creation and Transmission of RECONFIGURE-REQUEST . . . . 7 6.3. Creation and Transmission of RECONFIGURE-REQUEST . . . . 8
6.4. Intermediate Relay Agents Behavior . . . . . . . . . . . 9 6.4. Intermediate Relay Agents Behavior . . . . . . . . . . . 9
6.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 9 6.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 9
6.6. Receipt of RECONFIGURE-REPLY . . . . . . . . . . . . . . 10 6.6. Receipt of RECONFIGURE-REPLY . . . . . . . . . . . . . . 10
7. Rate Limiting Considerations . . . . . . . . . . . . . . . . 11 7. Rate Limiting Considerations . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 12
skipping to change at page 3, line 19 skipping to change at page 3, line 19
Section 6 provides the detailed specification of the procedure to Section 6 provides the detailed specification of the procedure to
trigger Reconfigure messages by DHCPv6 relay agents. trigger Reconfigure messages by DHCPv6 relay agents.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Problem 3. Problem Statement
[RFC6422] updates the DHCPv6 specification with a new feature to let For cases where the DHCPv6 relay agent possesses some information
a DHCPv6 relay agent communicate information towards a DHCPv6 client, that would be useful to the DHCPv6 client, [RFC6422] specifies a
and which is not available at the DHCPv6 server. This is achieved mechanism whereby the DHCPv6 relay agent can provide such information
owing to the use of RSOO (Relay-Supplied Options option) which to the DHCPv6 server, which can, in turn, pass this information on to
carries configuration data to the DHCPv6 server. The data conveyed the DHCP client. This is achieved owing to the use of RSOO (Relay-
in an RSOO is then sent back by the DHCPv6 server to the requesting Supplied Options option) which carries configuration data to the
DHCPv6 client. 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 Figure 1; only a subset of An example of a RSOO context is shown in Figure 1; only a subset of
exchanged DHCPv6 and RADIUS messages is represented. Figure 1 shows exchanged DHCPv6 and RADIUS messages is represented. Figure 1 shows
a broadband network scenario in which the Network Access Server (NAS) a broadband network scenario in which the Network Access Server (NAS)
embeds a DHCPv6 relay agent. embeds a DHCPv6 relay agent.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius | |DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server | |Client | |(DHCPv6| |Server |
| | | Relay)| | | | | | Relay)| | |
skipping to change at page 4, line 13 skipping to change at page 4, line 14
|---Relay-Forward----------->| |---Relay-Forward----------->|
| (RSOO(OPTION_AFTR_NAME)) | | (RSOO(OPTION_AFTR_NAME)) |
| | | |
| |<--Relay-Reply--------------| | |<--Relay-Reply--------------|
|<--Advertise---------------| (e.g., OPTION_AFTR_NAME) | |<--Advertise---------------| (e.g., OPTION_AFTR_NAME) |
| (e.g., OPTION_AFTR_NAME) | | (e.g., OPTION_AFTR_NAME) |
.... ....
Figure 1: An Example of the RSOO Option Usage Figure 1: An Example of the RSOO Option Usage
The change of the configuration may result in an exchange of CoA A configuration change may result in an exchange of CoA (Change-of-
(Change-of-Authorization, [RFC5176]) messages between the NAS/DHCPv6 Authorization, [RFC5176]) messages between the NAS/DHCPv6 relay agent
relay agent and Dynamic Authorization Client (DAC) server as shown in and Dynamic Authorization Client (DAC) server as shown in Figure 2.
Figure 2. In this example, the NAS answers with a CoA-Ack message to In this example, the NAS answers with a CoA-Ack message to notify the
notify the DAC the CoA-Request is successfully handled. DAC the CoA-Request is successfully handled.
Note the change of the configuration in the DHCPv6 relay agent can be Note the change of the configuration in the DHCPv6 relay agent can be
triggered by any other out-of-band mechanism. triggered by any other out-of-band mechanism.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius | |DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server/| |Client | |(DHCPv6| |Server/|
| | | Relay)| | DAC | | | | Relay)| | DAC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| | | | | |
skipping to change at page 4, line 40 skipping to change at page 4, line 41
|------CoA-Ack-------------->| |------CoA-Ack-------------->|
.... ....
Figure 2: Change of configuration Figure 2: Change of configuration
Whenever the configuration information sent by the DHCPv6 relay agent Whenever the configuration information sent by the DHCPv6 relay agent
to the DHCPv6 server change, the DHCPv6 server has no means to detect 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 the change so that it can send a Reconfigure message accordingly. A
solution is sketched in Section 4. solution is sketched in Section 4.
4. Proposed Solution 4. Solution Overview
To solve the problem described in Section 3, this document proposes a To solve the problem described in Section 3, this document proposes a
new DHCP message called Reconfigure-Request. In the example depicted new DHCP message called Reconfigure-Request. In the example depicted
in Figure 3, a Reconfigure-Request message is sent by the DHCPv6 in Figure 3, a Reconfigure-Request message is sent by the DHCPv6
relay agent to a DHCPv6 server as soon as the configuration data relay agent to a DHCPv6 server as soon as the configuration data
conveyed in an RSOO option have changed. Upon receipt of this conveyed in an RSOO option have changed. Upon receipt of this
message, and if it is configured to support such mode, the DHCPv6 message, and if it is configured to support such mode, the DHCPv6
server must build Reconfigure-Reply and Reconfigure messages. server must build Reconfigure-Reply and Reconfigure messages.
Reconfigure-Reply is used to acknowledge the receipt of Reconfigure- Reconfigure-Reply is used to acknowledge the receipt of Reconfigure-
Request. Reconfigure message encapsulated in Relay-Reply is sent to Request. Reconfigure message encapsulated in Relay-Reply is sent to
skipping to change at page 6, line 47 skipping to change at page 6, line 48
link-address: An IPv6 address used by the server to identify the link-address: An IPv6 address used by the server to identify the
link on which the client is located. link on which the client is located.
The Link Address Option is used by the relay agent to indicate to the 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 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 use a link-address value that is equivalent to the value used when
relaying messages from the client to the server. Two link-address relaying messages from the client to the server. Two link-address
values are said to be equivalent if both values are IPv6 addresses 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 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 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 to the DHCPv6 server when relaying messages from the client to the
server, as in Section 20.1.1 of [RFC3315]. server, as in Section 20.1.1 of [RFC3315].
6. Detailed Specification 6. Detailed Specification
6.1. Messages Format 6.1. Messages Format
Two new message type codes are defined: Two new message type codes are defined:
o RECONFIGURE-REQUEST (To be assigned by IANA, see Section 8). o RECONFIGURE-REQUEST (To be assigned by IANA, see Section 8).
skipping to change at page 8, line 32 skipping to change at page 8, line 35
might insert when relaying a message received from a client. might insert when relaying a message received from a client.
When several clients on the same link are affected by a configuration When several clients on the same link are affected by a configuration
change, the relay MUST include several Client Identifier Options, change, the relay MUST include several Client Identifier Options,
each of them identifies a specific client. If including Client each of them identifies a specific client. If including Client
Identifier Options of all impacted clients exceeds the maximum Identifier Options of all impacted clients exceeds the maximum
message size (see Section 7), the relay MUST generate several message size (see Section 7), the relay MUST generate several
RECONFIGURE-REQUEST messages required to carry all Client Identifier RECONFIGURE-REQUEST messages required to carry all Client Identifier
Options. Rate-limit considerations are discussed in Section 7. Options. Rate-limit considerations are discussed in Section 7.
The relay sets the destination address of the Reconfigure-Request The relay sets the destination address of the RECONFIGURE-REQUEST
message to the IP address it would have sent a Relay-Forw message message to the IP address it would have sent a Relay-Forw message
(see Section 20 of [RFC3315]). (see Section 20 of [RFC3315]).
In case multiple servers are configured to the relay agent, several In case multiple servers are configured to the relay agent, several
Reconfigure-Request messages are to be built. The behavior of the RECONFIGURE-REQUEST messages are to be built. The behavior of the
relay agent to disambiguate responses when multiple servers are relay agent to disambiguate responses when multiple servers are
configured is implementation-specific. For example, an configured is implementation-specific. For example, an
implementation may generate distinct "transaction-id"s per server implementation may generate distinct "transaction-id"s per server
while another implementation may use the content of the "transaction- while another implementation may use the content of the "transaction-
id" field and the Server Identifier Option to disambiguate the id" field and the Server Identifier Option to disambiguate the
responses. responses.
The relay transmits RECONFIGURE-REQUEST messages according to The relay transmits RECONFIGURE-REQUEST messages according to
Section 14 of [RFC3315], using the following parameters: Section 14 of [RFC3315], using the following parameters:
skipping to change at page 9, line 20 skipping to change at page 9, line 17
The relay MAY remove clients from the client identifier list in The relay MAY remove clients from the client identifier list in
subsequent retransmissions, but MUST NOT add clients to the client subsequent retransmissions, but MUST NOT add clients to the client
identifier list. This decision is local to the relay (e.g., it may 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 be based on observed events such as one or more clients were
reconfigured on their own). reconfigured on their own).
The relay may receive Reconfigure encapsulated in Relay-Reply before The relay may receive Reconfigure encapsulated in Relay-Reply before
Reconfigure-Reply. The relay SHOULD NOT interpret it as if the Reconfigure-Reply. The relay SHOULD NOT interpret it as if the
Reconfigure-Request was successfully handled by the Server. The Reconfigure-Request was successfully handled by the Server. The
relay SHOULD use Reconfigure-Reply, not the Reconfigure message, to relay SHOULD use Reconfigure-Reply, not the Reconfigure message, to
determine if the request was successful. determine if the request was successful (see the discussion in
Section 4) .
6.4. Intermediate Relay Agents Behavior 6.4. Intermediate Relay Agents Behavior
The relay agent MUST be configurable to accept or reject RECONFIGURE- The relay agent MUST be configurable to accept or reject RECONFIGURE-
REQUEST messages received from other relay agents. If no indication REQUEST messages received from other relay agents. If no indication
is explicitly configured to the relay, the default behavior is to is explicitly configured to the relay, the default behavior is to
accept RECONFIGURE-REQUEST messages. accept RECONFIGURE-REQUEST messages.
If the relay is configured to reject RECONFIGURE-REQUEST, the relay If the relay is configured not to allow RECONFIGURE-REQUEST messages,
MUST silently discard any RECONFIGURE-REQUEST it receives. If the the relay MUST silently discard any RECONFIGURE-REQUEST message it
relay is configured to accept RECONFIGURE-REQUEST messages, these receives. If the relay is configured to accept RECONFIGURE-REQUEST
messages are relayed as specified in Section 20.1.1 of [RFC3315]. messages, these messages are relayed as specified in Section 20.1.1
of [RFC3315].
6.5. Server Behavior 6.5. Server Behavior
The server MUST be configurable to accept or reject RECONFIGURE- The server MUST be configurable to accept or reject RECONFIGURE-
REQUEST messages. If no indication is explicitly configured to the REQUEST messages. If no indication is explicitly configured to the
server, the default behavior is to reject RECONFIGURE-REQUEST server, the default behavior is to reject RECONFIGURE-REQUEST
messages. messages.
Upon receipt of a valid Reconfigure-Request message from a DHCPv6 Upon receipt of a valid RECONFIGURE-REQUEST message from a DHCPv6
relay agent (see Section 6.2), the server determines the client(s) relay agent (see Section 6.2), the server determines the client(s)
for which a Reconfigure message is to be sent. for which a Reconfigure message is to be sent.
The server constructs a Reconfigure-Reply message by setting the The server constructs a Reconfigure-Reply message by setting the
"msg-type" field to RECONFIGURE-REPLY, and copying the transaction ID "msg-type" field to RECONFIGURE-REPLY, and copying the transaction ID
from the RECONFIGURE-REQUEST message into the "transaction-id" field. from the RECONFIGURE-REQUEST message into the "transaction-id" field.
The server includes its server identifier in a Server Identifier The server includes its server identifier in a Server Identifier
Option. The server MUST include a Status Code Option [RFC3315] Option. The server MUST include a Status Code Option [RFC3315]
indicating whether the request is successfully processed, failed or indicating whether the request is successfully processed, failed or
partially failed. partially failed.
o If the server fails to validate the request, the server MUST set o If the server fails to process the request, the server MUST set
the Status Code Option to the appropriate status code (e.g., the Status Code Option to the appropriate status code (e.g.,
UnspecFail, NotAllowed, etc.). In particular, UnspecFail, NotAllowed, etc.). In particular,
* UnspecFail MUST be returned if Reconfigure-Request message is * UnspecFail MUST be returned if Reconfigure-Request message is
malformed. malformed.
* NotAllowed MUST be returned if the server is not configured to * NotAllowed MUST be returned if the server is not configured to
allow Reconfigure-Request. allow Reconfigure-Request.
* NotConfigured MUST be returned if the server has no record of * NotConfigured MUST be returned if the server has no record of
the link. the link [RFC5007].
o If the Reconfigure-Request is successfully validated, the server o If the RECONFIGURE-REQUEST is successfully validated, the server
MUST return a Status Code Option indicating "Success". In MUST return a Status Code Option indicating "Success". In
addition, the server MUST include a list of all the Client addition, the server MUST include a list of all the Client
Identifier Options of the clients to which Reconfigure messages Identifier Options of the clients to which Reconfigure messages
will not be sent (e.g., the server has no record of the client or 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 the client did not negotiate for Reconfigure support). Note that
this means that "Success" will be returned even if Reconfigure this means that "Success" will be returned even if Reconfigure
messages will not be sent to any of the clients. messages will not be sent to any of the clients.
If RSOO is supplied, the server MAY use its content to double check 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 whether a Reconfigure is required to be sent to the client. This
assumes the server stored the content of RSOO it used to generate assumes the server stored the content of RSOO it used to generate
configuration data sent to requesting clients. configuration data sent to requesting clients.
The server MAY use the content of the Reconfigure Message Option The server might use the content of the Reconfigure Message Option
supplied by the relay agent to determine which form of Reconfigure to supplied by the relay agent to determine which form of Reconfigure to
use. use.
Then, the server MUST follow the procedure defined in Section 19.1 of Then, the server MUST follow the procedure defined in Section 19.1 of
[RFC3315] to construct a Reconfigure message. [RFC3315] to construct a Reconfigure message.
Rate-limit considerations are discussed in Section 7. Rate-limit considerations are discussed in Section 7.
6.6. Receipt of RECONFIGURE-REPLY 6.6. Receipt of RECONFIGURE-REPLY
Depending on the status code enclosed in a received RECONFIGURE-REPLY Depending on the status code enclosed in a received RECONFIGURE-REPLY
message, the relay may decide to terminate the request or try a message, the relay may decide to terminate the request (e.g.,
different corrected Reconfigure-Request. NotAllowed, NotConfigured, and Success) or try a different corrected
RECONFIGURE-REQUEST (e.g., UnspecFail).
When multiple servers are configured, the relay should expect to When multiple servers are configured, the relay should expect to
receive several Reconfigure-Reply messages. As mentioned in receive several RECONFIGURE-REPLY messages. As mentioned in
Section 6.3, the relay should be able to disambiguate these responses Section 6.3, the relay should be able to disambiguate these responses
and associate them with a given server. The relay agent assumes the and associate them with a given server. The relay agent assumes the
request is successfully handled for a client if the corresponding request is successfully handled for a client if there is at least one
Client Identifier Option does not appear in at least one Reconfigure- Reconfigure-Reply message in which the corresponding Client
Reply message. Identifier Option does not appear.
7. Rate Limiting Considerations 7. Rate Limiting Considerations
The relay MUST rate-limit Reconfigure-Request messages to be sent to The relay MUST rate-limit RECONFIGURE-REQUEST messages to be sent to
the server. The relay MUST be configured with required rate-limit the server. The relay MUST be configured with required rate-limit
parameters (i.e., the rate of Reconfigure-Request messages). The parameters. The maximum RECONFIGURE-REQUEST packet size SHOULD be
maximum Reconfigure-Request packet size SHOULD be configurable and configurable and the default value MUST be 1280 octets.
the default value MUST be 1280 octets.
The server MUST rate-limit Reconfigure messages triggered by The server MUST rate-limit Reconfigure messages triggered by
Reconfigure-Request messages. The server MUST be configured with RECONFIGURE-REQUEST messages. The server MUST be configured with
required rate-limit parameters (i.e., the rate of Reconfigure required rate-limit parameters.
messages).
8. IANA Considerations 8. IANA Considerations
IANA is requested to assign the following new DHCPv6 Message type in IANA is requested to assign the following new DHCPv6 Message type in
the registry maintained in http://www.iana.org/assignments/ the registry maintained in http://www.iana.org/assignments/
dhcpv6-parameters: dhcpv6-parameters:
RECONFIGURE-REQUEST RECONFIGURE-REQUEST
RECONFIGURE-REPLY RECONFIGURE-REPLY
skipping to change at page 11, line 46 skipping to change at page 11, line 38
IANA is requested to assign the following new DHCPv6 Option Codes in IANA is requested to assign the following new DHCPv6 Option Codes in
the registry maintained in http://www.iana.org/assignments/ the registry maintained in http://www.iana.org/assignments/
dhcpv6-parameters: dhcpv6-parameters:
OPTION_LINK_ADDRESS OPTION_LINK_ADDRESS
9. Security Considerations 9. Security Considerations
Security considerations elaborated in [RFC3315] (in particular Security considerations elaborated in [RFC3315] (in particular
Section 21.1) and [RFC6422] must be taken into account. In addition, Section 21.1) and [RFC6422] must be taken into account. In addition,
DHCPv6 servers MAY be configured to reject relayed Reconfigure- DHCPv6 servers MAY be configured to reject relayed RECONFIGURE-
Request messages or restrict relay chaining (see [RFC5007] for more REQUEST messages or restrict relay chaining (see [RFC5007] for more
discussion about the rationale of this recommended behavior). discussion about the rationale of this recommended behavior).
Section 6.5 specifies the error code to return when the server is Section 6.5 specifies the error code to return when the server is
configured to reject Reconfigure-Request messages. configured to reject RECONFIGURE-REQUEST messages.
Relay agents SHOULD implement appropriate means to prevent using Relay agents SHOULD implement appropriate means to prevent using
Reconfigure-Request messages as a denial-of-service attack on the RECONFIGURE-REQUEST messages as a denial-of-service attack on the
DHCPv6 servers. DHCPv6 servers.
Because Reconfigure-Request message provides a mechanism for Because RECONFIGURE-REQUEST message provides a mechanism for
triggering the DHCP Reconfigure message, and the DHCP Reconfigure triggering the DHCPv6 Reconfigure message, and the DHCPv6 Reconfigure
message can raise security threats (e.g., to control the timing of a message can raise security threats (e.g., to control the timing of a
DHCP renewal), the DHCP server MUST have some mechanism for DHCPv6 renewal), the DHCPv6 server MUST have some mechanism for
determining that the relay agent is a trusted entity. A control determining that the relay agent is a trusted entity. DHCPv6 servers
policy based on the content of received Relay Identifier Option MAY and relay agents MUST implement relay message authentication as
be enforced by the DHCPv6 server. Reconfigure-Request messages described in Section 21.1 of [RFC3315]. DHCPv6 servers MAY also
originating from unknown relay agents MUST be silently dropped. implement a control policy based on the content of 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 10. Acknowledgements
Many thanks to R. Maglione, A. Kostur, G. Halwasia, C. Jacquenet, Many thanks to R. Maglione, A. Kostur, G. Halwasia, C. Jacquenet,
and R. Sparks for the comments and review. 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 Special thanks to T. Lemon, B. Volz and T. Mrugalski who provided
a detailed review. a detailed review.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC
6422, December 2011. 6422, December 2011.
11.2. Informative References 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, [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007. "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
Aboba, "Dynamic Authorization Extensions to Remote Aboba, "Dynamic Authorization Extensions to Remote
Authentication Dial In User Service (RADIUS)", RFC 5176, Authentication Dial In User Service (RADIUS)", RFC 5176,
January 2008. January 2008.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February
2009. 2009.
 End of changes. 33 change blocks. 
59 lines changed or deleted 80 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/