Also musste ich den Fehler suchen. Die Überwachungstechnik zeigte mir keinen Ausfall in der Backbohne an. Eine Fehlfunktion bei anderen Webseiten war ebenfalls nicht feststellbar.
Bei so einer Situation denkt man dann immer erst mal an ein Problem der Verbindungen der einzelnen Netzwerke untereinander, aber sowohl ping www.rtl.de als auch ping6 www.rtl.de haben einwandfrei funktioniert. Das war echt sonderbar.
ping6 www.rtl.de PING www.rtl.de(2a03:d680::200) 56 data bytes 64 bytes from 2a03:d680::200: icmp_seq=1 ttl=59 time=99.2 ms 64 bytes from 2a03:d680::200: icmp_seq=2 ttl=59 time=15.1 ms 64 bytes from 2a03:d680::200: icmp_seq=3 ttl=59 time=17.0 ms 64 bytes from 2a03:d680::200: icmp_seq=4 ttl=59 time=15.6 ms 64 bytes from 2a03:d680::200: icmp_seq=5 ttl=59 time=15.1 ms 64 bytes from 2a03:d680::200: icmp_seq=6 ttl=59 time=15.1 ms 64 bytes from 2a03:d680::200: icmp_seq=7 ttl=59 time=15.6 ms 64 bytes from 2a03:d680::200: icmp_seq=8 ttl=59 time=15.8 ms 64 bytes from 2a03:d680::200: icmp_seq=9 ttl=59 time=14.8 ms ^C --- www.rtl.de ping statistics --- 9 packets transmitted, 9 received, 0% packet loss, time 8008ms rtt min/avg/max/mdev = 14.815/24.865/99.204/26.290 ms
Der Schnelltest hat gezeigt, das www.rtl.de neben dem alten IPv4 Internet auch das neue IPv6 Internet unterstützt. Nötig wurde das neue IPv6 Internet, weil bei IPv4 die Adressen 32 Bit Lang sind. 232 sind 4.294.967.296 mögliche Teilnehmer am Internet. Von dieser Zahl gehen aber noch etliche Adressen für Sonderfunktionen ab. So gibt es Beispielsweise 224 = 16.777.216 Adressen für die Rechner interne Kommunikation, 17.891.328 Adressen für die Lokale Belegung, die also nicht im öffentlichen Teil des Internets transportiert werden und von jedem lokal genutzt werden können oder 268.435.456 Multicast Adressen für die Handhabung von Rundsendungen, die also von den Routern nach ganz anderen Regeln behandelt werden.
Es gibt also weniger als 4 Milliarden Adressen, aber auf der Welt leben über 7 Milliarden Menschen. Die IP's reichen also nicht mal dazu, jedem Handy eine zuzuweisen, selbst dann wenn die Leute beim schlafen alle Ihr Handy ausschalten würden. Aus diesem Grund ist die Vergrößerung des Adressraums von 232 auf sagenhafte 2128 das zentrale Feature bei der Umstellung von IPv4 auf IPv6. Wärend also früher eine IP den Speicherplatz von 4 Buchstaben in Anspruch nimmt, sind es heute 16 Buchstaben. Die über 340.000.000.000.000.000.000.000.000.000.000.000.000 Adressen werden dazu genutzt, die Vergabe der Adressen zu systematisieren. Übrigens falls sie diese Zahl vorlesen wollen, sie heißt in Worten Dreihundertvierzighexillionen.
Wird ein Kunde an das IPv6 Angeschaltet, so erhält er typischerweise einen 48 Bit Präfix. Mit jedem Internetzugang werden also immer 280, also über 1.200.000.000.000.000.000.000.000 Adressen für die Peer to Peer Kommunikation zugewiesen sowie noch mal 248 = 280.000.000.000.000 Adressen für die Aussendung von Multicast, also wenn man so will Rundfunk Adressen. Es ist klar, das jeder einzelne Internet Anschluss genug Kapazität hat, um das ganze Sonnensystem zu Verkabeln. In dem oberen 48 Bit ist ein 16 Bit Präfix reserviert, der zusammen mit den 32 Bit der IPv4 Adresse hinter jeder gültigen IPv4 Unicast Adresse solch ein 80 Bit IPv6 Netz zuordnet. Damit kann jeder Router, der IPv6 beherrscht auch dann IPv6 Routen, wenn der Anbieter sich noch gar nicht um IPv6 gekümmert hat. Dazu werden die Pakete von IPv6 fähigen Routern in einem Tunnelpacket an die zuständige IPv4 Adresse gesendet. Wird eine IPv6 Adresse außerhalb des Kompatibilitätsbereichs gesendet, so wird der Nächste IPv6 Router über die Anycast Adresse 192.88.99.1 angesteuert. Einziger Nachteil, das Multicasting, also der Netzwerk effektive Empfang von Rundfunksendungen, wird nicht unterstützt.
IPv6 ist eine sehr grundsätzliche Revision des Internets. So wurden zum Beispiel beim IPv4 Pakete die an einen Ort geroutet wurden wo sie grössenmäßig nicht hindurch passten von den Routern in kleinere fragmentiert. Damit war es aber in seltenen Fällen möglich, wenn der Erste Engpass 1300 Byte, der nächste 1100 Byte als Grenzwert hatte, das ein Paket von 1500 Bytes in eines mit 1100Bytes und zwei mit 200 Bytes zerlegt wird. Unschwer zu erkennen, das diese Suboptimal ist. Die technische Entwicklung führte dann dazu, das man in den IPv4 IP Stacks dazu überging, das Don't Fragment Bit zu setzen, welches die Router anwies, mit ICMP Packt zu Groß den Transport zu verweigern. Aufgrund der Ergebnisse mit ICPM Paketen konnten die Endstellen dynamisch die Maximale Paketlänge zu den einzelnen Zielen bestimmen, und mit diesem Wissen die Pakete gleich mit optimaler Länge auf die Reise zu schicken.
Auf diese Weiße hat man das IPv6 aufgeräumt und von Historischen Ballast bereinigt. Mit dem gewonnen Platz werden die längeren Adressen möglich gemacht. Der Preis für diese grundsätzliche Revision ist aber, das IPv4 und IPv6 als unabhängige Netze nebeneinander existieren. Ich kann also nur kommunizieren, wenn beide Seiten IPv4 können oder beide Seiten IPv6 können. Können beide Seiten beides, so sehen die technischen Regeln des Internets vor, das IPv6 zu verwenden ist. Hat ein IPv6 Rechner keinen eigene IPv4 Adresse und will mit einem IPv4 Rechner kommunizieren, so muss er ein Gateway wie zum Beispiel einen Dual stack Proxy oder das neu definierte aber noch nicht weitläufig implementierte NAT64 verfahren verwenden verwenden.
Jetzt haben wir die Grundlagen zu verstehen, warum www.rtl.de aus dem IPv6 Netz nicht zu erreichen war. Der Browser hat zunächst festgestellt, das sowohl eine IPv4 als auch eine IPv6 Adresse hinterlegt ist.
> dig -t a www.rtl.de ; <<>> DiG 9.8.3-P2 <<>> -t a www.rtl.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10794 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.rtl.de. IN A ;; ANSWER SECTION: www.rtl.de. 3050 IN A 217.118.169.100 ;; AUTHORITY SECTION: rtl.de. 24590 IN NS ns2.eurodns.com. rtl.de. 24590 IN NS ns3.eurodns.com. rtl.de. 24590 IN NS ns4.eurodns.com. rtl.de. 24590 IN NS ns1.eurodns.com. ;; Query time: 2 msec ;; SERVER: 195.52.22.21#53(195.52.22.21) ;; WHEN: Thu Aug 23 02:30:37 2012 ;; MSG SIZE rcvd: 127 > dig -t aaaa www.rtl.de ; <<>> DiG 9.8.3-P2 <<>> -t aaaa www.rtl.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23963 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.rtl.de. IN AAAA ;; ANSWER SECTION: www.rtl.de. 36 IN AAAA 2a03:d680::200 ;; AUTHORITY SECTION: rtl.de. 24576 IN NS ns4.eurodns.com. rtl.de. 24576 IN NS ns3.eurodns.com. rtl.de. 24576 IN NS ns1.eurodns.com. rtl.de. 24576 IN NS ns2.eurodns.com. ;; Query time: 3 msec ;; SERVER: 195.52.22.21#53(195.52.22.21) ;; WHEN: Thu Aug 23 02:30:51 2012 ;; MSG SIZE rcvd: 139
dig -t aaaa www.rtl.de ; <<>> DiG 9.8.3-P2 <<>> -t aaaa www.rtl.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23963 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.rtl.de. IN AAAA ;; ANSWER SECTION: www.rtl.de. 36 IN AAAA 2a03:d680::200 ;; AUTHORITY SECTION: rtl.de. 24576 IN NS ns4.eurodns.com. rtl.de. 24576 IN NS ns3.eurodns.com. rtl.de. 24576 IN NS ns1.eurodns.com. rtl.de. 24576 IN NS ns2.eurodns.com. ;; Query time: 3 msec ;; SERVER: 195.52.22.21#53(195.52.22.21) ;; WHEN: Thu Aug 23 02:30:51 2012 ;; MSG SIZE rcvd: 139
Dann wird anhand der Erkenntnis, das beide Peers IPv6 können die Entscheidung getroffen, die Verbindung per IPv6 aufzubauen. Weil aber nun die IPv6 Adresse in der Verarbeitung im Webserver ein Problem hatte, wurde der Verbindungsaufbau zurückgewiesen.
> telnet 2a03:d680::200 80 Trying 2a03:d680::200... telnet: connect to address 2a03:d680::200: Connection refused
Hier nochmal ein tcpdump des obigen Vorgangs:
# tcpdump -i wlan1 -n host 2a03:d680::200 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlan1, link-type EN10MB (Ethernet), capture size 65535 bytes 02:40:34.705132 IP6 2002:d914:7335:181:21d:e0ff:feae:a509.34602 > 2a03:d680::200.80: Flags [S], seq 2294964999, win 14360, options [mss 1436,sackOK,TS val 113692357 ecr 0,nop,wscale 7], length 0 02:40:34.962353 IP6 2a03:d680::200.80 > 2002:d914:7335:181:21d:e0ff:feae:a509.34602: Flags [R.], seq 0, ack 2294965000, win 0, length 0 ^C 2 packets captured 2 packets received by filter 0 packets dropped by kernel
Man kann verstehen, das sich die großen Provider, die aufgrund ihrer Größe und der früheren Entwicklung des Internets in Amerika und Europa einen ausreichenden Vorrat von IPv4 Adressen zugeteilt bekommen haben, mit der Einführung von IPv6 bei uns zurückhalten. Wenn eine Installation von gesamtgesellschaftlicher Relevanz wie rtl.de so ein Problem produzieren, dann hätte so ein großer Provider Ruck Zuck tausende oder sogar zehntausende von Support anfragen im System.
Das Problem ist im Übrigen weiter verbreitet als man denkt. So war auch das Liquid Feedback der Piratenpartei aus dem gleichen Grund nach der Umstellung einige Stunden nicht aus dem IPv6 Bereich zu Erreichen. Besonders ärgerlich ist das, wenn man Bedenkt, das sich die Konkurrenz durch die Einführung von LTE deutlich verschärft hat, und so eine Panne geeignet ist bei den Kunden den Eindruck zu erwecken, das die kleineren IPv6 basierenden Installationen unzuverlässig wären.
Es wäre Wünschenswert, wenn Webseitenbetreiber neben www.website.com auch wwwv4.website.com und wwwv6.website.com vereinbaren würden, damit man auch explizit nur eine v4 Verbindung oder nur eine v6 Verbindung aufbauen kann. Beispielweise ist www.v6.facebook.com ein reiner IPv6 Service. Wenn Sie diese Adresse nicht erreichen, haben sie kein IPv6. Damit wird das Testen sehr viel einfacher. Das macht aber nur Sinn, wenn der Webserver nur mit dem Port ohne die Adresse konfiguriert wird, so das sowohl IPv4 als auch IPv6 über die gleiche Schnittstelle empfangen und über die gleichen Konfigurationsregeln bearbeitet werden.
Unter http://www.sixxs.net/tools/gateway/ gibt es einen Proxy, der es erlaubt aus der IPv6 Welt heraus auf die IPv4 Welt und umgekehrt zuzugreifen. Das ist eine Nützliche Sache um nach dem aufsetzen oder verändern der Konfiguration eines Servers beide Verbindungswege zu testen. Das sollte man als Betreiber von Webseiten sorgfältig machen, um den Umstieg auf IPv6 nicht zu diskreditieren. Wenn Sie wissen wollen, ob ihr Netzwerk bereits IPv6 kann, rufen sie diesen IPv6 Test auf. Mit der Website http://ipv6-test.com/validate.php können sie die IPv6 Funktionalität einer Webseite unabhängig vom Browser testen.
Keine Kommentare:
Kommentar veröffentlichen