Re: Evolution of the IP model - ICMP and MTUs

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 18 aug 2008, at 11:46, Rémi Després wrote:

> > However, we could come up with a new fragment header for both IPv6  
> > and IPv4 that DOES have all the information NATs and firewalls need  
> > in the fragment header, as well as a larger ID field.

> Fixing the problem for IPv6 may be worth the pain, but fixing it for  
> IPv4 (the only subject of my comment) would IMO be counterproductive.

Counterproductive?

> Do you know applications other than NFS on UDP that, needing to  
> transmit longer than than 1280 octet datagrams, impose fragmentation  
> even in IPv6?

Most applications have more than 1200 bytes of data to transmit, so  
potentially this could be most UDP applications, as well as ALL  
tunneling mechanisms. Now of course applications try to avoid this  
issue by sending smaller packets, but that's a terrible solution,  
because we'll never be able to use bigger packets when our link  
technologies improve.

On 18 aug 2008, at 14:21, Rémi Denis-Courmont wrote:

> And would cause the packet to be rejected by existing middleboxes.

Yes, so deployment would be slow because we need to wait for these to  
be updated or replaced, and the solution would incur some additional  
complexity for deciding whether to use old style or new style  
fragmentation.

> Firewalls can simply let every non first fragments in. Deep packet
> inspection needs to de-fragment anyway - adding the port number to  
> every
> fragment does not help. Hence, this issue is really only about NATs.

Don't forget that this also buys us a larger ID space for IPv4, which  
makes some of the less visible issues with fragmentation go away.

And, if we can solve PMTUD for datagrams (i.e., UDP) life gets a lot  
easier for applications.