> On Nov 13, 2019, at 8:34 PM, Manoj Nayak <[email protected]> wrote:
>
> Hello Joe,
>
> Please find my reply.
>
>>> - why does this doc assume the max ICMP is 576?
>>> we?re still talking IPv4 here; it?s still 68 (that?s why only 64 bits
>>> of the orig payload are guaranteed)
>>> (yes, your note in the end of sec 1 is relevant, but given v4-in-v4
>>> tunneling, it?s possible that
>>> paths might be smaller than the 576 assumption)
>
> We use an unused field in first 8 bytes of ICMP error/reply message.
Please explain. Most ICMP messages have 4 bytes of unused field, but not all
(one has only 3).
> How the idea would be
> affected if minimum packet size is 68 bytes or 576 bytes. As per my
> understanding,
> existing ICMP error/reply message works in v4-in-v4 tunnelling, so it would
> continue to
> work with the idea proposed in our draft. we won’t let the ICMP message
> exceed a reasonable size.
> in our implementation, that will be 576.
Sending the largest response possible given an untunneled MTU size is an
invitation to black-hole the response itself if (when) an IPv4-in-IPv4 tunnel
is encountered.
In most situations, ICMP responses are received from small initial messages
that don’t stress that limit. The use in this doc is the opposite - it relies
on ongoing use of ICMP for max-sized packets and returns max-sized payloads.
This isn’t helpful. It would be more useful to try to limit the size to the
minimum expected to be useful and account for these other encapsulations.
>
>>> - why would this approach find the largest fragment through a system?
>>> rfc1812 talks about various strategies, one of which is ?equal sized?,
>>> which might never find
>>> the max the way you propose
>
>
> As per section 4.2.2.7 from rfc 1812,
>
> “There are several fragmentation techniques in common use in the
> Internet. One involves splitting the IP datagram into IP
> fragments with the first being MTU sized, and the others being
> approximately the same size, smaller than the MTU. “
>
> In both of the above cases, idea in our draft works.
The issue is further down in that section:
One other fragmentation technique discussed was splitting the IP
datagram into approximately equal sized IP fragments, with the
size less than or equal to the next hop network's MTU. ...
In that case, none of the fragments gives you the path MTU.
Joe_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
