[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: automatic tunneling and v6 interoperation



-----BEGIN PGP SIGNED MESSAGE-----

Pekka Savola wrote:

> Christian presented issues in the Unamanged connectivity 
> possibilities in Minneapolis on Wednesday.
> 
> There are multiple issues which I don't think came across 
> clearly.  I hope this mail helps in clarifying them.
> 
> 1) the implication of economics to automatic tunneling mechanisms
> 
> Christian stated that tunnel brokers and similar mainly make 
> sense (from economics perspective etc.) if the ISP [or maybe also a 
> transit of the ISP, btw.] is providing the service.

For SixXS we try to keep traffic as local as possible.
Dutch users only use dutch POP's, german users only the .de POP etc.
Most ISP's are peering at the IX's anyways, so that doesn't burden
much in the traffic costs as peering is (usuall) free.
Next to that one could consider the "tunnelbroker" system as
a ftp or website, it generates traffic at both the ISP where
the user is located and the POP's site, it's just another service.
Seeing that the traffic is still very small (4.5mbit/s) spread
over about 1000 active tunnels should also indicate that the
cost for the hardware is higher than the cost for traffic.

Indeed it is all generosity at the moment that ISP's allow
other ISP's users to use this service. You could also view
it as free advertisement for the ISP's hosting the POP's as
the people using it will see that their IPv6 service is good
which will quite probably mean that all other services provided
by them are good too.

<SNIP>

> It's best to be sure to understand the problems automatic tunneling
> mechanisms try to solve.  Both Teredo and 6to4 seem 
> reasonably usable if used only between {6to4,6to4} and {Teredo,Teredo},
> ({native|tunnel-service,native|tunnel-service} being the 
> first category).

We have almost finished adding and testing tinc (http://tinc.nl.linux.org)
support to the SixXS software which allows endusers, even behind
firewalls and also NAT's to tunnel IPv6 over UDP or TCP (over httptunnel? :)
Thus this will allow anybody, anywhere to use the service.

The heartbeat clients make it easy to setup these tunnels and
also allows real dynamic proto-41 tunnels using the heartbeat protocol.
Endpoints are updated on-the-fly when the POP receives a heartbeat
from the client, allowing dynamic IPv4 non-24/7 hosts to use the
service.

Every POP is directly connected to the ISP's own IPv6 infrastructure
thus routing is the same as for native clients, except that the last
end is actually going over IPv4 instead. This would all
function much better ofcourse when there where more POPs scathered
around the world, or even better, a POP per ISP...

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook Alpha 13 Int.
Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/

iQA/AwUBP7OYHimqKFIzPnwjEQIIXQCfd7/9e8zymzVNM1DpRc41nZ96xuUAn3ta
tdYvpGFrYMYhmV+5rUB2O4jg
=CmW4
-----END PGP SIGNATURE-----