Als netzwerktechnisches Spielkind beschäftige ich mich nicht nur mit den Netzwerken großer Firmenumgebungen, sondern auch mit meinem eigenen Anschluss daheim. Vor vielen Jahren habe ich dem echten Dual-Stack Anschluss der Deutschen Telekom mal auf die Finger geguckt – heute ist die Variante der Deutschen Glasfaser an der Reihe, welches zwar ein Dual Stack, aber ohne eigene öffentliche IPv4 Adresse ist. Quasi ein halbes DS-Lite. Kernfrage für mich war: Kann ich die Fritzbox (mit ihren mitgelieferten Presets für verschiedene ISPs) durch eine echte Enterprise-Firewall ersetzen, die ja leider nicht unbedingt alle Sprecharten wie PPPoE im Subinterface oder PPP IPv6CP unterstützen.
TL;DR: DHCP, DHCPv6-PD, RA.
Testaufbau
Bei einem Privatkundenanschluss der Deutschen Glasfaser (DG) habe ich einen echten TAP (in Form meines ProfiSharks) zwischen das Glasfaser-Modem und der Fritzbox gepackt und entsprechend alle Pakete originalgetreu mitgeschnitten:
Das Glasfaser-Modem (NT) ist von der DG gestellt und ein Nokia G-010G-Q Gerät. Dort ist auch eine “Lower MAC ID” aufgedruckt, bei der ich aber nicht weiß, an welcher Stelle sie auftaucht. Es ist ja ein Modem auf Layer 1 und wandelt somit nur die Glasfaser auf ein Kupferkabel um. Ethernet (Layer 2) wird auf beiden Seiten gesprochen. (Oder? Zumindest gehe ich davon aus.) Als Router habe ich eine FRITZ!Box 7590 mit FRITZ!OS 7.56. Der Internetanbieter ist auf “Deutsche Glasfaser” gesetzt, die IPv6-Anbindung auf “Native IPv4-Anbindung verwenden”. (Hier könnte ich mal etwas mehr technische Details in der GUI gebrauchen, um zu verstehen, was genau diese Option im Gegensatz zu den anderen macht.)
Als TAP kam ein Profitap ProfiShark 1G zum Einsatz, welcher praktischerweise zwischen dem Modem und dem WAN-Port der Fritzbox eingeschleust werden konnte. Das Modem ging an Port A des TAPs, die Fritzbox an Port B. (Kann man in Wireshark bei Frame sehen, “on interface …_A bzw. …_B.) Modem und Fritzbox waren ausgeschalten. Ich hatte dann zuerst das Modem eingeschaltet und gewartet, bis sowohl “PON” als auch “LAN” grün leuchteten. Danach habe ich die Fritzbox eingeschaltet.
ABER: Dafür hat man *echtes* IPv6 Internet. Jeder Kund bekommt ein /56er Präfix, welches meiner Erfahrung nach sogar statisch ist. Es überlebt einen Reboot des Routers. Das ist unglaublich gut. Zum Glück macht die DG hier nicht den Quatsch eines dynamischen IPv6 Präfixes mit, wie es leider andere ISPs in Deutschland wie die Telekom machen.
Ich dachte immer, dass man diese Anschlussart bereits als DS-Lite bezeichnet. Technisch korrekt ist ein CGNAT aber nur die eine Hälfte von DS-Lite. Die andere wäre das Tunneln von IPv4 über eine IPv6-only Infrastruktur im Backbone des ISPs. Dies ist bei der DG nicht der Fall, was immerhin die typischen Probleme von DS-Lite Anschlüssen wie die verringerte MTU-Size umgeht. (Danke an Thomas für den Hinweis!)
Analyse
Zunächst mal kamen noch vor der IP-Adressvergabe bereits IPv6 und IPv4 Päckchen vom Modem an. Das waren aber alles vorherige Sessions von vor dem Ausschalten, oder eingehende Verbindungen zu meinen gehosteten Servern Raspis. Deutet auf jeden Fall darauf hin, dass dem Glasfaser-Anschluss ein dedizierter Port am vorgelagerten Switch/Router zugewiesen ist bzw. der ARP-/Neighbour-Cache noch am Leben war.
Legacy IP
Die öffentliche CGNAT IPv4 Adresse bekommt der eigene Router ganz klassisch per einfachem DHCPv4. Kein PPP oder PPPoE oder sonstwas und auch keine Authentifizierung. Einfach nur DHCP. Wie angenehm. Hier zwei Screenshots, welche das Discover der Fritzbox und das Offer der DG zeigen. ARP fand erst nach der DHCP Session statt. Und anscheinend ist der ARP Timeout der Fritzbox 300 Sekunden, weil immer dann (Delta Time) ein neuer ARP Request kam:
IPv6
Zunächst sendet die Fritzbox ihre Duplicate Address Detection (DAD, Punkt 1 im Screenshot) für ihre link-local Adresse, gefolgt von ein paar Router Solicitations (RS, 2). Diese RSs werden an dieser Stelle aber nicht durch ein entsprechendes Router Advertisement (RA) beantwortet! Das ist schon mal die erste interessante Erkenntnis. Für das DHCPv6 wartet die Fritzbox aber zum Glück nicht auf das M-Flag im RA, sondern fängt kurzerhand selbst mit einem SOLICIT (3) an. Der DUID Type der Fritzbox ist vom Typ “link-layer address” (Pfeil 4) und anfragen tut sie neben einer non-temporary address (5) auch einen Prefix ohne Längenangabe (6, DHCPv6-PD, Prefix Delegation):
Im DHCPv6 ADVERTISE sehen wir den Server Identifier der Deutschen Glasfaser vom Typ “link-layer address plus time” und eine MAC-Adresse, die von der OUI auf “VMware, Inc.” hinweist (1). (Fun fact: Die MAC-Adresse an dieser Stelle wird von Wireshark trotz der eingeschalteten “Resolve Physical Addresses” Option nicht aufgelöst. Einen Feature Request habe ich entsprechend gestellt, der keine 2 Tage später bereits implementiert war!) Dann die non-temporary address für das WAN-Interface das Fritzbox selbst (2), die IPv6 Adressen der rekursiven DNS Server (3), und schließlich der ersehnte Präfix mit einer /56 Länge (4). DANKE noch mal an dieser Stelle an die Deutsche Glasfaser, dass sie sich an sinnvolle Vorgaben hält und nicht etwa ein /60, /62 oder gar ein einziges /64 liefert. Nächste Erkenntnis: Die Fritzbox macht keine Duplicate Address Detection für die soeben erhaltene global unicast Adresse, obgleich der Standard (RFC 4862) das explizit vorschreibt. (Mehr bzgl. DAD hier.)
Interessant ist weiterhin, dass zu diesem Zeitpunkt noch nicht die Default Route bekannt ist. Denn:
Eben dieses notwendige RA (1) kam aber erst mit einer Verzögerung von knapp 600 Sekunden (2) = 10 Minuten (!!!) bei der Fritzbox an. Es deutet also darauf hin, dass die RAs seitens der Deutschen Glasfaser hier ausschließlich periodisch, nicht jedoch in Anfrage eines RS, verschickt werden. Die link-local Adresse des DG Routers sieht auch lustig aus: fe80::ff:fe:01:101 (3). Das M-flag ist korrekt gesetzt (4) und unmittelbar danach fragt die Fritzbox per Neighbour Solicitation auch nach der MAC-Adresse eben dieses Routers (5). Dieses NS wiederholt sich dann alle knapp 30 Sekunden. Ob der Neighbour Cache Timeout der Fritzbox auf nur 30 Sekunden steht?
Genau dieses Fehlen der Default Route sorgt leider für ein verzögertes IPv6. In der Tat hat ein Ping über IPv4 wenige Augenblicke nach Einschalten der Fritzbox wieder funktioniert, während IPv6 erst einige Minuten später lief. Entsprechend hatte bis dahin die Fritzbox korrekterweise mit einem “No route” von ihrer WAN-Interface GUA Adresse geantwortet:
From 2a00:6020:1000:40::436 icmp_seq=312 Destination unreachable: No route From 2a00:6020:1000:40::436 icmp_seq=313 Destination unreachable: No route From 2a00:6020:1000:40::436 icmp_seq=314 Destination unreachable: No route From 2a00:6020:1000:40::436 icmp_seq=315 Destination unreachable: No route From 2a00:6020:1000:40::436 icmp_seq=316 Destination unreachable: No route From 2a00:6020:1000:40::436 icmp_seq=317 Destination unreachable: No route From 2a00:6020:1000:40::436 icmp_seq=318 Destination unreachable: No route From 2a00:6020:1000:40::436 icmp_seq=319 Destination unreachable: No route 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=320 ttl=57 time=6.98 ms 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=321 ttl=57 time=4.65 ms 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=322 ttl=57 time=2.73 ms 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=323 ttl=57 time=4.20 ms 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=324 ttl=57 time=2.92 ms 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=325 ttl=57 time=4.94 ms 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=326 ttl=57 time=3.94 ms 64 bytes from redirector.heise.de (2a02:2e0:3fe:1001:302::): icmp_seq=327 ttl=57 time=5.84 ms
Nunja, es gibt schlimmeres. Aber ganz sauber ist es halt auch noch nicht. Und es sorgt natürlich nicht für ein “IPv6 ist genau so gut umgesetzt wie IPv4” bei den Endnutzern. :( Ich werde sowohl die Deutsche Glasfaser als auch AVM mal anschreiben/-twittern.
(Die oben gezeigten Pakete werden ihren Weg auch ins Ultimate PCAP finden.)
Fritzbox durch Firewall ersetzen
Bei meinem damaligen Versuch, an einen Glasfaseranschluss der Telekom eine Enterprise-Firewall ans Rennen zu bekommen, bin ich ziemlich gescheitert. Zu viele Untervarianten der PPP Protokolle konnten die Firewalls damals nicht richtig umsetzen. Hier sollte das jetzt anders aussehen. DHCP für IPv4 ist absoluter Standard, und auch DHCPv6 und DHCPv6-PD beherrschen die gängigen Betriebssysteme von Palo Alto Networks oder Fortinet. Ich bin gespannt. Und es bleibt noch offen, ob VoIP aka SIP mit der Deutschen Glasfaser funktioniert, wenn der SIP-Endpunkt nicht das direkt angeschlossene Gerät ist. Das ließ sich vor Jahren mit einer Juniper ScreenOS Firewall ebenso schlecht aufbauen.
Photo by Andrik Langfield on Unsplash.