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

[Tom Herbert <[e-mail]>]

On Tue, Sep 17, 2019 at 1:21 PM Bob Hinden <[e-mail]> wrote:
>
> 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.
>
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:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      +                as possible without the ICMPv6 packet          +
      |                exceeding the minimum IPv6 MTU [RFC4443]       |

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

> 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 <[e-mail]> wrote:
> >
> > 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 <[e-mail]> wrote:
> >>
> >>
> >> 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/
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>