draft-ietf-dhc-triggered-reconfigure-02.txt   draft-ietf-dhc-triggered-reconfigure-03.txt 
DHC Working Group M. Boucadair DHC Working Group M. Boucadair
Internet-Draft X. Pougnard Internet-Draft X. Pougnard
Updates: 3315, 6422 (if approved) France Telecom Updates: 3315, 6422 (if approved) France Telecom
Intended status: Standards Track December 17, 2012 Intended status: Standards Track January 21, 2013
Expires: June 20, 2013 Expires: July 25, 2013
RECONFIGURE Triggered by DHCPv6 Relay Agents RECONFIGURE Triggered by DHCPv6 Relay Agents
draft-ietf-dhc-triggered-reconfigure-02 draft-ietf-dhc-triggered-reconfigure-03
Abstract Abstract
This document defines a new DHCPv6 message type: RECONFIGURE-REQUEST. This document defines new DHCPv6 messages: Reconfigure-Request and
This message is sent by a DHCPv6 relay agent to notify a DHCPv6 Reconfigure-Ack. Reconfigure-Request message is sent by a DHCPv6
server about a configuration information change, so that the DHCPv6 relay agent to notify a DHCPv6 server about a configuration
server can send a RECONFIGURE message accordingly. information change, so that the DHCPv6 server can send a Reconfigure
message accordingly.
This document updates RFC3315 and RFC6422. This document updates RFC 3315 and RFC 6422.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 20, 2013. This Internet-Draft will expire on July 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4
3. Link Address Option . . . . . . . . . . . . . . . . . . . . . . 5 3. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6
4. RECONFIGURE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 6 4. RECONFIGURE-REQUEST and RECONFIGURE-ACK . . . . . . . . . . . 6
4.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Messages Format . . . . . . . . . . . . . . . . . . . . . 6
4.2. Message Validation . . . . . . . . . . . . . . . . . . . . 6 4.2. Messages Validation . . . . . . . . . . . . . . . . . . . 7
4.3. Creation and Transmission of RECONFIGURE-REQUEST . . . . . 7 4.2.1. RECONFIGURE-REQUEST . . . . . . . . . . . . . . . . . 7
4.4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. RECONFIGURE-ACK . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Creation and Transmission of RECONFIGURE-REQUEST . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 4.4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Receipt of RECONFIGURE-ACK . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Rate Limiting Considerations . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
1.1. Problem 1.1. Problem
[RFC6422] updates the DHCPv6 specification [RFC3315] with a new [RFC6422] updates the DHCPv6 specification [RFC3315] with a new
feature to let a DHCPv6 relay agent communicate information towards a feature to let a DHCPv6 relay agent communicate information towards a
DHCPv6 Client, and which is not available at the DHCPv6 server. This DHCPv6 Client, and which is not available at the DHCPv6 server. This
is achieved owing to the use of RSOO (Relay-Supplied Options option) is achieved owing to the use of RSOO (Relay-Supplied Options option)
which carries configuration data to the DHCPv6 server. The data which carries configuration data to the DHCPv6 server. The data
skipping to change at page 4, line 40 skipping to change at page 4, line 40
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Proposed Solution 2. Proposed Solution
To solve the problem described in Section 1.1, this document proposes To solve the problem described in Section 1.1, this document proposes
a new DHCP message called Reconfigure-Request. In the example a new DHCP message called Reconfigure-Request. In the example
depicted in Figure 3 a Reconfigure-Request message is sent by the depicted in Figure 3 a Reconfigure-Request message is sent by the
DHCPv6 relay agent to a DHCPv6 server as soon as the configuration DHCPv6 relay agent to a DHCPv6 server as soon as the configuration
data conveyed in an RSOO option have changed. Upon receipt of this data 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 a Reconfigure message. This message is then sent server must build Reconfigure-Ack and Reconfigure messages.
to the DHCPv6 relay, which in turn will forward the message to the Reconfigure-Ack is used to acknowledge the receipt of Reconfigure-
appropriate DHCPv6 client. Request. Reconfigure message is then 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 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 has enough information to send the Reconfigure-Request message to the
server. Means to recover state in failure events must be supported, server. Means to recover state in failure events must be supported,
but are not discussed in this document. but are not discussed in this document.
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius | |DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server/| |Client | |(DHCPv6| |Server/|
| | | Relay)| | DAC | | | | Relay)| | DAC |
skipping to change at page 5, line 23 skipping to change at page 5, line 23
| | | |
|------CoA-Response--------->| |------CoA-Response--------->|
.... ....
| +-------+ | +-------+
| |DHCPv6 | | |DHCPv6 |
| |Server | | |Server |
| | | | | |
| +-------+ | +-------+
| | | |
|---Reconfigure-Request----->| |---Reconfigure-Request----->|
| | |<--Reconfigure-Ack----------|
| | | |
| |<--Relay-Reply -------------| | |<--Relay-Reply -------------|
|<--Reconfigure-------------| (Reconfigure) | |<--Reconfigure-------------| (Reconfigure) |
| | | | | |
.... ....
Figure 3: RECONFIGURE-REQUEST Flow Example Figure 3: RECONFIGURE-REQUEST Flow Example
The Reconfigure-Request message can also be used in other scenarios 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 than those that assume the use of RSOO. It is out of scope of this
document to describe all these scenarios. document to describe all these scenarios.
The support of Reconfigure-Ack simplifies the retransmission
procedure of the relay as it provides an explicit indication from the
server. 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-
Ack), 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.
3. Link Address Option 3. Link Address Option
Figure 4 shows the format of the Link Address Option. Figure 4 shows the format of the Link Address Option.
0 1 2 3 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 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 | | OPTION_LINK_ADDRESS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| link-address (IPv6 address) | | link-address (IPv6 address) |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Message Format of Link Address Option Figure 4: Message Format of Link Address Option
The description of the fields are as follows: The description of the fields are as follows:
option-code: OPTION_LINK_ADDRESS (To be assigned by IANA, see option-code: OPTION_LINK_ADDRESS (To be assigned by IANA, see
Section 5). Section 6).
option-len: 16 (octets). option-len: 16 (octets).
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. The relay agent SHOULD use the same value that was sent
to the DHCP server when relaying messages from the client to the to the DHCP 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].
The relay agent MUST NOT use the IPv6 unspecified address (0::0) in 4. RECONFIGURE-REQUEST and RECONFIGURE-ACK
this option. The server MUST discard any Reconfigure Request message
containing a Link Address Option that carries the unspecified
address.
4. RECONFIGURE-REQUEST 4.1. Messages Format
4.1. Message Format Two new message type codes are defined:
A new message type code is defined: RECONFIGURE-REQUEST (To be assigned by IANA, see Section 6).
RECONFIGURE-REQUEST (To be assigned by IANA, see Section 5). RECONFIGURE-ACK (To be assigned by IANA, see Section 6).
RECONFIGURE-REQUEST uses the same format as defined in Section 6 of RECONFIGURE-REQUEST and RECONFIGURE-ACK use the same format as
[RFC3315]. defined in Section 6 of [RFC3315].
4.2. Message Validation 4.2. Messages Validation
4.2.1. RECONFIGURE-REQUEST
Clients MUST silently discard any received RECONFIGURE-REQUEST Clients MUST silently discard any received RECONFIGURE-REQUEST
messages. messages.
Servers MUST silently discard any received RECONFIGURE-REQUEST Servers MUST silently discard any received RECONFIGURE-REQUEST
messages that meet any of the following conditions: 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 Client Identifier Option [RFC3315].
o the message does not include a Link Address Option (Section 3). o the message does not include a Link Address Option (Section 3).
skipping to change at page 7, line 31 skipping to change at page 7, line 46
relayed as specified in Section 20.1.1 of [RFC3315]. relayed as specified in Section 20.1.1 of [RFC3315].
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 DHCP Reconfigure message, and the DHCP 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 DHCP renewal), the DHCP server MUST have some mechanism for
determining that the relay agent is a trusted entity. RECONFIGURE- determining that the relay agent is a trusted entity. RECONFIGURE-
REQUEST messages originating from unknown relay agents MUST be REQUEST messages originating from unknown relay agents MUST be
silently dropped. silently dropped.
4.2.2. RECONFIGURE-ACK
Clients and Servers MUST silently discard any received RECONFIGURE-
ACK messages.
The relay MUST silently discard any received RECONFIGURE-ACK 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].
4.3. Creation and Transmission of RECONFIGURE-REQUEST 4.3. Creation and Transmission of RECONFIGURE-REQUEST
For any event (e.g., modification of the configuration information) For any event (e.g., modification of the configuration information)
that requires the server to issue a Reconfigure message, the relay that requires the server to issue a Reconfigure message, the relay
agent determines the client which is affected by the change and then agent determines the client which is affected by the change and then
builds a Reconfigure-Request message: the relay agent sets the "msg- builds a Reconfigure-Request message: the relay agent sets the "msg-
type" field to RECONFIGURE-REQUEST and sets the "transaction-id " type" field to RECONFIGURE-REQUEST, generates a transaction ID and
field to 0. The relay agent MUST include a Client Identifier Option inserts it in the "transaction-id" field. The relay agent MUST
[RFC3315] and a Link Address Option (Section 3) so that the DHCPv6 include a Client Identifier Option [RFC3315] and a Link Address
server can identify the corresponding client and the link on which Option (Section 3) so that the DHCPv6 server can identify the
the client is located. The relay agent MAY supply the updated corresponding client and the link on which the client is located.
configuration in the RSOO [RFC6422]. The relay agent MAY supply a The relay agent MAY supply the updated configuration in the RSOO
Reconfigure Message Option to indicate which form of Reconfigure to [RFC6422]. The relay agent MAY supply a Reconfigure Message Option
use. to indicate which form of Reconfigure to use. The relay agent MAY
include any option (e.g., Interface Identifier [RFC3315]) which it
might insert when relaying a message received from a client.
When several clients on the same link are concerned with a When several clients on the same link are affected by a configuration
configuration change, the relay MUST include several Client change, the relay MUST include several Client Identifier Options,
Identifier Options, each of them identifies a specific client. If each of them identifies a specific client. If including Client
including Client Identifier Options of all impacted clients exceeds Identifier Options of all impacted clients exceeds the maximum
the maximum message size, the relay MUST generate several message size (see Section 5), the relay MUST generate several
RECONFIGURE-REQUEST messages required to carry all Client Identifier RECONFIGURE-REQUEST messages required to carry all Client Identifier
Options. Options. Rate-limit considerations are discussed in Section 5.
The relay transmits RECONFIGURE-REQUEST messages according to Section
14 of [RFC3315], using the following parameters:
IRT 1 sec
MRT 10 secs
MRC 5
MRD 0
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 (Relay-Reply) Reconfigure before Reconfigure-
Ack. The relay SHOULD NOT interpret it as if the Reconfigure-Request
was successfully handled by the Server. The relay SHOULD use
Reconfigure-Ack, not the Reconfigure message, to determine if the
request was successful.
4.4. Server Behaviour 4.4. Server Behaviour
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 4.2), the server determines the client(s) relay agent (see Section 4.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 MAY use the content of the Reconfigure Message Option The server constructs a Reconfigure-Ack message by setting the "msg-
supplied by the relay agent to determine which form of Reconfigure to type" field to RECONFIGURE-ACK, and copying the transaction ID from
use. the RECONFIGURE-REQUEST message into the transaction-id field. The
server MUST include a Status Code Option [RFC3315] indicating whether
the request is successfully processed, failed or partially failed.
o If the request is successfully handled by the server, the server
MUST include a Status Code Option indicating "Success".
o If the request includes several Client Identifier options but the
server will issue reconfigure requests only for a subset of them,
the server MUST include a Status Code Option indicating "Success"
but in the meantime it MUST copy back the list of Client
Identifier Options pointing to clients for which the server won't
issue a Reconfigure message.
o If the server failed to process the request for all clients, the
server MUST set the Status Code Option to the appropriate status
code (e.g., UnspecFail, NotAllowed, etc.).
If RSOO is supplied, the server MAY use its content to double check 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 whether a Reconfigure is required to be sent to the client. This
assumes the server store the content of RSOO it used to generate assumes the server store 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
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 Then, the server MUST follow the procedure defined in Section 19.1 of
[RFC3315] to construct a Reconfigure message. This message may be [RFC3315] to construct a Reconfigure message. This Reconfigure
sent directly to the DHCPv6 client or to a relay agent [RFC3315]. message may be sent directly to the DHCPv6 client or to a relay agent
[RFC3315].
5. IANA Considerations Rate-limit considerations are discussed in Section 5.
4.5. Receipt of RECONFIGURE-ACK
Depending on the status code enclosed in a received RECONFIGURE-ACK
message, the relay may decide to terminate the request or try a
different corrected Reconfigure-Request.
5. 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 (i.e., the rate of Reconfigure 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).
6. 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 the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
RECONFIGURE-REQUEST RECONFIGURE-REQUEST
RECONFIGURE-ACK
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 the registry maintained in
http://www.iana.org/assignments/dhcpv6-parameters: http://www.iana.org/assignments/dhcpv6-parameters:
OPTION_LINK_ADDRESS OPTION_LINK_ADDRESS
6. Security Considerations 7. Security Considerations
Security considerations elaborated in [RFC3315] and [RFC6422] must be Security considerations elaborated in [RFC3315] (in particular
taken into account. In addition, DHCPv6 servers MAY be configured to Section 21.1) and [RFC6422] must be taken into account. In addition,
discard relayed RECONFIGURE-REQUEST messages or restrict relay DHCPv6 servers MAY be configured to discard relayed RECONFIGURE-
chaining (see [RFC5007] for more discussion about the rationale of REQUEST messages or restrict relay chaining (see [RFC5007] for more
this recommended behavior). Relay agents SHOULD implement discussion about the rationale of this recommended behavior). Relay
appropriate means to prevent using RECONFIGURE-REQUEST messages as a agents SHOULD implement appropriate means to prevent using
denial-of-service attack on the DHCPv6 servers. RECONFIGURE-REQUEST messages as a denial-of-service attack on the
DHCPv6 servers.
7. Acknowledgements 8. Acknowledgements
Many thanks to R. Maglione, A. Kostur, G. Halwasia, C. Jacquenet and Many thanks to R. Maglione, A. Kostur, G. Halwasia, C. Jacquenet and
B. Volz for the comments and review. B. Volz for the comments and review.
Special thanks to T. Lemon who provided a detailed review. Special thanks to T. Lemon who provided a detailed review.
8. References 9. References
8.1. Normative References 9.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", [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options",
RFC 6422, December 2011. RFC 6422, December 2011.
8.2. Informative References 9.2. Informative References
[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.
Authors' Addresses Authors' Addresses
 End of changes. 33 change blocks. 
75 lines changed or deleted 178 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/