Subject: [rohc] IPv6 fragmentation header in RFC 3095.

From: Carl Knutsson <[email-masked]>
Date: Thu, 25 Feb 2010 14:07:36 +0100

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 26 Feb 2010 08:33:10 +0100

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:
> compression of future IPv6 extension headers will work as described
> in RFC 3095. 
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/rohc

---

From: Carl Knutsson <[email-masked]>
Date: Fri, 26 Feb 2010 08:47:23 +0100

Hi,

I was CDR for RFC 4815, so I should know this section

> So, IMO the option of compressing "future IPv6 extension headers" seems closed as the refrence [9] is to RFC2460 only.
Agreed. I was CDR for RFC 4815, so I should have known about this
section :).

> 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…
I think this is the right way to move forward.

/Calle