Found 3 records.

Status: Verified (1)

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

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

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