Carsten Bormann wrote:
OK, let me phrase my question in another way: why does the spec
contain a feature that does not really work? (Even as optional
feature?)
Well, it actually does work.
RFC 4224, section 5.2.1 tells us that when a channel is reordering
and you don't notice, packets will be lost. Now IPsec is a strange
animal: It is reordering, but the order can be reconstructed from
the sequence number. So a reassembler could (here really: SHOULD)
use that to avoid stitching together packets in the wrong order and
then discarding them.
Well, the current drafts don't specify any such behavior, so the
feature as it's currently written does not work. (Also, using the
ESP/AH sequence number this way would be very unusual -- there
might be some complications...)
Is ROHC segmentation "better" than IP fragmentation?
It certainly has fewer of the problems of IP fragmentation.
It does require throwing some CPU at the data (it uses a CRC).
Because header compression creates a variable-MTU channel, being able
to segment in a pinch is a boon.
Since the ROHC framework has the functionality, and it is not hard
to make it work on IPsec, I would favor retaining it.
Making it work for IPsec might not be impossible, but it does
require additional work beyond what's in the current drafts.
Best regards,
Psai
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf