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

Versions: 00

Network Working Group                                        S. Bhandari
Internet-Draft                                               G. Halwasia
Intended status: Standards Track                                 B. Volz
Expires: March 14, 2013                                    Cisco Systems
                                                      September 10, 2012


                   DHCPv4 INFORM Refresh Time Option
             draft-halwasia-dhc-inform-refresh-time-opt-00

Abstract

   This document describes a Dynamic Host Configuration Protocol for
   IPv4 (DHCPv4) [RFC2131] option for specifying an upper bound for how
   long a client should wait before refreshing information retrieved
   from DHCPv4 Server by using DHCP INFORM message.  It is used with
   stateless DHCPv4 as there are no addresses or other entities with
   lifetimes that can tell the client when to contact the DHCPv4 server
   to refresh its configuration.

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

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 March 14, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Bhandari, et al.         Expires March 14, 2013                 [Page 1]


Internet-Draft      DHCPv4 INFORM Refresh Time Option     September 2012


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  DHCPv4 INFORM Refresh Time Option . . . . . . . . . . . . . . . 3
   3.  Client Behaviour  . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Server Behaviour  . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6





























Bhandari, et al.         Expires March 14, 2013                 [Page 2]


Internet-Draft      DHCPv4 INFORM Refresh Time Option     September 2012


1.  Introduction

   DHCPv4 [RFC2131] specifies DHCP INFORM message which a client can
   sent to obtain other local configuration parameters in case client
   has obtained a network address through some other means.  This other
   configuration data will typically have no associated "lease", hence
   there may be no information telling a host when to refresh its
   configuration data.  Therefore, an option that can be used from
   server to client to inform the client when it should refresh the
   other configuration data is needed.

   This option is useful in many situations:-

   - Unstable environments where unexpected changes are likely to occur.

   - For planned changes, including renumbering.  An administrator can
   gradually decrease the time as the event nears.

   - Use cases described in [I-D.bhandari-netext-pmipv6-dhcp-options]
   also intends to use this option to exchange configuration parameters
   in between MAG and LMA.


2.  DHCPv4 INFORM Refresh Time Option

   The INFORM refresh time option specifies an upper bound for how long
   a client should wait before refreshing configuration parameters
   retrieved from DHCPv4.  It is only used in DHCP ACK messages in
   response to DHCP INFORM messages.  In other messages there will
   usually be other options that indicate when the client should contact
   the server.  Note that it is only an upper bound.  If the client has
   any reason to send DHCP INFORM before the refresh time expires, it
   should attempt to refresh all the configuration parameters.  A client
   may contact the server before the refresh time expires due to various
   reasons.  For example, it may need additional configuration
   parameters (such as by an application), or that it has an indication
   that it may have moved to a new link etc.  The expiry of the refresh
   time in itself does not in any way mean that the client should remove
   the data.  The client should keep its current data while attempting
   to refresh it.  When a client receives a ACK message to an INFORM
   message that contains configuration information, it should install
   that new configuration information after removing any previously
   received configuration information.  It should also remove
   information that is missing from the new information set, e.g., an
   option might be left out or contain only a subset of what it did
   previously.





Bhandari, et al.         Expires March 14, 2013                 [Page 3]


Internet-Draft      DHCPv4 INFORM Refresh Time Option     September 2012


     The format of the DHCPv4 INFORM Refresh Time Option option is shown
     below.
       0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  option-code  |  option-len   |         option-value          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     option-value(cont.)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         option-code:  8-bit option code
         option-len:   4
         option-value: Time duration relative to the current time,
                       expressed in units of seconds


