← Back to team overview

rohc team mailing list archive

Use of RoHC in 6bed4


Hello Didier,

My compliments for the good overview of RoHC on your website, and thank
you for your hard work on the code!

We are working on 6bed4, which is an "IPv6 everywhere" tunnel run over
UDP/IPv4 [0].  It includes procedures for reliable discovery[1]of direct
peering, for which we are intend to use RoHC [2].

Any comments that you might have on RoHC in sections 9 and 10 would be
greatly welcomed, but I have no idea if you can find the time of course.

The minimum level that we require is to at least interpret RoHC setup
attempts and respond negatively to them.  If we are correct, this means:

 - detecting start nibbles 14 and 15 and treating them as RoHC
 - signal STATIC-NACK in response to them

The specs are very difficult to read, due to layering of the concepts. 
This makes it difficult to (1) know if this is correct and complete, and
(2) how exactly to produce these STATIC-NACK values.

Again, any guidance you might give us would be welcome.  It is not often
that a protocol is so complex that I find it difficult to produce the
bytes to be sent :-S  I hope that doesn't sound silly... but I find RoHC
both useful and a very, very hard nut to crack.  Any help is _quite_
welcome and may improve overall consistency.


Rick van Rein
OpenFortress / InternetWide.org / ARPA2.net

[0] It is a bit like 6to4, but with UDP inserted to make it pass through
NAT.  There are other subtleties as well, in support of direct peering.

[1] It differs from Teredo by verifying bidirectionally, rather than
theorising on a too-simple model of types of NAT.  It also differs from
Teredo in that it actually works :)

[2] The tunnel was designed to overcome a lack of tunnels for SIP/RTP
traffic.  This is why we emphasise direct peering whenever possible. 
SIP/RTP stands to gain a lot from being IPv6-only, and so we need IPv6
everywhere [so we can rely on the remote party to also use it].