Skip to main content

DHCPv6 Bulk Leasequery
draft-ietf-dhc-dhcpv6-bulk-leasequery-06

Revision differences

Document history

Date Rev. By Action
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2009-01-22
06 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-01-22
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-01-22
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-01-22
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-01-21
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-01-21
06 (System) IANA Action state changed to In Progress
2009-01-21
06 Amy Vezza IESG state changed to Approved-announcement sent
2009-01-21
06 Amy Vezza IESG has approved the document
2009-01-21
06 Amy Vezza Closed "Approve" ballot
2009-01-21
06 Jari Arkko State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Jari Arkko
2009-01-21
06 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2009-01-14
06 Jari Arkko State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko
2009-01-14
06 Jari Arkko Waiting on Lars to check if the new version is acceptable. My own evaluation says that it is.
2009-01-13
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-01-13
06 (System) New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-06.txt
2008-12-21
06 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko
2008-12-11
06 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-12-11
06 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-12-11
06 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-12-11
06 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-12-11
06 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2008-12-11
06 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-12-10
06 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-12-10
06 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-12-10
06 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-12-10
06 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-12-10
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-12-10
06 Lars Eggert
[Ballot comment]
Section 6.6., paragraph 1:
>    The Requestor MAY close its end of the TCP connection after sending a
>    LEASEQUERY message …
[Ballot comment]
Section 6.6., paragraph 1:
>    The Requestor MAY close its end of the TCP connection after sending a
>    LEASEQUERY message to the server.  The Requestor MAY choose to retain
>    the connection if it intends to issue additional queries.  Note that
>    this client behavior does not guarantee that the connection will be
>    available for additional queries: the server might decide to close
>    the connection based on its own configuration.

  The end system closing a TCP connections needs to maintain the
  TIME-WAIT state, which is undesirable for servers serving many
  clients. It may hence be a good idea here to recommend that the client
  close the connection under normal operation.
2008-12-10
06 Lars Eggert
[Ballot discuss]
Section 5.6., paragraph 2:
>    This section presents a table of values used to control Bulk
>    Leasequery behavior, including recommended …
[Ballot discuss]
Section 5.6., paragraph 2:
>    This section presents a table of values used to control Bulk
>    Leasequery behavior, including recommended defaults.  Implementations
>    MAY make these values configurable.
>
>    Parameter            Default  Description
>    ------------------------------------------
>    BULK_LQ_CONN_TIMEOUT  30 secs  Bulk Leasequery connection timeout
>    BULK_LQ_DATA_TIMEOUT  30 secs  Bulk Leasequery data timeout
>    BULK_LQ_MAX_RETRY    60 secs  Max Bulk Leasequery retry timeout
>    BULK_LQ_MAX_CONNS    10      Max Bulk Leasequery TCP connections

  DISCUSS: I'm OK with permitting these to be configurable, but it
  SHOULD NOT be possible to make these timeout values any shorter. (Or
  at least much shorter, but then we need to define what the acceptable
  lower limits are.) Please add a corresponding statement.


Section 6.2., paragraph 2:
>    If the TCP connection becomes blocked while the Requestor is sending
>    its query, the Requestor SHOULD be prepared to terminate the
>    connection after BULK_LQ_DATA_TIMEOUT.  We make this recommendation
>    to allow Requestors to control the period of time they are willing to
>    wait before abandoning a connection, independent of notifications
>    from the TCP implementations they may be using.

  DISCUSS: Typical TCP APIs don't let applications know when a
  connection  "gets stuck", at least not before the socket buffer has
  completely filled up, which is unlikely to be possible here due to the
  size of the messages. I would rephrase this paragraph (as well as
  other text in the document that talks about connections getting
  "blocked" or "stuck", e.g. in Sections 6.3, 7.1, 7.2, ...) to talk
  about the reply to a request not arriving within the
  BULK_LQ_DATA_TIMEOUT period, because that is always visible to an
  application using TCP.
2008-12-10
06 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2008-12-10
06 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2008-12-08
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-11-25
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-11-25
05 (System) New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-05.txt
2008-11-24
06 Jari Arkko Telechat date was changed to 2008-12-11 from 2008-12-04 by Jari Arkko
2008-11-24
06 Jari Arkko Moved document one week forward to load balance December telechats
2008-11-12
06 Jari Arkko State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Jari Arkko
2008-11-12
06 Jari Arkko
Status from the author:

I think there have been two categories of comment. As there often are, there have been some suggestions about textual changes …
Status from the author:

I think there have been two categories of comment. As there often are, there have been some suggestions about textual changes to improve clarity or consistency. Your comments, Alfred's, and some of Robert Sparks's fall into that category, and pretty much all of those comments seem to me to help.

Robert and Pekka Savola both had some other questions. Pekka seemed to object to the use of operational or management extensions to the DHCP protocol at all, and suggested developing an entirely new approach using SNMP. No one else seemed to support that position - the only two responses to it were negative. And it's not uncommon for protocols to include some operational capabilities along with their direct 'client-server' capabilities. As I see it, the working group has spoken there.

Robert asked a question about TCP security considerations, and another about the possibility and consequences of implementor confusion around the TCP framing for the DHCP messages proposed in the draft. I plan to address those in the next draft version. I'll add some discussion about the framing issue, to try to make it clearer. I think the TCP overview RFC and associated docs cover TCP security, so I plan to just point clearly to them.

So - I'm working on a new version, and I'm hoping to get it submitted this week.
2008-11-12
06 Jari Arkko State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko
2008-11-11
06 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Jürgen Schönwälder.
2008-11-10
06 Jari Arkko Placed on agenda for telechat - 2008-12-04 by Jari Arkko
2008-11-03
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2008-10-31
06 Amanda Baber
IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the
following assignment in the "DHCP Option Codes" registry at …
IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the
following assignment in the "DHCP Option Codes" registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Value Description Reference
----- ----------- ---------
[TBD] OPTION_RELAY_ID [RFC-dhc-dhcpv6-bulk-leasequery-04]


Action 2:

Upon approval of this document, the IANA will make the
following assignment in the "Status Codes" registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Code Name Reference
---- ------ ----------
[TBD] QueryTerminated [RFC-dhc-dhcpv6-bulk-leasequery-04]


Action 3:

Upon approval of this document, the IANA will make the
following assignments in the "DHCP Message types" registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Value Description Reference
----- ------------ ----------
[TBD] LEASEQUERY-DONE [RFC-dhc-dhcpv6-bulk-leasequery-04]
[TBD] LEASEQUERY-DATA [RFC-dhc-dhcpv6-bulk-leasequery-04]


Action 4:

Upon approval of this document, the IANA will make the
following assignments in the "OPTION_LQ_QUERY option" registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Code Name Reference
---- ----- ---------
[TBD] QUERY_BY_RELAY_ID [RFC-dhc-dhcpv6-bulk-leasequery-04]
[TBD] QUERY_BY_LINK_ADDRESS [RFC-dhc-dhcpv6-bulk-leasequery-04]
[TBD] QUERY_BY_REMOTE_ID [RFC-dhc-dhcpv6-bulk-leasequery-04]


We understand the above to be the only IANA Actions for this
document.
2008-10-21
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Jürgen Schönwälder
2008-10-21
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Jürgen Schönwälder
2008-10-20
06 Amy Vezza Last call sent
2008-10-20
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2008-10-20
06 Jari Arkko placed on the agenda
2008-10-19
06 Jari Arkko Last Call was requested by Jari Arkko
2008-10-19
06 Jari Arkko State Changes to Last Call Requested from AD Evaluation by Jari Arkko
2008-10-19
06 Jari Arkko State Changes to AD Evaluation from Last Call Requested by Jari Arkko
2008-10-19
06 Jari Arkko
I have made my AD review of this draft. The specification was well written and I had no major complaints -- thanks!

The draft has …
I have made my AD review of this draft. The specification was well written and I had no major complaints -- thanks!

The draft has been sent for IETF Last Call. However, there were two minor editorial issues that I'd like the authors to address. Feel free to submit a new version right away, or wait for Last Call comments and address these along with the other received comments.

Please expand the term DUID upon first use.

>    DATA message that does not contain an OPTION_CLIENT_DATA MUST BE
s/MUST BE/MUST be/
2008-10-19
06 Jari Arkko State Changes to Last Call Requested from Publication Requested by Jari Arkko
2008-10-19
06 Jari Arkko Last Call was requested by Jari Arkko
2008-10-19
06 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2008-10-19
06 Jari Arkko Ballot has been issued by Jari Arkko
2008-10-19
06 Jari Arkko Created "Approve" ballot
2008-10-19
06 (System) Ballot writeup text was added
2008-10-19
06 (System) Last call text was added
2008-10-19
06 (System) Ballot approval text was added
2008-10-19
06 Jari Arkko
This summary sheet is submitted as part of the dhc WG request to
publish draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt as a Proposed
Standard.

1) Have the chairs personally reviewed …
This summary sheet is submitted as part of the dhc WG request to
publish draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt as a Proposed
Standard.

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; 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; 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 the document; most of the
expressed support has come from a few key WG contributors representing
several different vendors.

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 are a couple of nits; the most serious is a normative down
reference to an Informational RFC; I will have the author change the
reference to informative.

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

  - Technical Summary

  DHCPv6 "leasequery" allows a DHCPv6 server to be queried for
  information about DHCPv6 bindings.  As an example, a network
  element may use leasequery to recover state derived from DHCP
  message exchanges.  The existing leasequery mechanism is limited to
  queries for individual bindings.  In some situations individual
  binding queries may not be efficient, or even possible.  DHCPv6
  bulk leasequery expands on the Leasequery protocol, adding new
  query types and allowing for bulk transfer of DHCPv6 binding data
  via TCP.

  - Working Group Summary

  The dhc WG reviewed this document and raised several issues during
  the WG last call.  All of the issues have been resolved or
  addressed in this revision of the draft.  One set of issues was
  raised in
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg08468.html;
  the issues were resolved in a revision to the draft.

  - Protocol Quality

  DHCPv6 bulk leasequery was originally developed as a simple
  extension to DHCPv6 leasequery, carried over UDP.  Because of the
  possible effect on the network of a bulk data transfer over UDP,
  DHCPv6 bulk leasequery was re-architected to use TCP.  The
  specification for the resulting protocol has been reviewed by both
  dhc WG members and external transport experts.  DHCPv6 bulk
  leasequery was originally developed at the request of a large ISP,
  in anticipation of IPv6 service deployment.  At least one DHCPv6
  server vendor plans to implement DHCPv6 bulk leasequery.
2008-10-19
06 Jari Arkko Draft Added by Jari Arkko in state Publication Requested
2008-10-16
04 (System) New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-04.txt
2008-06-12
03 (System) New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-03.txt
2008-06-03
02 (System) New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-02.txt
2008-05-23
01 (System) New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-01.txt
2008-02-12
00 (System) New version available: draft-ietf-dhc-dhcpv6-bulk-leasequery-00.txt