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