Legacy IP? Gibts nicht mehr. Aber kein Netz ist auch keine Lösung. Modernes IP aus Sicht eines "Rese

Herald: Hallo und herzlich willkommen auf
dem FEM Kanal und zu unserem ersten Talk

heute von margau. Margau hat irgendwann
mal angefangen bei Freifunk und ist dann

irgendwann immer professioneller geworden
und inzwischen beim C3 Infrastructure Team

angekommen. Kümmert man sich also jetzt
genau gerade um die RC3 World und das

ganze was es dahinter gibt. Aus genau dem
Grund gibt es heute auch kein Q&A bei dem

Talk, denn der Talk ist aufgezeichnet.
Margau ist busy mit dem Betrieb, so. Es

geht um IPv6 und zwar nicht wie sonst
immer mit ... v4 zusammen, sondern

standalone. Also quasi das, was der Traum
eines jeden Netzwerkers unter 40 Jahren

ist. Er wird ein paar Erfahrungen
weitergeben und Tipps, falls wir das auch

alle mal machen wollen, dann... for the
English speaking viwers, there will be a

translation. To listen to it, select on
the language selection select the first

translated option to hear the english
translation. Und jetzt viel Spaß beim Talk

mit Margau.
[placeholder remove me in amara]

margau: Ja hallo, ich bin margau. 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. 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 bei meinem Netz geht es um, ich
sage mal, echtes Internet. Das heißt, wir

haben einen AS, wir haben IP-space der BGP
mit dem Rest des Internets spricht. Das

ganze ist kein Spielzeug! Betrieb eines
AS's ist deutlich mehr als einfach nur

irgendwo eine virtuelle Maschine klicken
und da einen Linux drauf zu installieren

und einen Webserver 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
ihr tut. Weil, wenn es erst mal nur ums

Üben und ums Spielen mit BGP, mit
Internet, mit Routing geht, gibt z.B. das

den DN42, 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 der

Formalkram geklärt is, machen wir mal
weiter mit der Terminologie. Ich werde in

dem Talk ein paar Begriffe häufig nutzen,
nämlich IP oder richtiges IP meint

natürlich IPv6, das Moderne die 128 Bit
Variante und wenn ich von Legacy IP

spreche, meine ich damit IPv4, die alter
32 Bit Variante. Genau. Aber wie hat das

ganze eigentlich angefangen? Irgendwann in
2020 habe ich mir gedacht, so

Infrastruktur betreibe ich eigentlich
schon lange genug, mehrere Jahre. Das DN42

und auch bei anderen Möglichkeiten,
Routing etc. auch schon einiges an

Erfahrung gesammelt. Es hat sich in ein
ganzer Zoo an Diensten angesammelt, der

mal einen ordentlichen 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 RIPE-

Mitglied werde, von einem Sponsoring LIR
bekommen. Ich brauche Konnektivität. Also

irgendwie muss ich ja meine IP Adressen
meines Autonomen Systems ins Internet

bringen. Da gibt es virtuelle Maschinen
mit IXP, also Internet Exchange Points

Anbindung. Es gibt virtuelle Maschinen mit
BGP Upstream. Also auch das ist nicht das

Problem. Zuletzt brauche ich natürlich im
Netz noch IP Adressen. Richtiges IP, also

IPv6, auch kein Problem. Gibt es zu Hauf,
von RIPE bekommt man /48 PI als Provider

Independent und das ist an einen selbst
oder an die Organisation gebunden, aber

nicht an den Provider, der jemandem das
bereitstellt. 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

RIPE guckt, wie die RIPE-Mitglieder auf
neue IPv4-Adressen warten, sieht man der

Graph, 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, nenne ich es mal, für
IPv4-Adressen ist jetzt nicht gerade so

toll, da bezahlt man definitiv einen
zweistelligen Betrag in mittlerer Größe

für eine IPv4-Adresse, natürlich auch je
nach Präfixgröße etc. Aber IPv4 ist

eigentlich für so ein privates Best Effort
Projekt allein aus finanzieller Sicht

schon keine wirkliche Lösung mehr. Was
macht man also? Einfach nur IPv6? Weil

IPv6 haben wir ja. Ist kein Problem oder
ist kein Problem, das zu bekommen. Machen

wir IPv6 only. Als nächstes habe ich mir
überlegt, was soll mein Netz eigentlich

machen? Ich habe dann so eine kleine Liste
an Diensten, die ich betreibe, die auch in

dieses Netz dann umziehen sollen.
Natürlich ein klassischer Webserver mit

einem Blog dahinter, eine Nextcloud, einen
Hedgedoc, über den übrigens gerade diese

Präsentation hier läuft. Mailserver,
kommen wir später noch zu und auch noch

