Ohje das wird wohl ein längerer Text. Bei Interesse kann ich auch Abends mal einen kleinen Infoworkshop via Jitsi oä. basteln, wie das Innenleben eines ISP so aussieht. Im Testlab hab ich auch GPON/XGSPON/VDSL ISAMs zur Verfügung (Nokia, DZE wäre auch da, da kenne ich mich aber überhaupt nicht aus), wollte da auch mal mein eigenes Glasfasermodem 2 provisionieren, da könnten wir ein wenig zusammen rumprobieren, im Access bin ich nämlich auch "Fachfremd" 
PPPoE ist immer noch eine aus Endkundensicht nutzlose Last, CPEs loesen dass mit Hardware-Beschleinigern, die aber in der Regel ihre eigenen Trade-offs mit sich bringen, z.B. dass sie nur unter bestimmten (haeufig vorkommenden) Bedingungen funktionieren und bei bestimmten Netzwerkkonfigurationen eben nicht mehr vernuenftig arbeiten.
Im Falle von Mikrotik müsste Fasttrack mittlerweile eigentlich auch für IPv6 funktionieren. Jedenfalls kann es IPv4 beschleunigen, und da IPv6 in den meisten Fällen erst nach erfolgreichem Aufbau des IPv4 NCP via DHCPv6 vergeben wird, sollte das ja auch beschleunigt werden. Da muss ich selbst aber noch einmal genauer testen.
ABER, schon allein wegen der Standardvertraege der Telekom zu WIA und IP-BSA wird PPPoE in Deutschland so schnell nicht aussterben, egal was ich davon halten mag... (bei L2-BSA geht auch DHCP laut vertrag)...
Ja, die DTAG bietet bei IPBSA ausschließlich PPPoE an, L2BSA machen wir z.B. auch DHCP, allerdings gilt da bei der DTAG eine Besonderheit: der Outertag kann sich beim gleichen Anschluss ändern. BNGs stören sich daran nicht, aber man muss es halt wissen.
Ich bin da auch gegen PPPoE und für DHCP mit echten IPv6. 
War halt so ein DSL-Ding.
Es verursacht unnötig hohe Last im Router. Schau dir nur die Anforderung bei OpenWrt an, 1 GB/s-Leitung bekommst du nicht mehr mit einem Raspberry hin. Aber auch bei einer Unifi UDM sieht man Grenzen bei 1 GB/s, wenn Firewall hinzukommt. Nicht so bei DHCP auf der WAN-Seite.
Das ist dann aber eine Unifi Sonderlocke. Ich bekomme Sub-100-Euro Router, die 1G problemlos über PPPoE durchkriegen, auch mit ganz normalen Firewalling/NATting.
Die Identifizierung des Anschlusses per Modem-ID bei GPON sollte doch reichen als Zuordnung, bei AON ist es ja sowieso eine eigene Leitung, aber da gibt es ja auch häufig DHCP.
Die Identifizierung des Anschlusses geschieht nicht mit der Modem-ID, sondern einer, vom Provider fest vergebenen Line-ID. Mit der Modem ID wird lediglich ein Teilnehmer-ONT in einem PON-Strang identifiziert. Diese beiden Verfahren, also:
- Das Identifizieren eines legitimen ONT in einem PON-Segment, und
- Das Identifizieren eines Users hinsichtlich seines gebuchten Internetdienstes
sind zwei vollkommen separate Vorgänge. Da spielt die Art der Adressvergabe gar keine Rolle.
Es gibt dennoch ein paar Besonderheiten: bei DHCP wird die oben erwähnte Line-ID, neben einer Circuit-ID als Options Feld (Option 82) im DHCP Request mitgeschickt. Diese beiden Attribute können vom BNG ausgewertet werden. Daneben kann z.B. das ANCP-Protokoll verwendet werden. Hier kenne ich jedoch keinen einzigen Provider in Deutschland, der das tut. Die DTAG hat es wohl mal getestet, aber produktiv genutzt wurde es nie. Daneben können auch bei PPPoE im Intermediate Agent Informationen zur Line-ID (die eigentlich Agent Remote ID genannt wird), Circuit ID sowie Parameter zur "Access-Line" gesendet werden. Bei L2BSA Anschlüssen der DTAG werden diese Access-Line Attribute nicht immer mitgeschickt, oder sind manchmal auch schlicht falsch. Daher sind die auch eher mit Vorsicht zu genießen.
Außerdem ist PPPoE weltweit nicht sehr verbreitet und es gibt unterschiedliche Varianten, daher wird es bei vielen internationalen Routerhersteller nur lieblos unterstützt, z.B. mehrere VLAN.
Dem würde ich doch eher widersprechen wollen, außer du beziehst dich nur auf den Hersteller Unifi.
Bringt denn PPP dem Provider Vorteile im Management?
Ich weiß jetzt nur von der verfügbaren Bandbreite, die via PPP übermittelt wird.
Das ist ein längeres Thema, evtl. für einen oben genannten, Interaktiven Videocall
Wir sind einer der wenigen Provider, die Beide Arten im relativ großen Stil im Einsatz haben. PPPoE ist hier tendenziell aber eher auf dem absteigenden Ast, hat aber keine technologische Begründung. Begründung in ganz kurz: es skaliert wesentlich einfacher/breiter und schneller.
Naja, die Telekom braucht fuer ihre (WIA*)/IP-BSA/(L2-BSA**) Zwischenprodukte halt einfache Methoden eigene Pakete von denen der Resellerkunden zu unterscheiden und den Resellertraffic dahin zu tunneln wo er uebernommen wird. PPPoE ist da nicht die einzige Option, aber halt die noch aus den alten "Abrechnung nach on-line Zeit" Zeiten existierte, das ist dann halt entsprechend umgenutzt worden. D.h. IMHO ist der Vorteil von PPPoE gegeueber den Alternativen, dass es (teilweise) schon da war... (aber ich weiss da keine Interna, d.h. das ist Spekulatius der feinsten Sorte)
*) Bei wholesale internet access wird gerade mal die Rechnung vom Reseller erstellt, der Rest ist Telekom-Internet unter anderer Flagge.
**) Bei L2-BSA wird der Traffic lokal am BNG uebergeben, da kann der Kunde zwischen PPPoE und DHCP waehlen
Das ginge auch anders, ist aber auch aus den oben kurz genannten Gründen einfach geblieben. Ein weiteres Bonbon ist aber natürlich die einfache Weiterleitung von Traffic je nach Realm über L2TP, was die Entscheidung bei der Telekom sicher auch beeinflusst haben wird. Vor xBSA-Anschlüssen gab es von der DTAG sog. "Z-Gate" Wholebuy Anschlüsse, noch zu einer "Pre-BNG-Ära". Da wäre es tatsächlich nicht so trivial möglich gewesen einen DHCP-Kundenanschluss zu einem anderen Vorleister zu bringen.
PPPoE erlaubt, wenn ich mich richtig erinnere, auch Verschluesselung, wenn das genutzt wird, duerfte es richtig teuer werden was die CPU Last angeht, zumindest ohne entsprechende Offloads oder spezialisierte CPU-Befehle...
Verschlüsseln kann man grundsätzlich fast alles, beim normalen PPPoE kenne ich es jedoch nicht, da müsste ich mich auch erst die RFCs wühlen. Oder meintest du die verschlüsselte Übergabe der Credentials via CHAP ? Das setzt eigentlich auch so gut wie kein Provider hierzulande ein.
Setzt man PPP im GPON ein, dann reicht zur Provisionierung die GPON-Serial als Gerätekennung für die Verschlüsselung völlig aus, alle anderen Zuordnungsmetkmale erhält man aus dem PPP. Bei DHCP/IPoE im GPON fragen manche OLTs (meiner Meinung nach) unnötige Daten ab. Originär nur zum Sicherstellen, dass ein Nokia OLT nur mit einem Nokia ONT zusammen funktioniert. Man kann Nokia an dieser Stelle durch z.B. Ubuquiti, ZTE, Huawei und weitere ersetzen.
Das hat, wie weiter oben erwähnt, absolut nichts miteinander zu tun. Bevor ich am BNG ein PADI-Frame sehe, ist der ONT längst im PLOAM-State O5.
Ich wette die meisten OLT koennen DHCP Option 82 und damit ist es prinzipiell ebenfalls moeglich den Anschlussinhaber zu identifizieren
Korrekt.
Der OLT muss den ONT identifizieren koennen, mehr diese ID weiter nach oben durchreichen koennen, und das geht mit DHCP genauso wie mit PPPoE. Ich meine sogar, dass war bei DHCP schon laenger ueblich, dass die Telekom das auch bei PPPoE fier ihre eigen Kunden macht ist da eher das Novum (PPPoE-Verkapselung ist immer noch notwendig, aber PPPoE Nutzername und Passwort sind egal/nicht mehr notwendig).
Ja, das stimmt. Allerdings hat der Wegfall von Username/Password bei PPPoE mit der DTAG damit nix zu tun. Das ist Sache des BNG, der bei aktivierter Funktionalität (ich glaube, die Telekom nennt es "Easy Start" oder so), den Teilnehmer ausschließlich anhand seiner Line-ID zu identifizeren.
Hm, ich denke das ist schon zu weit fortgeschritten, da findet ja schon Kommunikation statt. Die Identifikation bzw. Provisionierung des Endgerätes findet über die GPON-Serial im GPON-Protokollstack statt. Ob danach noch die Line-ID oder Circuit-ID via DHCP Option benötigt wird?
Ja wird benötigt, siehe oben.
