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

[Ballot comment]
Thanks for addressing my Discuss and Comment points!

I suggest to additionally apply Alissa's suggestion in Section 1.1:

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.

[Ballot comment]
Hi,

thank you for this document

I'm only reporting nits I found here and there:
s/specification is provide/specification is to provide/
s/may used/may be used/

[Ballot comment]
One nit, at the top of page 5: s/applicably/applicability

I also urge that the document is updated prior to approval to address Bernard's TSVART review comment.

[Ballot comment]
Question(s):

In section 1 you say " New ICMPv6 code points are defined as an update to [RFC4443]."
Should this document actually update RFC4443?

And in section 2.2 you have:
"  [RFC8200] specifies that a destination host should send an
  "unrecognized next header type" when a Next Header value is
  unrecognized in a packet. This document extends this to allow
  intermediate nodes to send this same error for a packet that is
  discarded because the node does not recognize a Next Header type."
Does this document also update RFC8200?

Comment(s):

Editorial in Sec 5.3.1:
"      * Increasing prevalence of deep packet inspection in middleboxes.
        In particular, many intermediate nodes now parse network layer
        encapsulation protocols or transport layer protocols."
This sounds like DPI is a reason for longer headers but I think you only mean DPI is a reason for in-network processing. Maybe you can clarify this!


Also I agree with Roman's points and the TSV-ART feedback (Thanks Bernard!) that the security considerations section could be a bit more extensive and a mentioning of PMTU discovery would be good as well. I saw that there was a reply by the author to the TSV-ART review on March 5 but no updates submitted yet.

