2. Set a commonly supported ROHC MTU for the tunnel and use ROHC
segmentation to handle the packets that gets expanded beyond PMTUD.
[...] Not
certain that the ROHC segmentation mechanism can work over reordering
transports.
As Carl pointed out, ROHC segmentation is efficient only for non-
reordering links.
It is similar to AAL5, but does not use a length field.
Assuming the CRC is effective, it responds to undetected reordering
with dropping the (reassembled) packet(s) affected with a likelihood
of p ≈ 1-2**-32 (and delivering a bad one with q ≈ 2**-32).
I'm not happy about the security implications if it is not.
However, the IPsec sequence number might be good enough to reliably
detect reordering or even to resequence before ROHC reassembly. I
think that might be the right thing to do, as ROHC segmentation is
much better than IP fragmentation on a non-reordering link.
So there *was* something specific that ROHC could bring to the table...
The remaining problem is that the compressor needs to know the tunnel
MTU.
On ROHC, I wrote:
So what would you want the compressor to do?
Run PLPMTUD (probes can be done by occasionally compressing badly*) on
the tunnel and reject (ICMP unreachable/Frag needed) all DF/IPv6
packets that would not fit with worst-case expansion?
Probably safe, but somewhat expensive.
[...]
*) Yes, this needs way more text.
You would need to compress badly whenever compressing a packet that,
badly compressed, would not fit the currently established safe
PMTU. That unfortunately tends to shrink while compressing well,
which ROHC tends to do :-)
So let's replace that with:
Run PLPMTUD (probes can be done by occasionally compressing badly*) on
the tunnel and ROHC-segment all DF/IPv6 packets that would not fit
with worst-case expansion.
*) This can be done by sending the packet on a separate CID with an
IR, with some impact on compression efficiency on the original CID.
Does that work?
Gruesse, Carsten
