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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf