RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Verified (2)

RFC 5007, "DHCPv6 Leasequery", September 2007

Source of RFC: dhc (int)

Errata ID: 3763
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Darpan Malhotra
Date Reported: 2013-10-23
Verifier Name: Ted Lemon
Date Verified: 2014-03-02

Throughout the document, when it says:


4.3.3.  Receipt of LEASEQUERY-REPLY

   A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE
   option (or an OPTION_STATUS_CODE option with a success code).  There
   are three variants:

   1.  If the server had bindings for the requested client, the message
       includes an OPTION_CLIENT_DATA option and the requestor extracts
       the client data from the LEASEQUERY-REPLY and updates its binding
       information database.  If the OPTION_CLIENT_DATA contains no
       OPTION_CLT_TIME, the requestor SHOULD silently discard the
       OPTION_CLIENT_DATA option.

...

4.3.4.  Handling DHCPv6 Client Data from Multiple Sources

...

   The requestor SHOULD use the OPTION_CLT_TIME to resolve data
   conflicts originated from different servers, and SHOULD accept data
   with most recent OPTION_CLT_TIME.

It should say:

4.3.3. Receipt of LEASEQUERY-REPLY

   A successful LEASEQUERY-REPLY is one without an OPTION_STATUS_CODE
   option (or an OPTION_STATUS_CODE option with a success code).  There
   are three variants:

   1.  If the server had bindings for the requested client, the message
       includes an OPTION_CLIENT_DATA option and the requestor extracts
       the client data from the LEASEQUERY-REPLY and updates its binding
       information database.  

...

4.3.4. Handling DHCPv6 Client Data from Multiple Sources

...

   The requestor SHOULD use the OPTION_CLT_TIME to resolve data
   conflicts originated from different servers, and SHOULD accept data
   with most recent OPTION_CLT_TIME. If OPTION_CLT_TIME is not
   present in a response, then response from other servers having
   OPTION_CLT_TIME should be preferred.

Notes:

Consider the scenario of DHCPv6 Failover (as mentioned in RFC 7031), there will be cases where only one server (Main) would have communicated with the client. Bindings for the client will be present on both servers, but the partner server (Backup) will not have Client Last Transaction Time. When a requestor sends Leasequery to the backup server, the response should not contain OPTION_CLT_TIME.

Further, consider the following scenarios:
1. Requestor gets response for Leasequery from both servers (main and backup).
In this scenario, response having OPTION_CLT_TIME should be preferred by the requestor. This is the justification for adding the text in Section 4.3.4.

2. Requestor gets response for Leasequery from only from one server (as other server is down).
Consider main to be down. So, the requestor gets response only from Backup. The requestor should still accept this data. This is justification of removing the text from Section 4.3.3.

Errata ID: 4816
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Sander Steffann
Date Reported: 2016-10-02
Verifier Name: Eric Vyncke
Date Verified: 2021-02-08

Throughout the document, when it says:

There are references to OPTION_CLIENT_LINK, which doesn't exist.

It should say:

The references are apparently for option 48: OPTION_LQ_CLIENT_LINK.

Notes:

-- Verifier note --
Section 4.1.2.5 of this RFC indeed specifies OPTION_LQ_CLIENT_LINK (the DHCPv6 IANA registry also uses OPTION_LQ_CLIENT_LINK). So, sections 4.3.3 and 4.4.1 should use "OPTION_LQ_CLIENT_LINK" rather than "OPTION_CLIENT_LINK".

Report New Errata



Advanced Search