Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
RFC 4242
Note: This ballot was opened for revision 03 and is now closed.
(Margaret Cullen) Yes
(Ted Hardie) Yes
(Brian Carpenter) No Objection
(Bill Fenner) No Objection
(Sam Hartman) No Objection
(Scott Hollenbeck) No Objection
Comment (2005-05-10)
No email
send info
send info
I think it would be helpful if the values in section 3.1 were described in units of seconds ("86400 (24 hours))" sort of implies seconds), but since the units are identified in section 3.4 I don't see this as a serious deficiency.
(Russ Housley) No Objection
(David Kessens) No Objection
(Allison Mankin) No Objection
Comment (2005-05-12)
No email
send info
send info
The security considerations discussion of the use of this option by a DHCP forger reminds me that we haven't seen a draft whereby a DHCP client receive a certificate from a DCHP server. What is so hard about this? I believe it is part of the working group's charter to add some protection for clients against spoofing servers; is it relays that make the problem so hard?
(Jon Peterson) No Objection
(Mark Townsley) No Objection
(Bert Wijnen) No Objection
(Alex Zinin) No Objection
Comment (2005-05-11)
No email
send info
send info
In Section 3.2. "Client behaviour": When the client detects that the refresh time has expired, it SHOULD try to update its configuration data by sending an Information- Request as specified in section 18.1.5 of [RFC 3315], except that the client MUST delay sending the first Information-Request by a random amount of time between 0 and INF_MAX_DELAY. It isn't clear whether "the first" means the first Information-Request message on that interface during the client's lifetime (as 3315 suggests), the first message for a particular refresh timer expiration, or something else.