Kriterium: Unterstützung von IPv6

[marians]

Sollte die Unterstützung von IPv6 ein Prüfkriterium werden? Wenn ja, warum?

TODO

• Sicher stellen, dass wir in der ausführenden Umgebung IPv6-Konnektivität haben.
• Prüfen, ob dieselbe Site, die per IPv4 erreicht wird, auch per IPv6 erreicht werden kann.

[patrickhanft]

Ich glaube, wir sollten hier zwei unterschiedliche Prüfkriterien unterscheiden. Und zwar:

1.) Unterstützt die Website IPv6?
2.) Sofern ein AAAA-Record für die Website existiert, löst dieser auch richtig auf?

Wobei der zweite Fall der in meinen Augen wichtigere ist.

Unterstützt die Website IPv6?

So sehr ich auch dafür bin die Verbreitung von IPv6 zu fördern, so ist das erste Kriterium derzeit (noch) kein Zwangskriterium um gut im Internet erreichbar zu sein. Die "Legacy-Welt IPv4" wird eine per IPv4-only gehostete Website zwangsläufig erreichen und alle ISPs, die ihren Kunden keinen nativen IPv4-Zugang mehr ermöglichen (können), die also eine Form von Carrier-Grade-NAT (CGN) einsetzen (klassisch NAT44(4) oder DS-lite), liefern damit die Möglichkeit IPv4-Websites zu erreichen.

Es gibt dennoch Gründe dafür, die Aktivierung von IPv6 zu empfehlen. Und zwar eben gerade für Nutzer*innen hinter CGN-Setups (das sind wir übrigens auch alle im Mobilfunknetz!), da bei Verfügbarkeit von IPv6 dann diese CGN-Setups umgangen werden können.

Ganz abgesehen davon forcieren auch größere Content-Anbieter wie Facebook oder Google die Verfügbarkeit ihrer Inhalte per IPv6. Dass letztere diese Frage in ihren Page-Rank einfließen lassen könnten, halten manche nur für eine Frage der Zeit.

Ganz allgemeine Gründe für den Support von IPv6 sind neben der immer akuter werdenden IPv4-Adressknappheit im Internet und der damit verbundenen immer stärkeren Fragmentierung der IPv4-BGP-Routing-Tabellen im Default-Free-Zone-Internet, die Wiederherstellung des "Ende-zu-Ende"-Prinzips im Internet und der Verzicht auf NAT¹, sowie der inzwischen in Deutschland schon sehr große Support für IPv6: Bereits über 40% der deutschen Internet-Nutzer*innen erreichen Google inzwischen via IPv6².

¹ Durch diese Effekte wird IPv6 im Allgemeinen eine bessere Service-Qualität unterstellt. Jedenfalls messen große Content-Anbieter bessere Performance via IPv6 zu ihren Kunden. Insbesondere dort, wo im IPv4-Bereich große CGN-Setups zum Einsatz kommen. Spannend in diesem Zusammenhang: https://www.youtube.com/watch?v=76XbdedSrww Dort wird ein finanzieller Gegenwert für große Content-Provider bei der Nutzung von IPv6 aufgemacht, da die bessere Verfügbarkeit über IPv6 zu besseren Conversion-Rates führt …
² Siehe: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption

Wenn ein AAAA-Record für die Website existiert, löst dieser auch richtig auf?

Das zweite Prüfkriterium hingegen beschreibt ggf. einen klaren Fehlerfall. Wer in seinem DNS einen AAAA-Record für seine Website hinterlegt, behauptet damit explizit auch via IPv6 erreichbar zu sein und sollte dem dann auch Rechnung tragen.

Zwar Unterstützen aktuelle Browser beim Verbindungsaufbau typischerweise einen Fallback auf IPv4, wenn der IPv6-Verbindungsaufbau nicht innerhalb eines gewissen Zeitfensters zustande kommt, in diesem Fall erhöht sich aber natürlich auch die Latenz für den Seitenaufbau.

Und gerade weil dieser "Happy Eyeballs" genannte Algorithmus solche Fehler bei IPv6 in der Praxis oft verbirgt, sollte Green Spider diesen Fehlerfall erkennen. Es gibt jedoch auch stets Situationen, in denen Happy Eyeballs gar nicht zieht, beispielsweise beim Einsatz von curl.

Außerdem hilft Happy Eyeballs auch nicht, falls per IPv6 ein Verbindungsaufbau zustande kommt, jedoch vom Webserver falsche Inhalte ausgeliefert werden. Einer Website-Admin, die selbst ausschließlich eine IPv4-Verbindung ins Internet hat, wird dieser Fehler nie auffallen, während Nutzer*innen mit IPv6-Konnektivität keinen Zugang zu den Inhalten erhalten werden.

[marians]

Kann eine Website über IPv6 erreichbar sein, wenn es keinen AAAA-Record gibt? (Nein, ich gehe nicht davon aus, dass jemand direkt die IPv6-Adresse in den Browser eingibt.)

[marians]

Dieser Artikel von 2014 nennt einige klare Vorteile: https://teamarin.net/2014/07/02/ipv6-effects-web-performance/

• IPv6 does not fragment packets
• Checksumming Done at Higher Layers
• The IPv6 packet header is much simpler than the IPv4 header
• "Jumbograms": Having the ability to squeeze up to 4096 MB in a single packet will reduce the number of round trips required to download data.
• Better Mobile Performance

[patrickhanft]

Kann eine Website über IPv6 erreichbar sein, wenn es keinen AAAA-Record gibt?

