[6bed4-devel] PtP tunnel forking instead of a tunnel spanning the ipv4 internet

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

There are a lot of scenarios other that Ipv6 transitions that involve
Point to Point tunnels in a mesh over a Non-Broadcast Multi-Access
network.  VPN and the like.

In those tunnels you can work very hard to achieve multicast and
broadcast parity with existing ipv6 links or you can take the line that
you simply have a lot of point to point connections that give you
connectivity, and you have the ability to create a new point to point
connection at need.

In the startup configuration of these kinds of networks you bootstrap
with a tunnel to some well known central point so you have connectivity.
Then you create tunnels to other endpoints on demand.



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.

It looks like a general approach that is going to be simple and
easy to implement.

I don't know if it is going to be really useful in the 6bed4 design
scenario.  Having to throttle hole punching to 20ms or slower looks
like it is going to be a real drag on tunnel creation speed and my
hunch is that most transitive internet connections will be over
before a tunnel can be established.

However I do think this is a fun way to experiment with ICE and a very
interesting way of coping with implementing NAT traversal outside
end applications, so I am going to keep playing with this as time
permits.  So far except for tunnel setup speeds this looks very
promising, and the least NIH that I have found.

Eric