Wegen Eurer Diskussion zu Transistion-Mechanisms:
6in4 verkapselt IPv6 in IPv4 - dazu braucht man eben einen Tunnelbroker. Im Fall von erhöhten Latenzen deutet das u.U. auf ein ausgelastetes Gateway hin; in diesem Fall -wie bei he.net vorgesehen-, kann man einfach den PoP wechseln, indem man einen anderen Tunnel auf einer anderen Location anlegt. Man bekommt dann aber auch einen anderen Prefix zugewiesen.
4in6 verkapselt IPv4 in IPv6 und mapt IPv4 zu IPv6.
6to4 ist eine Sonderform von 6in4. Technisch ist es dasselbe, aber der fix definierte IPv4 Tunnelpunkt wird per Anycast von mehreren PoPs angekündigt, man „fällt dort raus“, wo es auf dem Weg liegt. Das Protokoll macht Schwierigkeiten beim Zurückrouten des Prefix zum „richtigen“ IPv4-PoP und gilt daher als deprecated.
Dual Stack: natives IPv4 und natives IPv4
DS-Lite: Die Verbindung läuft rein über IPv6 ab, IPv4 wird mittels 4in6 auf Deinem jeweiligen „Providermodem“ (CPE) auf einen spezifischen Prefix geroutet, diese Pakete kommen dann auf einem Gateway an, der sie zu IPv4 rückübersetzt und ge-nat-tet.
Überlegungen zu DS-Lite: Ob die Adressen aus RFC1918 sein müssen, müsste ich erst in RFC6333 nachlesen. Im Grunde könnte man den Mechanismus auch für zugewiesene öffentliche IPs nützen, die aber dennoch am CGN/4in6-Gateway „anliegen“. Das wird bei Endkunden nicht gemacht und für zahlungskräftige Businesskunden kann man dafür ohnehin auf Dual Stack und MPLS/VPLS zurückgreifen.
Das Problem mit den 6in4 und 6to4 ist außerdem, dass man über eine externe IPv4 verfügen MUSS. D.h. hinter NAT kann man sich das abschminken, weil die in IPv4 verkapselten IPv6-Pakete einen routbaren, erreichbaren Endpunkt benötigen, und den gibt es gerade nicht, weil die letzte routbare Adresse das Gateway ist. Detto geht klassisches ipip, wie auch der SIT-Tunnel deshalb nicht. Auch würde Protocol 41 wohl in den meisten Fällen gar nicht ge-nat-tet werden, sondern nur tcp, udp, icmp und eventuell noch gre.
Für Knoten hinter einem NAT bleibt eigentlich dann nur ein TCP- oder UDP-Tunnel, wie ihn Teredo vorgesehen hat, oder man nützt eben einen eigenen Dual-Stack-Cloudhost mit einer Tunnellösung wie etwa OpenVPN. Teredo dürfte auch nicht mehr allzu aktiv sein und hat den Nachteil, dass es nur eine Adresse ( /128) zur Verfügung stellt, über die nicht weiter geroutet wird.
Eventuell kann lokal auch ein in einem RFC6598- Range (100.64.0.0/16) gelegener Node mit einem 6in4-Tunnel funktionieren, wenn der Access Provider und der PoP zusammenarbeiten und den Shared Adress Space routen. Ich bezweifle, dass das irgendwo real nutzbar existiert, denn dann kann man iaR auch gleich Dual Stack anbieten. https://tools.ietf.org/html/rfc6598