draft-ietf-dhc-triggered-reconfigure-00.txt   draft-ietf-dhc-triggered-reconfigure-01.txt 
DHC Working Group M. Boucadair DHC Working Group M. Boucadair
Internet-Draft France Telecom Internet-Draft X. Pougnard
Updates: 3315, 6422 (if approved) X. Pougnard Updates: 3315, 6422 (if approved) France Telecom
Intended status: Standards Track Orange Labs Intended status: Standards Track September 28, 2012
Expires: March 15, 2013 September 11, 2012 Expires: April 1, 2013
RECONFIGURE Triggered by DHCPv6 Relay Agents RECONFIGURE Triggered by DHCPv6 Relay Agents
draft-ietf-dhc-triggered-reconfigure-00 draft-ietf-dhc-triggered-reconfigure-01
Abstract Abstract
This document defines a new DHCPv6 message type: RECONFIGURE-REQUEST. This document defines a new DHCPv6 message type: RECONFIGURE-REQUEST.
This message is sent by a DHCPv6 relay agent to notify a DHCPv6 This message is sent by a DHCPv6 relay agent to notify a DHCPv6
server about a configuration information change, so that the DHCPv6 server about a configuration information change, so that the DHCPv6
server can send a RECONFIGURE message accordingly. server can send a RECONFIGURE message accordingly.
This document updates RFC3315 and RFC6422. This document updates RFC3315 and RFC6422.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 March 15, 2013. This Internet-Draft will expire on April 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 6, line 17 skipping to change at page 6, line 17
o the message does not include an OPTION_CLIENTID option. o the message does not include an OPTION_CLIENTID option.
o the message includes an OPTION_SERVERID option but the contents of o the message includes an OPTION_SERVERID option but the contents of
the OPTION_SERVERID option does not match the server's identifier. the OPTION_SERVERID option does not match the server's identifier.
The server MUST be configurable to accept or reject RECONFIGURE- The server MUST be configurable to accept or reject RECONFIGURE-
REQUEST messages. If the server is configured to reject RECONFIGURE- REQUEST messages. If the server is configured to reject RECONFIGURE-
REQUEST, the server MUST silently discard any RECONFIGURE-REQUEST it REQUEST, the server MUST silently discard any RECONFIGURE-REQUEST it
receives. receives.
Discussion Note: Should the document specify the behavior of The relay agent MUST be configurable to accept or reject RECONFIGURE-
intermediate relay agents if any? REQUEST messages received from other relay agents. 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 [RFC3315].
Because this message provides a mechanism for triggering the DHCP Because RECONFIGURE-REQUEST message provides a mechanism for
Reconfigure message, and the DHCP Reconfigure message can raise triggering the DHCP Reconfigure message, and the DHCP Reconfigure
security threats (e.g., to control the timing of a DHCP renewal), the message can raise security threats (e.g., to control the timing of a
DHCP server MUST have some mechanism for determining that the relay DHCP renewal), the DHCP server MUST have some mechanism for
agent is a trusted entity. RECONFIGURE-REQUEST messages originating determining that the relay agent is a trusted entity. RECONFIGURE-
from unknown relay agents MUST be silently dropped. REQUEST messages originating from unknown relay agents MUST be
silently dropped.
3.3. Creation and Transmission of RECONFIGURE-REQUEST 3.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 and sets the "transaction-id "
field to 0. The relay agent MUST include an OPTION_CLIENTID option field to 0. The relay agent MUST include an OPTION_CLIENTID option
[RFC3315] so that the DHCPv6 server can identify the corresponding [RFC3315] so that the DHCPv6 server can identify the corresponding
skipping to change at page 6, line 47 skipping to change at page 7, line 5
RSOO [RFC6422]. The relay agent MAY supply an OPTION_RECONF_MSG RSOO [RFC6422]. The relay agent MAY supply an OPTION_RECONF_MSG
option to indicate which form of Reconfigure to use. option to indicate which form of Reconfigure to use.
When several clients are concerned with a configuration change, the When several clients are concerned with a configuration change, the
relay MUST include several OPTION_CLIENTID options, each of them relay MUST include several OPTION_CLIENTID options, each of them
identifies a specific client. If including OPTION_CLIENTID options identifies a specific client. If including OPTION_CLIENTID options
of all impacted clients exceeds the maximum message size, the relay of all impacted clients exceeds the maximum message size, the relay
MUST generate several RECONFIGURE-REQUEST messages required to carry MUST generate several RECONFIGURE-REQUEST messages required to carry
all OPTION_CLIENTID options. all OPTION_CLIENTID options.
Discussion Note: What to do when all clients bound to the same
relay agent are impacted by a configuration change? Should the
document indicate the relay MUST include Relay-ID Option
(RFC5460)?
3.4. Server Behaviour 3.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 3.2), the server determines the client(s) relay agent (see Section 3.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 OPTION_RECONF_MSG option The server MAY use the content of the OPTION_RECONF_MSG 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.
skipping to change at page 8, line 36 skipping to change at page 8, line 36
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Rennes, 35000 Rennes, 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Xavier Pougnard Xavier Pougnard
Orange Labs France Telecom
Lannion, Lannion,
France France
Phone: Phone:
Email: xavier.pougnard@orange.com Email: xavier.pougnard@orange.com
 End of changes. 7 change blocks. 
20 lines changed or deleted 20 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/