3.  Client Behaviour

   A client MUST request this option in the Parameter Request List
   Option when sending Parameter Request List message to the DHCPv4
   server.  A client MUST NOT request this option in the Parameter
   Request List option in any other messages.  This document recommends
   default refresh time of 86400 seconds and minimum default refresh
   time of 600 seconds.  If the Reply to an INFORM message does not
   contain this option, the client MUST behave as if the option with
   value 86400 seconds (24 hrs) was provided.  A client MUST use the
   refresh time of 600 seconds if it receives the option with a value
   less than 600 seconds.

   The value 0xffffffff in this option implies that the client should
   not refresh its configuration data without some other trigger (such
   as detecting movement to a new link).  If a client contacts the
   server to obtain new data or refresh some existing data before the
   refresh time expires, then it SHOULD also refresh all data covered by
   this option.  When the client detects that the refresh time has
   expired, it SHOULD try to update its configuration data by sending an
   INFORM message as specified in section 4.4.3 of [RFC2131].  A client
   MAY have a maximum value for the refresh time, where that value is
   used whenever the client receives this option with a value higher
   than the maximum.  This also means that the maximum value is used
   when the received value is "0xffffffff".  A maximum value might make
   the client less vulnerable to attacks based on forged DHCP messages.
   Without a maximum value, a client may be made to use wrong
   information for a possibly infinite period of time.  There may
   however be reasons for having a very long refresh time, so it may be
   useful for this maximum value to be configurable.





Bhandari, et al.         Expires March 14, 2013                 [Page 4]


Internet-Draft      DHCPv4 INFORM Refresh Time Option     September 2012


4.  Server Behaviour

   A server sending a ACK message to an INFORM message SHOULD include
   this option if it is requested in the Parameter Request List Option
   of the INFORM message.  The option value MUST NOT be smaller than 600
   seconds.  The server SHOULD give a warning if it is configured with a
   smaller value.  The option MUST only appear in the ACK messages.


5.  IANA Considerations

   This document defines DHCPv4 INFORM Refresh Time Option which
   requires assignment of DHCPv4 option code TBD1 assigned from "Bootp
   and DHCP options" registry (http://www.iana.org/assignments/ bootp-
   dhcp-parameters/bootp-dhcp-parameters.xml), as specified in
   [RFC2939].


6.  Security Considerations

   Section 7 of [RFC2131] outlines the DHCPv4 security considerations.
   This option does not change these in any significant way.  An
   attacker could send faked ACK messages with a low INFORM refresh time
   value, which would trigger use of minimum recommended value of 600
   seconds to minimize this threat.  Another attack might be to send a
   very large value, to make the client use forged information for a
   long period of time.  A possible maximum limit at the client is
   suggested, which would reduce this problem.


7.  Acknowledgements

   Thanks to Authors of [RFC4242] as this document is essentially an
   edited version of their memo.


8.  Normative References

   [I-D.bhandari-netext-pmipv6-dhcp-options]
              Systems, C. and S. Kumar, "DHCPv4 Configuration Options in
              PMIPv6", draft-bhandari-netext-pmipv6-dhcp-options-00
              (work in progress), July 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.



Bhandari, et al.         Expires March 14, 2013                 [Page 5]


Internet-Draft      DHCPv4 INFORM Refresh Time Option     September 2012


   [RFC2939]  Droms, R., "Procedures and IANA Guidelines for Definition
              of New DHCP Options and Message Types", BCP 43, RFC 2939,
              September 2000.

   [RFC4242]  Venaas, S., Chown, T., and B. Volz, "Information Refresh
              Time Option for Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 4242, November 2005.


Authors' Addresses

   Shwetha Bhandari
   Cisco Systems
   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
   Bangalore, KARNATAKA  560 087
   India

   Phone: +91 80 4426 0474
   Email: shwethab@cisco.com


   Gaurav Halwasia
   Cisco Systems
   Cessna Business Park, Sarjapura Marathalli Outer Ring Road
   Bangalore, KARNATAKA  560 087
   India

   Phone: +91 80 4426 1321
   Email: ghalwasi@cisco.com


   Bernie Volz
   Cisco Systems
   1414 Massachusetts Ave
   BOXBOROUGH, MASSACHUSETTS  01719
   UNITED STATES

   Phone: +1 978 936 0382
   Email: volz@cisco.com












Bhandari, et al.         Expires March 14, 2013                 [Page 6]


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