Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-10-14
03 (System) Notify list changed from rdroms@cisco.com, venaas@uninett.no to rdroms@cisco.com
2005-12-04
03 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-12-04
03 Amy Vezza [Note]: 'RFC 4242' added by Amy Vezza
2005-11-22
03 (System) RFC published
2005-05-16
03 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-05-16
03 Amy Vezza IESG state changed to Approved-announcement sent
2005-05-16
03 Amy Vezza IESG has approved the document
2005-05-16
03 Amy Vezza Closed "Approve" ballot
2005-05-13
03 (System) Removed from agenda for telechat - 2005-05-12
2005-05-12
03 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2005-05-12
03 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-05-12
03 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-05-12
03 Allison Mankin
[Ballot comment]
The security considerations discussion of the use of this option by
a DHCP forger reminds me that we haven't seen a draft whereby …
[Ballot comment]
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?
2005-05-12
03 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-05-11
03 Alex Zinin
[Ballot comment]
In Section 3.2. "Client behaviour":

  When the client detects that the refresh time has expired, it SHOULD
  try to update its …
[Ballot comment]
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.
2005-05-11
03 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-05-11
03 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-05-11
03 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-05-11
03 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-05-10
03 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie by Ted Hardie
2005-05-10
03 Scott Hollenbeck
[Ballot comment]
I think it would be helpful if the values in section 3.1 were described in units of seconds ("86400 (24 hours))" sort of …
[Ballot comment]
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.
2005-05-10
03 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-05-10
03 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-05-09
03 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-05-08
03 Sam Hartman [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Sam Hartman
2005-05-08
03 Margaret Cullen
Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward …
Submission Questionnaire:

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes and yes.

2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

Yes and no.

3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No.

4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No.

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

WG as a whole understands and agrees with this document.  We have
discussed the document at a couple of WG meetings and have had good
engagement.  There were only a few responses to the WG last call;
those responses were unanimously in favor of submitting the document
to the IESG.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No.
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

There is a minor boilerplate nit:

  * The document seems to lack a 1id_guidelines paragraph about the list of
    Shadow Directories.

  (Expected a match on the following text:
    "The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html")


8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

  A host that uses stateless address autoconfiguration (RFC 2462)
  will still require the configuration of other configuration
  information.  DHCPv6 (RFC 3315, RFC 3736) is one way in which a
  host might obtain other configuration information.  The mechanism
  described in RFC 3736, "stateless DHCPv6", provides configuration
  information but does not give the host any indication of when the
  DHCPv6 server should be contacted to refresh that configuration
  information.  This document describes a DHCPv6 option for
  specifying an upper bound for how long a client should wait before
  refreshing information retrieved from DHCPv6.

  The option specified in this document meets the requirements of
  draft-ietf-dhc-stateless-dhcpv6-renumbering, which has been
  accepted for publication as an Informational RFC.

  - Working Group Summary

  The dhc WG developed, discussed and published
  draft-ietf-dhc-stateless-dhcpv6-renumbering, which defines the
  requirements for managing the updating of configuration parameters
  obtained through stateless DHCPv6.

  The specification in this document has been given thorough review
  by the dhc WG.  During the review, several issues about details of
  the configuration update process were resolved through discussion
  in the WG mailing list.

  - Protocol Quality

  The protocol specified in this document is a simple extension to
  the DHCPv6 protocol, which would have been appropriate to include
  in RFC 3315.  The option has been implemented in KAME DHCP server
  and in Lucent DHCP client. The two implementations have been tested
  for interoperability.  From Joe Quanaim prior to previous IETF:

    Since the lifetime draft will be discussed next week at the ietf,
    I thought I would let you know that I have implemented the
    functionality in a dhcpv6 client and successfully tested it
    against the kame server implementation.  I figure it might help
    to be able to cite implementations.
2005-05-08
03 Margaret Cullen [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman
2005-05-08
03 Margaret Cullen Ballot has been issued by Margaret Wasserman
2005-05-08
03 Margaret Cullen Created "Approve" ballot
2005-05-08
03 Margaret Cullen State Changes to IESG Evaluation from Waiting for Writeup by Margaret Wasserman
2005-05-05
03 Margaret Cullen Placed on agenda for telechat - 2005-05-12 by Margaret Wasserman
2005-04-20
03 (System) State has been changed to Waiting for Writeup from In Last Call by system
2005-04-06
03 Michelle Cotton
IANA Last Call Comments:
Upon approval of this document the IANA will register an option code for the information refresh time option from the DHCPv6 …
IANA Last Call Comments:
Upon approval of this document the IANA will register an option code for the information refresh time option from the DHCPv6 option-code space found at the following:
2005-04-06
03 Amy Vezza Last call sent
2005-04-06
03 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-04-06
03 Margaret Cullen State Changes to Last Call Requested from Publication Requested by Margaret Wasserman
2005-04-06
03 Margaret Cullen Last Call was requested by Margaret Wasserman
2005-04-06
03 (System) Ballot writeup text was added
2005-04-06
03 (System) Last call text was added
2005-04-06
03 (System) Ballot approval text was added
2005-02-23
03 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2005-01-11
03 (System) New version available: draft-ietf-dhc-lifetime-03.txt
2004-09-09
02 (System) New version available: draft-ietf-dhc-lifetime-02.txt
2004-07-19
01 (System) New version available: draft-ietf-dhc-lifetime-01.txt
2004-03-09
00 (System) New version available: draft-ietf-dhc-lifetime-00.txt