[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-dhc-triggered-reconfigure

DHC Working Group                                           M. Boucadair
Internet-Draft                                            France Telecom
Updates: 3315 (if approved)                                  X. Pougnard
Intended status: Standards Track                             Orange Labs
Expires: February 28, 2013                               August 27, 2012


              RECONFIGURE Triggered by DHCPv6 Relay Agents
              draft-boucadair-dhc-triggered-reconfigure-01

Abstract

   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, which requires issuing a Reconfigure message, has
   occurred.

   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 28, 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
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Boucadair & Pougnard    Expires February 28, 2013               [Page 1]

Internet-Draft         Relay Triggered Reconfigure           August 2012


   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 . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8





























Boucadair & Pougnard    Expires February 28, 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)|                    |  DAC  |
      +-------+                   +-------+                    +-------+
          |                           |                            |
          |---Solicit---------------->|                            |
                                      |---Access-Request---------->|
                                      |<--Access-Accept------------|
                                      |  (e.g. DS-Lite-Tunnel-Name)
                                    ....

                                      |                        +-------+
                                      |                        |DHCPv6 |
                                      |                        |Server |
                                      |                        |       |
                                      |                        +-------+
                                      |---Relay-Forward----------->|
                                      | (RSOO(DS-Lite-Tunnel-Name))
                                      |
                                      |<--Relay-Reply--------------|
          |<--Advertise---------------|
             (e.g., OPTION_AFTR_NAME) |
                                     ....


                        Figure 1: RSOO Flow Example

   The change of the configuration may result in RADIUS exchanges
   ([RFC5176]) between the NAS/DHCPv6 relay agent and Dynamic
   Authorization Client (DAC) 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 & Pougnard    Expires February 28, 2013               [Page 3]

Internet-Draft         Relay Triggered Reconfigure           August 2012


      +-------+                   +-------+                    +-------+
      |DHCPv6 |                   |  NAS  |                    |Radius |
      |Client |                   |(DHCPv6|                    |Server/|
      |       |                   | Relay)|                    |  DAC  |
      +-------+                   +-------+                    +-------+
          |                           |                            |
                                      |<-----CoA-Request-----------|
                                      | (e.g. DS-Lite-Tunnel-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.  In the example,
   depicted in Figure 3, Reconfigure-Request message is sent by the
   DHCPv6 relay agent to a DHCPv6 server when a configuration data
   already supplied in an RSOO is detected.  Upon receipt of this
   message, and if it is configured to support such mode, the DHCPv6
   server must build a Reconfigure message.  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.











Boucadair & Pougnard    Expires February 28, 2013               [Page 4]

Internet-Draft         Relay Triggered Reconfigure           August 2012


      +-------+                   +-------+                    +-------+
      |DHCPv6 |                   |  NAS  |                    |Radius |
      |Client |                   |(DHCPv6|                    |Server/|
      |       |                   | Relay)|                    | DAC   |
      +-------+                   +-------+                    +-------+
          |                           |                            |
                                      |<-----CoA-Request-----------|
                                      |   (e.g. DS-Lite-Tunnel-Name)
                                      |------CoA-Response--------->|
                                    ....
                                      |                        +-------+
                                      |                        |DHCPv6 |
                                      |                        |Server |
                                      |                        |       |
                                      |                        +-------+
                                      |---Reconfigure-Request----->|
                                      |
                                      |
                                      |<--Relay-Reply -------------|
          |<--Reconfigure-------------|   (Reconfigure)
                                      |
                                    ....

                Figure 3: RECONFIGURE-REQUEST Flow Example

   The proposed solution (Reconfigure-Request message) can be used in
   other non-RSOO scenarios.  It is out of scope of this document to
   describe all these scenarios.


3.  RECONFIGURE-REQUEST

3.1.  Message Format

   A new message type code is defined:

      RECONFIGURE-REQUEST (To be assigned by IANA, see Section 4).

   RECONFIGURE-REQUEST uses the same format as defined in Section 6 of
   [RFC3315].

3.2.  Message Validation

   Clients MUST silently discard any received RECONFIGURE-REQUEST
   messages.

   Servers MUST silently discard any received RECONFIGURE-REQUEST
   messages that meet any of the following conditions:



Boucadair & Pougnard    Expires February 28, 2013               [Page 5]

Internet-Draft         Relay Triggered Reconfigure           August 2012


   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.


   Server MUST be configurable to accept or reject RECONFIGURE-REQUEST
   messages.  If the server is configured to reject RECONFIGURE-REQUEST,
   the server MUST silently discard any RECONFIGURE-REQUEST it receives.

   Server MUST be configurable to accept or ignore any received
   OPTION_RECONF_MSG option in RECONFIGURE-REQUEST messages.  If an
   OPTION_RECONF_MSG option is received, the server uses the content of
   that option as a hint to determine which form of Reconfigure to use.
   If the server is configured to ignore any received OPTION_RECONF_MSG
   option or if this option is not supplied, the server is supposed to
   determine which form of Reconfigure to use.

   Because this message provides a mechanism for triggering the DHCP
   Reconfigure message, and the DHCP Reconfigure message can be used by
   an attacker to control the timing of a DHCP renewal, the DHCP server
   MUST have some mechanism for determining that the relay agent is a
   trusted entity.  RECONFIGURE-REQUEST messages originating from
   unknown relay agents MUST be 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 or for other events requiring the server to issue
   Reconfigure message, 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
   MAY 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.  The relay agent MAY supply an
   OPTION_RECONF_MSG option to indicate which form of Reconfigure to
   use.

3.4.  Server Behaviour

   Upon receipt of a valid Reconfigure-Request message from a DHCPv6
   relay agent (see Section 3.2), the server follows the procedure
   defined in Section 19.1 of [RFC3315] and, if an RSOO is supplied,
   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.




Boucadair & Pougnard    Expires February 28, 2013               [Page 6]

Internet-Draft         Relay Triggered Reconfigure           August 2012


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.  In addition, DHCPv6 servers MAY be configured to
   discard relayed RECONFIFURE-REQUEST messages or restrict relay
   chaining (see [RFC5007] for more discussion about the rationale of
   this recommended behavior).  Relay agents SHOULD implement
   appropriate means to prevent using RECONFIFURE-REQUEST messages as a
   denial-of-service attack on the DHCPv6 servers.


6.  Acknowledgements

   Many thanks to T. Lemon, R. Maglione, A. Kostur and G. Halwasia for
   the comments and review.


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.

   [RFC5176]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
              Aboba, "Dynamic Authorization Extensions to Remote
              Authentication Dial In User Service (RADIUS)", RFC 5176,
              January 2008.




Boucadair & Pougnard    Expires February 28, 2013               [Page 7]

Internet-Draft         Relay Triggered Reconfigure           August 2012


Authors' Addresses

   Mohamed Boucadair
   France Telecom
   Rennes,   35000
   France

   Email: mohamed.boucadair@orange.com


   Xavier Pougnard
   Orange Labs
   Lannion,
   France

   Phone:
   Email: xavier.pougnard@orange.com


































Boucadair & Pougnard    Expires February 28, 2013               [Page 8]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/