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:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
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.
Nach deiner Beschreibung ist es genau genommen kein DS-Lite sondern dualstack mit nicht öffentlicher IPv4 Adresse.
Das Verhalten für den Kunden ist ähnlich dem von DS-Lite, außer dass die IPv4 MTU wahrscheinlich besser ist.
Du willst darauf hinaus, dass der ISP im Backbone nicht auf reines IPv6-only (mit getunneltem IPv4), sondern auf Dual-Stack setzt? Ich hatte bisher Anschlüsse mit CGNAT immer als DS-Lite definiert, hier halt mitohne IPv6-only auf der WAN-Seite. ;)
Ja, das meinte ich. Ist schließlich in RFC 6333 so definiert.
Da hast du wohl Recht. Danke für den Hinweis. Ich habe die Passagen im Blogpost korrigiert!
Interessant wäre der Austausch vom ONT und direkte Nutzung an einer Enterprise Firewall mit Glasfaser.
Setzt DG AON oder GPON ein?
Bei AON ist ein Glasfasermodul zu finden recht leicht.
Es sieht aber nach GPON aus, da gar keine Authentifizierung stattfindet.
Hier müsste dann ggf. die Seriennummer vom GPON-Modul zur Freischaltung an DG gemeldet werden.
Kleiner Spoiler: Seit vorgestern habe ich eine PA-440 direkt am Modem hängen. Läuft super. ;) Artikel über DHCPv6-PD an der Palo kommt demnächst…
Auf dem Modem leuchtet eine “PON” LED. Und nach vorherigen Erfahrungen akzeptiert die Deutsche Glasfaser eine andere MAC-Adresse, wenn man das Modem neugestartet und eine Stunde gewartet hat. Scheint ein Timeout irgendwo zu sein. Auf jeden Fall hat die Vergabe per DHCP für IPv4 als auch DHCPv6 für IPv6 bei mir problemlos geklappt.
Richtig spannend wird es erst, wenn Du die Glasfaser direkt an die PA steckst. Mit einer PA-445 wäre das vielleicht möglich, GPON-SFP Module gibt es bei fs.com zu kaufen.
https://www.fs.com/de/c/gpon-onu-olt-3660
Mit den RJ-45 Ports der PA440 könnte es aber auch gehen: auf glasfaserforum.de habe ich schon Leute getroffen die sich einfach einen Medienconverter von Amazon bestellt haben (TP-Link MC220L):
https://www.tp-link.com/de/business-networking/accessory/mc220l/
Das waren zwar AON Anschlüsse, könnte aber mit GPON auch klappen wenn das SFP Modul beim Provider registriert ist (danke Routerfreiheit!).
Soviel ich weiß setzt die Deutsche Glasfaser nicht auf PPPoE, somit sollte es auch kein Problem sein IPv6 zum Laufen zu bekommen, wenn man die Glasfaser direkt an die PA Firewall holt. PAN-OS kann ja immernoch kein IPv6 mit PPPoE… wahrscheinlich wird sich das auch nie ändern.
Hey Simon. Ich habe in der Tat mittlerweile die Fritzbox durch eine PA-440 direkt ersetzt. Von der Deutschen Glasfaser hat das Glasfaser-Modem ja eine RJ45 Buchse direkt. Und in der Tat setzt die DG ja kein PPPoE ein, sondern nur direktes DHCP und DHCPv6-PD. Es läuft also super. ;)
Ein Artikel über DHCPv6-PD auf der Palo kommt demnächst.
Meine PA-220 bekommt auch bald Ablösung, vermutlich eine PA-445. Leider gibt es bei mir Glasfaser von “Glasfaser Nordwest”, also Telekom & EWE. Das heißt, mit PPPoE. Und das bedeutet wiederum kein IPv6, weil PAN immernoch kein IPv6 in PPPoE implementiert hat. Ich schätze, das wird auch nie passieren.
In der Zwischenzeit bin ich aber auf diese geniale Seite gestoßen: https://hack-gpon.org/
Dort sieht man, dass viele G-PON SFP Module in Wahrheit nur gebrandete/gelabelte Module sind.
Ich denke, den Anfang werde ich aber mit dem Telekom Glasfaser Modem 2 machen (gebrandetes Sercomm FG1000B.11). Das ist eigentlich gar nicht schlecht und hat deutlich mehr Wumms als die meisten SFP Module: https://hack-gpon.org/ont-sercomm-fg1000b-11/
Auf deinen DHCPv6-PD für Palo Alto bin ich gespannt, insbesondere auf das Firewallregelwerk. Mit dynamischen IPv6 Präfixen kann man nach meinem Verständnis nur noch zonenbasierte Firewall Policys machen?! Was PAN-OS seitig eindeutig fehlt, sind Objekte bei denen man das Objekt anhand eines IPv6 Interface ID definiert.
Hey Simon.
Good news: Mit PAN-OS 11.1 hat tatsächlich PPPoE für IPv6 Einzug gehalten: https://docs.paloaltonetworks.com/pan-os/11-1/pan-os-release-notes/features-introduced-in-pan-os/networking-features
Die Thematik mit GPON verstehe ich ehrlich gesagt nicht ganz. Ich dachte immer, dass es nur ein einfaches SFP Modul ist? Entweder die Firewall kann ein SFP-GPON Modul aufnehmen oder halt nicht. Im 2. Fall brauchst du dann halt einen Umsetzer/Modem. Genau so habe ich es ja bei mir zu Hause gelöst. Oder vergesse ich hier was? Gibt es verschiedene GPON Module? Authentifiziert dich der ISP mit genau dem Serial eines GPON Moduls oder sowas?
“Was PAN-OS seitig eindeutig fehlt, sind Objekte bei denen man das Objekt anhand eines IPv6 Interface ID definiert.” –> Können das denn andere Hersteller? Praktisch wäre es. Die Fritzbox macht das ja zum Beispiel so. ;)
Man muss aber ganz klar sagen: Das Konzept von dynamischen Präfixen ist absoluter Bullshit. Sehr schade, dass so viele deutsche ISPs es anwenden, obgleich es *keinen* Grund dafür gibt, außer einen teureren Businessanschluss mit statischen Adressen zu verkaufen. Das heißt aber auch, dass ich einen ISP-Anschluss mit dynamischen Präfix nur und ausschließlich im Privatkundensegment sehe, wo wiederum nur Clients im Netz sind; keine Server. Für die reicht wiederum ein einfaches Regelwerk, zB Zonenbasiert. Oder natürlich per User-ID. :)
(Ich persönlich habe mit der Deutschen Glasfaser echt Glück: Ich bekomme per DHCPv6-PD immer den gleichen Präfix. Juchu. Somit habe ich meinen Raspis usw. statische IPv6-Adressen geben, diese in Objekten auf der Palo verhackstückelt und im Regelwerk angewendet.)
Oh, das IPv6 mit PPPoE ab PAN-OS 11.1 möglich ist, ist eine gute Nachricht. Das freut mich wirklich :)
Alles Folgende ist mein Kenntnisstand. Irrtümer nicht ausgeschlossen!
Also:
gewöhnliche BASE-xx SFP Module und GPON SFP Module sind nicht vergleichbar. Bei GPON ist es nötig, dass GPON spezifische Verbindungsparameter ausgehandelt werden, ähnlich wie bei einem DSL Modem. Aus dem Grund läuft auf allen GPON ‘Modems’ eine Firmware, die das übernimmt. Der Formfaktor spielt dabei keine Rolle, es ist egal ob das ein GPON SFP Modul oder ein externes Gerät ist, welches meistens vom Provider kommt – auch bekannt als Glasfaser-Modem (NT). Darüber hinaus ist GPON verschlüsselt. Jeder PON Teilnehmer am gleichen Strang (in Deutschland üblicherweise bis zu 32 Teilnehmer) sieht alle Daten die über den Strang laufen, also auch die Daten anderer Teilnehmer. Damit Sicherheit und Privatsphäre gewährleistet ist, kommt AES Verschlüsselung zum Einsatz. Das ist in der GPON Standard so festgelegt (habe die RFC gerade nicht zur Hand). Der Grund dafür ist, dass das Prisma welches bei PON nötig ist, nicht etwa die Farben (Wellenlängen) für jeden Teilnehmer aufsplittet, sondern die Lichtimpulse für bis zu 32 Fasern vervielfältigt (PON arbeitet mit Zeitschlitzen, nicht mit unterschiedlichen Wellenlängen). Deshalb sieht jeder alles.
Da es notwendig ist, dass eine eigene Firmware auf den GPON Modems läuft, ist diese oftmals auch über eine vom Hersteller vordefinierte IP Adresse erreichbar. Ein Webinterface liefert beispielsweise Statusinformationen. Auf hack-gpon.org findet man aber auch Credentials, mit denen man per SSH in die Firmwares reinkommt. Witzigerweise gibt es einige GPON Modems die auf OpenWrt setzen, allerdings sind das heute total veraltete Versionen: 12 und 14.
Wie gesagt gibt es viele GPON spezifische Parameter. Der wichtigste Parameter ist wohl die Modem ID, welche zur Authentifizierung, also zur Wiedererkennung des Kunden eingesetzt wird. Es gibt aber auch nicht-GPON spezifische Parameter die ausgehandelt werden. Etwa kann der ISP das GPON Modem anweisen, alle Daten in ein bestimmtes VLAN zu werfen. Das freut mich persöhnlich sehr, denn wie wir wissen, können Palo Alto Firewalls (nach meinem Kenntnisstand) kein PPPoE auf Subinterfaces. Wenn das Modem das VLAN tagging also übernimmt, ist mir das sehr recht.
Zwei Anmerkungen noch zu GPON SFP Modulen:
1. die Dinger können ziemlich heiß werden. Liegt wahrscheinlich an der Ver- und Entschlüsselung. Ich habe nicht so Lust auf durch Hitzetod-sterbende SFP Module, aus dem Grund ist mir ein klassisches externes GPON Modem aktuell noch lieber. Vermutlich müssen noch ein paar Jahre ins land ziehen, bis die Dinger etwas weiter entwickelt sind. Das ist aber nur meine persönliche Meinung.
2. Das GPON SFP Modul welches bei Fritzboxen dabei ist, scheint ein Sonderfall zu sein, zumindest nachdem was ich so gelesen habe. Es funktioniert wohl nicht in anderen Geräten. Meine Vermutung ist, dass es “dumm” ist. Soll heißen, die Firmware ist nicht dauerhaft im GPON Modul gespeichert/geflasht, sondern sie wird beim Einschalten der Fritzbox in das GPON Modul geladen. Das macht Firmwareupdates vom GPON Modul deutlich leichter. Bei DSL Modems macht man das übrigens seit Jahren genauso.
Zum Thema IPv6 Interface ID:
ja, das können auch andere Hersteller. Ich kenne das vor allem von Lancom. Ja ich weiß… Lancom Geräte sind nur bessere Router, keine echten Firewalls. Aber das Arbeiten mit dynamischen IPv6 Präfixen funktioniert da echt traumhaft gut. Man kann dort, wie bei Palo Alto Firewalls auch, Objekte anlegen, welche über ihr IPv6 Interface ID definiert sind. Es gibt aber bestimmt noch weitere Hersteller die das können. Nur Palo Alto leider nicht :/
Ich stimme dir bedingt zu. Mir gehen dynamische IPv6 Präfixe auch mega auf den Keks. Allerdings erkenne ich auch an, dass feste Präfixe für nicht IT-affine Anwender völlig irrelevant sind. Eigentlich hätte ich gedacht dass Provider an festen Präfixen interessiert sind, denn wenn sich Adressen nicht ändern, bräuchten die Provider nur einen Bruchteil an Speicherplatz, um Verbindungsdaten zu loggen (was ja gesetzlich vorgeschriebenen ist). Aber andererseits setzen viele Provider auch im Jahr 2024 immernoch auf PPPoE. Cleverness darf man wohl nicht erwarten. Es hat wohl mehr Vorrang, ein paar Hobby- ITlern das betreiben eines Server Zuhause zu vermiesen.
Was ich vom Hörensagen weiß ist, dass man bei der Deutschen Glasfaser semi-feste IPs bekommt. Solange die Deutschen Glasfaser keine Änderung am Glasfaser OLT durchführt, läuft das wohl ewig so weiter.
Edit:
Vielleicht hätte ich das genauer erklären sollen.
tl;dr: GPON Modems sind keine Layer 1 Medienkonverter, sondern machen mehr.
Die Modem ID ist deshalb nötig, weil PON Netzwerke ein shared Medium sind, also vergleichbar mit Internet über DOCSIS Kabel. Um die Teilnehmer eindeutig identifizieren zu können wird also ein Indentifier benötigt. Dieser ist bei PON Modems auf dem Modem aufgedruckt und muss beim Provider registriert werden (danke Routerfreiheit!). Einige Provider haben aber auch einen Selfservice, wie etwa die Telekom. Erst dann ist ein Verbindungsausbau möglich. Die Modem ID sind, soviel ich weiß, 16 Hexadezimal Symbole, also 64 bit. Bei manchen Modems sind sie wohl auch kürzer, da muss man (ich glaube vorne) mit Nullen auffüllen. Bei allen gesendeten Daten über die PON Faser bekommt jedes Datenschnippsel die Modem ID angehängt (ähnlich wie ein VLAN tag), sodass zugeordent werden kann, für welchen PON Teilnehmer dieser Schnippsel ist, bzw. von welchem PON Teilnehmer es kommt. Ich weiß allerdings nicht ob die Modem ID im Klartext dafür genutzt wird, oder möglicherweise als Hashwert.
Bei AON Netzwerken ist das anders. Kein shared Medium, deswegen kann man ein AON Modem einfach einstecken und es geht los. Der Teilnehmer wird über seinen Port am OLT identifiziert. PON und AON haben beide Vor- und Nachteile. Aus Kostengründen machen aber die meisten Provider in Deutschland PON. Als größeren Provider kenne ich in Deutschland nur EWE Tel, der AON nutzt (und das auch nur bei reinen Eigenausbauten. Bei der Koorperation mit der Telekom (Glasfaser Nordwest) kommt PON zum Einsatz).
Übrigens:
da PON ein shared Medium ist kann es auch hier wie bei DOCSIS zu Überlastung kommen. Allerdings ist das Maximum in Deutschland üblicherweise 32 Teilnehmer. Also bei Weitem nicht so krass überbucht wie Kabelnetze. Außerdem können PON Netzwerke viel leichter aufgerüstet werden, ohne Tiefbauarbeiten. GPON, XGPON und XGSPON können ko-existent auf der selben Faser laufen.
Auch bei AON teilt man sich irgendwann einen Link ins Internet.
Die Frage ist halt wo und wie günstig der Provider aufrüsten kann.
Ich habe AON von EWE Tel und meine Gegenstelle ist ein Adtran hiX 5630. Dieser hat dann einen Uplink 10G Uplink zum nächsten Switch. Es stecken auf unserem schon sehr viele Glasfaser, es mehr also 10. Und wie viele Switches der nächste aggregiert und wie sein Uplink aussieht ist mir nicht bekannt.
Aber ich stimme voll zu, dass das Problem wesentlich geringer als bei DOCSIS ist.
Und die Latenz bei Glasfaser ist wirklich sehr sehr gut und das merkt man auch beim normalen surfen.
“Auch bei AON teilt man sich irgendwann einen Link ins Internet.”
Ich teile mir auch eine Glasfaser mit vielen anderen Menschen, wenn ich meine Daten durch ein transatlantisches Seekabel in die USA schicke. Darum geht es hier aber nicht.
Wenn man argumentiert, dass irgendwo im Providerinternen Netz mehrere Kunden über die gleiche Faser laufen, dann kann man gleich sagen, dass der ganze Provider und das ganze Internet ein shared Medium ist. Es geht bei der Frage aber nur um den Endverbraucher-Uplink. Um die Frage beantworten zu können muss also definiert werden, wo man die Trennlinie zieht.
AON ist in dieser Hinsicht 100% vergleichbar mit DSL. Die Anbindung der Endkunden zum ersten aktiven Hop (OLT oder DSLAM) ist dedicated. Das ist, worum es bei der Definitionsfrage “shared Medium: ja oder nein” geht. Denn ab dem ersten aktiven Hop kann die weitere Anbindung theoretisch beliebig schnell sein. Dass diese Anbindung ausreichend dimensioniert ist, fällt in die Verantwortung des Providers.
GPON, Kabel (DOCSIS) und Mobilfunk sind shared. Das Übertragungsmedium bis zum ersten Hop ist geteilt.