Re: IPv6 fragmentation header in RFC 3095.

Hi Calle,

I mostly agree, but I *think* we partially closed that hole with RFC4815:

5.4.  Headers Compressed with List Compression

   In RFC 3095-Section 5.8, it states that headers that can be part of
   extension header chains "include" AH [14], ESP NULL [13], minimal
   encapsulation (MINE) [15], GRE [16][17], and IPv6 [9] extensions.
   This list of headers that can be compressed is correct, but the word
   "include" should not be there, since only the header types listed can
   actually be handled.  It should further be noted that for the Minimal
   Encapsulation (MINE) header, there is no explicit discussion of how
   to compress it, as the header is sent either uncompressed or fully
   compressed away.

So, IMO the option of compressing "future IPv6 extension headers" seems closed as the refrence [9] is to RFC2460 only.

W.r.t. the v6 fragmentation header, the only place it is mentioned is in 4.5.5 of RFC3095 (the IP-ID offset encoding section), which says:

   There is no
   explicit support in ROHC for the IPv6 fragmentation header, so there
   is never a need to discuss IP IDs outside the context of IPv4.

So that probably tells us that the plan was to exclude the frag header from ROHC, but it must have been forgotten along the way.

Therefore, it seems appropriate to add an errata to completely ban compression of the IPv6 fragmentation header as it obviously doesn't work for some length fields with INFERRED classification. And as you also state, it would be silly to compress it even if it did work for all profiles.

BR,
  Kristofer

Carl Knutsson wrote:
> 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
> _______________________________________________
> Rohc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rohc