On 2011-07-28 01:36 , Mark Andrews wrote:
Is there *one* tunnel management protocol that they all support or
does a cpe vendor have to implement multiple ones to reach them
all? I'm pretty sure I know the answer to this question but I'd
love to be proved wrong.
There is no 'one' solution to the problems that they are solving.
As such there tend to be a combo of:
- static proto-41 tunnel
- TSP => dynamic NATted addresses
- proto-41 + heartbeat + TIC => dynamic public addresses
- AYIYA + TIC => dynamic NATted addresses
TSP conveys configurartion information inline with the UDP packets.
TIC is solely for configuration information and does not do tunneling
but can be used for all proto-41/heartbeat/AYIYA protocols (and for
instance AVM chose to only do proto-41 + heartbeat as their devices
always have public IPv4 IPs).
Teredo is only for a single host thus is not useful for CPEs and thus
not included in them.
One of the advantages of 6to4 anycast is that it is just needs a
check box to turn on and off. Everybody speaks the same thing.
Except that it does not work behind a NAT and most people do sit behind
Next to that those anycasts are even rarer around the world and on top
of that it is hard to figure out issues when they are there (although
some people have tricks to apparently debug them, the anycast on both
IPv4 and IPv6 requires one to contact a lot of folks).
The big advantage over a known tunnel endpoint is the known behavior of
that endpoint and the simple way of complaining when something is
broken. And people fortunately do complain when stuff is broken,
unfortunately not always with the proper details though, but I am to
blame for not finishing that program up...
Another advantage of 6to4 is it doesn't require manual intervention
on renumber events. Manual tunnel don't pass muster.
I guess you are one of the lucky people to get a public static IPv4
address prefix at home that never renumbers? Guess what, most of the
world does not have that luxury, they get 1 dynamic address and for
instance in Germany they get a disconnect/force-renumber every 24 hours
(according to the ISPs because of 'accounting' reasons...)
Do realize that when you have that public IPv4 address, when it changes
you are renumbering your 2002:<ipv4>::/48 prefix everywhere. Fun...
(I hope you also like asking 6to4.nro.net everytime to change your reverse)
The tunnels above all have ISP-supplied prefixes and tend to be static
(I think TSP anonymous tunnels rotate addresses, but the majority just
keeps on returning the same static allocation, in the case of SixXS you
really get a fixed address, much easier on the PoP side and we can do
whois and store it in the relevant RIR registry)
Another advantage of 6to4 is you don't have to register. For most of
the tunnel brokers you have to register.
I guess you also where able to anonymously sign up to your IPv4 ISP!? :)
Especially that static IPv4 address must be wonderful to get that way.
Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away.
Something with the amounts of abuse made us (SixXS) require that we
require valid address data. Next to that it is a RIPE requirement to
register /48 prefixes. Other Tunnelbrokers just started blocking things
like IRC and NNTP because there was too much abuse or traffic....
We kill off accounts of people when they abuse, google my name and you
will find various people who where caught in the act and are quite mad
that they can't have funny vhosts on IRC anymore and attract 500mbit
DoSses and other such nonsense which are not the goal of providing IPv6.
Also, the registration means that people can just type in their
username/password (and optionally which tunnel they want to use out of
the multiple tunnels they might have) in their CPE and the CPE then uses
TIC or TSP to fetch this configuration and set it all up, and it will
As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg
Next to that knowing where the user is and more importantly their
endpoint allows one to select a proper PoP for that user close to their
endpoint causing low latency and generally high throughput.
With anycast you are just hoping that that all will work.
Ietf mailing list