das eine oder andere, je nachdem wie
gerade Bedarf ist. 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 eine oder andere Mal mit
diesen Diensten interagieren. Was macht

man jetzt aber, wenn die Nutzer der
Dienste nur Legacy IP haben? Wir haben ja

eben gesagt, wir machen ein IPv6 only
Netz. Kann man in mehreren Stufen lösen.

Step 1, so mittelmäßig ernst gemeint,
Awareness schaffen. Ihr seht hier diese

schönen Banner auf meinem Blog. Falls ihr
das nicht lesen könnt, da steht drin: Du

besuchst diese Seite mit einem veralteten
IPv4-Internetzugang. Möglicherweise treten

in Zukunft Probleme mit der Erreichbarkeit
und Performance auf. Bitte frage deinen

Internetanbieter oder Netzwerk-
Administrator nach IPv6-Unterstützung. Was

ist die Idee dahinter? Wenn das genug
Leute machen, wirds zu einem Marketing

Problem wenn ein Netz oder ein Provider
kein IPv6 kann, also kein richtiges IP

anbieten. Und damit wird sich das Problem
lösen, weil dann hoffentlich mehr

richtiges IP anbieten etc. Das ist eine
schöne Diskussion für Twitter, wenn ich

ehrlich bin. Wie gesagt, ist nicht so ganz
ernst gemeint, aber falls ihr das auch

machen wollt, wie habe ich das Ding
gemacht? nginx hat eine Weiche drin. Ob

der Request per richtigem IP oder per
Legacy IP kam. Und wenn er herausfindet,

dass der Request per Legacy IP 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 nichts,
solange das nicht sehr sehr viele

Webseiten etc. machen. Naja, also Step 1
naja. Brauchen wir also doch Legacy IP

überall? Nein, weil dafür gibt es Step 2,
den Layer 4 Proxy. Und da ist die Idee,

dass eine geringe Anzahl an Kisten doch
noch eine Legacy IP Adresse bekommt. Bei

mir heißen die Gateways, kann man nennen
wie man will. Genau. Und auf diesen Kisten

läuft dann ein nginx und der verteilt
quasi die Anfragen an die Legacy IP

Adresse nach Port. Heißt, wenn eine
Anfrage an TCP Port 80 kommt, über Legacy

IP weiß nginx, schickt es an an den und
den Server mit richtigem IP etc. weiter.

Nachteil ist dann natürlich, man braucht
für jeden Dienst der einen auf dem schon

belegten Port was macht, eine neue IP
Adresse oder neue Public V4 Adresse, weil

sonst kann man es ja nicht, sondern
auseinander sortieren. Heißt natürlich

besonders für http und https, dass ich mir
da ein zentrales Reverse Proxy Gateway

gebaut habe, weil ich sonst viel zu viele
Gateways brauche, um das auseinander zu

sortieren. Ich habe da auch mal ein
Beispiel-Config. Man sieht hier den nginx

stream Block, das ist nicht der standard
nginx http 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 nginx dann: Hier

bitte auf dieser IP Adresse UDP und Port,
hört, das ist in dem Fall natürlich die

public v4, sollte das sein. Die 10.1.2.3
ist einfach nur ein Example und das ganze

andere, das dann an das entsprechende
Backend weiterleitet. Das Ganze gibt es

hier drunter noch mal für die TCP
Variante, genau. Also, eigentlich auch

kein Hexenwerk, das ganze zu machen. Wie
sieht das praktisch aus? Interne Dienste,

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 erreichbar, aber er brauch ja kein V4,
wenn keine Endnutzer von V4, die nur V4

haben, von außen drauf zugreifen müssen.
Nehmen wir mal ein 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 einen anderen
Hostnamen, hier z.B. ns1.example.com. Und

der geht für richtiges IP einmal direkt
auf die konfigurierte Adresse. Da hängt

kein Gateway mehr dazwischen etc. Das ist
natürlich direkte Ende zu Ende

Kommunikation. Genau. Und die V4 Adresse
geht an dieses nginx stream Gateway, was

wir eben gesehen haben, was dann natürlich
entsprechend konfiguriert sein muss, dass

es auf Port 53 eingehende Anfragen
entsprechend behandelt. Das Thema Wie

sprechen Endnutzer mit den Servern ist
jetzt gelöst. Wie sprechen aber jetzt die

Server nach außen? Das Problem ist, manche
Endpunkte haben kein richtiges IP. Da gibt

es nur 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 Netzwerkproblem
hat und insbesondere ein

Adressierungsproblem macht man natürlich
NAT. Diesmal nur nicht ganz so schlimm.

Wir machen nicht NAT 44, sondern wir
machen NAT 64. 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 64

