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

Versions: 00 draft-ietf-dhc-dhcpv6-stateful-issues

Network Working Group                                           O. Troan
Internet-Draft                                                   B. Volz
Intended status: Informational                                     cisco
Expires: September 29, 2012                               March 28, 2012


              Issues with multiple stateful DHCPv6 options
             draft-troan-dhc-dhcpv6-stateful-issues-00.txt

Abstract

   [RFC3315] was not written with the expectation that other stateful
   DHCPv6 options would be developed.  [RFC3633] shoe-horned the new
   options for Prefix Delegation options for DHCPv6 into DHCPv6.
   Implementation experience of the CPE model described in [RFC6204] has
   shown multiple issues with the DHCPv6 protocol in supporting multiple
   stateful options.

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 September 29, 2012.

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
   the Trust Legal Provisions and are provided without warranty as



Troan & Volz           Expires September 29, 2012               [Page 1]


Internet-Draft          Multiple Stateful Option              March 2012


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Handling of multiple IA_* options . . . . . . . . . . . . . . . 3
     3.1.  Advertisement message . . . . . . . . . . . . . . . . . . . 3
     3.2.  Placement of Status codes . . . . . . . . . . . . . . . . . 4
     3.3.  T1/T2 timers  . . . . . . . . . . . . . . . . . . . . . . . 5
     3.4.  Confirm message . . . . . . . . . . . . . . . . . . . . . . 5
     3.5.  Release / Decline messages  . . . . . . . . . . . . . . . . 6
     3.6.  Unanswered options  . . . . . . . . . . . . . . . . . . . . 6
     3.7.  Multiple provisioning domains . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7





























Troan & Volz           Expires September 29, 2012               [Page 2]


Internet-Draft          Multiple Stateful Option              March 2012


1.  Introduction

   [RFC3315] was not written with the expectation that other stateful
   DHCPv6 options would be developed.  [RFC3633] shoe-horned the new
   options for Prefix Delegation options for DHCPv6 into DHCPv6.
   Implementation experience of the CPE model described in [RFC6204] has
   shown multiple issues with the DHCPv6 protocol in supporting multiple
   stateful options.

   This document describes a number of problems encountered when
   introducing multiple IA_ options into DHCP.  The document also
   suggest solutions with suggested edits to the protocol specification.

   The intention of this work is to modify the DHCP protocol
   specification to support multiple IA_ options within a single DHCP
   session.  This problem can also be solved by implementing a separate
   DHCP session (separate client state machine) per IA_ option.  This
   latter approach has a number of issues.  Addition DHCP protocol
   traffic, 'collisions' between stateless options also included with
   the IA_ options, divergence in that each IA_ option specification
   basically specifies its own version of the DHCP protocol...


2.  Conventions

   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 RFC 2119 [RFC2119].


3.  Handling of multiple IA_* options

   DHCPv6 was written with the assumption that the only stateful options
   where for assigning addresses.  DHCPv6 PD describes how to extend the
   DHCPv6 protocol to handle prefix delegation, but RFC3633 did not
   consider how DHCP address assignment and prefix delegation could co-
   exist.

3.1.  Advertisement message

   RFC3315 specifies that a client must ignore an Advertise message if a
   server will not assign any addresses to a client.  A client
   requesting both IA_NA and IA_PD, with a server that only offers one
   of them, is not supported in the current protocol specification.

   Proposed solution: a client should accept Advertise messages, even
   when not all IA_ options are being offered.  A client should ignore
   an Advertise message when no IA_ options at all are being offered.



Troan & Volz           Expires September 29, 2012               [Page 3]


Internet-Draft          Multiple Stateful Option              March 2012


   Replace Section 17.1.3: (existing errata)


      The client MUST ignore any Advertise message that includes a Status
      Code option containing the value NoAddrsAvail, with the exception
      that the client MAY display the associated status message to the
      user.

   With:


      The client MUST ignore any IAs in an Advertise message that
      includes a Status Code option containing the value NoAddrsAvail,
      with the exception that the client MAY display the associated
      status message to the user. An Advertise message without any IA
      options MUST be ignored.

   It is important to note that the receipt of a Advertisement without
   any IA options, does not imply that the client should restart the
   Solicit retransmissions timers.  Doing so would lead to a Solicit/
   Advertisement storm.

3.2.  Placement of Status codes

   In Reply messages IA specific status codes (NoAddrsAvail, NotOnlink,
   NoBinding) are encapsulated in the IA option.  In Advertisement
   messages the Status code option with the NoAddrsAvail code is in the
   "global" scope.  That makes sense when the failure case is fatal.
   With the introduction of multiple IA options, there might be a case
   where a server is not willing to offer addresses, but might be
   willing to offer other options.

   While a Status Code option is implicitly bound to a specific type of
   IA.  E.g.  NoPrefixAvail is only applicable to IA_PD, and
   NoAddrsAvail is only applicable to IA_NA/IA_TA, it may be problematic
   to make this assumption for all status codes.  If so the Status Code
   must be embedded in the IA_ option for all DHCP messages.  This makes
   Advertisement messages equal to Reply messages.

   Proposed solution: Embedding the Status code option in the specific
   IA.  For backwards compatibility, the IA_NA status code can be kept
   in the global scope.

   Replace Section 17.2.2: (existing errata)







