Re: [6bed4-devel] Comments and thoughts on bed64 (Status)

[<ebi...@xm...>]

Rick van Rein <ri...@op...> writes:

>> And ultimately you have what is effectively a whole new protocol.
>
> This might be a bit over the edge, I fear ;-) and you say you agree.

> On Tue, Jul 03, 2012 at 06:33:49PM -0700, Eric W. Biederman wrote:
>> 
>> I have started playing the idea of encoding the ICE offer/answer
>> exchange as an STUN message and then I can let ICE/STUN take care
>> of trying different paths and finding one that works, and agreeing
>> on a common route.
>
> Interesting!

I have something working at this point, although not quite finished, I
haven't coded up the message-integrity check attribute of the
verification attribute but that is essentially orthogonal from the rest
of the work.  It takes about a 3rd more code than your version of peer.c
but the code is absolutely bored when it comes to peircing my NAT test
cases.

The packet flow:

      A                                           B
ipv6 port 3478  <----------ice offer----------- ipv6 port 3478
ipv6 port 3478  ----------ice answer----------> ipv6 port 3478
ipv4 6bed4 port <-----stun binding request----> ipv4 6bed4 port
ipv4 6bed4 port <-----stun binding reply------> ipv4 6bed4 port
ipv4 6bed4 port <== shortcut tunnel traffic ==> ipv4 6bed4 port

The ipv6 address does not need to be a 6bed4 address.  This allows any
host to bypass the 6bed4 router if it has the ability to receive traffic
on a ipv4 udp port.  Only the ice offer/answer packet exchange go
must go through the 6bed4 router.

Currenlty I am running I am not buffering traffic and running traffic to
it's destination over the 6bed4 tunnel, until a shortcut tunnel forms.
The awesome and terrible feature of the shortcut tunnels is that traffic
is not sent over them until round trip reachability is confirmed, which
looks like it means just in time for a small flow to be completely
routed over the 6bed4 router while the tunnel is forming.  Ugh.  So I
expect I may need to delay the initial traffic to a host a little, to
get the tunnel to be useful to short bursts of traffic.

On the side of debugability I have coded up a ICMPv4 to ICMPv6 converter
and started storing sync the hop_count and the traffic_class between v4
and v6. And I have explicitly not configured an address on the 6bed4
router interface.

Which seems to give me parity on debugability with traceroute over ipv4
and ipv6.  I can traceroute from an ipv6 host and see all of the ipv4
hops past the 6bed4 router.  Likewise I can traceroute on the 6bed4
client side and see all of the hops on the way to the 6bed4 router.  My
traceroutes through the 6bed4 router give me a router name other than
the generic 6bed4 name so I can tell which router I am dealing with.

It is kind of fun seeing a traceroute before and after the shortcut
tunnel forms.

Eric