@_bernd, Freifunk Frankfurt arbeitet daran alles auf Babel umzustellen. V6 ist fertig und befindet sich in der Testphase und für V4 muss noch etwas zusammengeschustert werden.
Ich sehe keinerlei Chance, /128 (oder auch nur /64) als PI-Space zu routen.
Ich sehe nicht, dass zwischen AS auf absehbare Zeit mit etwas anderem als BGP geroutet werden wird.
(Das ICVPN mag ein Sonderfall, ich betrachte das jedoch nicht als „providerunabhängig“)
Ok, bei den P2P war ich nciht ganz up2date.
gebe zu, ich nutze für mein internes Routing der Einfachheit Link-Lokal-Adressen bei den P2P-Sachen (ICMP läuft dann über eine IP auf Loopback/anderen Interface).
Grundsätzlich ist „batman-adv nur lokal, Rest Layer 3“ in meinen Augen eine gute Sache. (Egal ob Layer 3 dann batman „alt“, babel, olsr2 oder ospf ist)
Man muss sich nur überlegen, wie will man die Grenzen ziehen, wo Roaming möglich bleibt ohne jegliche Störungen (TTLs kann man ja klein setzen für größere Lücken).
Meine „naiver“ Ansatz wäre: Auf der Funk-Seite weiter batman-adv fahren, damit lokale Router meshen können und die Clients dann problemlos wandern können, auf den VPN/„Richtfunk-Backbones“/Kabel Layer drei. Jeder „extern“ angebundene Knoten annonciert ein /64. Falls es in einem lokalen Mesh mehr als einen Router mit Uplink gibt, bekommt der Client halt mehrere IPv6-Aressen, dann kann er sich aussuchen welche er nimmt.
Solange die Mesh-Inseln nicht sehr groß werden, dürfte das gut skalieren und pflegeleicht sein.
Das wird ja auch nur intern geroutet, zum Internet ist alles mit größerer Maske als /48 unroutbar.
Zwischen den Communities vermutlich alles >/56, intern was man will (ok, irgendwann „was die hardware kann“). Und so ein /127 vom p2p-Link muss ja im Zweifel auch garnicht geroutet sein, dient ja nur dafür den ICMP-Reply eindeutig zu identifizieren.
Das ist schon klar und steht meines Erachtens auch völlig außer Frage, zumindest was den Bereich des FFRL anbelangt, bei anderen ähnlich.
Nur das ist dann eben gerade eben NICHT das geforderte „providerabhängige“ Prefix.
Wieso? Jede Community kann doch sich ein /48 PI besorgen (theoretisch - wenn das RIPE-Problem nicht wäre), und das dann in /56ern im (Rheinland-)Backbone announcen.
So könnte man in einer Community mehrere „unabhängige Inseln“ aufbauen, die jeweils bis um 200 Layer 2 Wolken haben könnten und über den Backbone untereinander kommunizieren.
Nur nach ganz extern = Internet muss es wieder ein /48 sein => Jeder Backbone der das /48 annonciert muss alle /56 die genutzt werden erreichen können. (Und das könnten ja auch mehrere gleichzeitig sein)
Jeden Freifunk-Router weltweit routbares Netz zu geben, halte ich für illusorisch.
Moin!
Um mal dem ganzen hin-und-her hier ein Ende zu setzen und ein paar Dinge klarzustellen (ich habe nicht alles gelesen, das wurde mir zu verworren…)
- PA/PI was ist das?
Als LIR (zahlendes Mitglied des RIPE-NCC, 1400€/y) kann man „Allocations“ bekommen. Das ist bei v6 üblicherweise ohne Gründe erstmal ein /32 bis /29. Reserviert wird beim RIPE ein /26. Davon kann man Teile an Kunden weitergeben (-> Assignment) und dokumentiert das brav in der RIPE-DB. Genau das tun wir als FFRL. D.h. aber, dass die IPs dem LIR (in diesem Fall dem FFRL) gehören und wenn der umfällt / out-of-business geht müssen alle „Kunden“ renumberen. Üblicherweise kommt PA-Space im Kombi damit, dass man den Traffic über den LIR routen muss (-> GRE Tunnel zu AS201701). Das ist aber nicht unbedingt immer zwingend nötig, aber da wirds dann komplizierter. Aus dem v6 Bereich, aus dem PA-Allocations geschnitten werden, werden nicht notwendigerweise alle /48 Netze im Internet geroutet, sondern eher erst ab /44 oder /40. Das ist aber nicht festgeschrieben, das kann jeder ISP handeln, wie er möchte.
Als Normalo kann man beim RIPE direkt oder über einen „Sponsoring LIR“ PI (Provider Independent) space bekommen. Das ist ohne Begründung erstmal ein /48, wieviel da mi Diskussion geht weiss ich nicht. dafür brauchts noch ein eigenes AS für den PI-holder und dann kann man das irgendwie im Internet announcen. Das kann über den sponsoring LIR passieren oder über wen anders, oder beides, oder … Aus dem v6 Bereich, aus dem PI-Assignments geschniten werden, werden by design alle /48 und kleiner /47, /46…) im Internet geroutet. Ein PI kostet 50€/y, die ASN ggf. auch ein bisschen was.
- AP-WG Proposal 2016-04 "IPv6 Sub-assignment Clarification "
Ich habe auf dem RIPE-72 das Thema „PI-Space für Freifunk“ bzw. generell „Regularien für PI-Space“ mal auf die Tagesordnung der AdressPolicy-Workingroup (AP-GW), da diskutiert, ein Proposal zur Änderung der AP aufgemacht und schiebe das seitdem (mühsam ernährt sich das Eichhörnchen) durch den Policy Development Process (PDP).
→ IPv6 Sub-assignment Clarification — RIPE Network Coordination Centre
Das schon länger bekannte Problem mit der aktuell bestehenden Policy ist, dass sie keine „sub-assignments von PI-Space“ erlaubt, d.h. dass man aus einen PI-Assignment (ganzes /48) keine Subnetze egal welcher Größe (/64 oder auch /128) weiter delegieren darf. In der Auslegung des RIPE NCC ist eine IP, die sich ein Clientgerät er RA oder DHCP oder wie auch immer zieht (technically ein /128) ein sub-assignment. Das RIPE NCC sieht das seit Jahren als Problem und die Community schon mehrfach gefragt, ob das so ok ist. Bisher wurde das immer mit „ja“ beantwortet. Das fand ich doof, daher das Proposal. Nach einigen Ehrenrunden ist das jetzt auf der Zielgeraden. Die Änderung ist im Kern dieser zusätzliche Text:
Providing another entity with separate addresses (not prefixes) from a subnet used on a link operated by the assignment holder is not considered a sub-assignment. This includes for example letting visitors connect to the assignment holder’s network, connecting a server or appliance to an assignment holder’s network and setting up point-to-point links with 3rd parties.
Wenn das durch die „Last Call“ Phase durch ist und nicht noch gekippt wird, wird das Policy. Ab dann ist auch für Freifunk Communities möglich, sich direkt oder über einen Sponsoring-LIR PI-Space zu besorgen.
Ich denke (nur meine persönliche Meinung, Stand jetzt keine offizielle Aussauge des Backbone-Teams!), dass wir dann auch PI-Assignments von Euch routen werden, analog zu den bisherigen Announcments aus unserem PA-Space. Das werden wir noch intern klären und dazu eine Aussage treffen.
- ULA/SLA space
Tut das nicht! Ihr könnt von uns oder ggf. andere Providern GUA IPv6 space bekommen. Bald hoffentlich auch PI, wenn Ihr Euch nicht an uns „binden“ wollt. ULA/SLA bedeutet, dass Ihr irgendwo NATen müsst, wenn Ihr mit den Adresse ins Internet wollt. Genau das sollet mit diesem IPv6 ja verhindert werden. NAT braucht state (conntrack), state tötet. Und bitte denkt an die Enten (Nat, Nat, Nat)!
- Minimal Prefix Length für Announcements zu AS201701 / FFRL
Wir haben mal die Regelung raugegeben und umgesetzt, dass wir BGP Announcments mit /48 - /56er prefixen akzeptieren. Das hat schlicht den Grund, dass wir eine Explosion der v6 Routingtabelle bei uns vermeiden wollen. Aus Sicht von FFHO (Kunden-Hut) funktioniert das für mich ganz gut zur Trafficsteuerung. Im Zweifel nutzt Ihr ein /56 pro Domain/Site/Domäne/whatever und nutzt darauf das erste /64 im B.A.T.M.A.N. #FürSieGetestet #WorksForMe #Tuwat
Ich hoffe, damit alle Frage beantwortet zu haben.
LG
Max
8 „Gefällt mir“
Das ist aber doch die Frage, wie man als Community für möglichst kleines Geld ein /48 bekommen kann, ohne dafür LIR zu werden und einzelne Prefixe dann auch an Plasterouter (die bei Dritten stehen, die keinen expliziten „Vertrag“ haben oder das Eigentum am Router formal an die Community übertragen haben) deligieren zu dürfen.
Vom FFRL z.B.?
Das ist dann aber kein PIspace, aber ich mag mich irren. Oder kann ich das dann anders connectieren als über den ffrl? (zumindest habe ich die Frage des TE so verstanden)
Hat der @Barbarossa eben ja beschrieben, sobald die Regeln vom RIPE angepasst sind, ist es erst rechtlich möglich PI-Spache für Freifunk-Sachen zu beantragen.
Danach kann ein „sponsoring-LIR“ für überschaubares Geld (stand irgendwo weiter oben mal, so Größenordnung <100 EUR/Jahr) für Dritte (wie eine Community) ein /48 PI beantragen, dass man dann frei routen kann.
Dann brauch man „nur noch“ einen oder mehrere „ISP“ die das routen (zum Beispiel wieder der Freifunk-Rheinland-Backbone, oder die freundliche Stadtwerketochter oder oder).
Du sprachst nur von /48. Ich ging jetzt davon aus, dass die Geschmacksrichtung egal ist…
Mir ist tatsächlich auch vollkommen unklar, welches Problem eigentlich gelöst werden soll.
PI-Space ist aus meiner Sicht (im Gegensatz zum PA-Assignment, dass jede Community stand heute bekommen kann) nur eine andere Gechmacksrichtung und fühlt sich vielleicht schöner an. Das wird erst dann mehr als „geiler so vong Fühl her“, wenn Ihr wirklich lokalen Upstream habt, der Euch das für Euer AS routet. Ich würde erwarten, dass das eher die Ausnahme ist.
Ciao
Max
1 „Gefällt mir“
Mein Bauchgefühl ist: Man mag es nicht „abhängig vom Backbone zu sein“, daher der Wunsch nach PI. Glaube ernsthaft an multiple Upstreams denkt (zumindest in der Praxis) keiner.
Was mir für das Problem noch einfiele: Ein /48 aus Unique Local Addresses (ULA), mit 1:1 Nat66 (stateless), dann kann man bequem den Upstream wechseln ohne zu renumbern und sogar die Sub-/56 könnte man lokal direkt über normale Anschlüsse ausleiten (da gibt es ja ein /56 meistens => Nat66 für das Teilnetz möglich ohne VPN, setzt halt voraus das der Betreiber des Anschluss wenig Angst vor Konsequenzen hat).
Vermutlich - obwohl dreckiger Hack - fast spannender für einige Communities, weil man so mit paar angemieteten (V)DSL-Anschlüssen ohne VPN arbeiten könnte (bzw. das VPN nur um internen Verkehr abzuwickeln der im Vergleich ja wenig ist).
Und da Nat66 stateless ist, bricht es auch nicht das Ende-zu-Ende Prinzip.
Ich beziehe mich auf das erste Posting des Threads.
So habe ich die Frage von @MPW verstanden. Insbesondere Communities außerhalb des Rheinlandes aus dem hohen Norden oder an den Voralpen suchen nach Modellen, zukünftig auch andere Optionen zu haben, ohne gleich einen Jährlichen 4stelligen Betrag aufzubringen oder auf den Fortbestand des Rheinländer Backbones angewiesen zu sein.
Und daher dann eben die Frage von MPW, wie weit denn der Status dieses Projektes ist (z.B. „läuft noch“, „endgültig beerdigt“. oder „chancenlos für die nächsten Jahre“).
Das hatte Barbarossa ja eben gut beantwortet unter den Punkt 2 in den Beitrag #28: vermutlich „bald“ möglich.
Hallo @Barbarossa,
danke für deinen tollen Beitrag!
Evtl. könntet ihr auch /60 im Filter freischalten? Die Idee ist folgende: Wir haben 75 Batmandomänen im Münster-Emscherland. Jede hat ein /56, dass von beiden Gateways je Domäne ans FFRL gemeldet wird.
Das Gluon-Team arbeitet gerade daran, dass man pro Gateway in einer Domäne mit einem anderen /64 arbeiten kann und alle RAs bis auf die von dem Gateway, an dem man hängt, weggefiltert werden. Dadurch kann man mit spezifischen Präfixen arbeiten, ohne dass jeder Knoten mehrere Adressen bekommt, wodurch der Mehraufwand im Batman explodieren würde.
Ich würde jedes Präfix pro Domäne und pro Gateway gerne separat per BGP ans FFRL-Backbone melden (announcen) um Querverkehr zwischen den Gateways zu vermeiden. Das macht uns die Netzwerkkarten dicht und kostet extra, wenn die bei verschiedenen Hostern stehen.
Wenn ich pro Domäne drei Gateways mit drei /56ern rechne, kann ich die nicht so schön benennen und maximal 85 Domänen bauen. Wenn ich pro Domäne mit einem 56er und daraus mit Subpräfixen arbeiten kann, macht es das einfacher.
Setz das Münsterland bitte schon mal auf die Warteliste. Sobald die Änderung bei der Ripe durch ist, würden wir sofort einen PI-Bereich bei euch kaufen.
Lokal nicht, aber über andere FF-Backbones. Wir haben derzeit Gateways, die eigentlich am FFNW-Backbone hängen, aber zu euch auch einen Satz Tunnel nur für V6 haben.
Dann kann man sich diese Doppelanbindung sparen, weil der FFNW auch unseren V6-PI-Bereich routen dürfte.
Danke, dass du das bei der Ripe voran treibst!
Viele Grüße
Matthias
Ok, verstehe ich und kann ich aus eigener Erfahrung nachvollziehen. wenn wir jetzt - for the sake of the argument - darüber nachdenken würden, das import Limit auf /60 oder /64 zu vergrößern, wieviele Routen würdet Ihr dann etwa schicken wollen? Wenn wir über 75 Domänen/Sites/BATMAN-Instanzen/whatever reden würde ich mal ein sagen, dass 100 Routen reichen sollten. Sprich, was ich mir ggf. vorstellen könnte wäre, more specifics als /56 zu erlauben, aber maximal 30-50 Routen pro Sessions (aus der Hüfte geschossen) zu akzeptieren, damit unsere Table nicht explodiert. Dabei gehe ich davon aus, dass explizit nicht jeder Endpunkt auf Community-Seite alle Routen zu uns schickt, sondern nur die lokal sinnvollen prefixe + ggf. das Aggregate.
Würde das Dein Problem lösen?
Da gibt’s ein Missverständiss, ich ging davon aus, dass es generell um ein Assignment geht und das auch PA ok ist. Zu PI haben wir noch keine offizielle Meinung.
Ok, damit seid Ihr meines wissens die ersten, die die Vorteile von PI wirklich nutzen könnten 
VG
Max
Es wäre auf jeden Fall eine gute Sache. Wir würden uns da wohl als Versuchskaninchen anbieten 
.
Pro BGP-Sitzung reicht das knapp. Je nach Größe haben wir fünf bis 20 Domänen pro Gateway. Also 20x /60, dazu 20x /56 und 1x /48 als Rückfalloption, falls irgendwo etwas wegbricht. Das wären 41.
Also 50 wäre schon gut. 30 etwas knapp.
Insgesamt würde sich die Zahl von derzeit 76 für V6 auf 281 erhöhen. Aber jedes Gateway verkündet nur die seiner lokal angebundenen Domänen. Falls die direkte Anbindung wegbricht, fällt es auf das /48 zurück und wird bei uns per iBGP durchgereicht. Wir reichen also nicht die /60 Announcements anderer, indirekt angebundener Gateways durch. Das haben wir gerade mit den /56ern abgeschaltet. Jeder nur noch seine eigenen und als Rückfalloption das /48.
Verglichen mit der kompletten Tabelle des Internets sind das Kleinigkeiten. Ich denke, das frisst höchstens ein paar MB Ram.
Ich denke, was euch skalierungstechnisch mehr Sorgen machen sollte, ist die Anzahl der Gre-Tunnel pro Backboneserver. Und die würde bei uns dadurch sinken.
Viele Grüße
Matthias
Hi,
Da komme ich jetzt nicht mit.
Wenn wir /64 erlauben würden, warum dann noch /56 schicken?
Ich hätte dann jetzt angenommen /48 + n-mal /64 (ggf. etwas aggregiert auf /60 oder was auch immer) pro Gateway/Borderrouter. Wofür schickst Du dann noch 20x /56 von den Gateway/Borderroutern?
„von derzeit 76 für V6 auf 281 erhöhen“ mein Routen? Aber doch nicht alle überall? Du sagst ja selber, dass jedes Gateway nur seine lokalen Routen verkündet? Ergo warum dann so viele pro Session?
RAM ist das eine, mehr Routen heisst auch mehr rechnen wenns wackelt.
Weniger Tunnel ist auch gut. Darum mache ich mir aktuell aber nicht so viele Gedanken
VG
Max
Und ich kann augenscheinlich das nicht in einen neuen Thread schieben, daher: no comment.
So wie die Ansätze zum /25 im Sande verlaufen, sehe ich nichts jenseits /48 als realistisch.