Incorrect implementation of IP static header in IR packet
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
rohc | Status tracked in Rohc-main | |||||
Rohc-1.6.x |
Invalid
|
Undecided
|
Didier Barvaux | |||
Rohc-1.7.x |
Invalid
|
Undecided
|
Didier Barvaux | |||
Rohc-main |
Invalid
|
Undecided
|
Didier Barvaux |
Bug Description
The ROHCv1 specification (RFC 3095) states that the first byte in the static part of the IP data must contain either a 0x40 for IPv4 or 0x60 for IPv6. Your implementation appears to be using the definition of the first byte from ROHCv2 (RFC 5225), which uses the upper byte to indicate either IPv4 or IPv6.
In looking at the test code, I am assuming that this happened due to the Aeroflex TM500 data in your interoperability test. It appears that they are using the ROHCv2 style header with ROHCv1 profile number and data. In Bug #1301518, the Aeroflex data you showed was as follows:
FD06FC00 06C0A895 6A0A0A02 020B0020
FB040080 536E3002 00019934 219CFFFF
263506A8 B88D05AC 01
This is an IR packet for TCP (profile 06) containing a dynamic chain. The CRC is 0xFC, and the 00 which follows the CRC should be a 04 instead of a 00.
Since the dynamic chain decoded correctly in the test, I can only assume that this is an ROHCv1 IR since the dynamic chain in ROHCv2 is different.
The ROHCv1 TCP profile is not defined in RFC 3095, but in RFC 6846. The Aeroflex data is indeed one IR packet.
RFC 6846 defines one IR packet as follow in §7.1:
* optional 1-byte add-CID octet
* 1-byte IR type octet = 0xFD
* optional 1-2-byte large CID
* 1-byte profile ID = 0x06
* 1-byte CRC
* static chain
* dynamic chain
* payload
So, the Aeroflex data may be read as follow:
* no Add-CID
* 1-byte IR type octet = 0xFD
* no large CID
* 1-byte profile ID = 0x06
* 1-byte CRC = 0xFC
* 14-byte static chain:
* 10-byte IPv4 static chain: 00 06 C0 A8 95 6A 0A 0A 02 02
* 4-byte TCP static chain: 0B 00 20 FB
* 24-byte dynamic chain:
* 5-byte IPv4 dynamic chain: 04 00 80 53 6E
* 19-byte TCP dynamic chain: 30 02 00 01 99 34 21 9C FF FF 26 35 06 A8 B8 8D 05 AC 01
* no payload
RFC 6846 defines the IPv4 static chain as follow:
COMPRESSED ipv4_static {
version_flag =:= '0' [ 1 ];
reserved =:= '0000000' [ 7 ];
protocol =:= irregular(8) [ 8 ];
src_addr =:= irregular(32) [ 32 ];
dst_addr =:= irregular(32) [ 32 ];
}
So, the Aeroflex 10-byte IPv4 static chain may be read as follow:
* 1-bit version flag = 0
* 7-bit reserved field = 0
* 1-byte protocol = 0x06 (= TCP)
* 4-byte source address = C0 A8 95 6A
* 4-byte destination address = 0A 0A 02 02
In conclusion, the Aeroflex packet looks fine. So looks the library. In consequence, I'm going to mark the ticket as 'invalid'.