It would invalidate all tunneling implementations. It is not compatible with
any one of them. PMTUD is killed. Revolution.
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.
Ed/
From: Joseph Touch [mailto:[email protected]]
Sent: Wednesday, March 24, 2021 5:36 PM
To: Vasilenko Eduard <[email protected]>
Cc: [email protected]; int-area <[email protected]>
Subject: Re: Proxy function for PTB messages on the tunnel end
Hi, Eduard,
I’ll try to be brief because we’ve covered most of these issues before. We can
have an extended discussion off-list if needed.
Joe
On Mar 24, 2021, at 2:00 AM, Vasilenko Eduard
<[email protected]<mailto:[email protected]>> wrote:
Hi all,
I could not stop the discussion at this point, because I was incomplete in the
last message. I have missed to mention one important point.
The difference between how tunnel and end node operate is in 2 things:
1. The tunnel has an unlimited buffer that is not counted as the
restriction. It is assumed always as “big enough” by all vendors.
Neither the number nor the size of buffers used for tunneling can be unlimited.
“Assuming” otherwise is simply ignoring the issue, resulting in the tunnel
being a black-hole.
2. The incoming packet is not checked against the buffer size. It is
checked against the MTU of this virtual/tunnel interface.
Tunnels all implement source fragmentation and egress reassembly for IPv6. It
may not be readily visible to you, but it is there as a parameter of the
virtual tunnel interface on the ingress and egress.
As a consequence: PMTUD could correct interface MTU, then the next oversized
packet would inform (by PTB) the real traffic source. PMTUD works.
I’ve cited numerous RFCs that focus on why ICMP PTB cannot be relied upon,
i.e., that PMTUD does not work. You might assume it does work because when it
fails it creates a black hole, where packets are simply dropped and no errors
are received (because the ICMPs are filtered or simply not sent).
All of the above is broken by draft-ietf-intarea-tunnels:
1. Buffer is assumed small (1500 minus headers)
Draft-tunnels reports existing limits of IPv6 mandatory minimums. Individual
implementations can be larger but there is no mechanism to discover some of
those values (EMTU_R in particular, at the IP layer)
2. The incoming packet is checked against the buffer size, not the MTU of
the virtual interface
Incoming packets are checked at the receiver against receive buffer sizes. If
that receiver is a router and the packet is relayed, that packet is checked
against the MTU of the tunnel virtual interface during the process of
transmission (after encapsulation); it is there that it is source fragmented.
Note: if that latter step does not occur, as you assert, then PMTUD would fail.
3. No feedback is proposed between interface MTU and the buffer size
On this we agree.
As consequence: PMTUD could not propagate through such interface (PTB feedback
from inside the tunnel would not activate at some point the PTB feedback in the
traffic source direction). PMTUD is effectively finished intentionally.
That occurred nearly 20 years ago and was the motivation for RFC4821, again
because ICMPs are filtered.
Hence, the need for additional fragmentation for the case when the packet is
below buffer size, but above tunnel interface MTU.
Correct.
The market has lost RFC 2473 functionality: it did propose a PTB proxy to react
to the 1st PTB message from inside the tunnel.
But the market has at least a slow reaction: the second oversized packet would
inform traffic source (1st would be used to correct MTU on the virtual
interface).
I had the message in draft-vasilenko-v6ops-ipv6-oversized-analysis: let’s
return to the original functionality proposed by RFC 2473.
RFC2473 has numerous errors; draft-tunnels lists them in section 5.2. Here is
an annotated version of that text:
o IPv6 tunnels [RFC2473<https://tools.ietf.org/html/rfc2473>] -- IPv6 or
IPv4 in IPv6
o Treats tunnel MTU as tunnel path MTU, not tunnel egress MTU
Following RFC2473 prevents IPv6 over IPv6 when the tunnel is constrained to
IPv6 minimum path MTU.
o Decrements transiting packet hopcount (by 1)
As Brian noted, this is incorrect. That is because a tunnel is a link and
Internet routers are supposed to decrement the hop count at routers, not over
links. Following RFC2473 would prohibit a tunnel from host to host. It also
thus affects tunnel mode IPsec.
o Copies traffic class from tunnel link to tunnel transit header
That should be a choice, not an assumption; most vendors allow the choice to
copy or not.
o Ignores IPv4 DF=0 and fragments at that layer upon arrival
(Ignore; this is an error to be deleted in the next update)
o Fails to retain soft ingress state based on inner ICMP messages
affecting tunnel MTU
Following this rule causes PMTUD - which you favor - to break.
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 frfrom
a device that is not a router.
o Fragments IPv4 over IPv6 fragments only if IPv4 DF=0
(misinterpreting the "can fragment the IPv4 packet" as
permission to fragment at the IPv6 link header)
This causes IPv4 over IPv6 to fail when it doesn’t need to, simply to adapt to
the tunnel path MTU rather than the tunnel EMTU_R.
Note: this is the behavior you’re advocating and it needlessly breaks things
because it cannot optimize.
draft-ietf-intarea-tunnels is the movement in opposite direction: it proposes
to completely scrape PMTUD for the environment with tunnels.
If you believe that is true, please cite the relevant text to support this
claim.
Draft-tunnels just admits that PMTUD doesn’t work; it doesn’t propose
deprecating it.
All this story is a good example of when vendors did solve the problem very
effective.
It is probably because the problem was simple and vendors were trying to be
transparent – not to introduce additional limitations visible for others.
The fact that the problem was not over-standardized and not regulated was the
important enabler.
But IETF has the intention to introduce additional limitations:
- PMTUD would be permanently broken inside the tunnel
Again, that is already true both inside and outside the tunnel.
- More traffic should be fragmented
Yes - more fragments rather than simply drop. That should be a win, not a
problem.
- It is not specified what to do for many tunnels that do not support
fragmentation and do not have buffers at all. By new specification - it should
be.
Draft-tunnels is intended as BCP; it’s not a protocol spec.
But if you want to know what to do with tunnels that do not support
fragmentation, it is stop using them. They’re broken.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
