> On Mar 23, 2021, at 12:10 PM, Vasilenko Eduard <[email protected]>
> wrote:
>
> 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”.
Agreed.
> The better terminology is “transit node”, “destination node” – like it is in
> RFC 8200, not “host” or “router”.
Please see section 2 of RFC8200 (color added by me):
2 <https://tools.ietf.org/html/rfc8200#section-2>. Terminology
node a device that implements IPv6.
router a node that forwards IPv6 packets not explicitly
addressed to itself. (See Note below.)
host any node that is not a router. (See Note below.)
The term “transit node” does no appear in RFC8200.
The terms “source node” and “destination node” are used in RFC8200 but not
defined in Sec 2. They are clearly hosts that originate IPv6 packets and hosts
that consume IPv6 packets, respectively.
In an IPv6 tunnel, the tunnel ingress emits new packets with IP headers it adds
using its IP address. That makes it a source node. Same for how the egress
consumes those packets.
From the perspective of the tunnel path, the ingress and egress are hosts and
intermediate hop relays are routers.
From the perspective of the overall path, the tunnel is a link, either
host/host, host/router, router/host, or router/router. A tunnel is not itself a
router, however.
> 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.
Reassembly happens at tunnel egresses whether you want it to or not.
> Hence, vendors had the freedom to choose a much bigger number than 1500 when
> reassembly did happen in reality (despite IPv6 architecture decisions).
1500 is the IPv5 minimum EMTU_R; vendors can always implement larger reassembly
when they choose to.
> 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).
Here’s how to do it:
- set interfaces to use 1280B packets
- setup an IPv6 tunnel
- send a 1280B packet through that tunnel
If you don’t implement reassembly, it won’t work. But it does. Everywhere.
> 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.
RFC8200 is the standard. Tunnel ingresses and egresses create and consume
packets, so they act as hosts. I don’t care if they’re implemented on routers;
routers implement lots of things as hosts (see e.g., RFC4201, Sec 3.1:
...A compliant host
implementation MUST support (a) and (c) and a compliant security
gateway must support all three of these forms of connectivity, since
under certain circumstances a security gateway acts as a host
> 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.
You asked for *specific examples* of what vendors do. Those RFCs provide them.
> 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).
I have not introduced anything; I am describing an existing requirement of any
device that consumes IP packets (i.e., acts as an IP destination). When it does
so, it is a host. Tunnel egresses do that.
> 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..
Draft-tunnels has been discussed and reviewed by int-area for over a decade.
Nobody else has agreed with your assertions.
Joe_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
