Re: IPv6 task list

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 27 Oct, 2013, at 09:41 , Beverly Schwartz <bschwart%bbn.com@localhost> wrote:
> Two IPsec tunnel related items - one a clear bug (also exists in Linux, FYI), 
> the other a little more controversial.
> 
> Clear Bug:
> Do source fragmentation BEFORE applying tunnel code.  Right now, what 
> happens, is all packets, regardless of size, are put through the IPsec code 
> BEFORE having source fragmentation applied.  So packet gets encapsulated, 
> then split up, then at the other end of the tunnel, the packet is 
> reassembled.  If the endpoint of the tunnel is different from the ultimate 
> destination of the packet, then the packet will then be dropped (because it 
> is too large for the MTU), and a packet-too-large message will be returned to 
> the source - all to have the same thing happen again.

This is clearly a bug.  For IPv6 fragmentation size depends on the
end-to-end path (unlike IPv4, where it depends solely on the next
hop interface) and must be tracked and applied at the very start
of the path.  The encapsulation tunnel is generally only a path
segment, i.e. is not the full end-to-end path, so fragmentation needs
to be done before you get there.

> More controversial issue...
> If an IPsec tunnel appears mid flight and applying tunnel code causes the 
> packet to be too big for the MTU, the packet is then fragmented.  Some people 
> have argued that because a new outer header is applied, it is a new packet, 
> therefore source fragmentation is allowed.  The primary author of the IPsec 
> RFC disagrees with this interpretation - he feels a packet-too-large message 
> should be returned.  The point of source fragmentation is to get the sizing 
> right in the first place so that we don't end up with a bunch of tiny 
> fragments.  That is exactly what happens in this scenario.  The new header 
> adds a handful of bytes over the MTU, so every full-size packet (and 
> full-size packets will be common in a large transfer) will be fragmented at 
> the tunnel - one full-size packet, and one tiny packet.
> 
> There are other weird behaviors with MTUs and IPsec tunnels that, for the 
> most part, won't occur in real life. And fixing some of these odd borderline 
> cases would involve changes to specifications.

I think it might be controversial to argue that fragmenting the
tunnel-encapsulated packet is not permitted as an implementation
choice, but I also think it is non-controversial to argue that not
doing it this way, instead using the information about the effective
tunnel MTU to persuade the packet originator to send packets small
enough to fit through it without (additional) fragmentation, is a
functionally superior implementation option to choose.  Anything that
reduces, or eliminates, the need for mid-path routers to do packet
reassemblies is always better just based on functional considerations,
and while there are always MTU-related warts associated with tunnelling
(even with IPv4) I believe you end up with fewer of them by always
pushing packet size issues (whether fragmentation, segmentation or
reassembly) as close to the ends of the end-to-end path as you can.

The reasons generic IPv4 tunnel implementations generally choose to
send encapsulated packets with the DF bit clear in the outer header
(i.e. to allow fragmentation of the encapsulated packet) are historical.
IPv6 doesn't share that history and needn't (and shouldn't) emulate this.

Dennis Ferguson