Hello Joe, Section 5 of the below RFC talks about the way to relay MTU size to sender if ipv4-to-ipv4 tunnel is there in the path from sender to destination.
There are two cases here. 1. Destination is outside tunnel. 2. Destination is tunnel end point. When destination is tunnel end point then MTU size is returned to sender using soft state maintained at tunnel entry point. https://tools.ietf.org/html/rfc2003 5<https://tools.ietf.org/html/rfc2003#section-5>. Tunnel Management Unfortunately, ICMP only requires IP routers to return 8 octets (64 bits) of the datagram beyond the IP header. This is not enough to include a copy of the encapsulated (inner) IP header, so it is not always possible for the encapsulator to relay the ICMP message from the interior of a tunnel back to the original sender. However, by carefully maintaining "soft state" about tunnels into which it sends, the encapsulator can return accurate ICMP messages to the original sender in most cases. The encapsulator SHOULD maintain at least the following soft state information about each tunnel: - MTU of the tunnel (Section 5.1<https://tools.ietf.org/html/rfc2003#section-5.1>) - TTL (path length) of the tunnel - Reachability of the end of the tunnel Regards Manoj Nayak From: Joe Touch <[email protected]> Date: Friday, 15 November 2019 at 8:20 PM To: Manoj Nayak <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt On Nov 13, 2019, at 8:34 PM, Manoj Nayak <[email protected]<mailto:[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
