Hi, Fred,
...
A GRE tunnel, IMO, has the MTU of whatever its outer encapsulation is.
I.e., GRE over IP with no options has an MTU of 65535-40-{gre_size}.
Beyond that it *cannot* reassemble.
I have a slightly different view, but one that still involves
fragmentation. The GRE tunnel MUST observe the minimum IPv6 MTU
of 1280 bytes.
In what it sends over IP (i.e., in the chunks it uses to transit from
ingress to egress). There's no reason to impose that limit on what it
receives at the ingress.
But, to uphold the de facto Internet cell size of
1500 bytes we should extend this up to 1500. So, if the MTU within
the tunnel is unknown and/or unknowable, then the ingress MUST use
fragmentation to make sure that packets no larger than 1500 bytes
get through - the egress then gets to reassemble.
This is an artificial limit that is unnecessary.
IMO, MTU is just that - "MAXIMUM". Not 'preferred'. So if GRE *can*
transit packets arriving at the ingress that are 65535-IP-GRE, why
should it do otherwise?
(yes, it *can* be configured lower if desired, just as with any other
link, but there's no reason to assume 'lower than maximum' as a default)
Packets larger than 1500 can be admitted into the tunnel unfragmented
and allowed to sink or swim on their own.
Whether and how much GRE fragments what it receives at an ingress ought
to be determined by its understanding of its own ingress-egress MTU
capability. However, those fragments are not directly related to what
the tunnel can transit *because* the ingress can fragment and the egress
can reassemble.
Acting like the ingress and egress can't participate in frag/reassembly
of the outer packet introduces an artificial limit to GRE tunnels. If
that's what you want to do - or what has already been done - that's
fine, but *that* is what is suboptimal.
> The ingress may or may not
get ICMP PTBs if one of these is dropped, but the source should be
using RFC4821 when it sends packets larger than 1500 bytes anyway,
so loss of PTBs should not affect the hosts.
Agreed on that point, but not the 1500-byte transit limit.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
