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

[Tom Herbert <[e-mail]>]

On Tue, May 16, 2017 at 9:52 AM, Ron Bonica <[e-mail]> wrote:
> Tom,
>
> I was confused before reading your response. Now I a profoundly confused :-/
>
> In your example, I think that the header stack looks like this:
>
> A) payload
>         3) data
>         2) TCP header (8 bytes)
>         1) IPv6 header (40 bytes)
> B) Geneve
>         3) Geneve header (260 bytes)
>         2) UDP Header (8 bytes)
>         1) IPv6 Header (40 bytes)
>
>
> It doesn't contain any IPv6 extension headers at all. A transit router, acting  as a middlebox, needs to see the TCP header, but can't because the TCP header is 340 bytes into the packet. So, we send an ICMPv6 Parameter Problem.
>
> Do I have that much right?
>
Yes, that is correct. Looking at the definition of Parameter Problem
in RFC1122 it seems the use here is okay even though the problem might
not specifically be about  IP layer.

Tom

>                                                                                       Ron
>
>
>> -----Original Message-----
>> From: Tom Herbert [mailto:[e-mail]]
>> Sent: Monday, May 15, 2017 5:28 PM
>> To: Ron Bonica <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: New Version Notification for draft-herbert-6man-icmp-limits-
>> 01.txt
>>
>> On Mon, May 15, 2017 at 10:53 AM, Ron Bonica <[e-mail]>
>> wrote:
>> > Tom,
>> >
>> > I may be parsing your response incorrectly.. Can you provide an example
>> where encapsulations elicit a Headers Too Long error code?
>>
>> It would be the case because of encapsulation a device is unable to parse the
>> headers it wants (typically would be down to transport headers). For
>> instance in Geneve, the maximum header length is 260 bytes. Adding UDP
>> outer header and using it for IPv6/IPv6 encapsulation gets the headers
>> before the inner transport header up to
>> 348 bytes. That in itself may exceed a parsing buffer. A few more extension
>> headers, SFC, or nested encapsulation could push the headers over 512
>> bytes that would probably exceed the parsing buffer sizes of many devices.
>> So The Headers Too Long could be sent in this case.
>> Implementing a fallback might be hard since there may be multiple sources
>> of the headers, but at least this might give some visibility to packet drops
>> happening.
>>
>> Tom
>>
>> >
>> >
>> > Ron
>> >
>> >>
>> >> > 2) Same comment for Sections 3.3 and 3.4
>> >> > 3) I'm not sure that I get the difference between Extension Header
>> >> > Chain
>> >> Too Long (Section 3.3) and Headers Too Long (Section 3.5). Are you
>> >> saying that there is a case where 3.5 will be true and 3.3 will be false?
>> >>
>> >> Headers too long could be caused by and reference encapsulation
>> >> headers as the culprit, it's not specific to extension headers.
>> >>
>> >