Re: 3-bit CRC and IPv6 ip_id_behavior

--===============0488584815==
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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,
>=20
> I have a question concerning section 6.6.11, =E2=80=9Ccontrol_crc3_enco=
ding=E2=80=9D of RFC 5225, particularly for the RTP profile.  The stateme=
nt of interest: =E2=80=9Cip_id_behavior, one octet for each IP header in =
the compressible  header chain starting from the outermost header.=E2=80=9D
> =C2=20
> 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.=20
> =C2=20
> I would personally argue =E2=80=9Cno=E2=80=9D, because at section 6.6.1=
1, ip_id_behavior for the ipv6 header is considered non-existent. Thus, I=
 believe that, although not explicitly stated, the crc3 encoding only inc=
ludes one octet for each IPv4 header.=20
> 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 belie=
ve that subsequently definitions makes that variable into a control field=
.=20
> Furthermore, in the RTP profile section, it states:
> UNCOMPRESSED v6 {
> ENFORCE(ip_id_behavior_innermost.UVALUE =3D=3D IP_ID_BEHAVIOR_RANDOM);
> Thus it only defines one ip_id_behavior_innermost, and not an ip_id_beh=
avior for each IPv6 header, as would be necessary for a control_crc3_enco=
ding that would encode every ipv6 header, and as it did in the UDP profil=
e:
> UNCOMPRESSED v6 {
> ENFORCE(ip_id_behavior.UVALUE =3D=3D 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 r=
egardless of ipv4 or ipv6, but not to expand the  control_crc3_encoding()=
 process.=20
> =C2=20
> Logically, I also don't think it makes sense to compute the CRC3 of ipv=
6 ip_id_behavior. The purpose of CRC3 is to ensure that our control varia=
bles are in sync. However,  ipv6 ip_id_behavior is always defined as RAND=
OM, so it can never be out-of-sync anyway. Adding it to the CRC3 calculat=
ion would be an unnecessary computation.=20
> =C2=20
> However, I definitely see why some of my colleagues would argue the oth=
er 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 explic=
itly as such?
> =C2=20
> If you would clarify your intentions when writing the RFC, that would p=
ut our minds to rest. Thank you.=20
> =C2=20
> Sincerely,
> Sasha Koruga
> =C2=20
>=20
> _______________________________________________
> Rohc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rohc


--===============0488584815==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Rohc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rohc

--===============0488584815==--