RFC 4242

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

📅 published November 2005, from ietf

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

  • Series: Network Working Group, Request for Comments 4242 💖
  • Authors: Stig Venaas (UNINETT), Tim Chown (University of Southampton), Bernard Volz (Cisco Systems, Inc.) 🫶
  • Category: Standards Track ✨
  • Date: November 2005 🦋
  • Obsoletes / Updates: the header doesn't list any RFCs this one obsoletes or updates 🌸

Status of This Memo 💅

Okay so this is an Internet standards track protocol for the whole Internet community, and it's basically asking everyone to talk about it and suggest improvements 🗣️ For the official standardization state and status, you check the "Internet Official Protocol Standards" (STD 1) document, which is the source of truth 📚 And the memo can be distributed freely, no cap 🌈

Copyright (C) The Internet Society (2005).

Abstract 🧚

This doc describes a DHCPv6 option that sets an upper bound on how long a client should wait before refreshing the information it got from DHCPv6 🕰️ It's meant for stateless DHCPv6, because there are no addresses or other things with lifetimes to tell the client when to check back in with the server. So this option literally fills that gap 🙌

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

1. Introduction ✨

Okay bestie, so [RFC3315] is the one that defines stateful autoconfiguration for IPv6 hosts 💻 But a lot of hosts go with stateless autoconfiguration from [RFC2462] for their addresses, and then only use DHCPv6 for other config stuff, which is covered in [RFC3736] 📦 That other config data usually doesn't come with a lifetime, so the host has no clue when to refresh it. That's the problem! So we need an option the server can send to the client that says when it should refresh that other config data 🔥

This option is super useful in a few situations 👑

  • Unstable environments where unexpected changes are likely to happen 🌪️
  • Planned changes, including renumbering. An administrator can gradually lower the time as the event gets closer 🗓️
  • Limiting how long it takes before new services or servers show up for the client, like a new NTP server or a DNS server with a new address. 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 gives an upper bound for how long a client should wait before refreshing the information it got from DHCPv6. It's only used in Reply messages sent in response to Information-Request messages 💌 In other messages there's usually some other option that tells the client when to contact the server, like addresses with lifetimes 🧠

Note that it's only an upper bound. If the client has any reason to make a DHCPv6 request before the refresh time runs out, it should try to refresh all the data 💫

A client may contact the server before the refresh time runs out. Reasons it might do this include needing extra config parameters (for example, because an application asked for them), a new IPv6 prefix announced by a router, or an indication that it may have moved to a new link 🚶‍♀️

The refresh time option sets one common refresh time for all the data. Having different refresh times for different data doesn't make sense, because once the client has a reason to refresh some of its data, it should refresh the rest too. That's why the option must only appear in the options area of the Reply message 🙅‍♀️

When the refresh time expires, that by itself does not mean the client should delete the data. The client should keep its current data while it tries to refresh it. However, the client is free to fall back to mechanisms other than DHCPv6 if it can't refresh the data within a reasonable amount of time 🔄

When a client gets a Reply to an Information-Request that has config information in it, it should install that new config information after removing any config information it got before. It should also remove any information that's missing from the new set. For example, an option might be left out, or it might contain only part of what it used to have 🧹

3.1. Constants 🌸

We define two constants for the protocol. How they're used is described in the sections below.

  • IRT_DEFAULT = 86400: In some cases the client uses a default refresh time, IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400 (24 hours). The client implementation SHOULD allow for this value to be configurable. 🛠️
  • IRT_MINIMUM = 600: This sets a minimum value for the refresh time. 🍃

3.2. Client Behaviour 🧚‍♀️

A client MUST request this option in the Option Request Option (ORO) when it sends Information-Request messages to the DHCPv6 server. A client MUST NOT request this option in the ORO in any other messages. 🙅‍♀️

If the Reply to an Information-Request message doesn't contain this option, the client MUST behave as if the option with value IRT_DEFAULT was provided. 🫶

A client MUST use the refresh time IRT_MINIMUM if it receives the option with a value less than IRT_MINIMUM. 🌷

As per section 5.6 of [RFC3315], the value 0xffffffff is taken to mean "infinity". It implies that the client should not refresh its config data without some other trigger, like detecting movement to a new link ♾️

If a client contacts the server to get new data or refresh some existing data before the refresh time expires, then it SHOULD also refresh all the data covered by this option. 🔁

When the client detects that the refresh time has expired, it SHOULD try to update its config data by sending an Information-Request as specified in section 18.1.5 of [RFC3315]. The one twist is that the client MUST delay sending the first Information-Request by a random amount of time between 0 and INF_MAX_DELAY. ⏳

A client MAY have a maximum value for the refresh time. If it does, that value is used whenever the client receives this option with a value higher than the maximum. This also means the maximum value is used when the received value is "infinity". A maximum value might make the client less vulnerable to attacks based on forged DHCP messages. Without one, a client could be made to use wrong information for a possibly infinite period of time 😱 There may still be reasons for a very long refresh time, so it may be useful for this maximum value to be configurable 🔐

3.3. Server Behaviour 🏰

A server sending a Reply to an Information-Request message SHOULD include this option if the Information-Request requested it in the ORO. 📬

The option value MUST NOT be smaller than IRT_MINIMUM. The server SHOULD give a warning if it's configured with a smaller value. ⚠️

The option MUST only appear in the options area of Reply messages. 🫧

To be continued… 💖 Part 2 has the option format, IANA, acknowledgements, security, and references 🦋

okay so the legal bit 💅 Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

THE DOCUMENT AND THE INFO IN IT ARE PROVIDED ON AN "AS IS" BASIS. Here's the exact legal text, bestie: "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 😭

Intellectual Property 🦋

The IETF takes no position on whether any Intellectual Property Rights (or other rights) claimed to cover the tech in this doc are valid, or how much they apply. It also doesn't know whether any license for those rights would be available, and it hasn't made any independent effort to find such rights. 🫶 If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79.

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr. 🌸

The IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. 💜 Send that info to the IETF at ietf-ipr@ietf.org. Lowkey important, so don't skip it! 🔥

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. 👑 Thank you, ISOC, for keeping the lights on! ✨

📦 where this page comes from