<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml">
<!ENTITY RFC2939 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2939.xml">
<!ENTITY RFC4242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml">
<!ENTITY I-D.draft-bhandari-netext-pmipv6-dhcp-options SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bhandari-netext-pmipv6-dhcp-options-00.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-halwasia-dhc-inform-refresh-time-opt-00"
     ipr="trust200902">
  <front>
    <title abbrev="DHCPv4 INFORM Refresh Time Option">DHCPv4 INFORM Refresh
    Time Option</title>

    <author fullname="Shwetha Bhandari" initials="S." surname="Bhandari">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Sarjapura Marathalli Outer Ring
          Road</street>

          <city>Bangalore</city>

          <region>KARNATAKA</region>

          <code>560 087</code>

          <country>India</country>
        </postal>

        <phone>+91 80 4426 0474</phone>

        <email>shwethab@cisco.com</email>
      </address>
    </author>

    <author fullname="Gaurav Halwasia" initials="G." surname="Halwasia">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Sarjapura Marathalli Outer Ring
          Road</street>

          <city>Bangalore</city>

          <region>KARNATAKA</region>

          <code>560 087</code>

          <country>India</country>
        </postal>

        <phone>+91 80 4426 1321</phone>

        <email>ghalwasi@cisco.com</email>
      </address>
    </author>

    <author fullname="Bernie Volz" initials="B." surname="Volz">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>1414 Massachusetts Ave</street>

          <city>BOXBOROUGH</city>

          <region>MASSACHUSETTS</region>

          <code>01719</code>

          <country>UNITED STATES</country>
        </postal>

        <phone>+1 978 936 0382</phone>

        <email>volz@cisco.com</email>
      </address>
    </author>

    <date day="10" month="September" year="2012"/>

    <abstract>
      <t>This document describes a Dynamic Host Configuration Protocol for
      IPv4 (DHCPv4) <xref target="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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>DHCPv4 <xref target="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.</t>

      <t>This option is useful in many situations:-</t>

      <t>- Unstable environments where unexpected changes are likely to
      occur.</t>

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

      <t>- <xref target="I-D.bhandari-netext-pmipv6-dhcp-options">Use cases
      described in</xref> also intends to use this option to exchange
      configuration parameters in between MAG and LMA.</t>
    </section>

    <section title="DHCPv4 INFORM Refresh Time Option">
      <t>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.</t>

      <figure>
        <artwork><![CDATA[   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
]]></artwork>
      </figure>
    </section>

    <section title="Client Behaviour">
      <t>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.</t>

      <t>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 <xref target="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.</t>
    </section>

    <section title="Server Behaviour">
      <t>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.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>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 <xref
      target="RFC2939"/>.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Section 7 of <xref target="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.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks to Authors of <xref target="RFC4242"/> as this document is
      essentially an edited version of their memo.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC2939;

      &RFC2131;

      &RFC4242;

      &I-D.draft-bhandari-netext-pmipv6-dhcp-options;
    </references>
  </back>
</rfc>
