Re: [Int-area] Proxy function for PTB messages on the tunnel end

[Vasilenko Eduard <[e-mail]>]

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:[e-mail]]
Sent: Wednesday, March 24, 2021 5:36 PM
To: Vasilenko Eduard <[e-mail]>
Cc: [e-mail]; int-area <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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