Google-Hack für mehr IPv6-Peerings

Googles Engagement für das neue Protokoll ist beim RIPE-Treffen mit viel Beifall bedacht worden.

In Pocket speichern vorlesen Druckansicht 188 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Monika Ermert

Suchmaschinenriese Google macht die nächsten Schritte bei IPv6. Einem IPv6-Eintrag für die zentrale Suchseite www.google.com hält man zwar noch für zu gewagt, sagte Lorenzo Colitti, Entwickler und IPv6-Experte bei Google, beim RIPE-Treffen in Dubai. Noch könne rund einer von 10.000 Nutzern im Fall einer Dual-Stack IPv4/IPv6 Variante die Google-Seite gar nicht mehr erreichen. Zwar sei die Zahl, die Google in einer eigenen Studie mit Nutzern ermittelt hat, niedriger als erwartet, sagte Colitti. "Trotzdem ist das nicht akzeptabel," sagte Colitti.

Stattdessen wirbt Colitti für möglichst viele direkte Peerings, um die Leitung zu www.ipv6.google.com frei zu machen. Um auch mit kleineren Partnern peeren zu können, will Google über automatische Announcments per "BGP-Community"-Tag möglichst viele Partner in die eigenen IPv6 Peering-Tabelle aufnehmen. Letzteres wird von Fachleuten und Colitti selbst als "Hack" beschrieben, wurde beim RIPE Treffen allerdings positiv beurteilt.

Zu lange Antwortzeiten beim Verkehr zwischen IPv6-Sites sind laut Colitti eines der zentralen Probleme, die die weitere Verbreitung des neuen Adressprotokolls verzögern. "Die schwache Verbreitung sorgt dafür, dass es wenig Datenverkehr gibt. Wenig Datenverkehr führt zu schlechten Verbindungsraten, und schlechte Verbindungen verzögern die weitere Verbreitung," beschrieb Colitti den Teufelskreis. Backbone und Transitprovider machten aktuell einen schlechten Job beim Anbebot von IPv6-Konnektivität. Umständliche Pfade, suboptimales Routing und schlechte Middleware-Boxen sorgten dafür, dass die Latenzzeiten höher sind als bei IPv4. In manchem Tunnel verschwindet Datenverkehr auf Nimmerwiedersehen. 413 Millisekunden braucht ein IPv6-Paket von der US-Westküste nach China, stellten die Google-Forscher in ihrer Studie fest. Das wolle man keinem Nutzer zumuten, so Colitti.

Um die bereits IPv6-unterstützten Google-Dienste über IPv6 zugänglich zu machen, will man alle disfunktionalen Routen kappen und selbst mit IPv6-Anwendern peeren. "Wir wollen diese Routen nicht, wir kaufen keinen Transit ein," sagte Colitti. "Keine Verbindung ist besser als eine schlechte Verbindung." Stattdessen rief Colitti wie schon beim RIPE-Treffen in Berlin dazu auf, IPv6-Datenverkehr direkt mit Google auszustauschen. Mit vielen großen IPv6-Anbietern habe man bereits Peerings abgesprochen, mit dem französischen Provider Free, einer der größten IPv6-Anbieter, sei man beispielsweise im Gespräch.

Um möglichst vielen IPv6-Nutzern den Zugang zu Googles IPv6-Angeboten zu ermöglichen, sollen kleinere Netze sich mittels "BGP Community Tag" (RFC 1997) in Googles Netzwerk von "Trusted Usern" einklinken können. Das Präfix des IPv4 Resolver eines teilnehmenden Netzes müsse dafür mit einem eigenen "Community"-Tag wie 15169:6666 versehen werden. Damit ließen sich sich die Netze automatisch auf eine Whitelist nehmen. Mit der Signalisierung des ensprechenden Community Tag verpflichte sich der entsprechende Provider, für gute IPv6-Konnektivität zu sorgen und die eigenen Nutzer bei Schwierigkeiten zu unterstützen.

Googles hartnäckiges Engagement für das neue Protokoll wurde bei den Adressverwaltern mit viel Applaus bedacht. Der Vorstoß wird als ein Versuch gesehen, das Henne und Ei-Problem des IPv4-Nachfolgeprotokolls zu lösen. Zwar wird es in drei Jahren keine neuen IPv4-Adressen mehr geben. Trotzdem warten die ISP auf auf "Killerapplikationen", die Inhalteanbieter warten und wollen erst einmal die Nutzernachfrage sehen. Auch Colittis Aufruf an die Router-Hersteller, Ipv6 nicht als Zusatzfeature extra zu bepreisen, wurde in Dubai beklatscht. Ein solcher Preisaufschlag sorge dafür, dass IPv6-Unterstützung als erstes eingespart werde, warnten verschiedene RIPE-Mitglieder aus Unternehmen und Universitäten.

Zur drohenden Knappheit von IPv4-Adressen sowie zu den Bemühungen und Übergangsszenarien für IPv6 siehe auch:

(Monika Ermert) / (jo)