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