> On Mar 23, 2021, at 2:18 AM, Vasilenko Eduard <[email protected]>
> 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_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
