datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
RFC 4242

Document type: RFC - Proposed Standard (November 2005)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4242 (Proposed Standard)
Responsible AD: Margaret Wasserman
Send notices to: rdroms@cisco.com, venaas@uninett.no

Network Working Group                                          S. Venaas
Request for Comments: 4242                                       UNINETT
Category: Standards Track                                       T. Chown
                                               University of Southampton
                                                                 B. Volz
                                                     Cisco Systems, Inc.
                                                           November 2005

                  Information Refresh Time Option for
         Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

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

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Information Refresh Time Option Definition ......................2
      3.1. Constants ..................................................3
      3.2. Client Behaviour ...........................................3
      3.3. Server Behaviour ...........................................4
      3.4. Option Format ..............................................5
   4. IANA Considerations .............................................5
   5. Acknowledgements ................................................5
   6. Security Considerations .........................................5
   7. References ......................................................6
      7.1. Normative References .......................................6
      7.2. Informative References .....................................6

Venaas, et al.              Standards Track                     [Page 1]
RFC 4242       Information Refresh Time Option for DHCPv6  November 2005

1.  Introduction

   DHCPv6 [RFC3315] specifies stateful autoconfiguration for IPv6 hosts.
   However, many hosts will use stateless autoconfiguration as specified
   in [RFC2462] for address assignment, and use DHCPv6 only for other
   configuration data; see [RFC3736].  This other configuration data
   will typically have no associated lifetime, hence there may be no
   information telling a host when to refresh its DHCPv6 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.

      - Limit the amount of time before new services or servers are
        available to the client, such as the addition of a new NTP
        server or a change of address of a DNS server.  See [RFC4076].

2.  Terminology

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

3.  Information Refresh Time Option Definition

   The information refresh time option specifies an upper bound for how
   long a client should wait before refreshing information retrieved
   from DHCPv6.  It is only used in Reply messages in response to
   Information-Request messages.  In other messages there will usually
   be other options that indicate when the client should contact the
   server, e.g., addresses with lifetimes.

   Note that it is only an upper bound.  If the client has any reason to
   make a DHCPv6 request before the refresh time expires, it should
   attempt to refresh all the data.

   A client may contact the server before the refresh time expires.
   Reasons it may do this include the need for additional configuration

[include full document text]