Genau im gleichen Maße, in dem eine Website über IPv4 erreichbar sein kann, für die es keinen A-Record gibt. Der Webserver kann so konfiguriert sein, dass er auf einer IPv6-Adresse lauscht und die Website auch darüber ausliefert, aber wenn diese nicht im DNS hinterlegt ist, wissen wir von außen nichts davon, wie auch der Client der End-Nutzer*in.

Dieser Artikel von 2014 nennt einige klare Vorteile

Ja, diese Layer-2/Layer-3-Eigenschaften gelten alle im Prinzip. Ob sie am Ende auf Layer 7 dann so viel ausmachen … naja. Ich könnte mir vorstellen, dass langfristig die wegen des Einsatz von CGN schlechter werdende IPv4-Performance den größeren Effekt ausmacht, als diese Protokoll-Designaspekte.

Beispiel: "The IPv6 packet header is much simpler than the IPv4 header". Das hat insbesondere für die Verarbeitungseffizienz von Routern eine Bedeutung. Da lassen sich prinzipiell vielleicht ein paar Microsekunden herausholen. Aber in der IPv4-Welt ist das dort wo es darauf ankommt alles hardwarebeschleunigt. Teilweise auch in End-Nutzer*innen-Routern. Aber gerade dort ist IPv6 heutzutage eher noch in Software implementiert.

Ich glaube, in der Praxis spielt das sehr selten eine große Rolle und ich verweise dann lieber auf die praktischen Beobachtungen, wie sie größere Content-Anbieter machen, dass sie bei IPv6 durchschnittlich bessere Performance liefern. Da dürfte der vereinfachte v6-Header im Endeffekt aber nur einen winzigen Anteil daran haben.

[patrickhanft]

Vielleicht noch ein anderes Beispiel. Das hier:

Better Mobile Performance

ist eigentlich ein ziemlich interessanter Aspekt. Dadurch, dass bei IPv6 kein NAT notwendig ist, ist es sehr häufig möglich, TCP-Sessions ohne großes Keep-Alive sehr lange aufrecht erhalten zu können. Das bedeutet, dass Endgeräte beispielsweise langanhaltende Sessions zu Mailservern erhalten können, ohne z.B. alle 30 Sekunden ein Keep-Alive-Paket senden zu müssen.

Das Endgerät kann dementsprechend die Hardware der Netzwerkschnittstelle länger im Stromsparmodus belassen und schont damit teilweise signifikant die Akkulaufzeit.

Hat das im Bereich Websites eine praktische Relevanz? Eher kaum. Zwar gibt es HTTP-basierte Applikationen mit langlebigen Sessions, aber wohl eher nicht bei unserer Zielgruppe, oder?

HTTP ist als Protokoll ja gerade eher dafür designt worden, eine "Websurfing-Session" von der eigentlichen TCP-Session zu trennen und letztere eher wieder schnell zu beenden. Mag inzwischen auch an vielen Stellen anders sein, aber eher weniger bei uns, oder?

[marians]

Mit dem PR #124 werden erst mal Daten zu AAAA-Records gesammelt. Tatsächliche IPv6-Konnektivität wird noch nicht getestet. Wir können uns schon mal überlegen, wie es dann weiter gehen soll.

Mein Vorschlag: Wir machen erst mal nichts damit. Dann ergänzen wir den Check der Erreichbarkeit via IPv6. Dazu gehört meines Erachtens eine Überprüfung, dass per IPv6 die gleiche Site erreicht wird, die per IPv4 erreicht wird. Wenn wir den haben, können wir für das gesamte IPv6-Paket einen Punkt geben (AAAA-Record + Site ist erreichbar und identisch).

Für den AAAA-Record alleine schon einen halben Punkt zu geben, wäre auch noch eine Möglichkeit.

[patrickhanft]

Mit dem PR #124 werden erst mal Daten zu AAAA-Records gesammelt.

Cool, prima!

Tatsächliche IPv6-Konnektivität wird noch nicht getestet. Wir können uns schon mal überlegen, wie es dann weiter gehen soll.

Nachvollziehbar, denn für die weiteren Tests müssen wir selbst sicherstellen, dass Green-Spider IPv6-fähig ist. :-)

Mein Vorschlag: …

Stimme ich 100%ig so zu!

Für den AAAA-Record alleine schon einen halben Punkt zu geben, wäre auch noch eine Möglichkeit.

Das finde ich nicht so gut, da ein falscher AAAA-Record – also entweder verweisend auf eine nicht erreichbare IPv6-Adresse oder eben verweisend auf einen falschen Inhalt – für die End-Nutzer*in eine schlechtere Experience bedeutet als gar kein AAAA-Record.

Ziehst du für derartige kaputte Sachen denn auch Punkte ab? Dann wäre aus meiner Sicht ein vorhandener AAAA-Record der auf eine IPv6-Adresse verweist, auf der kein Webserver erreichbar ist ein halber Punkt Abzug (Happy-Eyeballs sollte schnell einspringen) und ein vorhandener AAAA-Record mit anderem Inhalt als der des A-Record ein ganzer Punkt Abzug, denn in diesem Falle sehen IPv6- und IPv4-Nutzer*innen zwei unterschiedliche Websites.

Gar kein AAAA-Record wäre aus dieser Sicht dann (zumindest im heutigen Internet) neutral.

[marians]

Ziehst du für derartige kaputte Sachen denn auch Punkte ab?

Nein, Minuspunkte gibt es nicht. Möchte ich eigentlich auch nicht, weil es dadurch für alle komplizierter wird. Dann warten wir mit dem Punkte-geben (oder eben nicht geben) bis wir IPv6-Konnektivität tatsächlich prüfen können.

[b90g]

https://netzbegruenung.de/blog/ipv4-macht-das-internet-ungerecht-das-muss-sich-aendern/ ganz vergessen zu verlinken, hier noch ein
"Warum" :)