IPv6 fragmentation header in RFC 3095.

Hi all,

I have assumed that ROHC (RFC 3095) didn't support compression of
fragments at all. If I read the RFC today it is clear that all IPv6
extension headers are supported by RFC 3095, including the IPv6
Fragment header. As the RFC is written, all future IPv6 extension
headers should also be supported by an RFC 3095 implementation.

As it turns out, the list compression of IPv6 fragmentation is broken
for the RTP and UDP profiles. It is impossible to infer the UDP length
field from a single fragment. It is probably broken for the UDP and RTP
lite profiles as well (haven't checked).

There is also an issue regarding how to handle list compression of a
header chain with both IPv6 fragmentation and ESP null. The ESP null
trailer is compressed using RFC 3095 list compression. There is at least
a need for additional instructions on how to handle this.

The IPv6 Fragment header issue clearly shows the weakness of the
generic IPv6 extension header support. Since no IPv6 extension headers
are explicitly specified, it means that an implementation must support
any and all future IPv6 extension headers that the IETF community may
come up with, without requiring a ROHC profile version bump. The issue
with the IPv6 Fragment header shows that we cannot guarantee that list
compression of future IPv6 extension headers will work as described in
RFC 3095.

I suggest that we file an errata to RFC 3095 that:

1) forbids list compression of the IPv6 Fragment header.
2) explicitly list all IPv6 extension headers that can be compressed by
RFC 3095.

I also want to add that the gains of compressing IPv6 fragment, even for
ROHC-IP, is quite small in most cases due the optimistic approach and
changing nature of the identification field. Most of these packets will
be sent as an UOR-2-Ext3 with a compressed list containing a full copy
of the IPv6 Fragment header.

cheers,

/Carl Knutsson