[Ballot discuss]
I recognize that this document is trying to take the track of "we
recognize that some implementations/deployments violate RFC 8200, and
while we don't condone that behavior, we want to provide diagnostics to
try to mitigate the fallout from them", but I'm not sure it succeeds in
all cases.  The discussion in Section 5.1 that is quite clear about
"does not advocate behaviors that might be considered nonconformant",
but there is another usage in Section 2.2 ("[t]his code SHOULD be sent by
an intermediate node that discards a packet because it encounters a Next
Header type that is unknown in its examination") that seems worth
revisiting.  Perhaps we can reword to be more clear that this is the
recommended behavior subject to the predicate that an RFC 8200 violation
has occurred, which is not itself a recommended behavior.

In light of the updated usage described in Section 2.2, should we direct
IANA to make the "Reference" column for the "unrecognized Next Header
type encountered" parameter problem list both this document and RFC
4443?  (It currently does not list any reference, as is the case for
many entries on the containing page...)
This codepoint is not currently mentioned in the IANA Considerations at
all

[Ballot comment]
I agree with Alissa's COMMENT.

The [IANA-ICMPV6] reference is used as reference for both the "parameter
problem" and the "destination unreachable" codes, but the link points
specifically to the "destination unreachable" table at present.  (My
understanding is that IANA likes the URL fragment to be stripped from
the final RFC, in which case the distinction becomes moot.)

Can you help me walk through the various places where we discuss the
cardinality of new registered values, to ensure that we're internally
consistent?
The Abstract just says "several new ICMPv6 errors", nice and vague;
clearly fine.
Section 1 says "five of the errors are specific to processing of
extension headers; another error is used when [...]".  Are the "five"
the five "parameter problem" codepoints that we list, or the four new
"parameter problem" codepoints plus the one new "destination
unreachable" codepoint?  If the former, we are calling "unrecognized
next header type" a "new ICMPv6 code point", which is not exactly true.
Section 1.1 says "four parameter problem codes and extends the
applicability of an existing code".  It seems pretty clear that the four
are the new ones and the one is "unrecognized next header", so this is
fine.
Section 1.2 talks about the one "destination unreachable" code; which
seems okay on its own.  Maybe we want to check for parallelism in how,
e.g., Section 1's high-level overview discusses it vs. the other
allocations.
There doesn't seem to be an introduction subsection that mentions the
extended object class and subtype used for aggregate header limits,
which might be useful to have.

Section 1

  limits. New ICMPv6 code points are defined as an update to [RFC4443].

I suggest phrasing this as "to supplement those defined in [RFC4443]"
since we're just allocating from a registry and are not marking this
document with an "Updates: 4443" header.

Section 1.3

Please use the BCP 14 boilerplate from RFC 8174.

Section 2.1

        The pointer will point beyond the end of the ICMPv6 packet if
        the field having a problem is beyond what can fit in the
        maximum size of an ICMPv6 error message.

I understand that we're just reusing the RFC 4443 format for "parameter
problem" messages, but I'd suggest adding a note that recipients
should/MUST sanity-check the pointer value [perhaps with specifics].

Section 2.2

  This code SHOULD be sent by an intermediate node that discards a
  packet because it encounters a Next Header type that is unknown in
  its examination. The ICMPv6 Pointer field is set to the offset of the

To what extent is this diverging from the RFC 8200 dictum that extension
headers not be examined or processed by intermediate nodes?

  Note that when the original sender receives the ICMPv6 error it can
  differentiate between the message being sent by a destination host,
  per [RFC4443], and an error sent by an intermediate host based on
  matching the source address of the ICMPv6 packet and the destination
  address of the packet in the ICMPv6 data.

This is, of course, true only in the face of honest participants; there
is no cryptographic protection on ICMP packets so spoofing is trivial,
potentially even from off path(?).  (As RFC 4443 notes, IPsec AH helps.)

Section 2.4

  There are two different limits that might be applied: a limit on the
  total size in octets of the header chain, and a limit on the number
  of extension headers in the chain. This error code is used in both
  cases. In the case that the size limit is exceeded, the ICMPv6
  Pointer is set to first octet beyond the limit. In the case that the
  number of extension headers is exceeded, the ICMPv6 Pointer is set to
  the offset of first octet of the first extension header that is
  beyond the limit.

Do we want to mention the potential ambiguity when the size limit
happens to align with the first octet of an extension header?

Section 2.6

      * The length of a PADN options in destination options or hop-by-
        hop options is limited seven octets [RFC8504].

nit: some singular/plural mismatch here, and probably "limited to".

Section 4.1

I appreciate the thought that went into the priority of reporting list;
thanks for it!

Section 6

It's probably worth reiterating that applications that change their
behavior in response to unauthenticated ICMP messages without proper
message validation are susceptible to an attacker in the network forcing
them into a certain configuration.  When such a configuration is a
vulnerable one, that is an easy way for the attacker to escalate an
attack.

What does it mean for something to "conceptually be exploited for denial
of service attack"?

I see that RFC 4443 recommends that upper layers receiving ICMP messages
"perform some form of validation" upon them, but a brief read does not
seem to find it suggesting that, say, application-level traffic and ACKs
continuing to flow are an indication that ICMP messages indicating
failure to deliver packets are inaccurate; is that worth revisiting?

Section 9.1

RFC 7045 is referenced only once, and in a capacity that appears solely
informative.

Section 9.2

On the other hand, RFC 4890 is the target of an allegedly normative
"MAY" (which may, in fact, more properly be written as a descriptive
"may"), which would normally require it to be listed in the normative
references section.

[Ballot comment]
** Section 2.1.  As discussed in response to Bernard Aboba’s TSVART feedback on “The pointer will point beyond the end of the ICMPv6 packet if the field having a problem is beyond what can fit in the maximum size of an ICMPv6 error message.” please add caution about not de-referencing this pointer.  The same caution applies to Section 3.1.

** Section 5.2. Duplicate word.  s/to to/to/

** Section 6.  Per “In some circumstances, the sending of ICMP errors might conceptually be exploited for denial of service attack or as a means to covertly deduce processing capabilities of nodes”, one could conceivably conduct various active fingerprinting to determine more than just processing capabilities of nodes (say, device or OS identification) and perhaps also infer the middleboxes fielded in-path too.

[Ballot comment]
Please incorporate the edits from the Gen-ART review.

== Section 1.1 ==

"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 header for various purposes."

This is slightly confusing. I think it would be better to say:

"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."

[Ballot comment]
(1) There are a couple of normative statements that left me wanting more details.  For the cases below, I have these questions (to start with):  Are there more details on how this is done?  Are the actions implementation dependent?  Should these sentences even use rfc2119 keywords?  How can they be normatively enforced?

  - §4.2: "The packet in the ICMP data SHOULD be validated to match the upper
  layer process or connection that generated the original packet."  What if
  the validation fails?

  - §4.2: "A host MAY modify its usage of protocol headers in subsequent
  packets to avoid repeated occurrences of the same error."

  - §4.2: "A host system SHOULD take appropriate action if it is creating
  packets with extension headers on behalf of the application."  What is an
  "appropriate action"? 


(2) §4.2: "An error SHOULD be reported to an application if the application enabled extension headers for its traffic."

What is an application in the context of this document?  I ask because traditional applications (email, video) are probably not aware of the use (or not) of extensions headers in their traffic -- but others (segment routing, for example) probably are. 


(3) §5.1: "...this specification RECOMMENDS the sending of ICMP errors even in cases where a node might be discarding packets per a nonconformant behavior."  Recommending conformance when nonconformant behavior already exists sounds a little naïve to me.  It seems to me that using a lower case "RECOMMENDS" (BTW, the actual keyword is "RECOMMENDED".) would achieve the same thing.


(4) §6: "The ICMP errors described in this document MAY be filtered by firewalls in accordance with [RFC4890]."  s/MAY/may  In this case the text is just making a statement of fact.

 
(5) Consider moving §5 closer to the beginning of the document.  Maybe it makes more sense there.

[Ballot comment]
The correct intended status in the header is “Proposed Standard”.

— Abstract —

  Network nodes may discard packets if they are unable to process
  protocol headers of packets due to processing constraints or limits.

May they discard packets if they are unable to process protocol headers of *other* packets?  Or are you talking about the protocol headers of the packets being discarded?  The latter, yes?  So, “if they are unable to process those packets’ protocol headers” (or “of those packets”).

  When such packets are dropped, the sender receives no indication so
  it cannot take action to address the cause of discarded packets.

This sounds like the reason it receives no indication is to prevent it from taking action. I would say, “receives no indication, thus it cannot”.

— Section 1 —

  New ICMPv6 code points are defined as an update to [RFC4443].

The document header does not say that this “updates” 4443.  Do you maybe mean “as an extension to RFC4443”?

— Section 1.1 —
RFC 8200 does not capitalize “extension header” nor “upper-layer header”; is there a reason you do in this document?  Shouldn’t this be consistent with 8200?

— Section 1.3 —
Éric already got this: Please use the new BCP 14 boilerplate and add a normative reference to RFC8174.

— Section 3.2 —

        This error is sent in response to a node dropping a packet
        because the aggregate header chain exceeds the processing
        limits of a node.

I’m confused, so maybe I just am not understanding:  this says that Destination Unreachable / headers too long is sent *not* by the note that dropped the packet, but *in response* to that node?  What an I missing?  Should this maybe say this instead?:

NEW
        This error response is sent when a node drops a packet
        because the aggregate header chain exceeds the processing
        limits of the node.
END

[Ballot comment]
Tom,

Thank you for the work put into this document. It is short and easy to read while addressing a real problem in real deployments.

********************
*  I was about to add a DISCUSS for not using the right BCP14 RFC 8174 template but please FIX this
*      (as this is the first review, I would suggest to issue today a revised I-D with just this fix
*      before other IESG reviews).
* 
*  I was also about to ballot a DISCUSS on the comment in section 2.4...
*******************

Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.2 --
Just wondering why the "aggregate header limits" has a section on its own. Feel free to keep it like it is but this looks weird.

-- Section 2 --
Strongly suggest to use TBA1, TBA2, ... in order to avoid mistakes done by the IANA.

-- Section 2.2 --
Why not using a new code for 'unrecognized header' by intermediate node ? I really wonder why: it can only be confusing to existing implementation.

Please also ensure what is meant by 'destination' here... I would prefer to avoid discussions when a routing-header is used (too many discussions around this in 6MAN already)

-- Section 2.4 --
How can the original source distinguish among the two potential causes ? Why not using two code points?
Or am I missing something obvious? I was really about to issue a blocking DISCUSS on this one.

-- Section 3 --
Some justifications on why using a different ICMPv6 format would really help the reader.

-- Section 4.1 --
The wording "1) Real error (existing codes)" looks weird because the code points in this documents will also be existing. Why not using "1) RFC 4443 error codes" ?

-- Section 5.2 --
Is applicable to RFC 4443 in general, so, I wonder why it is in this document.

== NITS ==

-- Section 1.1 --
If I was picky, then I would argue that "Extension Headers are placed between the IPv6 header and the Upper-Layer Header in a packet" is not always true: if Next-Header is 59 (No Next Header per RFC 8200 section 4.7) ;-)

