Stateless Reconfiguration in Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
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]