Troan & Volz           Expires September 29, 2012               [Page 4]


Internet-Draft          Multiple Stateful Option              March 2012


      If the server will not assign any addresses to any IAs in a
      subsequent Request from the client, the server MUST send an
      Advertise message to the client that includes only a Status Code
      option with code NoAddrsAvail and a status message for the user, a
      Server Identifier option with the server's DUID, and a Client
      Identifier option with the client's DUID.

   With:


      If the server will not assign any addresses to an IA in a
      subsequent Request from the client, the server MUST send an
      Advertise message to the client that includes the IA containing a
      Status Code option with status code NoAddrsAvail and a status
      message for the user, a Server Identifier option with the server's
      DUID, and a Client Identifier option with the client's DUID. The
      server SHOULD include other stateful IA options (like IA_PD) and
      other configuration options in the Advertise message.

3.3.  T1/T2 timers

   The T1 and T2 timers determine when the client will contact the
   server to extend lifetimes of information received in an IA.  How
   should a client handle the case where multiple IA_ options have
   different T1 and T2 timers?

   In a multiple IA_ options model, the T1/T2 timers are protocol
   timers, that should be independent of the IA_ options themselves.  If
   we were to redo the DHCP protocol from scratch the T1/T2 timers
   should be carried in a separate DHCP option.

   Proposed solution: The server should set the T1/T2 timers in all IA_*
   to the same value.  To deal with the case where servers have not yet
   been updated to do that, clients must use the shortest T1/T2 timer
   (larger than 0) in any IA_ option.  Longer T1/T2 timers are ignored.

3.4.  Confirm message

   The Confirm message is specific to address assignment.  It lets a
   server without a binding to reply to the message, under the
   assumption that the server has knowledge of the prefix on the link,
   while not having the binding, can inform the client that the address
   is likely valid.  This message is sent when e.g. the client has moved
   and needs to validate its addresses.  Not all IA_ options can be
   validated by servers without the binding.

   Note: Confirm has a specific meaning and doesn't overload Renew/
   Rebind.  It also is lower processing cost as the server does NOT need



Troan & Volz           Expires September 29, 2012               [Page 5]


Internet-Draft          Multiple Stateful Option              March 2012


   to extend lease times or otherwise send back options.

   Proposed solution: Allow and specify the Confirm message for other IA
   options.  It is encouraged to use Renew instead of Confirm.

3.5.  Release / Decline messages

   A client can release any individual lease at any time.  A client can
   get "back" a lease by using a Renew message.  It MAY do this at any
   time, though must avoid creating a Renew storm.  E.g. wait until T1.

3.6.  Unanswered options

   If a client requests multiple IA_ options, but the server is willing
   to only offer a subset of them, the client could react in several
   ways.  Reset the state machine and continue to send Solicit messages,
   create separate DHCP sessions for each IA and continue to Solicit for
   the missing options, or it could continue with the single session,
   and include the missing options on subsequent messages to the server.

   Proposed solution: the client should keep a single session with the
   server.  The client should continue with the IA_ options received,
   while continuing to request the other IA options in subsequent
   messages to the server.  That means continue to include the empty
   unanswered IAs in subsequent Renew and Rebind messages.

   For the IAs that the server has no binding for, it must reply using
   the same behaviour as for a Request message.  That is with a
   "NoAddrsAvail" status.  (As opposed to the currently specified
   NoBinding).  This behaviour will not require the server to remember
   the IAs that it is not willing to server.  I.e. the change is to
   allow the client to include IAs (bindings) in Renew/Rebind messages
   which it has not received (yet).

3.7.  Multiple provisioning domains

   Out of scope for this set of proposed changes to RFC3315/RFC3633.


4.  IANA Considerations

   This specification does not require any IANA actions.


5.  Security Considerations

   There are no new security considerations pertaining to this document.




Troan & Volz           Expires September 29, 2012               [Page 6]


Internet-Draft          Multiple Stateful Option              March 2012


6.  Acknowledgements


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.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC6204]  Singh, H., Beebee, W., Donley, C., Stark, B., and O.
              Troan, "Basic Requirements for IPv6 Customer Edge
              Routers", RFC 6204, April 2011.

7.2.  Informative References


Authors' Addresses

   Ole Troan
   cisco
   Oslo,
   Norway

   Email: ot@cisco.com


   Bernie Volz
   cisco
   Out in the Woods somewhere,
   US of A

   Email: volz@cisco.com










Troan & Volz           Expires September 29, 2012               [Page 7]


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