Re: Path MTU discovery when having varying MTU

Iljitsch van Beijnum <[email protected]> Tue, 19 May 2009 12:18:17 +0200
Newsgroups gmane.ietf.tsv-area,gmane.ietf.rohc
Message-ID <[email protected]>
On 19 mei 2009, at 11:08, Magnus Westerlund wrote:

> So this is IPsec tunnel mode which is commonly used for VPN, which  
> means
> that one of parties are quite likely behind a NAT or at least a
> firewall. Thus, relying on IP fragmentation is likely to mean, all
> fragmented packets dropped on the floor by the middlebox.

Where do you get that?

I've never heard of fragmentation breaking consistently in  
middleboxes. This is from a system behind a NAT running peer-to-peer  
stuff for a while and communicating with some local systems. Since  
locally everything is ethernet and that communication is basically  
only TCP I don't think the fragments were local:

	94869703 total packets received
	112346 fragments received
	0 fragments dropped (dup or out of space)
	13 fragments dropped after timeout
	53614 packets reassembled ok

> Also, the segmentation mechanism that ROHC has is currently defined to
> be turned off. The ROHC people can fill in the motivation for that.  
> One
> is clearly the need to keep state in the tunnel end-points for  
> reassembly.

If you can do IPsec and header compression then reassembly for a small  
percentage of all packets isn't unreasonable.