… welches Stand heute aber an den Server gebunden ist, sprich unerreichbar bei Serverreboot, -ausfall und -wechsel. Ein dynamisches Routing der /64 im /56 wäre wünschenswert.
Ernsthaft: bevor Du v6 NATtest (Prefix translation wäre noch halbwegs ok), laß’ es bitte ganz!
Ausreichend v6-Adressraum wird per Tunnel zugeführt.
ich habe schon mal 2 NAT gateways kaskadiert… für IPv6. Geht prinzipiell, sogar gut.
(ist halt, so, wenn man Upstream keine PD bekommt und dort nur ein /64 anliegt, man aber noch zwei Hops weiter möchte und im Transitnetz ebenfalls SLAAC braucht.)
Daß das nicht ginge, habe ich auch nicht behauptet; geil ist auch Prefix Translation, dann klappt selbst das rein-SSH-en 
Aber: IPv6 bietet genug Adressen, daß man mit Krücken wie NAT gar nicht anfangen sollte, die Fehler von IPv4 einzuschleppen. Notfalls ein /48 von Hurricane Electric reintunneln … (fast) alles ist besser als NAT.
Nicht ganz das, aber mit genügend Geld bekommt man bei Hetzner „dynamische“ IPv4 und IPv6 Subnetze. Nur man bezahlt dann halt beispielsweise für ein /64 10 € im Monat und dann nochmal 1,19 € für das TB Traffic. Nur für Ausfallsicherheit ist das schon ein stolzer Preis. Gerade das der Traffic halt keine Flatrate ist.
Ist die logische Konsequenz dann nicht, die Host-IPs für das externe Interfacing zu nutzen (Gateways, Tunnel zu $woanders) und das Mesh mit ›beweglichen‹ IPs zu versorgen, z. B. $woanders = FFRL?
Das ist vermutlich eine der wenigen günstigen Möglichkeiten die man hat. Aber man macht sich dann ohne eigene ›beweglichen‹ IPs ein gutes Stück abhängig vom FFRL.
Naja, wie schon mal kurz angerissen vor ~1,5 Jahren, der Aufwand, dann weiterzugehen, ist nicht soo groß:
Ein IPv6-PI-Netz (typischerweise ein /48 als kleinesten routebaren Prefix) kostet jährlich 50 EUR netto ans RIPE; wenn das eine deutsche LIR – als sog. Sponsoring LIR – einer deutschen natürlichen oder juristischen Person weiterberechnet, kommen da ggf. 20% niederländische und darauf 19% deutsche MwSt. obendrauf.
Tipp: tatsächlichen Adressbedarf zusammenstellen und PI in einem Rutsch (z. B. 2-4 /48 für 2 bis 4 Standorte (== RZen)) anfordern, und auf viel Diskussionsbedarf gefaßt sein, wenn man statt 4 x /48 ein /46 bekommen möchte.
Effektiv zahlt man nicht per /48, sondern pro Assignment (was 4 /48 oder ein /32 sein kann (für letzteres würde mich die akzeptierte Begründung interessieren 
) die 50 EUR/Jahr.
Netzpolitischer Hinweis: PI-Adressraum ist von der Idee her an den Endnutzer zugewiesen; an sich darf diese Adressen also nur z. B. der Verein Freies Funken Niederelbe e. V. nutzen, konkret einzig dessen Mitglieder — nicht aber z. B. ein zu einer Besprechung anwesender Gast (dem hätte strenggenommen nur eine Adresse aus einem nicht-PIv6-Bereich, oder eben gar kein IPv6, gegeben werden dürfen).
Dank einer Initiative von @Barbarossa vor ein paar Jahren ist die Policy geändert worden, sodaß man mit PIv6-Adressraum per WLAN auch Außenstehenden einen Internetzugang ermöglichen darf.
Derzeit kostet eine AS-Nummer (ASN) seitens des RIPE NCC: nichts. (Das habe ich seinerzeit fälschlich auch mit 50 EUR benannt; leider kann ich den Beitrag nicht mehr editieren.) Ob und was Euch die Sponsoring LIR Eures Vertrauens dafür berechnet, ist ein anderes Thema. LIRs – Local Internet Registries, also quasi lokale Internet-Ressourcen-Vergabe-Institutionen – sind offensichtlich frei in dem, was sie für ihre Dienste berechnen.
Frage: bietet der FFRL sich eigentlich als Sponsoring LIR für Freifunk-Communities an?
Achtung, Voraussetzung für die Zuweisung einer AS-Nummer ist derzeit Multihoming, sprich: Euer AS-in-spe braucht >1 Upstream AS, deren Kontaktdaten im Antrag auch ans RIPE kommuniziert werden müssen (AFAIK aber von dort nicht weiter geprüft werden — wäre auch etwas zu viel des Guten, würde das RIPE NCC in Zeiten der DSGVO bei einem ISP anrufen und fragen, welche Vertragsbeziehungen bestehen …). Praktischerweise bieten sowohl Hurricane Electric als auch NetAssist neben IPv6-via-Tunnel auch IPv6-BGP-via-Tunnel an …
Ok, wie sieht der einfachste Weg zur eigenen ASN mit eigenem IPv6-PI-Adressraum also aus?
Wir definieren die Anzahl der Rechenzentren/auf Netzebene disjunkten Orte, an denen wir Server mieten [1/2/3/4/…] oder aufstellen (wegen Community-IX) wollen.
Wir haben uns eine Sponsoring LIR gesucht, zum Beispiel einen befreundeten ISP oder eines der Angebote am Markt, um eine AS-Nummer und unsere PIv6-Netze zu beantragen.
Wir holen uns v6-Tunnel von Hurricane Electric und NetAssist, geben deren Kontaktdaten für die Multihoming-Anforderung des RIPE NCCs an, schicken alle Daten für PIv6 und ASN an unsere Sponsoring LIR.
Parallel überlegen wir, ob ein /44 aus dem Fördervereins-Fundus nicht praktisch wäre.
Am Ende des Prozesses haben wir eine zugewiesene AS-Nummer (wie FFRL, FFNW, 4830.org und andere), ein oder mehrere (v6-) Netze — und ein Verständnis, daß jetzt die Arbeit erst losgeht (hinting @collimas) 
Denn nun muß man sehen, wie man seine Netze tatsächlich geroutet bekommt, natürliche Anlaufstelle wäre für mich der FFRL (auch wenn wir es in Eigenregie realisiert haben) und/oder andere Freifunk-Organisationen (wichtiger Baustein ist auch der Community-IX).
Kurzum: man kann sich einer anderen Organisation hingeben, man kann aber auch komplett sein eigenes Ding fahren oder eine Kombination davon — die Kosten pro Monat oder Jahr sind nicht exorbitant hoch.
Danke für deinen Text.
Wir hatten da vor 1-2 auch mal ein Dokument angefangen, das noch etwas ausführlicher sein sollte, aber z.B. Tunnel bisher nicht erwähnt. Vielleicht willst du ja daran weiterschreiben, damit es vielleicht veröffentlichungsfähig wird? Ich wäre nur Nutznießer der Informationen, noch machen wir soetwas nicht selbst.
Sehe ich es richtig, dass dein Text zwei Varianten vorsieht? Entweder Hardware und routing per FFRL/*IX/… oder Mietserver und tunnel von HE und netassist?
Ist dir aufgefallen, dass netassist.ua ein SSL-Cert hat das vor 8 Tagen abgelaufen ist?
Hast du langjährige Erfahrung mit deren Verlässlichkeit?
Wir sind mit Tunnelbroker ohne BGP an sich seit 2015 sehr zufrieden, jedoch weiß ich da keine gute Möglichkeit, um es redundant aufzubauen (hinsichtlich Serverausfall auf unserer Seite).
Andererseits fahren wir seit 2015 ohne jegliche Redundanzen und haben höhere Availability-Messwerte als jeder Consumer-ISP 
nein, off-topic hier, das Dokument befasst sich mit dem was du geschrieben hast und das hatte ja nix mit Proxmox zu tun. „how to ASN 4 FF“
Hallo,
es freut mich, dass ich mit meiner Frage eine Diskussion hin zu einem eigenen Freifunk v6-Subnetz wiederbelebt habe. Dies wäre für uns in der Zukunft sicherlich auch ein interessantes Thema.
Das obige Problem haben wir nun erstmal mit den /56 Subnetz von Hetzner einfach lösen können.
Dem schließt sich nun aber ein weiteres Problem an die ich mit meinen rudimentären IPv6 Kenntnisse leider nicht gelöst bekomme.
Wir haben jetzt 2 Blech-Server mit jeweils einem eigenem /56 Subnetz. Auf diesem diverse Gateways-VMs, welche entsprechend ein /64 Teilnetz bekommen und verteilen. Nun ist es so, das Beispielsweise auf beiden Servern je ein Gateway der gleichen Domäne, also des gleichen Client-Netz liegen. Die beiden Gateways verteilen per radvd ihr eigenes /64 Subnetz und die Clients genieren entsprechend für jedes Netz jeweils eine IPv6.
Jetzt kommt es vor, dass ein Client mit einer IP von GW1 (der FF-Router ist verbunden über GW1) seine Daten über GW2 schickt. Das funktioniert natürlich nicht.
Was kann ich machen, damit ein Client entsprechend seiner IP das richtige Gateway wählt?
Gruß Helmut
Das ist das „alte“ Quertraffic-Problem und schlägt bei allen Batmannetzen mit mehreren Supernodes (und Gateways) zu.
Will sagen: Es ist leider kein spezielles Hetzner-Problem.
Schau mal nach den diversen Quertraffic-Threads.
(Und ja, es behaupten Menschen, dass das nicht wirkllich ein Problem ist, da Batman…)
Das es kein spezielles Hetzner-Problem ist, ist mit bewusst.
Ich denke aber, dass das auch kein Batman-Quertraffic Problem in dem Sinne ist, sondern ehr ein IPv6.
Freifunk/Batman mit mehreren Gateways ist im IPv6-Sinn ja ein Multihoming-Umgebung. D.H. es gibt mehrere Router mit unterschiedlichen Präfixen welche diese per SLAAC an die Hosts verteilen.
Das gibt es ja nicht nur in Freifunk/Batman-Netzen. Für IPv4-DHCP hat Batman dies ja elegant gelöst, in dem DHCP-Anfragen an die anderen Gateways blockiert.
Nur, was kann ich mit IPv6 machen? So wie es jetzt ist, ist es ein Glücksspiel, ob ich per IPv6 raus komme oder nicht. Eigentlich sucht sich ja in Multihoming-Umgebungen der Client das Gateway anhand von Qualitätsmerkmalen. Ist es z.B. eine Lösung, wenn man an einem Gateway nur Traffic von Adressen des eigenen Präfix forwarded und den Rest wegkippt?
Naja, es ist ja auch kein Proxmox-Problem.
Also in Frankfurt ist es „auf bare metal“ auch aufgetreten.
Das ist auch richtig…
Mit meinem eigentlichen Problem von oben hat es nur noch entfernt etwas zu tun. Da aber auch zwischendurch thematisch die Diskussion nicht gepasst hat, habe ich jetzt keinen neues Thema aufgemacht.
Du musst kein neues Thema aufmachen, ich habe Dir zwei passende verlinkt weiter oben. Alternativ einen neuen aufmachen, wenn’s nicht passt.
(bitte immer dran denken, dass später mal Leute versuchen über die Suche etwas im Forum zu finden. und frustriert sein werden, wenn ein Thread 80 Artikel hat von dem 60+ etwas anderes diskutieren als im Thema steht)
Was damals diskutiert wurde, hat uns zum Setup mit ULA in der FW und Public-v6 mit ::/0 und DNS-Servern via RA von den GWs gebracht. (Das hat was damit zu tun, daß wir keinen eigenen v6-Adressraum haben, er ist uns nur direkt oder indirekt zugewiesen über LIRs — und LIRs könnten verschwinden, und mit ihren jener Addressraum. Daher ULA für die Notfallkonnektivität, das öffentliche v6 je Mesh können wir so je nach Bedarf über Konfigurationsänderungen an den GWs steuern.)
Gateways für ein Mesh sind »hintenrum« zusammengeschlossen, sodaß es egal ist, über welches GW der Traffic geht.
Du kannst z. B. Dein eigener kleiner FFRL sein und auf dem Blech mit dem 1. /56, ich nenne das mal »links«, per Tunnel das 1. »linke« /64 auch der entsprechenden VM »rechts« bereitstellen. Damit hast Du zwar weiterhin einen SPOF (Host »links«), aber kein Routingproblem mehr (dafür den Mehraufwand mit Tunneln).
Oder Du nutzt die Möglichkeiten des Hosters, daß ein Netz an mehreren Hosts (Servern/Blechen) anliegen kann. Sind halt ein paar kleine Münzen einzuwerfen, dafür entfällt auch der SPOF.
Naja, es geht ja auch mit Hetzner (scheint nur prohibitiv teuer zu sein). Ich meine, Freifunk Nord hat sich bei OVH ein paar Hosts und Netzwerk-Foo drumherum besorgt?
Naja, »elegant«; daß mein IPv4-Default-GW auf einem anderen System liegen kann als mein (fastd-/Tunneldigger-) VPN-Peer, finde ich vieles, nicht aber »elegant«. Es gab da mal [dieses automatische Umwandeln von »’« am Wortanfang zu »,« ist shice!] ‚nen Ansatz (IW’TGTFY), RAs nur vom ausgewählten Batman-Gateway durchzulassen — fand‘ ich damals einen charmanten Ansatz, heute, nach 5 Jahren Flatterman-Freifunk, weiß ich, daß weniger mehr ist und KISS ein endgeiles Prinzip 
Das Problem bei OVH ist, dass es dort zumindest meines wissens keine zusätzlichen IPv6-Prefixe gibt, auch nicht für Geld und gute Worte. Zumindest nicht solange man nicht zusätzlich ein V-Rack ordert, was afaik um die 100€/Monat „für nix“ (aus meiner Perspektive) zu Buche schlägt. (Und ja, nur bei OVH, nicht bei deren B-Brand „SoYouStart“.)
Und das eine /64 was man pro Blech bekommt, das reicht schlicht nicht.
Wenn es bei Hetzner zusätzliche Prefixe „gegen Einwurf kleiner Münzen“ gibt, dann würde ich wirklich das tun. Einfach weil es den Maintenance-Aufwand gering hält. Und „Zeit“ und vor allem „Frust-Level“ ist das, was man den Co-Admins (und sich selbst) ersparen möchte, wenn das Hobby länger freude bereiten soll.
IIRC hat das eine Community getan. Ich habe aus eigener fail2ban-Erfahrung OVH auf der schwarzen Liste, sprich bei zuviel Nerverei wird stumpf jeder Präfix von OVH geerdet — auf Abuse-Anfragen wird nach außen hin nicht reagiert, solche Netze muß ich nicht routen. Aufgrund der Größe sind Kollateralschäden unvermeidlich¹, aber, hey, mein Netz, meine Regeln.
¹ Bei ~140 IPv4 und ~20 IPv6-Präfixen wird was fehlen …