Search RFCs

RFC Editor

Found 3 records.

Status:Verified (1)

RFC 8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", November 2018

Note: This RFC has been obsoleted byRFC 9915

Errata ID:6183
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2020-05-19
Verifier Name: Erik Kline
Date Verified: 2020-05-21

Section 18.3.8 says:

   After all the addresses have been processed, the server generates a   Reply message by setting the "msg-type" field to REPLY and copying   the transaction ID from the Decline message into the "transaction-id"   field.  The client includes a Status Code option (see Section 21.13)   with the value Success, a Server Identifier option (see Section 21.3)   with the server's DUID, and a Client Identifier option (see   Section 21.2) with the client's DUID

It should say:

   After all the addresses have been processed, the server generates a   Reply message by setting the "msg-type" field to REPLY and copying   the transaction ID from the Decline message into the "transaction-id"   field.  The server includes a Status Code option (see Section 21.13)   with the value Success, a Server Identifier option (see Section 21.3)   with the server's DUID, and a Client Identifier option (see   Section 21.2) with the client's DUID

Notes:

The corrected text replaces "client" with "server".

I would like to thank Timothy Winters <tim@qacafe.com> for confirming that this is a bug in the specification.

Status:Held for Document Update (2)

RFC 8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", November 2018

Note: This RFC has been obsoleted byRFC 9915

Errata ID:6269
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Felix Hamme
Date Reported: 2020-08-30
Held for Document Update by: Eric Vyncke
Date Held: 2021-01-28

Throughout the document, when it says:

section 16:   A server MUST discard any Solicit, Confirm, Rebind, or   Information-request messages it receives with a Layer 3 unicast   destination address.section 18.2:   If the client has a source address of sufficient scope that can be   used by the server as a return address and the client has received a   Server Unicast option (see Section 21.12) from the server, the client   SHOULD unicast any Request, Renew, Release, and Decline messages to   the server.Appendix B does not permit a Server Unicast option in a Reconfigure message.

It should say:

section 16:   A server MUST discard any Solicit, Confirm, or Rebind messages    it receives with a Layer 3 unicast destination address.section 18.2:   If the client has a source address of sufficient scope that can be    used by the server as a return address and the client has received a    Server Unicast option (see Section 21.12) from the server, the client    SHOULD unicast any Request, Renew, Release, Decline, and Information-   request messages to the server.Appendix B permits a Server Unicast option in a Reconfigure message.

Notes:

Section 18.4 allows transmission of Information-request messages with a unicast destination address, if the client received a message with Server Unicast option. (See also https://mailarchive.ietf.org/arch/msg/dhcwg/x80cmfTN8fpRViiN_RHNXes-zVg/)

-- Verifier note --
After discussions inside the DHC WG (https://mailarchive.ietf.org/arch/msg/dhcwg/oNqBzT7CSOtoV7kQNLkJfSY_73E/), it appears that there is indeed an issue but as a RFC 8415-bis is probably coming and as the errata does not seem to be a couple of sentences to add/modify, I am selecting 'hold for document update'

Errata ID:6159
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2020-05-07
Held for Document Update by: Eric Vyncke
Date Held: 2020-05-07

Section 6.5 says:

   Temporary addresses were originally introduced to avoid privacy   concerns with stateless address autoconfiguration, which based   64 bits of the address on the EUI-64 (see [RFC4941].

It should say:

   Temporary addresses were originally introduced to avoid privacy   concerns with stateless address autoconfiguration, which based   64 bits of the address on the EUI-64 (see [RFC4941]).

Notes:

Missing close parenthesis

AD note: good catch but as it is a typo, it is for "Held for Document Update". Thank you.

Report New Errata