-- Section 2.1 + 3.1--
s/IPv6 Fields:/IPv6 Header Fields:/

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-6man-icmp-limits-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Type 4 - Parameter Problem subregistry of the ICMPv6 "Code" Fields registry on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

https://www.iana.org/assignments/icmpv6-parameters/

four new registrations are to be made as follows:

Code: [ TBD-at-Registration ]
Name: Extension header too big
Reference: [ RFC-to-be ]

Code: [ TBD-at-Registration ]
Name: Extension header chain too long
Reference: [ RFC-to-be ]

Code: [ TBD-at-Registration ]
Name: Too many options in extension header
Reference: [ RFC-to-be ]

Code: [ TBD-at-Registration ]
Name: Option too big
Reference: [ RFC-to-be ]

Second, in the Type 1 - Destination Unreachable sub-registry of the ICMPv6 "Code" Fields registry on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

https://www.iana.org/assignments/icmpv6-parameters/

a single registration is to be made as follows:

Code: [ TBD-at-Registration ]
Name: Headers too long
Reference: [ RFC-to-be ]

Third, in the ICMP Extension Object Classes and Class Sub-types registry on the Internet Control Message Protocol (ICMP) Parameters registry page located at:

https://www.iana.org/assignments/icmp-parameters/

a single, new registration is to be made as follows:

