Unter /48 wird ‚oben‘ nichts geroutet, im FFRL-Backbone nichts unter /56. Aus dem FFRL-/48 müßte man somit /56 schneiden, in denen die /64 der Meshes so liegen, daß man eine sinnvolle Verteilung auf die eigene Infrastruktur hinbekommt. Mehr als ein /64 je Mesh fände ich allerdings abenteuerlich, wäre an Erfahrungswerten aber natürlich interessiert. Insbesondere, wie die Verkehrsverteilung ist, AFAIR nimmt IPv6 ja selbst eine Routingentscheidung basierend auf den vorhandenen Prefixen/Routen vor (best-match), die dann immer gleich ausfallen sollte?
»Draußen« sehe ich Announcements für 2a03:2260::/30, 2a03:2260:1000::/36, 2a03:2260:2000::/36, 2a03:2260:3000::/36 — offensichtlich routet derzeit niemand »seinen« FFRL-Bereich selbst/anders, und mangels eigenem FF-AS (einem nicht eingetragenem Verein ein AS zuzuweisen, ziert sich das RIPE NCC aktuell noch; einfach eine AS-Nummer, die einer LIR zugewiesen wurde, selbst zu nutzen, wie es andere machen, zieren wir uns wiederum, noch) können wir das aktuell auch nicht probieren.
Kann auch meines Wissens nach derzeit keine Community, weil es da Probleme mit der Ripe und der Delegation gab. Aber ich bin da nicht genug vom Fach, um das zu erklären.
Alle V6-Pakete müssen durch das FFRL-Backbone und natürlich announcen die nach außen nur größere Blöcke und nicht jede Community einzeln.
Hmm. Als wir beim Förderverein v6-Space anfragten, sollten wir 2 Personen benennen, die als administrativer und technischer Kontakt in der RIPE-DB für den Bereich eingetragen werden sollten, ferner sollte jenes /44 einen »route6«-Eintrag bekommen mit dem Ziel, es ggf. lokal routen lassen zu können. Die Einträge in der RIPE-DB gibt es m. W. nach wie vor nicht …
Das Procedere beim FFRL war ähnlich, allerdings wurde 2a03:2260:117::/48 auch eingetragen: als »ASSIGNED«. Hätte der FFRL stattdessen »ALLOCATED-BY-LIR« als Status vergeben und »mnt-lower«-, »mnt-routes«- und »mnt-domains«-Einträge hinzugefügt, könnten wir u. a. Routing-Einträge (unabhängig vom FFRL) und das Reverse-Resolving selbst konfigurieren.
Ja, die Adressbereiche von FVFN als auch FFRL sind »PA«, d. h. nur das »große Netz« (/32 bzw. /29) sollte im Routing auftauchen (das »[a]lle V6-Pakete müssen durch das FFRL-Backbone« von oben). Für lokales Routing (z. B. über einen lokalen ISP) wäre der reinen Lehre nach sogenannter »PI space« notwendig (ein keinem Anbieter direkt zugewiesener Adressbereich, daher der Name »Provider Independent«, kurz: PI) — oder ein zugewiesener Adressbereich vom lokalen ISP.
Aber das scheint nicht wirklich so gelebt zu werden: im Selbstversuch habe ich mir eine AS-Nummer (weltweit eindeutige Nummer für Routingzwecke) und ein /48-IPv6-Netz über eine LIR in England geholt (war halt das günstigste Angebot; einmalig 30 UKP für das AS, das /48 gab’s für lau dazu). Und ich kann ›mein‹ /48er Netz problemlos in Europa als auch z. B. den USA »announcen«, sprich: routen lassen, obwohl es zu einem /29-Block von Adressen einer LIR gehört.
Rein technisch wäre es also möglich, daß Communities mit lokaler Connectivity »ihr« FFRL-Subnetz über den lokalen ISP laufen ließen — und wenn ich die Fülle an Angeboten sehe, die mir für bestenfalls moderate jährliche Summen bis zu einem /44 (für 24 EUR/Jahr) anbieten, kann ich auch nicht glauben, daß dies gegen die Vergabpraxis sei — dazu sind es zu viele und zu offene Angebote von RIPE-Mitgliedern, gegen die RIPE offensichtlich nicht vorgeht.
Kurzum: das »geht nicht« hätte ich gerne von FFRL-Seite bestätigt/begründet.
IPv6 hat eigentlich das Routing eingebaut. Daher ist es richtig, dass die involvierte Systeme auch die von der IPv6 gegebene Hierarchie respektieren. 2a03:2260::/48 gehört zu FFRL. Routing mäßig heißt es „-> RIPE → FFRL → community/GW“. Wenn die Communities ein Teilbereich des /48 Netz über ein weiteren ISP annunzieren würden, müssten umfangreiche Routing Tabellen aufgebaut werden. Für IPv4 müssen sehr große Tabellen, Segmentierung bedingt, vorhanden sein. IPv6 sollte die Fehlern von IPv4 nicht wiederholen.
Ich weiß jetzt nicht, woher Du Deine Informationen bezogen hast; wie gesagt, ich »spiele IPv6 gerade durch«, habe mir eine AS-Nummer geben lassen und einen /48er (PA-) IPv6-Adressbereich, und der wird geroutet, zumindest von so kleinen Providern wie Hurricane Electric, Telia oder GTT — also auch auf Tier-1-Ebene.
Was das Routing angeht, ist IPv6 auch eher harmlos; ich sehe derzeit gut 33.000 Routen zu v6-Netzen in der DFZ, das deckt sich mit den Werten von HE — verglichen mit 500.000+ Routen im IPv4-Internet ist v6 noch nicht im Mainstream angekommen. (Auch wenn ziemlich jede v6-Route mehrfach mehr Adressen umfaßt, als im gesamten IPv4-Internet Platz fänden.)
Wie man die Routenexplosion, die IPv4 zeitlebens begleitet hat, in IPv6 begrenzen will, nun, ich bin gespannt. Netze an ISPs zu binden, wird im Zweifel eher zu mehr dennzu weniger IPv6-Routen führen.
Nachdem das hier nun ein eigener Thread ist, ein bißchen was zum beobachteten Tun: FFHL hat ein PI-Netz (2001:67c:2d50::/48) und AS (201173), wohl über den FFRL, bezogen.
Den Pfaden im BGP (von Sprint, Tata, Cogent, DFN) nach, scheint es nur über Hurricane Electric announced zu werden (und damit an der FFRL-Infrastruktur vorbei => Dezentralität; Cogent allerdings kennt das Netz gar nicht); bei FFRL-Uplink allerdings geht’s scheint’s direkt (privates Peering?).
Von außen betrachtet, tauchen v6-Adressen von Hetzner & LeaseWeb im Trace auf (BGP-Tunnel von HE?).
Vielleicht mögen @NeoRaider oder @tcatm ja was zum Setup, dessen Hintergrund und den bisherigen Erfahrungen sagen?
Jein. In dem Proposal geht es darum, daß das RIPE NCC zur niedergeschriebenen Policy eigene »Interpretationen« parat hält, eine davon ist, daß die temporäre Zuweisung auch nur einer IPv6-Adresse eines PI-Adressraums eine »sub-allocation« darstellt, die bei PI-Adressraum nicht zulässig sei.
Daher nur soviel: PI-Adressraum vergibt einzig (für Europa und umzu) das RIPE durch dessen ausführendes Organ RIPE NCC. PI-Adressraum wird auf den Anfrager eingetragen, der das dann im Grunde bei jedem Anbieter routen lassen kann.
Der FFRL als LIR (Local Internet Registry) vergibt PA-Adressraum, der, der Idee nach, nur als aggregierter Block (daher der Name »Provider Aggregatable«) routebar ist/sein sollte. Sprich: wir Communities, die IPv6-Bereiche vom FFRL zugewiesen bekommen haben, können das nicht über lokale Provider statt über/zusätzlich zu dem FFRL routen lassen, und wenn der FFRL mal nicht mehr wäre, dürften wir die Adressen auch nicht mehr nutzten. Siehe auch »What are Provider Aggregatable ¶ addresses and Provider Independent (PI) addresses?«
Technisch ist zwischen PA und PI bei IPv6 allerdings derzeit kein spürbarer Unterschied, aber das muß nicht so bleiben (die IPv6-Routingtabelle ist aktuell noch so lächerlich klein verglichen mit der von IPv4, aktuell scheint »anything goes« zu gelten).
Das Thema ist nun durch, AS206813 is happy to peer
Logischer nächster Schritt wäre der Aufbau von Hardware an IXPs; hier wäre Koordination und Virtualisierung wünschenswert, denn drölfzig Kisten an den kleineren IXPs bringen im Ende niemanden voran?
