Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
obsoleted by
- rfc-8415 — Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Extracted elements (21)
A client MAY implement a configurable maximum refresh time cap, applied even when the received value is 'infinity', to limit how long forged DHCP messages can cause the client to use incorrect configuration data.
Expiry of the refresh time does not mean the client should remove its configuration data; the client should keep current data while attempting to refresh it, and may fall back to mechanisms other than DHCPv6 if refresh fails within a reasonable time.
The option is only applicable to stateless DHCPv6 (Information-Request/Reply exchanges) because stateful DHCPv6 already has address and prefix lifetimes that implicitly signal when the client should contact the server.
The refresh time option specifies a common refresh time for all configuration data rather than per-option lifetimes, because when the client has reason to refresh some of its data, it should also refresh the remaining data to maintain consistency.
When a client receives a Reply to an Information-Request containing configuration information, it should install the new configuration after removing previously received configuration information, including options that are missing from or reduced in the new information set.
A client MUST request the Information Refresh Time option in the Option Request Option (ORO) when sending Information-Request messages to the DHCPv6 server. A client MUST NOT request this option in the ORO in any other messages.
A client MUST use the refresh time IRT_MINIMUM (600 seconds) if it receives the option with a value less than IRT_MINIMUM, preventing servers or attackers from forcing excessively short refresh intervals.
A server sending a Reply to an Information-Request message SHOULD include this option if it is requested in the ORO of the Information-Request.
If a client contacts the server to refresh some data before the refresh time expires, it SHOULD also refresh all data covered by this option, ensuring consistency across all configuration parameters.
If the Reply to an Information-Request message does not contain this option, the client MUST behave as if the option with value IRT_DEFAULT (86400 seconds) was provided.
The Information Refresh Time option MUST only appear in the options area of Reply messages, not in any other DHCPv6 message type.
The option value MUST NOT be smaller than IRT_MINIMUM (600 seconds). The server SHOULD give a warning if it is configured with a smaller value.
When the client detects that the refresh time has expired, it SHOULD try to update its configuration data by sending an Information-Request, but MUST delay sending the first request by a random amount of time between 0 and INF_MAX_DELAY.
IRT_DEFAULT is defined as 86400 seconds (24 hours) and is used when the server does not include the option in its Reply. The client implementation SHOULD allow this value to be configurable.
IRT_MINIMUM is defined as 600 seconds and sets a floor on the refresh time a client will use, even if the server sends a smaller value. This protects against attacks using artificially short refresh times.
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. The option code is OPTION_INFORMATION_REFRESH_TIME (32).
The value 0xffffffff in the information-refresh-time field means 'infinity', implying the client should not refresh its configuration data without some other trigger such as detecting movement to a new link.
IANA assigned option code 32 (OPTION_INFORMATION_REFRESH_TIME) from the DHCPv6 option-code space defined in RFC 3315 for the Information Refresh Time option.
An attacker could send a very large refresh time value (or 'infinity') to cause the client to use forged or stale configuration information for an extended period. A configurable maximum refresh time at the client is suggested to mitigate this threat.
An attacker could send faked Reply messages with a low information-refresh-time value to force frequent re-requests; this is mitigated by IRT_MINIMUM (600s), which is the floor value a client will accept regardless of what the message contains.
The option format contains a 2-octet option-code (value 32), a 2-octet option-len (value 4), and a 4-octet information-refresh-time field expressing a time duration in seconds relative to the current time.