RE: New Version Notification for draft-herbert-6man-icmp-limits-01.txt

Mark,

Strictly speaking, Destination Unreachable is appropriate whenever a packet is discarded for any reason other than congestion. But according to that reasoning, you don't need an ICMP Packet Too Big message. The PTB error could be reported  by Destination Unreachable message with a PTB error code.

In reality, we need the ICMP PTB message because of its special status. That is, people know that they MUST NOT filter ICMP PTB's because filtering may cause black-holing. I am thinking that Header Too Long (HTL)  is akin to PTB. If HTL information hitchhikes on an existing ICMP message, that message should probably be PTB.

But then again, a new ICMP message may be required.

                                                                   Ron

> -----Original Message-----
> From: Mark Smith [mailto:markzzzsmith@gmail.com]
> Sent: Sunday, May 21, 2017 12:29 AM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: Tom Herbert <tom@herbertland.com>; 6man@ietf.org
> Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-
> 01.txt
> 
> On 21 May 2017 at 01:49, Ron Bonica <rbonica@juniper.net> wrote:
> > Hi Tom,
> >
> > Destination Unreachable isn't appropriate because the destination *is*
> reachable. The problem is that the header is too long.
> 
> It seems a DU is appropriate, going by what RFC4443 says, because the cause
> of the failure isn't congestion:
> 
> 
> "A Destination Unreachable message SHOULD be generated by a router, or
>    by the IPv6 layer in the originating node, in response to a packet
>    that cannot be delivered to its destination address for reasons other
>    than congestion.  (An ICMPv6 message MUST NOT be generated if a
>    packet is dropped due to congestion.)"
> 
> 
> (I looked it up because this discussion made me curious if a DA - Admin
> prohibited was making a positive confirmation of the destination's existence,
> and the prohibition was on being able to reach it. It seems not, which is
> better for security.)
> 
> Regards,
> Mark.
> 
> 
> 
> >
> > It seems like we are identifying an new constraint, the Path Maximum
> Header Length (PMHL). In some respects, PMHL is similar to PMTU. When
> PMTU is violated, we send an ICMP PTB to the source IP stack. The source IP
> modifies its estimate of the PMTU, informs upper layers (if appropriate) and
> fragments subsequent packets (if appropriate).
> >
> > What should happen when PMHL is violated? Does the source IP stack
> need to be informed? If so, what will the source IP stack do with the
> information? Or is really an upper layer application that needs to be
> informed?
> >
> >
> > Ron
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Tom Herbert [mailto:tom@herbertland.com]
> >> Sent: Thursday, May 18, 2017 4:51 PM
> >> To: Ron Bonica <rbonica@juniper.net>
> >> Cc: 6man@ietf.org
> >> Subject: Re: New Version Notification for
> >> draft-herbert-6man-icmp-limits- 01.txt
> >>
> >> On Wed, May 17, 2017 at 6:03 PM, Ron Bonica <rbonica@juniper.net>
> wrote:
> >> > Tom,
> >> >
> >> > The ICMP Parameter Problem message normally indicates that there is
> >> > a
> >> problem with an IP Parameter. In the example below, you use it to
> >> indicate that a middle box has a problem with the IP payload. This
> >> seems to be overloading the Parameter Problem message.
> >> >
> >> Hi Ron,
> >>
> >> Would Destination Unreachable message be appropriate then?
> >>
> >> Tom
> >>
> >> >
> >> > Ron
> >> >
> >> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------