Two points:
> On Mar 24, 2021, at 7:59 AM, Vasilenko Eduard <[email protected]>
> wrote:
>
> It would invalidate all tunneling implementations. It is not compatible with
> any one of them. PMTUD is killed. Revolution.
PMTUD is effectively dead, so if you’re worried about it, you’re 20+ years too
late - as per the RFCs I’ve already cited.
> All complaints against RFC 2473 are minor (if right),
> Except this one that is definitely wrong:
> o Tunnel ingress issues ICMPs
> This is a violation of RFC792 and 8200; the ICMPs issued are that of routers,
> not links. If the ingress is at the source host, these ICMPs would come from
> a device that is not a router.
> ICMP PTB is very important to deliver to the traffic source.
I’m saying something very specific:
- tunnels are links
- links NEVER *genenerate* ICMPs
- routers and hosts *generate* ICMPs
based on what happens inside them, e.g,, to their processes and
links
So the question is “under what conditions does a link cause a router/host to
generate an ICMP?”
There should be no unsolicited ICMPs, i.e., routers/hosts NEVER generate ICMPs
unless in reaction to a packet being sent or received.
PTB means “I cannot send the packet over this link”. Not path - link. There is
no PTB for a path; the assumption is that one link of a path that fails will
send the ICMPs back to the source.
For a tunnel, when can it NOT send a packet?
- only when that packet is larger than the tunnel EMTU_R (i.e., egress
received max, reassembled if reassembly is supported)
A packet that can be fragmented and traverse a tunnel is not too big. It’s
“bigger than you might like” or “bigger than desired”, but there is no ICMP to
indicate that sort of ‘soft’ (non failure) error.
So what should happen:
- tunnels ingress should know and update (if changing) the tunnel
EMTU_R value
- routers/hosts should use EMTU_R as the tunnel MTU
again, because the tunnel path MTU is a preference; the tunnel
EMTU_R is the actual strict limit
- routers/hosts sending packets over a tunnel generate ICMP PTBs as
needed
again, the router/host generates the message, not the tunnel
ingress
this happens when the router/host tries to send a packet over
out that tunnel interface that is larger than the tunnel MTU
So this all works, as long as ICMPs are relayed.
Draft-tunnels does not deprecate this behavior. It describes it and explains
why this is the correct behavior.
Tunnel ingresses that relay PTBs inside are broken; they fail in ways they do
not need to. That is the true error.
Joe_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