eigentlich funktioniert. Zumindest wenn
ihr im Telekom-Mobilfunknetz seid, ist die

Chance, dass ihr das unwissentlich schon
benutzt relativ groß, weil meines Wissens

macht die das Telekom das per Default oder
bietet das per default an. Genau, die

Realisierung bei mir ist: Ich habe diesen
Common Präfix, diesen V6 Präfix, wo der

gesamte IPv4 Adressraum drin abgebildet
werden kann. Dieser /96 Präfix wird im

internen Netz von den 64-Gateways
announced 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 einen

entsprechend konfigurierten DNS resolver,
der genau eine Adresse in diesem Range

zurückgibt. So Resolver gibt es
haufenweise, kann man selbst hosten.

Google hat da was, Cloudflare hat da was,
das ist auch alles ein gelöstes Problem,

einfach mal DNS 64 resolver googlen, da
findet man was. Also sind wir eigentlich

fertig. Wir können von innen nach außen
kommunizieren und von außen nach innen.

Gucken wir uns die Übersicht noch mal an.
Von erstmal unten haben wir unser großes

IPv6-only-Netzwerk. Bei mir läuft es mit
OSPF und IBGP. Wir haben den ganz normalen

Edge-Router, der die Adressen ins Internet
routet und umgekehrt. V6 Enduser gehen

direkt über diesen Edge-Router 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 Legacy to V6 Proxy nehmen. Das ist die
nginx stream Config, die wir eben gesehen

haben. 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 müssen sie noch einen
DNS64-Resolver natürlich fragen, um erst

mal die Adresse zu bekommen. Wäre
natürlich zu schön, wenn das ganze out of

the box funktioniert und man nicht den ein
oder anderen problematischen Dienst an der

Stelle hätte. Womit hatte ich Probleme?
Wie habe ich die gelöst? Mail ist an sich

kompliziert, weil Reverse-DNS etc., das
muss alles passen, sonst werden 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 und oder läuft sogar ganz
außerhalb. An der Stelle noch mal,

überlegt euch gut, ob ihr einen eigenen
Mailserver betreiben wollt. Wenn ihr das

noch nicht macht, das ist administrativ
nicht ganz einfach, wenn nicht sogar das

Komplizierteste an der ganzen Geschichte
hier, einen verfügbaren funktionierenden

Mailserver zu betreiben. Ein weiteres
Problem, was ich hatte mit der netten

Software Matrix Synapse, ein Home Server
für Matrix, also Instant Messaging. An

sich läuft das Ding IPv6 only. Es gibt da
nur eine komische Library, die E-Mails

verschickt und die kann kein Happy
Eyeballs. Das heißt, wenn die versucht

sich zu diesem SMTP Server, der eine V4
oder V6 Adresse hat zu connecten, ähm aber

den über Legacy nicht erreichen kann,
weil eine V6-only Kiste natürlich keine

default route für eine legacy IP-Adresse
hat, hört die einfach auf zu

funktionieren. Also es gibt ein Timeout,
sie kann es nicht erreichen. Habe ich noch

nicht gelöst. Gibt ein GitHub issue dazu,
müsste man wahrscheinlich mal etwas viel

Zeit rein investieren und dann ist auch
das Thema gefixt. Aber aktuell ist es noch

kaputt. 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

toll ist das ganze mit Gitlab Runnern. Ich
habe mal versucht ein GitLab Run in dieses

V6-only Netz zu stellen. Die Kommunikation
zwischen Containern klappte dann irgendwie

nicht, wenn man Docker in Docker gemacht
hat und dann noch irgendwie docker Service

containern brauchte. Eventuell muss ich
das Ding auf V4 only zurückbauen und dann

irgendwie so eine CLAT da hinstellen. Also
ohne jetzt ins Detail zu gehen. Alles ganz

schrecklich. Ist aktuell weiterhin kaputt.
Noch so ein Thema, wenn ich per https ins

Heimnetz will, aber das eben nicht über
einen Dyn-DNS machen will, sondern über

einen direkt angebundenen, über VPN
angebundenen Jumphost, nenne ich es mal,

ist das ein bisschen kompliziert, je
nachdem, wie man sein Netz aufbaut. Mein

OpenVPN-Server steht im IPv6-only Teil.
Das funktioniert auch. Kam trotzdem nicht

drumrum, ein Reverse Proxy Channing, also
quasi ein NAT für HTTP zu bauen. Ist nicht

schön, ginge bestimmt anders. Anders wäre
das halt deutlich zeitaufwändiger. 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 BGP-Konnektivität nach
außen, eine IXP-VM in Frankfurt und einmal

eine VM nur mit Transit. Transit für V6
ist relativ günstig. Gratis v6-Transit ist

zumindest für kleine Projekte auch
verfügbar. Und dann habe ich noch weitere

