Protocol Action: 'ICMPv6 errors for discarding packets due to processing limits' to Proposed Standard (draft-ietf-6man-icmp-limits-08.txt)

The IESG <iesg-secretary@ietf.org> Mon, 23 March 2020 21:01 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EFB3A0EBF; Mon, 23 Mar 2020 14:01:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'ICMPv6 errors for discarding packets due to processing limits' to Proposed Standard (draft-ietf-6man-icmp-limits-08.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.122.0
Auto-Submitted: auto-generated
Precedence: bulk
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
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Message-ID: <158499726139.2032.12306188378887421138@ietfa.amsl.com>
Date: Mon, 23 Mar 2020 14:01:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/gvWmr0dBIvxcd0nQD3KhvzggqME>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2020 21:01:02 -0000

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.