 Hallo und herzlich willkommen auf dem Femmkanal und zu unserem ersten Talk heute von Magau. Magau hat irgendwann mal angefangen bei Freifunk und ist dann irgendwann immer professioneller geworden und inzwischen beim C3-Infrastruktur-Team angekommen, können sich also jetzt genau gerade um die RC3 World und das Ganze was es dahinter gibt. Aus genau dem Grund gibt es heute auch keinen Q&A bei dem Talk, denn der Talk ist aufgezeichnet, Magau ist busy mit dem Betrieb. So, es geht um V6, IPv6 und zwar nicht wie sonst immer mit V4 zusammen, sondern Standelown, also quasi das, was der Traum eines jeden Netzwerkers unter 40 Jahren ist, wird ein paar Erfahrungen weitergeben und Tipps, falls wir das auch alle mal machen wollen. Done, and for the English speaking viewers, there will be a translation to listen to it, select the, under language selection, select the first translated option to hear the English translation. Und jetzt viel Spaß beim Talk mit Magau. Ja hallo, ich bin Magau, schön, dass ihr eingeschaltet habt zu meinem Talk, legacy IP gibt es nicht mehr, aber kein Netz ist auch keine Lösung, hier beim RC3 2021. Genau, worum geht es bei meinem Talk heute? Wie betreibe ich ein richtiges Netz mit IPv6 Focus oder soweit es geht IPv6 Only? Ein bisschen meine Erfahrungen, welche Probleme habe ich gefunden, welche Lösungen und natürlich auch ein bisschen Inspiration, was ihr für eure Netze, für eure Dienste mitnehmen könnt, damit vielleicht auch ihr dann in der Lage seid IPv6 Only zu sprechen, wenn ihr es noch nicht macht. Vorher, bevor wir loslegen, aber erst mal ein Disclaimer. In dem Talk und auch beim Netz geht es um, ich sage mal, echtes Internet. Das heißt, wir haben einen ARS, wir haben IP Space, der BTP mit dem Rest des Internets spricht. Das Ganze ist kein Spielzeug, Betrieb eines ARS ist deutlich mehr, als einfach nur irgendwo eine virtuelle Maschine klicken und da einen Liedungsdorf zu installieren und einen Webster hochzuziehen oder so. Also überlegt euch wirklich gut, ob ihr das könnt, ob ihr die Verantwortung tragen könnt und ja, ob ihr das auch braucht an der Stelle. Passt auf, dass ihr wisst, was er tut, weil wenn er das erst mal nur üben und umspielen mit BTP, mit Internet, mit Routing geht, gibt es zum Beispiel das CNC 42, das ist ein virtuelles Overlay Netz und das ist dafür sehr gut geeignet. Aber das sollte man nicht direkt produktiv im Internet tun. Genau. Dann, nachdem wir vom Micron geklärt ist, machen wir weiter mit der Theminologie. Ich werde in dem Talk ein paar Begriffe häufig nutzen, nämlich IP meint, oder richtiges IP, natürlich IPv6, das moderne, die 128-Bit-Variante und wenn ich von Legacy IP spreche, meine ich damit IPv4, die alte 32-Bit-Variante. Genau. Aber wie hat das Ganze eigentlich angefangen? Irgendwann in 2020 habe ich mir gedacht, so Infrastruktur betreibe ich eigentlich schon lang genug, also mehrere Jahre, das CNC 42 und auch bei anderen Fähigkeiten, Routing etc. auch schon einiges in Erfahrung gesammelt. Es hat sich ein ganz hanzo an Diensten angesammelt, der eh mal einen ordentlich Neubau brauchte, von daher so langsam lohnt sich eigentlich ein richtiges Netzwerk, oder? Was brauche ich denn für ein richtiges Netzwerk? Ich brauche erst mal ein autonomes System. Das kann ich, wenn ich nicht selbst Drive-Mitglied werde, von einem Sponsoring-Liar bekommen. Ich brauche Connectivity. Also irgendwie muss ich ja meine IP-Adressen meines autonomes Systems ins Internet bringen. Da gibt es virtuelle Maschinen mit ISP, also Internet-Exchange-Points-Anbindung. Es gibt virtuelle Maschinen mit BGP-Upstream, also auch das ist nicht das Problem. Zuletzt brauche ich natürlich von Netz noch IP-Adressen. Richtiges IP, also IPv6, auch kein Problem, gibt es zuhauf. ForWipe bekommt man einen Slecht48-Pi-Netz, also Provider Independent. Das ist an ein selbst oder an die Organisation gebunden, aber nicht an den Provider, der jemand um das reinstellt. Genau. Also, V6-Adressen haben wir. Legacy IP-Adressen oder auch IPv4-Adressen genannt. Jetzt wird es langsam interessanter, gibt es nämlich nicht mehr. Wenn man mal auf die Seite der Wipe guckt, wie die Wipe-Mitglieder auf neue IPv4-Adressen warten, sieht man, der Graf, die Warteliste steigt stetig an. Und ja, vermutlich hat es heute einen neuen Höchststand wie gestern, wie vorgestern, wie letzte Woche etc. Und auch der Gebrauchtmarkt, nenn ich es mal für IPv4-Adressen, ist jetzt nicht gerade so doll. Da bezahlt man definitiv einen zweistelligen Betrag im mittleren Größe für eine IPv4-Adresse. Natürlich auch je nach Präfix größer etc. Aber IPv4 ist eigentlich für so ein privates Best-Effort-Projekt, allein aus finanzieller Sicht schon keine wirkliche Lösung mehr. Was machen wir also? Einfach, nur IPv6. Nein, IPv6 haben wir ja. Ist kein Problem, oder ist kein Problem das zu bekommen? Machen wir IPv6 auch nicht. Als nächstes habe ich mir dann überlegt, was soll mein Netz eigentlich machen? Hab dann so eine kleine Liste an Diensten, die ich betreibe, die auch in dieses Netz an umziehen wollen. Natürlich ein klassischer Web-Server mit einem Blog dahinter. Eine Next-Lot, ein Headstock, also ein Head-Server, über den übrigens gerade diese Präsentation hier läuft. Mail-Server, so kommen wir später noch zu. Und auch noch das eine oder andere, je nachdem, wie gerade betraf es. Aber wenn man sich diese Liste anguckt, merkt man, das nutzen tatsächlich Menschen. Also es ist nicht nur für mich, um es zu haben. Da greifen tatsächlich Menschen drauf zu und wollen vielleicht das ein oder andere Mal mit diesen Diensten interagieren. Was machen wir jetzt aber, wenn Nutzer der Dienste nur Legacy-Appi haben? Wir haben ja eben gesagt, wir machen ein IPv6 Online-Netz. Kann man in mehreren Schufen lösen. Step 1, so mittelmäßig ernst gemeint, Awareness schaffen. Ihr seht hier diese schönen Banner auf meinem Blog. Falls ihr es nicht lesen könnt, da steht drin, du besuchst diese Seite mit einem veralteten IPv4 Internet zu. Möglicherweise treten in Zukunft Probleme mit der Erreichbarkeit und Performance auf. Bitte frage deinen Internetanbieter oder Netzag-Administrator nach IPv6 Unterstützung. Was ist die Idee dahinter? Wenn das genug Leute machen zu einem Marketing-Problem, wenn eine Netz- oder einen Provider keinen IPv6 können, also keine Ries-IP anbieten. Und damit wird sich das Problem lösen, weil dann hoffentlich mehr einiges IP anbieten, etc. Das ist eine schöne Diskussion für Twitter, wenn ich ehrlich bin. Wie gesagt, es ist nicht so ganz ernst gemeint, aber falls ihr das auch machen wollt, wie habe ich das Ding gemacht? EngineX hat eine Weichte drin, ob der Request per richtige IP oder per Legacy-Appi kam. Und wenn er herausfindet, dass er Request per Legacy-Appi kam, ersetzt er den schließenden Body-Tag mit diesem Banner und natürlich einem schließenden Body-Tag. Aber in Summe ist eine nette Spielerei, hilft aber nicht so lange, dass nicht sehr, sehr viele Webseiten etc. machen. Naja, also Step 1. Naja, brauchen wir also doch Legacy-Appi überall? Nein, weil dafür gibt's Step 2, den Layer 4 Proxy. Und da ist die Idee, dass eine geringe Anzahl an Kisten doch noch eine Legacy-Appi-Adresse bekommt. Bei mir heißen die Gateways, kann man nennen wie man will. Genau, und auf diesen Kisten läuft dann EngineX und der verteilt quasi die Anfragen an die Legacy-Appi-Adresse nach Port. Heißt, wenn eine Anfrage an TCP-Port 80 kommt über Legacy-Appi, weiß EngineX, schickt das an den und den Server mit richtigen IP etc. weiter. Nachteil ist dann natürlich, man braucht für jeden Dienst, der auf einem schon belegten Port was macht, eine neue IP-Adresse, eine neue Public-For-Fee-Adresse, weil sonst kann man es ja nicht mal auseinander sortieren. Heißt natürlich besonders für HTTPS und HTTPS, dass ich mir da ein zentrales VW Proxy-Gateway gebaut habe, weil ich sonst viel zu viele Gateways brauche, um das auseinander zu sortieren. Ich hab da auch mal eine Beispiel-Config. Man sieht hier den EngineX Stream Block, das ist nicht der Standard EngineX HTTPS Teil, sondern eben auf Layer 4, also TCP oder UDP. Man spezifiziert dann hier ein Upstream DNS UDP Backend in dem Beispiel, also hier geht es um DNS. Ein Server, in dem Fall V6 Only natürlich, mit einem Port, wo das Ganze hingeschickt werden soll. Und sagt dem EngineX dann hier bitte auf diese IP-Adresse UDP und Port. Das ist in dem Fall natürlich die Blick V4 sollte das sein. Die 10.1.2.3 ist einfach nur ein Exempel. Und das Ganze, das dann an das entsprechende Backend weiterleitet. Das Ganze gibt es hier drunter nochmal über die TCP-Variante. Genau, also eigentlich auch kein Hessenwerk, das Ganze zu machen. Wie sieht das samtlich aus? Internedienste, die nicht von außen erreichbar sein sollen oder müssen, haben bei mir generell nur eine Public V6-Adresse. Das heißt, wenn wir beim DNS bleiben, ein Hidden Primary, hat nur eine einzige V6-Adresse. Das ist auch die drauf konfigurierte, darunter ist er ja erreichbar. Aber braucht ja kein V4, wenn keine Endnutzer von V4, die nur V4 haben, von außen draufzugreffen müssen. Nehmen wir mal den Beispiel, den Secondary, der von Endnutzern erreichbar sein soll. Der Hostname und die IP, die die Kiste selbst hat, ist weiterhin V6 Only, wie man hier im oberen Beispiel erkennen kann. Die Endnutzer kriegen dann aber den anderen Hostname, hier zum Beispiel NS1-Exempel kommen. Und der geht für richtiges IP, einmal direkt auf die konfigurierte Adresse. Da hängt kein Gateway mal dazwischen, etc., das ist natürlich direkte Ende-zu-Ende-Kommunikation. Und die V4-Adresse geht an dieses Engine Extreme Gateway, was wir eben gesehen haben, was dann natürlich entsprechend konfiguriert sein muss. Das ist auf Port 53 eingehende Anfragen entsprechend behandelt. So, das Thema, wie sprechen Endnutzer mit den Servern, ist jetzt gelöst. Wie sprechen aber jetzt die Servern nach außen? Das Problem ist, manche Endpunkte haben kein richtiges IP. Da gibt es eine sehr, sehr bekannte Git-Webseite, die aktuell noch nicht per IPv6 Only bedienbar ist oder erreichbar ist. Was macht man also? The same procedure as every time. Wenn man ein Netzwerk-Problem hat und insbesondere ein Intersehungsproblem, macht man natürlich NAT. Diesmal nur nicht ganz so schlimm, wir machen nicht NAT 4.4, sondern wir machen NAT 6 vor. Das heißt, wir naten im Prinzip Adressen zwischen dem IPv6-Adressraum und dem IPv4-Adressraum. Das Ganze will ich jetzt nicht im Detail erklären. Das ist ein eigener Talk, da gibt es auch mehr als genug Infos und Literatur. Dazu, wie dieses NAT 6 vor eigentlich funktioniert. Zumindest wenn wir im Telekom Mobilfunknetzeit ist, ich hoffe, dass ihr das unwissentlich schon benutzt, tatsächlich relativ groß. Weil meines Wissens macht ihr das Telekom dann per Default oder bietet das per Default an. Die Realisierung bei mir ist, ich habe diesen Common Prefix, diesen V6-Prefix, wo der gesamte IPv4-Adressraum drin abgebildet werden kann. Dieserslich 96-Prefix wird im Internet von den 6 vor Gateways ernanzt, um quasi den Devices, die Routen dahin anzubieten. Also per ITP, genau. Und wenn eine IPv6-Only-Kiste jetzt auf eine IPv4-Only-Resource im Internet zugreifen will, macht sie eine Anfrage an den entsprechenden konfigurierten DNS-Visolver, der genaue Adresse in diesem Range hier zurückgibt. So wie Solver gibt es haufenweise, kann man selbst hosten, Google hat da was, Cloudflare hat da was. Das ist auch alles gelöst, das Problem. Einfach mal DNS64-Visolver googeln, da findet man was. Genau, also sind wir eigentlich fertig. Wir können von Ihnen nach außen kommunizieren und von außen nach innen. Gucken wir uns die Übersicht noch mal an. Erst mal unten haben wir unser großes IPv6-Only-Netzwerk. Bei mir läuft es mit OSBF und IPGP. Wir haben den ganz normalen Edgewater, der die Adressen ins Internet routet und umgekehrt. V6-End-User gehen direkt über diesen Edgewater, Ende zu Ende, zu dem Dienst unten auf der rechten Seite. Oben sehen wir noch Legacy-End-User. Der muss den Umweg über unser TCP-UDP Legacy2-V6-Proxy nehmen. Das ist die Nginx-Extreme-Config, die wir eben gesehen haben. Genau, auf der linken Seite nochmal zusammengefasst. Das, was ich eben kurz erklärte, wie native V6-Only-Services mit Legacy-Only-Ressourcen kommunizieren. Nämlich über ein NAT64-Gateway, was quasi auch an der Kante des IPv6-Only-Netzes steht. Und vorher mussten sie noch ein DNS64, wie soll man natürlich fragen, um erstmal die Adresse zu bekommen. Wäre natürlich zu schön, wenn das ganze Out-of-the-Box funktioniert und man nicht in ein oder anderen problematischen Dienst an der Stelle hätte. Woher hatte ich Probleme, wie habe ich die gelöst? Mail ist an sich kompliziert, weil reverse DNS etc., das muss alles passen, sonst wären E-Mails abgelehnt. Gleichzeitig ist E-Mail für mich ein sehr kritischer Dienst. Von da habe ich einfach von Anfang an gesagt, der lebt nicht IPv6-Only, der kriegt eine eigene V4 oder läuft sogar ganz außerhalb. An der Stelle noch mal. Überlegt euch gut, ob er dann eigene Mail-Server betreiben wollt. Wenn ihr das noch nicht macht, das ist adnistrativ. Nicht ganz einfach, wenn nicht sogar das kompliziert, dass da an der ganzen Geschichte hier einen verfügbaren, funktionierenden Mail-Server zu betreiben. Ein weiteres Problem, was ich hatte. Mit der netten Software Matrixynapse, ein Home-Server für Matrix, also Instant-Messaging. An sich läuft das Ding V6-Only. Es gibt da nur eine komische Library, die E-Mails verschickt und die kann kein Happy-Eye-Balls. Das heißt, wenn die versucht sich zu diesem SMTP-Server, der eine V4 und eine V6-Adresse hat, zu connecten. Aber über den über Legacy-IP nicht erreichen kann, weil eine V6-Only-Kiste natürlich keine Default-Rote für eine Legacy-IP-Adresse hat, wird die einfach aufzuf funktionieren. Also es gibt ein Teil am Auto, die kann es nicht erreichen. Habe ich noch nicht gelöst? Gibt ein GitHub-Icho dazu? Müsste man wahrscheinlich mal etwas viel Zeit reininvestieren und dann ist auch das Thema gefilgt. Aber aktuell ist es noch kaputt. Genau. Docker ist auch so ein Thema. Wenn man das entsprechend konfiguriert und die Zeit reinsteckt, läuft es dann per V6. Per Default nicht so wirklich. Ist eher anstrengend, sich um Docker in V6-Only zu kümmern. Geht aber, wenn man will. Weniger doll ist das Ganze mit Git-Lap-Onern. Ich habe mal versucht, ein Git-Lap-Onern in dieses V6-Only-Netz zu stellen. Die Kommunikation zwischen Containern klappte dann irgendwie nicht, wenn man Docker in Docker gemacht hat und dann doch irgendwie Docker-Service-Containern brauchte. Eventuell muss ich das Ding auf V4-Only zurückbauen und dann irgendwie so einen C-Lap dahin stellen. Also ohne jetzt ins Detail zu gehen, alles ganz schrecklich. Es ist aktuell weiterhin kaputt. Genau. Noch so ein Thema. Wenn ich per HTTPS in Zeit will, aber das eben nicht über dünn DNS machen will, sondern über einen direkt angebundenen über VPN angebundenen Jump-House nenn ich es mal. Ist das ein bisschen kompliziert, je nachdem wie man sein Netz aufbaut. Mein OpenVPN, sobald steht im IPv6-Only-Teil. Das funktioniert auch. Es kam trotzdem nicht drumherum, ein Reverse-Proxy-Chaining, also quasi ein Nut für HTTPS zu bauen, ist nicht schön, ging bestimmt anders, wäre es deutlich zeitaufwendiger. Genau. Dann kommen wir mal zum letzten wichtigen Teil. Konnektivität, Routing und Administration. Das ist jetzt nicht mehr so stark auf IPv6-Only bezogen, eher generell. Ich habe zwei Standorte mit BTP-Konnektivität nach außen. Einer XP-Vorm in Frankfurt und einmal eine Vorm nur mit Transit. Transit für V6 ist relativ günstig. Gratis V6 Transit ist zumindest für so kleine Projekte auch verfügbar. Und dann habe ich noch weitere Projekte, weitere Standorte mit billigem Compute, also wo die ganze Rechenleistung steht, wo ich aber leider kein BTP habe, zum Beispiel Herzna. Heißt, ich muss wie zwischen diesen beiden Standorten kommunizieren können. Da musste ich mir, weil ich nichts Besseres habe und ein WireGuard, also ein VPN Overlay bauen, waren intern, läuft da getrennt über Policy-Based Routing. IPvool ist ja Fan. VRS werden besser, um quasi die Sicht des eigenen Netzes und die Sicht des Herzna-Netzes zu trennen. Es gibt da auf der WireGuard-Mading-Liste eine Diskussion, die ist aktuell aber leider eher eingeschlafen. Also WireGuard kann dieses VRF noch nicht. Mit IPvool kriegt man das hin, das ist auch nicht so sonderlich großartig. Und es frisst natürlich MTU, also WireGuard. Genau, ihr wollt, wenn ihr sowas macht, strikte Firewall-Regeln haben, um Leaks zu unterbinden. Das heißt, ihr wollt nicht versehentlich aus eurem Internet Pakete mit eurer, mit eurer Source-IP an das Herzna Default-Gate versenden. Das wäre uncool, weil Herzna weiß ja nicht oder kennt ja euer IS nicht, oder euer Net nicht. Für Herzna ist das ja ein externes Netz, weil ihr da kein BTP-Abstemer habt. Also da wirklich aufpassen, was ihr da baut, vorher verstehen und dann bauen. Genau, mein Routing mache ich mit Spür 2 unter Linux, USPF als Interagelware-Protokoll, IBTP zwischen allen größeren Standorten. Ist im Wesentlichen Geschmackssache, wie man das baut. Da gibt es auch verschiedene Möglichkeiten. Genau, weiterhin das Thema Administration. Benutzt Configurationsmanagement. Ich benutze Allstack mit Ansible oder anderen Tools, geht das garantiert auch. Nur das wächst so schnell an, da kriegt ihr dann in die BTP-Filter, in die BTP-Konfiguration, in die Firewall-Regeln keine Konsistenz mehr rein. Wenn ihr das nicht, ich sag mal, systematisch ausrollt und per Config-Management sicherstellt, dass das System stabil und konsistent läuft. Genau, kommen wir zum Langsam, zum Ende. Was wäre noch cool für das Projekt? Weg von den IXP VMs hin zum echten Blech, was da steht und Pakete rotet oder auch Dienste hostet, ist natürlich aufwendiger und teurer, das mit echten Blech zu machen. Wer ist eine Option für die Zukunft? Genau, und echter Layer 2 Transportstart Overlay wäre natürlich auch cool, frisst mir dann nicht mehr die MTU-Weg und so weiter, ist aber gerade, was Standorte, Konnektivität etc. betrifft, nicht ganz real und auch nicht ganz billig. Sollte man definitiv machen, wenn das Netz produktiv führt, das ist irgendwie ein Best-Effort-Bastelnetz, oder Privatnetz, ist das so eigentlich in Ordnung. Fazit. Würde ich es nochmal machen? Definitiv V6 Only mit wenigen Legacy-App-Adressen auf den Edge, das ist durchaus sinnvoll machbar. Kostentechnik ist das eh schon interessant, gerade Hetzner hat ja zu kurz mit angekündigt, dass V4 zukünftig extra kosten wird oder es ohne V4 billiger wird. Also ja, das würde ich mir definitiv, mache ich definitiv weiter so und würde das auch in neuen Projekten so machen, dass ich V4 nur noch auf den Edge das habe, auch im privaten Umfeld, ihr habt ja gesehen, das ist nicht sonderlich kompliziert. Genau, der Aufbau mit diesen IXP VMs und Tunnelnaht zwischen ist okay für private Best-Effort-Services. Ihr hört schon, ich bin nicht so ganz überzeugt. Es ist nicht für wirklich produtive, produktive Netze geeignet, also nichts, was Geld verdient etc. Dafür Lea 2 Transport, ordentliche Peerings, ordentliche Transit, ordentliche Hardware. Genau, aber das ist ja hier in Nechtel auch nicht Ziel des Ganzen. Genau, und damit bin ich am Ende. Vielen Dank fürs Einschalten, fürs Zuhören. Und wenn ihr Fragen habt, sendet gerne eine Mail an rc3atipv6.schild. Und dann sind wir wieder zurück hier. Vielen Dank an Margot für den Talk. Es gibt leider kein Q&A, weil Margot mit der C3 Infrastruktur beschäftigt ist. Aber wie ihr gesehen habt, könnt ihr ihm ja eine Mail schreiben an die gerade eingeblendete E-Mail-Adresse. Hier auf dem Fernsehen geht es jetzt gleich weiter am 19 Uhr mit der nächsten Herald News Show und um 20.15 Uhr mit Wattie zu Networks als Datenquelle für Netzwerkinfrastruktur. Bis dahin.