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.