Projekte, weitere Standorte mit billigem
Compute. Also die ganze Rechenleistung

steht, wo ich aber leider kein BGP habe,
zum Beispiel Hetzner. Heißt ich muss

irgendwie zwischen diesen beiden
Standorten kommunizieren können. Da musste

ich mir, weil ich nichts besseres habe,
einen Wireguard, also ein VPN-Overlay

bauen. WAN-intern, läuft da getrennt über
Policy Based Routing. iprule is your

friend. VRFs wären besser, um quasi die
Sicht des eigenen Netzes und die Sicht des

Hetzner-Netzes zu trennen. Es gibt da auf
der wireguard-Mailingliste eine

Diskussion, die ist aktuell aber leider
eher eingeschlafen. Also wireguard kann

dieses VRF noch nicht. Mit iprule kriegt
man das hin, das ist auch nicht sonderlich

großartig und es frisst natürlich MTU.
Also Wireguard. Ihr wollt, wenn ihr so was

macht, strikte Firewall-Regeln haben um
Leaks zu unterbinden. Das heißt ihr wollt

nicht versehentlich aus eurem internen
Netz Pakete mit eurer source IP an das

Hetzner Default-Gateway senden. Das wäre
uncool. Weil Hetzner weiß ja nicht, oder

kennt ja euer AS nicht oder euer NAT
nicht. Für Hetzer ist das ja ein externes

Netz, weil ihr da kein BGP upstream habt.
Also da wirklich aufpassen, was ihr da

baut. Vorher verstehen und dann bauen.
Mein Routing mache ich mit bird2 unter

Linux, OSPF als interior gateway-
Protokoll, IBGP zwischen allen größeren

Standorten. Ist im wesentlichen
Geschmackssache, wie man das baut. Da gibt

es auch verschiedenste Möglichkeiten.
Weiterhin das Thema Administration.

Benutzt Konfigurationsmanagement. Ich
benutz Saltstack mit Ansible oder anderen

Tools geht das garantiert auch. Nur das
wächst so schnell an, da kriegt ihr dann

in die BGP-Filter, in die BGP-
Konfiguration, in die Firewall Regeln

keine Konsistenz mehr rein, wenn ihr das
nicht, ich sage mal systematisch ausrollt

und per config management sicherstellt,
dass das System stabil und konsistent

läuft. Kommen wir so 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 routet oder auch Dienste

hostet. Ist natürlich aufwendiger und
teurer, das mit echtem Blech zu machen.

Ist eine Option für die Zukunft. Und
echter Layer 2 Transport statt 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 trivial und auch

nicht ganz billig. Sollte man definitiv
machen, wenn das Netz produktiv wird,

solange es irgendwie ein Best Effort
Bastelnetz ist oder Privat-Netz ist, ist

das so eigentlich in Ordnung. Fazit: Würde
ich es noch mal machen? Definitiv, v6-only

mit wenigen Legacy IP-Adressen auf den
Edges ist durchaus sinnvoll machbar.

Kostentechnisch ist es eh schon
interessant. Gerade Hetzner hat jetzt vor

kurzem ja angekündigt, dass v4 zukünftig
extra kosten wird oder es ohne V4 billiger

wird. Also ja, das mache ich definitiv
weiter so und würde das auch in neuen

Projekten so machen, dass ich V4 nur noch
auf den Edges habe, auch im privaten

Umfeld. Ihr habt ja gesehen, dass ist
nicht sonderlich kompliziert. Der Aufbau

mit diesen IXP-VMs und Tunneln dazwischen
ist okay für private best effort services.

Ihr hört schon, ich bin nicht so ganz
überzeugt. Also es ist nicht für wirklich

produktive Produktiv-Netze geeignet. Also
nichts, was Geld verdient etc. Dafür Layer

2 Transport, ordentliche Peerings,
ordentlicher Transit, ordentliche

Hardware. Aber das ist ja hier an der
Stelle auch nicht Ziel des Ganzen. 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 rc3
at ipv6.church.

Herald: Und dann sind wir wieder zurück
hier. Vielen Dank an margau für den Talk.

Es gibt leider kein Q&A, weil margau mit
der C3 Infrastruktur beschäftigt ist. Aber

wie ihr gesehen habt, könnt ihr ihr eine
Mail schreiben an die gerade eingeblendete

Email-Adresse. Hier auf dem FEM-Channel
geht es jetzt gleich weiter um 19 Uhr mit

der nächsten Herald News Show und um 20:15
Uhr mit votti zu NetBox als Datenquelle

für Netzwerkinfrastruktur. Bis dahin.

Untertitel erstellt von c3subtitles.de
im Jahr 2023. Mach mit und hilf uns!