There are some issues with the doc:
- abstract has a typo, doc uses ’node’ where it should use ‘router’ for
on-path frag, etc
- discussion should to be more specific with respect to RFCs 1122, 792,
and 4821
- the overall problem is assumed but never clearly defined
I agree with Michael Richardson’s post of 8-16-22 on a few points:
1) it is premature for a TSV ART review of this document
I’m not actually sure that TSV review is relevant, as tunneling
is more an INTDIR issue (on which I do not sit),
though I’m probably at least as appropriate a reviewer on
tunnel issues
2) this discussion is confusing as to both aspects and terminology of
tunneling
I encourage those interested review draft-intarea-tunnels -
while expired
(I’m getting back to it), it remains definitive in the IETF
AFAICT
The stated point of this work, rephrased, is to have the IPsec tunnel egress
tell the IPsec tunnel ingress that the (next hop) link MTU out of the egress
(i.e., after traffic exits the tunnel) is too small for the packets the egress
node tries to forward.
So it tells the tunnel ingress that the egress link MTU is too small. But that
MTU is of the origin packet (not the tunnel packet, which includes the source
packet as a paylaad), which the tunnel ingress has no control over.
I.e., this isn’t a signal from the egress to the ingress about the tunnel
(path) MTU. Even if it were, then the tunnel ingress would be sending more
fragments (at the tunnel ingress by source-fragmented at the outer header); it
can’t change the MTU of the origin packets it happens to receive — that happens
at the packet origin, which can be upstream of the ingress, or at a minimum is
outside the scope of IPsec (even if the ingress and packet origin are a the
same node).
What exactly is this a solution for?
Joe
—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
