Internet DRAFT - draft-jiang-dhc-stateless-reconfiguration
draft-jiang-dhc-stateless-reconfiguration
DHC WG S. Jiang
Internet-Draft B. Liu
Intended status: Standards Track Huawei Technologies Co., Ltd
Expires: August 18, 2014 February 14, 2014
Stateless Reconfiguration in Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)
draft-jiang-dhc-stateless-reconfiguration-01
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 August 18, 2014.
Copyright Notice
Copyright (c) 2014 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 August 18, 2014 [Page 1]
Internet-Draft DHCPv6 Stateless Reconfiguration February 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Stateless Reconfiguration Use Cases . . . . . . . . . . . . . 4
4. New DHCPv6 Specifications . . . . . . . . . . . . . . . . . . 5
4.1. Multicast Address . . . . . . . . . . . . . . . . . . . . 5
4.2. Stateless Reconfigure Message . . . . . . . . . . . . . . 5
5. Stateless Reconfiguration Procedure . . . . . . . . . . . . . 5
5.1. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6
5.2. Relay Agent Behavior . . . . . . . . . . . . . . . . . . 7
5.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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.
The lifetime option for DHCPv6 [RFC4242] assigns a lifetime to
configuration information obtained through DHCPv6. At the expiration
of the lifetime, the host contacts the DHCPv6 server to obtain
updated configuration information. This lifetime gives the network
administrator another mechanism to configure hosts with new
configuration by controlling the time at which the host refreshes the
list. However, such mechanism is not flexible enough: one aspect is
the minimum of refresh time is 10 minutes, which is so long that it
Jiang & Liu Expires August 18, 2014 [Page 2]
Internet-Draft DHCPv6 Stateless Reconfiguration February 2014
might not be suitable for unplanned configuration changes; the other
aspect is, in order to update the configuration quickly, the short
time setting would cause un-necessary refresh all the time.
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) Static configuration
Network administrators manually configure static unicast addresses of
all relay agents on the DHCPv6 server.
Pros: no need to update any protocol/function implementation in
relays; allows fast deployment in current network.
Cons: cost significant human management burden; error-prone,
mistakenly configuring the relay addresses or leaving out some relays
are expected.
b) Define a new ALL_RELAY_AGENT multicast address
The DHCPv6 server could send the stateless reconfiguration messages
directly to the new multicast address.
Pros: a solid coverage of all relays.
Cons: network administrators need to maintain an all-relay-agent
multicast group; all relays and DHCPv6 servers need to be updated to
know the new multicast address.
c) DHCPv6 server dynamic learning
the DHCPv6 server dynamically records unicast addresses of all relay
agents from client Information-request messages and maintains the
relay addresses list. A keepalive mechanism is needed between relay
agents and servers to track the availability of the list entries.
Pros: automatic processing without human intervene.
Cons: requires more function update to the DHCPv6 server; the
keepalive mechanism requires more function/protocol burden to the
whole DHCP system.
Jiang & Liu Expires August 18, 2014 [Page 3]
Internet-Draft DHCPv6 Stateless Reconfiguration February 2014
[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. Stateless Reconfiguration Use Cases
This section described scenarisos where stateless reconfiguration are
expected.
- Configuration error
Configuration errors, eithor caused by human or program, are hard to
be immune in networks. Especially, human errors is identified as one
of the top reasons of network failure. In stateless DHCPv6, if the
administrators/program accidentally mis-configure the parameters
(e.g. DNS), then significant network failure would be expected.
Current protocols just lack the ability to eliminate the
configuration errors when such accident happens. The hosts
configured with wrong parameters can only wait until the wrong
parameters lifetime expired then to refresh them. This would not be
acceptable especially when the lifetime was long. The stateless
reconfiguration mechanism could be highly expected in this scenario.
- Emergent event
The network needs to initially update the already configured
parameters within a short period due to some emergent events; and
waiting the clients to refresh the parameters according to the
lifetime is just un-acceptable. These scenarios would also require
statless reconfiguration.
Jiang & Liu Expires August 18, 2014 [Page 4]
Internet-Draft DHCPv6 Stateless Reconfiguration February 2014
4. New DHCPv6 Specifications
This section define new DHCPv6 elements requested by the stateless
configuration mechanism, including multicast address constant, and
message type.
4.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
4.2. Stateless Reconfigure Message
A new Stateless-Reconfigure message, which is mainly based on server
to clients advertise model, is defined in order to distinguish from
the existing Reconfigure message, which is mainly based on server/
client one-to-one model.
[Editor Notes] According to the results of Qeston 2 and Question 4
(in Section 5 & 7 below), there might be two new messages needed.
Current document uses the alternative of one new message.
STATELESS-RECONFIGURE-TRIGGER 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.
5. Stateless Reconfiguration Procedure
{Question to WG No.2} There could be two kind of stateless DHCPv6
reconfiguration modes as the following, which one is proper? Or we
should support both?
- Trigger mode
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.
Jiang & Liu Expires August 18, 2014 [Page 5]
Internet-Draft DHCPv6 Stateless Reconfiguration February 2014
This mode 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.
- Push mode
The server sends out a multicast Stateless-Reconfiguration message to
ALL_CLIENT_MULTICAST_ADDRESS to directly advertise new configuration
to the clients. The clients then update the parameters accordingly.
Trigger mode requires every client to initial individual request to
servers. This is reasonable for the stateful information that need
to be maintaind and tracked in the servers, e.g. clients' IP
addresses. But for the stateless information shared among clients
(such as DNS), it might not necessary. Some resource constrained
networks (e.g. a 802.15.4e/g based mesh network) might have efficency
problem with the trigger mode. These scenarios might significantly
benifit from the push mode stateless reconfiguration mechanism.
However, push mode seems breaking the triditional behavior model of
DHCP. Whether it is a good break needs further discussion.
[Editor Notes] the current form of this document is based on
triggering client information-request model, which complies the
traditional behavior model of DHCPv6. If the WG chooses to directly
advertise new configuration, the document would be updated
accordingly.
5.1. Server Behavior
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
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.
Jiang & Liu Expires August 18, 2014 [Page 6]
Internet-Draft DHCPv6 Stateless Reconfiguration February 2014
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.
5.2. Relay Agent Behavior
The relay agent extracts the Stateless-Reconfigure message from the
Relay Message option and relays it to all clients. If the relay
agent is 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.
Jiang & Liu Expires August 18, 2014 [Page 7]
Internet-Draft DHCPv6 Stateless Reconfiguration February 2014
5.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.3} Should we define a maximum time of random delay
time? If yes, should it come from server by a new option?
6. 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.}
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.
7. 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:
Jiang & Liu Expires August 18, 2014 [Page 8]
Internet-Draft DHCPv6 Stateless Reconfiguration February 2014
STATELESS-RECONFIGURE Message Type, TBD2.
{Question to WG No.4} As raised in Question 2, if we support both
Trigger mode and Push mode, then there should be two kind of
corresponding messages. We could use two message types to
distinguish them; or use a flag in one message type. Which is
better?
8. Acknowledgements
The authors would like to thanks the valuable comments made by Suresh
Krishnan, Ted Lemon, Bernie Voltz and other members of DHC WG.
This document was produced using the xml2rfc tool [RFC2629].
9. References
9.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-17 (work in progress),
January 2014.
[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.
9.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005.
Jiang & Liu Expires August 18, 2014 [Page 9]
Internet-Draft DHCPv6 Stateless Reconfiguration February 2014
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 August 18, 2014 [Page 10]
