ICMPv6 Errors for Discarding Packets Due to Processing Limits
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: The IESG <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Bob Hinden <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Protocol Action: 'ICMPv6 errors for discarding packets due to processing limits' to Proposed Standard (draft-ietf-6man-icmp-limits-08.txt) The IESG has approved the following document: - 'ICMPv6 errors for discarding packets due to processing limits' (draft-ietf-6man-icmp-limits-08.txt) as Proposed Standard This document is the product of the IPv6 Maintenance Working Group. The IESG contact persons are Éric Vyncke and Suresh Krishnan. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/
Technical Summary Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication so it cannot take action to address the cause of discarded packets. This specification defines several new ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may be able to modify what it sends in future packets to avoid subsequent packet discards. Working Group Summary This document had good w.g. review, was discussed at several face to face 6man sessions and on the list. The chairs also did individual reviews. This found one important issue with the use of RFC4884. This is fixed in the current draft. Document Quality No known implementations. Difficult to implement until the IANA code points have been assigned. Issues raised in reviews have been resolved in current draft. Personnel The Document Shepherd is Bob Hinden. The Responsible Area Director is Suresh Krishnan.
RFC Editor Note OLD: Per [RFC8200], except for Hop by Hop options, extension headers are not examined or processed by intermediate nodes. Many intermediate nodes, however, do examine extension headers for various purposes. NEW: Per [RFC8200], except for Hop by Hop options, extension headers are not examined or processed by intermediate nodes. However, in deployed networks many intermediate nodes do examine extension headers for various purposes.