Subject: [rohc] 3-bit CRC and IPv6 ip_id_behavior

From: "Sasha Koruga" <[email-masked]>
Date: Wed, 15 Sep 2010 17:52:57 -0400

Dear ROHC enthusiasts,

I have a question concerning section 6.6.11, “control_crc3_encoding” of RFC 5225, particularly for the RTP profile.  The statement of interest: “ip_id_behavior, one octet for each IP header in the compressible  header chain starting from the outermost header.”
 
For the RTP profile, are the ipv6 ip_id_behaviors included in the crc3 coverage? We are having an internal team debate on the issue, and thus I seek your guidance. 
 
I would personally argue “no”, because at section 6.6.11, ip_id_behavior for the ipv6 header is considered non-existent. Thus, I believe that, although not explicitly stated, the crc3 encoding only includes one octet for each IPv4 header. 
Only later in the text, in the lower layers (section 6.8.2.4), does an ipv6 ip_id_behavior occasionally get defined as RANDOM, but I don't believe that subsequently definitions makes that variable into a control field. 
Furthermore, in the RTP profile section, it states:
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior_innermost.UVALUE == IP_ID_BEHAVIOR_RANDOM);
Thus it only defines one ip_id_behavior_innermost, and not an ip_id_behavior for each IPv6 header, as would be necessary for a control_crc3_encoding that would encode every ipv6 header, and as it did in the UDP profile:
UNCOMPRESSED v6 {
ENFORCE(ip_id_behavior.UVALUE == IP_ID_BEHAVIOR_RANDOM);
I believe the purpose of the RTP definition was to allow functions such as ip_id_sequential_variable() and profile_1_7_flags1_enc() to be used regardless of ipv4 or ipv6, but not to expand the  control_crc3_encoding() process. 
 
Logically, I also don't think it makes sense to compute the CRC3 of ipv6 ip_id_behavior. The purpose of CRC3 is to ensure that our control variables are in sync. However,  ipv6 ip_id_behavior is always defined as RANDOM, so it can never be out-of-sync anyway. Adding it to the CRC3 calculation would be an unnecessary computation. 
 
However, I definitely see why some of my colleagues would argue the other way: that the ip_id_behavior for each and every IP header is included in the CRC3 coverage. They argue that if the intention was to include the ip_id_behavior's of only IPv4 headers, why would it not be stated explicitly as such?
 
If you would clarify your intentions when writing the RFC, that would put our minds to rest. Thank you. 
 
Sincerely,
Sasha Koruga

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 16 Sep 2010 10:34:29 +0200

Sasha Koruga,

There are no ipid_behavior control field for outer IPv6 headers. So they
hardly can be added to the control crc.

Section 6.6.11 is very clear, the ip_id_behavior should be added for
every IP header. I don't remember if the intention was to include IPv6
ip_id_behavior or not. However it is clear that something is broken.

I agree with you, it makes no sense adding the inner ipid_behavior and
outer ipid_behavior for IPv6 to the control_crc. These field (if
existing) are not sent as-is in any of the packet formats and are pretty
much protected by the crc-validation/verification. There is no need for
extra protection as in the ip-id case since the decompression will fail
if anything else than RANDOM is sent for IPv6.

Given the text in section 6.6.11, it is not really clear how to handle
this.

I would like to change the text in 6.6.11 to say
"for each IPv4 header" instead of "for each IP header"

I will discuss this with the authors and the AD (I am no longer
responsible for the WG) and file an errata if necessary.

/Calle

On 09/15/2010 11:52 PM, Sasha Koruga wrote:
> � 
> � 
> � 
> � 
> � 
> � 
> � 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc