Providerunabhängige IP Adressen der Ripe

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…)

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

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

  1. 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)!

  1. 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 Likes

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 Like

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 :slight_smile:

VG
Max

Es wäre auf jeden Fall eine gute Sache. Wir würden uns da wohl als Versuchskaninchen anbieten :stuck_out_tongue: .

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 :slight_smile:

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.

Nunja, einerseits … hat der FFRL ein Prefix-Limit. Andererseits … kannst Du ja durchaus PIv6 anfragen und z. B. für WiFi ein PA-Netz (z. B. vom FFRL) vorsehen. (Was Du nachher mit Deinem Netz tust — dürfte auch nicht mehr gegen die Vergaberichtlinien verstoßen als das, was das RIPE NCC tut …)

Aber im ICVPN ist doch gerade BGP die Basis?

Ja, nein, vielleicht. Fakt ist, das derzeit alles ab /48 geroutet wird, sofern entsprechende Einträge in „der“ Routing-DB existieren. So route ich erfolgreich ein /48 meines ARIN-/47 nach/in Europa (lange Geschichte).

Ein eigenes AS braucht’s nicht (ein routendes braucht’s), und die 50,–/Jahr „plus LIR-Spesen“ (also Märchensteuer plus Aufwand) sind pro zugewiesenem Block: fragst Du 3x /48 nacheinander an ist das teurer als 5 /48 am Stück … Eine AS-Nummer („ASN“) kostet … an sich nix, normalerweise verlangen die LIRs einmalig 50€ + x.

Kernpunkt hier: „In der Auslegung des RIPE NCC“, und insofern kloppen Max und andere und ich uns derzeit im Umfeld der „RIPE Address Policy Working Group“, denn ich finde, eine bekiffte Auslegung gehört nüchtern bewertet, Max will einfach die Kuh vom Eis haben.

Nunja und siehe oben; falls das Policy wird, kann jeder ISP im Grunde PIv6 beantragen und seinen Kunden im Zweifel nur genau eine v6-IP zuweisen — wie es heute schon bei v4, idealerweise, der Fall ist. Fällt dann unter „kann man so machen, ist dann aber scheiße“. Und insofern ist der Vorstoß in der Art auch abzulehnen.

Faktisch routet, on request, der FFRL jetzt schon PI-/PA-Space der Communities, das hat nix mit dem RIPE-Antrag zu tun. (Wichtig hingegen ist das Route-Limit in Richtung der Peers — sprich, wieviele Routen announced FFRL gen Upstream?)

Nope. Mit „rechtlich“ hat das nix zu tun. Es hängt derzeit nur davon ab, wie Du Dein PIv6 anfragst. Mit …

… habe ich mein /47 für die DC + das /48 für zuhause bekommen … war ja überall „PA for stuff“ enthalten.

Gretchenfrage: „überprüft daß denn nachher wer?“ Gretchenantwort: hysterische Lache — noch Fragen?!

Nunja, PI „ist meins“, auch wenn FFRL lange schon Geschichte ist, vgl. IN. Als IN-Gründungsmitglied meide ich das Feuer :wink:

Wie gesagt, derzeit routet Dir jeder alles.

Nunja, bei 4 /24 müßten ja nur 4 Communities zusammenarbeiten und es wäre jährlich nur ein (niedriger) dreistelliger Betrag …

seufz

dazu braucht man aber nicht FFRL, PI-Space kann man über jede beliebige LIR haben.
und „kaufen“ kann man den nicht so direkt, man bekommt ihn solange man die Verwaltungsgebühren der RIPE bezahlt - maximal die uralten IPv4 Blöcke aus der Zeit bevor es die RIPE gab könnte man vielleicht unter „kaufen“ einsortieren

Mittlerweile ist die Sache wohl entschieden:

3 Likes

Yeah, super Sache!

Könnt ihr euch im Vorstand (@lzy und @pberndro) und Technikteam (@takt, @Lars, @Barbarossa) überlegen, ob der FFRL das für Communities anbieten würde? (Für, die nicht alles gelesen haben, wir vom Freifunk Münsterland würden das gerne nutzen um unser IPV6-Präfix, das wir von euch haben, auch über den FFNW routen zu können.)

Viele Grüße
Matthias

1 Like