Hop Limit 8-bit unsigned integer. Decremented by 1 by
each node that forwards the packet. The packet
is discarded if Hop Limit is decremented to
zero.

It should say:

TBD

Notes:

The original text overlooks the case that a node receives a packet which already has a hop limit of zero (eg, coming from a misbehaving node, or malicious traffic). Following the instructions in that case would result in decrementing the hop limit from 0 to -1 (so, 255), then forwarding the packet.

The text also doesn't state what a non-forwarding node (ie, a host) should do upon reception of a packet which already has a hop limit of zero: should the packet be accepted or dropped?

* While the above issues are worth discussing, they are beyond the scope of an erratum. Discussion on updating the text to handle Hop Limits from malicious or misbehaving nodes should be taken up within the working group. *

In response to an IPv6 packet that is sent to an IPv4 destination
(i.e., a packet that undergoes translation from IPv6 to IPv4), the
originating IPv6 node may receive an ICMP Packet Too Big message
reporting a Next-Hop MTU less than 1280. In that case, the IPv6 node
is not required to reduce the size of subsequent packets to less than
1280, but must include a Fragment header in those packets so that the
IPv6-to-IPv4 translating router can obtain a suitable Identification
value to use in resulting IPv4 fragments. Note that this means the
payload may have to be reduced to 1232 octets (1280 minus 40 for the
IPv6 header and 8 for the Fragment header), and smaller still if
additional extension headers are used.

It should say:

(delete paragraph)

Notes:

This requirement makes it impossible to offer services over IPv6 without keeping per-flow state in the server node. There is no reason why IPv4 fragmentation cannot be used after translation to IPv4.
--VERIFIER NOTES--
This would be a fundamental change to the IPv6 protocol specification. Such a proposal would need to be formally proposed as an internet draft.