Subject: I-D Action: draft-ietf-6man-icmp-limits-05.txt

From: [email-masked]
Date: Tue, 10 Sep 2019 10:39:01 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance WG of the IETF.

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

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-icmp-limits/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-6man-icmp-limits-05
https://datatracker.ietf.org/doc/html/draft-ietf-6man-icmp-limits-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-icmp-limits-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tom Herbert <[email-masked]>
Date: Tue, 10 Sep 2019 10:47:28 -0700

Hello,

I've submitted this draft to address the comments in the chairs' review.

Thanks,
Tom

On Tue, Sep 10, 2019 at 10:40 AM <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Tue, 17 Sep 2019 13:21:15 -0700

Tom,

I took a look at the new draft.  Thanks for fixing most of the issues I raised.  Much better.

I think there is still an issue with Section 3 that defines a new code point for the Destination unreachable message.

RFC4884 Section 4.4 "ICMPv6 Destination Unreachable” in the header format includes:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    As much of invoking packet                 |
     +                as possible without the ICMPv6 packet          +
     |                exceeding the minimum IPv6 MTU [RFC4443]       |

but in draft-ietf-6man-icmp-limits-05 shows:

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M
  |                       Original Datagram                       | P
  ~     Internet Header + leading octets of original datagram     ~ |
  |                                                               | |

This is a change from RFC4884.  Further, the draft has:

     Original Datagram
        As much of invoking packet as possible without exceeding the
        minimum ICMPv6 packet minus twelve bytes (for the ICMP
        extension structure and the ICMP extension object) and any
        necessary padding. The Original Datagram field MUST be zero
        padded to the nearest 64-bit boundary [RFC4884]. If the
        original datagram did not contain 128 octets, the Original
        Datagram field MUST be zero padded to 128 octets.

I can’t find anything in RFC4884 that says to reduce the size of the original datagram to allow the extensions to fit.   This is a change from what RFC4884 specifies.    RFC4884 specifically says:

   The syntax and semantics of all fields are unchanged from RFC 4443.
   However, a length attribute is added to the second word.  The length
   attribute represents length of the padded "original datagram" field,
   measured in 64-bit words.

I think this change to RFC4884 is out of scope for a document that wants to define a new code point.

I think a possible solution (beside not changing the RFC4884 format) is to say the new extensions can only be sent with packets that don’t exceed the minimum IPv6 MTU.   Or else, add a code point to the Parameter Problem as Ron suggested, even though it’s not idea for the reasons you pointed out.

Bob

> On Sep 10, 2019, at 10:47 AM, Tom Herbert <[email-masked]> wrote:
> 
> Hello,
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 20 Sep 2019 13:46:08 -0700

> RFC4884 Section 4.4 "ICMPv6 Destination Unreachable” in the header format includes:
Bob,

Looking at it, I think the text in RFC4884 is  sufficient:  "As much
of invoking packet as possible without the ICMPv6 packet exceeding the
minimum IPv6 MTU [RFC4443]. That implicitly accounts for any ICMP
extension or padding to keep the whole ICMP packet within minimum MTU.

I propose text which should clarify and be consistent with RFC4884 and RFC4443.

The diagram would have description same as RFC4884:

Text for the field description would be:

     Original Datagram
        As much of invoking packet as possible without the ICMPv6
packet exceeding the minimum IPv6 MTU [RFC4443]. The Original Datagram
field MUST be zero padded to the nearest 64-bit boundary [RFC4884]. If
the original datagram did not contain 128 octets, the Original
Datagram field MUST be zero padded to 128 octets.

Tom

---

From: Ole Troan <[email-masked]>
Date: Mon, 23 Sep 2019 11:24:14 +0200

Hi Tom,

The new draft looks good.
I read through the whole document again, and I ended up finding myself unclear of a couple of points:

- when is the destination unreachable "ICMPv6 error for aggregate header limits" used versus e.g. the "parameter problem, extenshion header chain too long"?
- what is the logic that determines when a parameter problem type versus a destination unreachable type is used?

Best regards,
Ole

> On 10 Sep 2019, at 19:39, [email-masked] wrote:
> 
>