Found 3 records.

Status: Verified (1)

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

Note: This RFC has been obsoleted by RFC 9915

Source of RFC: dhc (int)

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 by RFC 9915

Source of RFC: dhc (int)

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