draft-ietf-dhc-triggered-reconfigure-05.txt   draft-ietf-dhc-triggered-reconfigure-06.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 Intended status: Standards Track France Telecom
Intended status: Standards Track March 21, 2013 Expires: November 07, 2013 May 06, 2013
Expires: September 22, 2013
Reconfigure Triggered by DHCPv6 Relay Agents Reconfigure Triggered by DHCPv6 Relay Agents
draft-ietf-dhc-triggered-reconfigure-05 draft-ietf-dhc-triggered-reconfigure-06
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.
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 September 22, 2013. This Internet-Draft will expire on November 07, 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
skipping to change at page 2, line 16 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4 4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 4
5. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6 5. Link Address Option . . . . . . . . . . . . . . . . . . . . . 6
6. Detailed Specification . . . . . . . . . . . . . . . . . . . 6 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 . . . . 7
6.4. Intermediate Relay Agents Behaviour . . . . . . . . . . . 9 6.4. Intermediate Relay Agents Behavior . . . . . . . . . . . 9
6.5. Server Behaviour . . . . . . . . . . . . . . . . . . . . 9 6.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 9
6.6. Receipt of RECONFIGURE-REPLY . . . . . . . . . . . . . . 10 6.6. Receipt of RECONFIGURE-REPLY . . . . . . . . . . . . . . 10
7. Rate Limiting Considerations . . . . . . . . . . . . . . . . 10 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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document specifies two new DHCPv6 messages [RFC3315]: This document specifies two new DHCPv6 messages [RFC3315]:
Reconfigure-Request and Reconfigure-Reply. Reconfigure-Request and Reconfigure-Reply.
Section 3 describes a typical problem encountered to trigger the Section 3 describes a typical problem encountered to trigger the
DHCPv6 server to issue a Reconfigure message when the configuration DHCPv6 server to issue a Reconfigure message when the configuration
data is supplied by the relay agent. This problem may be encountered 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 in other contexts. It is out of scope of this document to list all
skipping to change at page 5, line 7 skipping to change at page 5, line 9
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
the DHCPv6 relay, which in turn will forward the message to the the DHCPv6 relay, which in turn will forward the message to the
appropriate DHCPv6 client. 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. How the state is recorded in the relay is out of scope. server. How the state is recorded in the relay is out of scope. For
Furthermore, means to recover state in failure events must be better resilience of the proposed solution, means to recover state in
supported, but are not discussed in this document. failure events (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 | |DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server/| |Client | |(DHCPv6| |Server/|
| | | Relay)| | DAC | | | | Relay)| | DAC |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
| | | | | |
|<-----CoA-Request-----------| |<-----CoA-Request-----------|
| (e.g. DS-Lite-Tunnel-Name) | | (e.g. DS-Lite-Tunnel-Name) |
| | | |
skipping to change at page 5, line 52 skipping to change at page 6, line 8
to conclude whether Reconfigure-Request was successfully handled or to conclude whether Reconfigure-Request was successfully handled or
not. Nevertheless, this implicit approach may fail to achieve its not. Nevertheless, this implicit approach may fail to achieve its
goals in some cases: e.g., the server accepts the request but it goals in some cases: e.g., the server accepts the request but it
delays to generate the corresponding Reconfigure messages due to its delays to generate the corresponding Reconfigure messages due to its
rate-limiting policies, the request was partially failed for some rate-limiting policies, the request was partially failed for some
clients, etc. To avoid useless reconfigure cycles (e.g., due to the clients, etc. To avoid useless reconfigure cycles (e.g., due to the
loss of Reconfigure-Reply), the approach adopted in this document loss of Reconfigure-Reply), the approach adopted in this document
allows the relay to correct the content of a re-transmitted allows the relay to correct the content of a re-transmitted
Reconfigure-Request based on some observed events (e.g., the client Reconfigure-Request based on some observed events (e.g., the client
has retrieved the updated configuration). If the relay has no client has retrieved the updated configuration). If the relay has no client
to reconfigured, it stops sending Reconfigure-Request messages. to be reconfigured, it stops sending Reconfigure-Request messages.
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.
5. Link Address Option 5. 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
skipping to change at page 9, line 4 skipping to change at page 9, line 9
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:
IRT 1 sec IRT 1 sec
MRT 10 secs MRT 10 secs
MRC 5 MRC 5
MRD 0 MRD 0
When retransmission is required, the relay may decide to correct the
content of RECONFIGURE-REQUEST message it issues (e.g., update the The relay MAY remove clients from the client identifier list in
Client Identifier list). This decision is local to the relay (e.g., subsequent retransmissions, but MUST NOT add clients to the client
it may be based on observed events such as one or more clients were 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). 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.
6.4. Intermediate Relay Agents Behaviour 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 to reject RECONFIGURE-REQUEST, the relay
MUST silently discard any RECONFIGURE-REQUEST it receives. If the MUST silently discard any RECONFIGURE-REQUEST it receives. If the
relay is configured to accept RECONFIGURE-REQUEST messages, these relay is configured to accept RECONFIGURE-REQUEST messages, these
messages are relayed as specified in Section 20.1.1 of [RFC3315]. messages are relayed as specified in Section 20.1.1 of [RFC3315].
6.5. Server Behaviour 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.
skipping to change at page 12, line 16 skipping to change at page 12, line 20
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. A control determining that the relay agent is a trusted entity. A control
policy based on the content of received Relay Identifier Option MAY policy based on the content of received Relay Identifier Option MAY
be enforced by the DHCPv6 server. Reconfigure-Request messages be enforced by the DHCPv6 server. Reconfigure-Request messages
originating from unknown relay agents MUST be silently dropped. originating from unknown relay agents MUST be silently dropped.
10. Acknowledgements 10. Acknowledgements
Many thanks to R. Maglione, A. Kostur, G. Halwasia and C. Many thanks to R. Maglione, A. Kostur, G. Halwasia, C. Jacquenet,
Jacquenet for the comments and review. and R. Sparks 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.
 End of changes. 14 change blocks. 
24 lines changed or deleted 24 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/