Re: [v4v6interim] Fragmentation Options in NAT6 presentation

On Thursday 09 October 2008 15:43:31 ext Magnus Westerlund, you wrote:
> You can't make 4821 style PMTUD generic over UDP. The issue is of course
> the feedback that needs to be integrated with the protocol. And that you
> need to have some way of knowing exactly which packet is which.

I agree. I actually believe that this is one half one the problem: there is no 
(semi-)standard way to do this with the a UDP BSDish socket.

To the best of my knowledge, Linux supports this through IP_MTU_DISCOVER, in a 
awkward yet usable way. On Windows, you can set the DF bit, but that's about 
it. On BSD/OSX, you cannot even set the DF bit. I might be wrong.

> When it comes to "safe", no value is truly safe and that is the issue.
> Things starting to get really high success rates when you go down below
> 500 bytes, i.e. 576 - reasonable overhead. But even 1400 is to big in a
> number of places for IPv4 networks. Also the tendency to make tunnels in
> tunnels is one of the bigger issues about how much you should deduct.

Sure. In fact, my 3G provider sets an MTU of 1400 bytes, so sending UDP 
packets with 1400 bytes payload would be awfully bad.

> Thus in addition to get TCP and SCTP stacks to implement 4821, have
> application that uses other transport to also include solution we do
> need a solution for the address family translation that support
> fragmentation enabled to avoid black holes.

In Dublin, I thought we came to the conclusion that all significant IPv6 
stacks supported the provision for fragmentating IPv6 even below 1280 bytes. 
If I understand correctly, they then send IPv6 packets with a fragment 
header, so that it is "easy" for the translation box to do its job.

As for IPv4 side, I think we have what we have and we cannot improve it much. 
If the application supports 4821, good. If not, then well, it might not work, 
with and without IPv6 translation. However, I think it would be (or have 
been) a good idea to promote an Informational socket API extension for 
RFC4821, so that apps can control the DF bit, fetch the known MTU, dequeue 
per-destination Too Big errors, etc.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim