Re: draft-bonica-6man-frag-deprecate

[Ole Troan <[e-mail]>]

Fred,

>> in my understanding the 1280 minimum MTU for IPv6 was already chosen to
>> accommodate nested tunnels.
> 
> Right, but..
> 
>> the expectation made, I believe, was that native links support at least
>> an MTU of 1500 bytes,
> 
> But, that expectation went out the window at the same time the IPv6
> minMTU was set to 1280 - so now 1280 is all that can be expected.

quite the opposite.
physical link MTUs aren't getting smaller.
do you have any evidence that operators set the IPv6 MTU to a value smaller than the MTU supported
by the link-layer?

as far as I can see the setting IPv6 minimum MTU to 1280, which gives ample room for
nested tunnels works as designed.

> So, without fragmentation, when the tunnel ingress receives a 1280
> packet, it emits a (1280+HLEN) packet. If that packet is dropped
> at a link that configures a 1280 MTU, then it simply black holes.
> 
>> allowing 220 bytes for tunnel encap (5 IPv6 headers).
> 
> Tunnels within tunnels presents an additional pain point, but the
> plain truth is that IPv6 links only need to configure a 1280 MTU;
> not a 1500.

again, why would anyone do that?
the pain here is fragmentation, not supporting an MTU larger than 1280.

>> you want to avoid reassembly at tunnel endpoints, if you care about
>> performance that is.
> 
> Unfortunately, reassembly is absolutely necessary if the tunnel is
> configured over a path that contains at least one 1280 link (see above).

reassembly in the network is a non-starter.
the vendor I'm most familiar with does not do this in hardware. sure, you can get reassembly, but at an order of one or two magnitudes less. if anyone know of platforms doing IPv6 fragment reassembly at line rate for 10G or 100G interfaces I'll stand corrected. ;-)
for now reassembly in the network is not realistic.

cheers,
Ole