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

[Carl Knutsson <[e-mail]>]

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:
> 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
> Â 
> 
> _______________________________________________
> Rohc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rohc