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]> > 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