Class Value: [ TBD-at-Registration ]
Class Name: Extended information
Reference: [ RFC-to-be ]

Fourth, a new sub-registry is to be created in the ICMP Extension Object Classes and Class Sub-types registry on the Internet Control Message Protocol (ICMP) Parameters registry page located at:

https://www.iana.org/assignments/icmp-parameters/

The new registry will be named Sub-types -- Class [ TBD-at-Registration ] - Extended information - where [ TBD-at-Registration ] is set to be the same as the value used in action three above.

IANA Question --> what is the registration procedure for this new sub-registry?
RFC 4884 says that the registration procedure has to be named in the document.

There is a single, new registration in the new sub-registry as follows:

C-Type (Value): [ TBD-at-Registration ]
Description: Pointer
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-02-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-6man-icmp-limits@ietf.org, ipv6@ietf.org, bob.hinden@gmail.com, Bob Hinden , suresh@kaloom.com, 6man-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (ICMPv6 errors for discarding packets due to processing limits) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'ICMPv6 errors for discarding packets due
to processing limits'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-02-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/ballot/


No IPR declarations have been submitted directly on this I-D.

Title          : ICMPv6 errors for discarding packets due to processing limits
Author          : Tom Herbert
Filename        : draft-ietf-6man-icmp-limits-06.txt
Pages          : 16
Date            : 2019-09-24


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

  Standards track RFC, Proposed Standard.  It is creating new code
  points for ICMPv6, this is the correct status.  It is noted in the
  header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  Abstract

  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:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

  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:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  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:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Document Shepherd:  Bob Hinden
  Area Director:  Suresh Krishnan


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  Document Shepard did a review of the document that raised issues in
  two areas, how the IANA assignments were described, and the use of
  RFC4884 was being used.  These issue have been fixed in the current
  draft.  Document is ready to advance.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No.  The document is creating new ICMPv6 code points.  No new issues
  created.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No issues to raise.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  The author has confirmed this.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures.


(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

  Strong w.g. consensus.
 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  There were issues in the previous version, author did an update, now
  IDnits is clear.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  N/A


(13) Have all references within this document been identified as either
normative or informative?

  Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative references are RFCs or IANA assignments.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No.


(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

  No changes to other RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

  The document shepherd found several issues in this area, these have
  been fixed in the current draft.  IANA registries are clearly
  identified and what IANA is being asked to do is clear.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are created.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  N/A
 

Title          : ICMPv6 errors for discarding packets due to processing limits
Author          : Tom Herbert
Filename        : draft-ietf-6man-icmp-limits-06.txt
Pages          : 16
Date            : 2019-09-24


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

  Standards track RFC, Proposed Standard.  It is creating new code
  points for ICMPv6, this is the correct status.  It is noted in the
  header.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  Abstract

  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:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

  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:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  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:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Document Shepherd:  Bob Hinden
  Area Director:  Suresh Krishnan


(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  Document Shepard did a review of the document that raised issues in
  two areas, how the IANA assignments were described, and the use of
  RFC4884 was being used.  These issue have been fixed in the current
  draft.  Document is ready to advance.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

  No.  The document is creating new ICMPv6 code points.  No new issues
  created.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No issues to raise.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

  The author has confirmed this.


(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures.


(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

  Strong w.g. consensus.
 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  There were issues in the previous version, author did an update, now
  IDnits is clear.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  N/A


(13) Have all references within this document been identified as either
normative or informative?

  Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  All normative references are RFCs or IANA assignments.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No.


(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

  No changes to other RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 8126).

  The document shepherd found several issues in this area, these have
  been fixed in the current draft.  IANA registries are clearly
  identified and what IANA is being asked to do is clear.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are created.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  N/A