Stateless Reconfiguration in Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-jiang-dhc-stateless-reconfiguration-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Sheng Jiang , Bing Liu | ||
| Last updated | 2013-10-07 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| 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-jiang-dhc-stateless-reconfiguration-00
DHC WG S. Jiang
Internet-Draft B. Liu
Intended status: Standards Track Huawei Technologies Co., Ltd
Expires: April 11, 2014 October 08, 2013
Stateless Reconfiguration in Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)
draft-jiang-dhc-stateless-reconfiguration-00
Abstract
This document defines a mechanism to propagate reconfigure messages
towards stateless configured DHCPv6 clients.
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 April 11, 2014.
Copyright Notice
Copyright (c) 2013 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
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.
Jiang & Liu Expires April 11, 2014 [Page 1]
Internet-Draft DHCPv6 Stateless Reconfiguration October 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. New DHCPv6 Specifications . . . . . . . . . . . . . . . . . . 3
3.1. Multicast Address . . . . . . . . . . . . . . . . . . . . 3
3.2. Stateless Reconfigure Message . . . . . . . . . . . . . . 3
4. Stateless Reconfiguration Procedure . . . . . . . . . . . . . 4
4.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 4
4.2. Relay Agent Behavior . . . . . . . . . . . . . . . . . . 6
4.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
[RFC3736] defines a stateless configuration procedure using DHCPv6.
With it, the network configure information, such as the addresses of
DNS recursive name servers, can be propagated to nodes, which have
obtained their IPv6 addresses through some other mechanism. The
basic scenario is that a newly online client initiates an information
request to DHCPv6 server, then the server responses with requested
configuration information. This mechanism is called the Stateless
DHCPv6 services, because DHCPv6 servers do not maintain any dynamic
state for individual clients, including the unicast addresses of
clients.
However, the specification of stateless DHCPv6 service lacks a
mechanism to inform these configured clients if some configuration
information is changed. Transplanting Reconfigure message of
[RFC3315] into stateless DHCPv6 services does not solve the issue,
because in stateful DHCPv6, servers send Reconfigure messages to
clients using their unicast addresses.
This document defines a mechanism to propagate a newly defined
Stateless-Reconfigure message towards stateless configured DHCPv6
clients. It requests a mechanism for the DHCPv6 server to be aware
of all relay agent destinations.
{Question to WG No.1} There are three potential mechanisms to create
relay agent destinations on the DHCPv6 server: a) network
administrators manually configure static unicast addresses of all
relay agents on the DHCPv6 server. b) define an ALL_RELAY_AGENT
Jiang & Liu Expires April 11, 2014 [Page 2]
Internet-Draft DHCPv6 Stateless Reconfiguration October 2013
multicast address, for which network administrators need to maintain
an all-relay-agent multicast group. c) the DHCPv6 server dynamically
records unicast addresses of all relay agents from client
Information-request messages. The dynamic records need a keepalive
mechanism between relay agents and servers.
[Editor Notes] the current form of this document is based on only the
first mechanism of above three. If the WG decided to change or
include other mechanism, the document would be updated accordingly.
The document newly defines a new link-scope well-known all-client
multicast address and a new DHCPv6 message type for stateless
reconfiguration. Correspondent server behavior, agent behavior and
client behavior are specificed in details.
The design of new DHCPv6 elements and precedures obey the
recommendations and guidance of [I-D.ietf-dhc-option-guidelines].
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119] when they appear in ALL CAPS. When these words are not in
ALL CAPS (such as "should" or "Should"), they have their usual
English meanings, and are not to be interpreted as [RFC2119] key
words.
3. New DHCPv6 Specifications
This section define new DHCPv6 elements requested by the stateless
configuration mechanism, including multicast address constant, and
message type.
3.1. Multicast Address
ALL_CLIENT_MULTICAST_ADDRESS (FF02::xxxx, TBD1) A link-scoped
multicast address used by a DHCPv6 server or relay agent to
communicate with neighboring (i.e., on-link) clients. All clients
are members of this multicast group
3.2. Stateless Reconfigure Message
A new Stateless-Reconfigure message, which is mainly based on server
to client advertise model, is defined in order to distinguish from
the existing Reconfigure message, which is mainly based on server/
client one-to-one model.
Jiang & Liu Expires April 11, 2014 [Page 3]
Internet-Draft DHCPv6 Stateless Reconfiguration October 2013
STATELESS-RECONFIGURE Message Type Value is TBD2. It follows the
message format specification, defined in Section 6 of [RFC3315].
A server sends a Stateless-Reconfigure message to a client to
inform the client that the server has new or updated configuration
parameters, and that the client is to initiate an Information-
request transaction with the server in order to receive the
updated information.
4. Stateless Reconfiguration Procedure
In stateless DHCPv6 reconfiguration scenario, the server sends out a
multicast Stateless-Reconfiguration message to
ALL_CLIENT_MULTICAST_ADDRESS. As response, every client is requested
to initiate an Information-Request message back to the server. The
server can then inform the changed configuration information to
clients.
{Question to WG No.2} directly advertise new configuration or trigger
client information-request?
[Editor Notes] the current form of this document is based on
triggering client information-request model, which is similar with
stateful DHCPv6 reconfiguration and also provide the potential
possibility that the server response to information-request
differently according to various user policies. If the WG chooses to
directly advertise new configuration, the document would be updated
accordingly.
A server sends a Stateless-Reconfigure message to cause all clients
to initiate an Information-request message exchange with the server.
4.1. Server Behavior
{Question to WG No.3} direct Stateless-Reconfigure message or
encapsulated Relay-Reply message?
[Editor Notes] the current form of this document is based on
encapsulated relay-reply message model, which is similar with
stateful DHCPv6 reconfiguration and have minimum impact to relay
behavior. If the WG decided to choose direct ly advertise new
configuration, the document would be updated accordingly.
When the network configuration information on a stateless DHCPv6
server changes, the server creates and transmit a new Stateless-
Reconfigure message towards all clients following the below steps:
o The server sets the "msg-type" field to STATELESS-RECONFIGURE.
The server sets the transaction-id field to 0. The server MUST
Jiang & Liu Expires April 11, 2014 [Page 4]
Internet-Draft DHCPv6 Stateless Reconfiguration October 2013
include a Server Identifier option containing its DUID in the
Reconfigure message.
o The server MAY include an Option Request option to inform the
client of what information has been changed or new information
that has been added.
o The server MUST NOT include a Reconfigure Message option (defined
in section 22.19 of [RFC3315]), which is mandated in Reconfigure
message to indicate the client to respond a Renew or an
Information-Request message. It is because there is only one
possible response on the client follow a Stateless-Reconfigure
message - an Information-request message.
o The server MUST NOT include any other options in the Reconfigure
except as specifically allowed in the definition of individual
options.
o The server sends Stateless-Reconfigure message to its direct local
link using ALL_CLIENT_MULTICAST_ADDRESS.
o Simultaneously, the server uses a Relay-Reply message (as
described in Section 20.3 of [RFC3315]) to send the Stateless-
Reconfigure message to all relay agents in its static relay-agent-
destination record using the unicast address of these relay
agents. The peer-address of the Relay-Reply message MUST be
filled by Relay-Reply message ALL_CLIENT_MULTICAST_ADDRESS.
Notes: since there is no previous Relay-Forward message that went
through multiple relay agents and the server has to send the Relay-
Reply message through the return same path, the server should be able
to send the Relay-Reply message to the relay agent that direct
connects with clients. Consequently, the Relay-Reply message SHOULD
NOT contain another Relay-Reply message.
The below is an example of a typical Relay-Reply message that
contains a Stateless-Reconfigure message:
msg-type: RELAY-REPLY
hop-count: 0
link-address: 0
peer-address: ALL_CLIENT_MULTICAST_ADDRESS
Relay Message option: <Stateless-Reconfigure message>
Servers MUST discard any received Stateless-Reconfigure messages.
Jiang & Liu Expires April 11, 2014 [Page 5]
Internet-Draft DHCPv6 Stateless Reconfiguration October 2013
4.2. Relay Agent Behavior
The relay agent extracts the Stateless-Reconfigure message from the
Relay Message option and relays it to all client. If the relay agent
attached to multiple links, it MUST broadcast the Stateless-
Reconfigure message on every links. This behavior is compliance with
normal behavior of relaying a Relay-reply Message, defined in
Section 20.2 of [RFC3315].
Relay agents MUST discard any received Stateless-Reconfigure
messages. By design, relay agents do not process any directly
received Stateless-Reconfigure messages.
The result is that the relay agent sends out a Stateless-Reconfigure
message towards all client on the local link using
ALL_CLIENT_MULTICAST_ADDRESS.
4.3. Client Behavior
Clients MUST discard any Stateless-Reconfigure messages that meets
any of the following conditions:
o the message was not multicast to the client using
ALL_CLIENT_MULTICAST_ADDRESS.
o the message does not include a Server Identifier option.
o the message contains a Reconfigure Message Option, defined in
Section 22.19 of [RFC3315].
Upon receipt of a valid Stateless-Reconfigure message, after a random
delay time, the client responds with an Information-request message.
The random delay time is designed to avoid congested Information-
request on the server. While the transaction is in progress, the
client silently discards any Stateless-Reconfigure messages it
receives.
{Question to WG No.4} Should we define a maximum time of random delay
time? If yes, should it come from server by a new option?
5. Security Considerations
Malicious server sends Stateless Reconfigure message to cause all
clients response. There is the risk of denial of service attacks
against DHCP clients and server. {Current auth mechanism cannot work
in this broadcast model, server public key model maybe work.}
Jiang & Liu Expires April 11, 2014 [Page 6]
Internet-Draft DHCPv6 Stateless Reconfiguration October 2013
Since the clients response to Information-Request using the standard
mechanism, defined in [RFC3315], the chance that receive wrong
configuration information from malicious attackers does not raise.
6. IANA Considerations
Per this document, IANA has assigned one new well-known Multicast
Address in the "IPv6 Multicast Address Space Registry" registry
(currently located at http://www.iana.org/assignments/ipv6-multicast-
addresses) for the following attribute:
ALL_CLIENT_MULTICAST_ADDRESS: (FF02::xxxx, TBD1).
Per this document, IANA has assigned one new DHCPv6 Message Type in
the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry
(currently located at http://www.iana.org/assignments/
dhcpv6-parameters) for the following attribute:
STATELESS-RECONFIGURE Message Type, TBD2.
7. Acknowledgements
The authors would like to thanks the valuable comments made by Suresh
Krishnan, Ted Lemon and other members of DHC WG.
This document was produced using the xml2rfc tool [RFC2629].
8. References
8.1. Normative References
[I-D.ietf-dhc-option-guidelines]
Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
draft-ietf-dhc-option-guidelines-14 (work in progress),
September 2013.
[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.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.
Jiang & Liu Expires April 11, 2014 [Page 7]
Internet-Draft DHCPv6 Stateless Reconfiguration October 2013
8.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Authors' Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: jiangsheng@huawei.com
Bing Liu
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: leo.liubing@huawei.com
Jiang & Liu Expires April 11, 2014 [Page 8]