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 12, 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

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

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.

   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.

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. References

Authors' Addresses