rohc

UOR-2 extension options for IPv6

Bug #1166618 reported by Elisabeth on 2013-04-09

This bug affects 1 person

	Status	Importance	Assigned to	Milestone
rohc	Status tracked in Rohc-main
1.3.x	Fix Released	Medium	Didier Barvaux	rohc 1.3.5
1.4.x	Fix Released	Medium	Didier Barvaux	rohc 1.4.3
Rohc-1.5.x	Fix Released	High	Didier Barvaux	rohc 1.5.2
Rohc-main	Fix Released	High	Didier Barvaux	rohc 1.6.0

Bug Description

Dear Didier,
Dear ROHC team,

We have detected some problems in the decide_extension function in c_generic.c. More specifically, two issues which both are related to the (non-RTP) UOR-2 case, one related to IP version and one related to the number of SN bits.

If interpreting RFC3095 correctly, the one extension available for IPv6 and non-RTP traffic is extension-3.
Assuming this interpretation to be correct, we would have expected IP version to be part of the conditions for which extension to be used. Our first issue is that IP version is not part of the decision criteria for which extension to be used.

The second issue is related to the UOR-2 case where no extension is required.
In code version 1.5.1. the condition for when not to use an extension is nr_sn_bits<5. Should it not be nr_sn_bits <=5? As the non-RTP UOR-2 message format seems to be capable of carrying 5 bits of SN.

Best regards,
Elisabeth

Tags:

Revision history for this message

Didier Barvaux (didier-barvaux) wrote on 2013-04-09:

Elisabeth,

> If interpreting RFC3095 correctly, the one extension available
> for IPv6 and non-RTP traffic is extension-3.

Yes, you're right. The other extensions contains some IP-ID bits,
so they cannot be used with IPv6.

> Assuming this interpretation to be correct, we would have
> expected IP version to be part of the conditions for which
> extension to be used. Our first issue is that IP version is not
> part of the decision criteria for which extension to be used.

My intention was to perform an indirect check on the IP version through
the checks on nr_innermost_ip_id_bits and nr_outermost_ip_id_bits, but
you're right that it might not be enough to avoid IPv6 packets to use the
forbidden extensions. I have to find an IPv6 stream that causes the
problem to occur (for non-regression tests). Do you have one?

> The second issue is related to the UOR-2 case where no extension
> is required.
> In code version 1.5.1. the condition for when not to use an extension
> is nr_sn_bits<5. Should it not be nr_sn_bits <=5? As the non-RTP
> UOR-2 message format seems to be capable of carrying 5 bits of SN.

You're right. The check should be <= 5 instead of 5. The checks for the
other extensions are OK. I have to find an IP stream that causes the
problem to occur (for non-regression tests). Do you have one?

Thank you for reporting those two problems!

Regards,
Didier