Hi Joseph,
I am not much interested to discuss IPv4 now. (despite that 2 MTUs for one
interface is absent there too)
Let’s look at your reference to RFC 8200.
Section 4.5: unlike IPv4, fragmentation in IPv6 is performed only by source
nodes, not by routers along a packet's delivery path
It means that all these discussions about fragmentation and reassembly are not
related to transit nodes. It is for the “source and destination nodes”.
The better terminology is “transit node”, “destination node” – like it is in
RFC 8200, not “host” or “router”.
You see – nobody is asking vendors to be compliant with any reassembly buffers
in transit. Because it was assumed that would be not reassembly at transit.
Hence, vendors had the freedom to choose a much bigger number than 1500 when
reassembly did happen in reality (despite IPv6 architecture decisions).
Please, show any evidence (or just claim if you could not disclose) that any
vendor has 1500B (or less) for reassembly in the data plane (on transit node).
I neither know nor care. That’s a compliance issue, not a standards issue.
It is not a compliance issue, because there is no regulation/standard to comply
with. Vendors had the freedom and solved the problem easily.
This is described in detail in:
RFC1858
RFC4459
RFC4944
RFC6946
RFC6980
RFC7588
RFC8021
RFC8900
I did not ask for a general discussion. Of course, fragmentation is a big topic
with many publications.
I did ask for any evidence that there is 2 MTU per 1 virtual interface and
fragmentation problem as the result of this (when packet would come in between
of these MTUs).
I don’t see why you’re stuck on this issue.
Because you are trying to introduce additional fragmentation to the area where
it was absent before. The root cause is the introduction of the second MTU per
interface (that is in the reality the buffer size).
2 MTUs for one interface is the innovation. It does not exist in any standard
or any real implementation. It is invented only in draft-ietf-intarea-tunnels.
It is not just new names and new classification. It new things that does not
exist in the real world. Harmful, because of additional fragmentation
introduced..
Eduard
From: Joseph Touch [mailto:[email protected]]
Sent: Tuesday, March 23, 2021 9:00 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,
On Mar 23, 2021, at 8:47 AM, Vasilenko Eduard
<[email protected]<mailto:[email protected]>> wrote:
Hi Joseph,
Please, show any except (or section number) from any RFC that push vendor to
use 1500B buffer for reassembly in the data plane on the transit node? (or any
other number on the transit node)
The Internet defines:
- nodes that create or consume IP packets are hosts
- nodes that relay IP packets are routers
RFC1122/1123 summarizes host requirements. RFC1812 summarizes router
requirements. - both for IPv4. For IPv6, the former is largely in the IPv6 spec
RFC8200 and RFC8504 and the latter in RFC8200, though there are some useful
observations in RFC7084.
To your question, assuming you’re speaking of IPv6, RFC8200 requires nodes that
consume IPv6 packets to support 1500B reassembly.
RFC791 requires that nodes that consume IPv4 packets support 576B reassembly.
Please, show any evidence (or just claim if you could not disclose) that any
vendor has 1500B (or less) for reassembly in the data plane (on transit node).
I neither know nor care. That’s a compliance issue, not a standards issue.
Please, show the evidence that the fragmentation problem exists.
This is described in detail in:
RFC1858
RFC4459
RFC4944
RFC6946
RFC6980
RFC7588
RFC8021
RFC8900
As well as nearly any tunnel protocol description.
All your discussions for EMTU_R are not relevant – it is for *host* reassembly
buffer.
See above; you need to understand that the Internet defines HOST as any device
that creates or consumes IP packets.
Data Plane on the transit node has not been regulated before – It was not
needed. Vendors have chosen big enough numbers that did not affect anybody so
far.
See above; that’s not correct.
It was effectively 1 MTU restriction per 1 virtual interface, not 2.
I do not accept this:
That’s just the case where pathMTU == EMTU_R.
That means the EMTU_R is not needed *in practice*, but in principle it still
exists.
If particular tunneling technology does not have a reassembly buffer (reject
fragmentation in principle) – we could not talk about it like it exists.
I don’t see why you’re stuck on this issue. You don’t have to implement a
separate reassembly buffer to have an implementation behave exactly as if there
was one with the same size as the pathMTU. The effect is the same - no
reassembly.
If you would look to microcode – you would not find it. We could go very far
with such logic.
I don’t take my cues from others’ implementations.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
