Re: [Int-area] Proxy function for PTB messages on the tunnel end

[Joseph Touch <[e-mail]>]

> On Mar 23, 2021, at 2:18 AM, Vasilenko Eduard <[e-mail]> wrote:
> 
> Hi Joseph,
> I still do not understand why you believe that any tunnel has a second MTU restriction now.

All tunnels - like all links, have both:
	- a largest message that can traverse the internal hops of that link
	- a largest message that can be reassembled at the egress of that link

These are generally referred to as “path MTU” and “EMTU_R” for IP.

> The rest of your logic is based on this assumption that I do understand how you come to it. But the rest does not make sense to discuss if the initial assumption is not right.
> 1.       It could not be the case for tunneling that does not support fragmentation (L2TPv3, MPLS, VxLAN). Fragmentation buffer is just not needed in principle. Second restriction is not needed in principle.

That’s just the case where pathMTU == EMTU_R.

That means the EMTU_R is not needed *in practice*, but in principle it still exists.

> 2.       Reassembly buffer is needed for tunneling that does support fragmentation (NVO3, IPv6 GRE). But under no circumstances it should have any relationship to EMTU_R developed for TCP stack on the host. Vendors have chosen this fragmentation buffer always much bigger than maximum MTU for not to have another reason for fragmentation.

EMTU_R is the IP reassembly buffer, as defined in RFC1122; it is not developed for TCP.

Vendors (and protocol designers) set EMTU_R > pathMTU so that fragmentation allows recursive tunneling (IPv4-in-IPv4, IPv6-in-IPv6). If they are equal, then you can never have direct recursive tunneling (you need a shim layer that creates a separate tunnel with fragmentation and reassembly).

For IPv4, min EMTU_R is 576 and min pathMTU is 68.
For IPv6, min EMTU_R is 1500 and min pathMTU is 1500.

These are different for a reason.

> That’s it – no second MTU restriction to pay attention to. It is the reason why this is not documented in any vendor’s documentation: no problem – no need to document.

RFC791 and RFC 2460 (and 8200) all define these.

> But you have assumed that vendors did always have fragmentation buffer with limited size related to EMTU_R. It is just not the case. Data Plane has no TCP stack to inherit TCP restrictions.

EMTU_R is the end-of-path reassembly. Vendors all implement this for packets terminating at routers. Vendors should (MUST) also implement this for tunnels that egress at the router; some do, some have an *implementation error* if they do not.

> Again: the current standards and implementations have only 1 MTU restriction per tunnel.

Any tunnel where pathMTU == EMTU_R cannot be used to tunnel over itself. That is a standards and implementation flaw, not a feature.

> It does permit to inform the host about oversized packets (by PTB).

PTB means only “I *cannot* deliver packets this big”, not “if you send me packets that are smaller, I won’t have to fragment them over tunnels. If you can fragment over tunnels, you CAN deliver packets that big and sending PTB would be incorrect.

> draft-ietf-intarea-tunnels proposes new solutions with 2 MTU restrictions per tunnel (small/restricted reassembly buffer size and MTU on the tunnel path) that pushes for fragmentation between these restrictions.

Draft-tunnels describes what already exists, in terms that allow us to have conversations about these properties.

It describes how current ICMP messages are insufficient to support your tunneling concerns. 

Joe