ICMPv6 Errors for Discarding Packets Due to Processing Limits
draft-ietf-6man-icmp-limits-08

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, bob.hinden@gmail.com, suresh@kaloom.com, Bob Hinden <bob.hinden@gmail.com>, rfc-editor@rfc-editor.org, 6man-chairs@ietf.org, draft-ietf-6man-icmp-limits@ietf.org, ipv6@ietf.org
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/

Ballot Text

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

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.