RECONFIGURE Triggered by DHCPv6 Relay Agents
draft-boucadair-dhc-triggered-reconfigure-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Mohamed Boucadair | ||
| Last updated | 2012-08-24 | ||
| Replaced by | draft-ietf-dhc-triggered-reconfigure, draft-ietf-dhc-triggered-reconfigure, RFC 6977 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-boucadair-dhc-triggered-reconfigure-00
Network Working Group M. Boucadair
Internet-Draft France Telecom
Updates: 3315 (if approved) August 24, 2012
Intended status: Standards Track
Expires: February 25, 2013
RECONFIGURE Triggered by DHCPv6 Relay Agents
draft-boucadair-dhc-triggered-reconfigure-00
Abstract
This document specifies a companion solution to the RSOO (Relay-
Supplied Options option) procedure to trigger a DHCPv6 server to
issue a RECONFIGURE message. This document defines a new DHCPv6
messages type: RECONFIGURE-REQUEST. This message is issued by a
relay agent to notify a DHCPv6 server a change has occurred in the
configuration supplied in an RSOO.
This document updates RFC 3315.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 25, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Boucadair Expires February 25, 2013 [Page 1]
Internet-Draft Relay Triggered Reconfigure August 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 4
3. RECONFIGURE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Message Format . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Message Validation . . . . . . . . . . . . . . . . . . . . 5
3.3. Creation and Transmission of RECONFIGURE-REQUEST . . . . . 6
3.4. Server Behaviour . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Boucadair Expires February 25, 2013 [Page 2]
Internet-Draft Relay Triggered Reconfigure August 2012
1. Introduction
1.1. Problem
[RFC6422] updates DHCPv6 specification [RFC3315] with a new feature
to let a DHCPv6 relay agent communicate information not available at
the DHCPv6 server to a DHCPv6 client. 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 illustration example is shown in Figure 1; only a subset of
exchanged messages are represented.
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server |
| | | Relay)| | |
+-------+ +-------+ +-------+
| | |
|---Solicit---------------->| |
|---Access-Request---------->|
|<--Access-Accept------------|
| (e.g. AFTR_NAME)
....
| +-------+
| |DHCPv6 |
| |Server |
| | |
| +-------+
|---Relay-Forward----------->|
| (RSOO(AFTR_NAME))
|
|<--Relay-Reply--------------|
|<--Advertise---------------|
(e.g., AFTR_NAME) |
....
Figure 1: RSOO Flow Example
The change of the configuration may result in RADIUS exchanges
between the NAS/DHCPv6 relay agent and AAA server as shown in
Figure 2. Note the change of the configuration in the DHCPv6 relay
agent can be triggered by any other out-of-band mechanism.
Boucadair Expires February 25, 2013 [Page 3]
Internet-Draft Relay Triggered Reconfigure August 2012
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server |
| | | Relay)| | |
+-------+ +-------+ +-------+
| | |
|<-----CoA-Request-----------|
| (e.g. AFTR_NAME)
|------CoA-Response--------->|
....
Figure 2: Change of configuration
In the event of the change of the configuration data supplied to the
DHCPv6 server by the DHCPv6 relay agent, DHCPv6 server has no trigger
to issue a Reconfigure message with the updated configuration data.
A solution is sketched in Section 2.
1.2. Requirements Language
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 [RFC2119].
2. Proposed Solution
To solve the problem described in Section 1.1, this document proposes
a new DHCP message called Reconfigure-Request. This message is sent
by the DHCPv6 relay agent to a DHCPv6 server when a configuration
data already supplied in an RSOO is detected. In particular,
Reconfigure-Request must include RSOO with the new configuration.
Upon receipt of this message, and if it is configured to support such
mode, the DHCPv6 server must build a Reconfigure message which copies
the data conveyed in RSOO. This message is sent to the DHCPv6 relay
and then relayed to the appropriate DHCPv6 client.
This setup assumes the relay has a record of the client, so it has
enough information to send the request to the server. Means to
recover state in failure events must be supported.
An example is depicted in Figure 3.
Boucadair Expires February 25, 2013 [Page 4]
Internet-Draft Relay Triggered Reconfigure August 2012
+-------+ +-------+ +-------+
|DHCPv6 | | NAS | |Radius |
|Client | |(DHCPv6| |Server |
| | | Relay)| | |
+-------+ +-------+ +-------+
| | |
|<-----CoA-Request-----------|
| (e.g. AFTR_NAME)
|------CoA-Response--------->|
....
| +-------+
| |DHCPv6 |
| |Server |
| | |
| +-------+
|---Reconfigure-Request----->|
| (RSOO(AFTR_NAME))
|
|<--Relay-Reply -------------|
|<--Reconfigure-------------| (Reconfigure(AFTR_NAME))
(e.g., AFTR_NAME) |
....
Figure 3: RECONFIGURE-REQUEST Flow Example
3. RECONFIGURE-REQUEST
3.1. Message Format
The RECONFIGURE-REQUEST message uses the Client/Server message format
described in Section 6 of [RFC3315]. A new message type code is
defined
RECONFIGURE-REQUEST (To be assigned by IANA, see Section 4).
3.2. Message Validation
Clients MUST discard any received RECONFIGURE-REQUEST messages.
Servers MUST discard any received RECONFIGURE-REQUEST messages that
meet any of the following conditions:
o the message does not include an OPTION_CLIENTID option.
o the message includes an OPTION_SERVERID option but the contents of
the OPTION_SERVERID option does not match the server's identifier.
o the message does not include an RSOO.
Boucadair Expires February 25, 2013 [Page 5]
Internet-Draft Relay Triggered Reconfigure August 2012
Server MUST be configurable to accept or reject RECONFIGURE-REQUEST
messages. If the server is configured to reject RECONFIGURE-REQUEST,
any received RECONFIGURE-REQUEST is silently dropped.
3.3. Creation and Transmission of RECONFIGURE-REQUEST
In the event of change of an information which has been supplied to
the DHCPv6 server, the relay agent determines the client which is
concerned by the change and then builds a Reconfigure-Request
message: the relay agent sets the "msg-type" field to RECONFIFURE-
REQUEST and sets the "transaction-id" field to 0. The relay agent
MUST supply the updated configuration in RSOO as defined in [RFC6422]
and MUST include an OPTION_CLIENTID option [RFC3315] to identify the
client to the DHCPv6 server.
3.4. Server Behaviour
Upon receipt of a valid Reconfigure-Request message from a DHCPv6
relay agent, the server follows the procedure defined in Section 19.1
of [RFC3315] and Section 4 of [RFC6422] to construct a Reconfigure
message.
As defined in [RFC3315], this message may be sent directly to the
DHCPv6 client or to a relay agent.
4. IANA Considerations
This document requests IANA to assign a new DHCPv6 Message type:
RECONFIGURE-REQUEST
5. Security Considerations
Security considerations elaborated in [RFC3315] and [RFC6422] must be
taken into account.
Some security issues discussed in [RFC5007] may also be valid for
RECONFIGURE-REQUEST. This will be elaborated in further versions of
this document.
6. Acknowledgements
Many thanks to T. Lemon for the discussion prior to the publication
of this document.
Boucadair Expires February 25, 2013 [Page 6]
Internet-Draft Relay Triggered Reconfigure August 2012
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options",
RFC 6422, December 2011.
7.2. Informative References
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng,
"DHCPv6 Leasequery", RFC 5007, September 2007.
Author's Address
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange.com
Boucadair Expires February 25, 2013 [Page 7]