Der gesamte Adressraum des Internets wird, bis auf ein paar Ausnahmen, von den Regional Internet Registries (RIRs) verwaltet, eine Aufgabe, die ihnen von der Internet Assigned Numbers Authority (IANA) zugeteilt wurde. In der Zwischenzeit hat sich das System bewährt und sich innerhalb der letzten zehn Jahre von einem einfachen, zentralisierten System zu einem komplexen, dezentralen System entwickelt.

Für das Verständnis der Entstehnung der RIRs ist es wichtig, daß die komplexe, dezentrale Struktur kein Resultat eines ständig wachsenden Internets ist, sondern vielmehr aus dem Bedürfnis heraus entstand, das Internet leichter administrierbar zu machen. Andererseits ist es sehr eng mit der Adressarchitektur des Internet Protocols verbunden.

Innerhalb einer relativ kurzen Zeit stabilisierte sich das RIR-System und entwickelte sich zu einer robusten Umgebung zur Verwaltung Internetadresse. Heute verwaltet sich das System vollständig selbst, wie wir es von vielen anderen offenen Communities her kennen. Seine Legitimation bezieht es aus seiner strengen Anlehnung an offene, transparente und partizipatorische Prozesse.

Zustand vor den Regional Internet Registries

In diesem Abschnitt gehe ich kurz auf die grundlegenden Adressierungsmechanismen und frühe Registrierungsbemühungen ein. Sie werden helfen, die Grundzüge und Beweggründe, die zur Etablierung des RIR-Systems führten, zu verstehen.

Die IP-Adressierungsstruktur

Das wichtigste Feature des Internet Protocols (IP) ist die Fähigkeit, IP-Pakete über viele verschiedene Netzwerkarchitekturen transparent zu transportieren. Das wird erreicht, indem IP-Pakete in einem Layer-2-Frame gekapselt werden. Router verbinden mehrere Netzwerke miteinander und leiten IP-Pakete in andere Netzwerke weiter, indem sie die IP-Pakete wieder auspacken und erneut in einem Frame-Format kapseln, das die Netzwerkarchitektur unterstützt.

Um diese Aufgabe transparent zu erfüllen, benötigt IP eine Adressstruktur, die zweistufig ist, sowohl für das Routing als auch dür die eigentliche Adressierung. Ein Teil der Adresse, der Netzwerkanteil, identifiziert das Netzwerk in dem sich ein Host befindet, und der zweite Teil repräsentiert den Hostanteil (auch lokaler Teil genannt), der den Host im Netzwerk identifiziert.

Beim Routing im Internet funktioniert nur auf Basis des Netzwerkanteils der IP-Adresse. Kennt ein Router die Netzwerkadresse des Ziels, so wird das Paket schließlich weitergeleitet. Der lokale Teil der Adresse spielt beim Routing keine Rolle. Vielmehr wird erst im Zielnetzwerk die Hostadresse benötigt, um das Paket letztendlich seinem Empfänger zuzustellen.

Die ursprüngliche Internetadresse bestand aus 32 Bits, wobei die ersten 8 Bits den Netzwerkanteil, und die übrigen 24 Bits den lokalen Teil ausmachten. Diese Struktur war viele Jahre lang ausreichend, zumindest so lange bis David D. Clark und Danny Cohen im Jahr 1978 eine weitreichende Feststellung machten, die sie in IEN 46 (Internet Engineering Note) mit dem Titel A proposal for addressing and routing in the internet niederschrieben:

Der derzeitige Internet-Header ist groß genug, um 256 Netzwerke zu adressieren. Die Annahme ist, zumindest für die nahe Zukunft, das jedes Netzwerk, das dem Internet beitritt, eine Nummer aus diesem Bereich erhalten wird. Während es unwahrscheinlich ist, daß sehr große Netzwerke, wie beispielsweise das ARPANET, dem Internet beitreten, ist es zu erwarten, daß viele kleine Netzwerke in nicht allzu ferner Zukunft zum Internet gehören werden. Wir sollten uns daher auf den Tag vorbereiten, wenn mehr als 256 Netzwerke im Internet teilnehmen.

Adressierung nach Klassen

Wie ganz richtig vorhergesagt, wurde es notwendig, die Adressarchitektur so zu verändern, daß mehr als 256 Netzwerke am Internet teilnehmen können. Zu dieser Zeit war bereits klar, daß, wie in RFC 790 beschrieben, die Internetadresse auf verschiedenste Weise segmentiert werden kann, um drei Adressklassen zu etablieren.

In Klasse A ist das höchste Bit 0 und die nächsten 7 Bits repräsentieren das Netzwerk. Die übrigen 24 Bits sind die lokale Adresse. In Klasse B sind die beiden höchsten Bits 1 und 0 und die nächsten 14 Bits stellen die Netzwerkadresse dar, während die letzten 16 Bits nun den lokalen Teil repräsentieren. Schließlich sind in Klasse C die drei höchsten Bits 1, 1 und 0, und die nächsten 21 Bits sind die Netzwerkadresse und die letzten 8 Bits die lokale Adresse.

Diese Klassenarchitektur reichte für die nächsten 12 Jahre aus und das Internet wuchs von einem US-Forschungsnetz zu einem globalen akademischen Netzwerk heran.

Frühe Registrierungsmodelle

In den 80er Jahren, wurde das Hochgeschwindigkeitsnetz der American National Science Foundation (NSF) an das ARPARNET angebunden und formte das Internet wie wir es heute kennen. Von diesem Tag an, war es notwendig, die IP-Adressen zu verwalten, um sicherzustellen, daß nicht zwei Netzwerke versuchen, die gleiche Netzwerkadresse im Internet zu verwenden.

Zunächst hat Jon Postel diese Aufgabe freiwillig übernommen und soll dabei lediglich einen Schreibblock verwendet haben. Mit dem Wachstum des Internets, insbesondere mit der Einführung der Klassenarchitektur, war es mit einem Notizblock nicht mehr getan und die Internet Assigned Numbers Authority (IANA) wurde ins Leben gerufen und mit ihr die Internet Registry (IR). Später übernahm die AUfgabe SRI International in Menlo Park, California. Zwischen der SRI und der NSF wurde ein Vertrag geschlossen und das Network Information Center (NIC) gegründet.

Während dieser Zeit wurden Netzwerkadressen sehr liberal vergeben (allokiert) und jede Organisation, die auch nur den geringsten Anforderungen genügte, war qualifiziert, auch größere Adressbereiche zu erhalten. Mit dem beschleunigten Wachstum des Internets während der 80er Jahre, bahnten sich zwei größere Probleme an: der Adressraum verringerte sich rapide aufgrund der größzügigen Adressallokation über alle Klassen hinweg. Zusätzlich wurden die Routing-Tabellen zu groß, weil sie nicht aggregiert , also zusammengefaßt, wurden.

Adresskonservierung und -Aggregation

Adresskonservierung und Aggregation stehen im Gegensatz zu einander: zum einen möchte man so viel Adressraum wie möglich konservieren und zum anderen sollen aber viele Einträge in Routing-Tabellen zu einem Eintrag zusammengefaßt werden. Warum das sich beides so gegensätzlich verhält sehen wir an folgendem Beispiel.

Innerhalb einer Organisation geibt es nur eine Internet-Verbindung, aber die einzelnen Gebäudeteile und Abteilung haben oftmals eigene lokale Netzwerke. Das lag meist an den geringen Entfernungen der zugrundeliegenden Netzwerktechnologie, wie etwa Ethernet. Diese Netzwerke müssen in der Regel mehr als 254 Hosts, die durch Klasse-C-Netze adressierbar waren, aufnehmen können aber auch nicht mehr als 1000. Einerseits könnte das Klasse-C-Netz weiter unterteilt werden, damit es unterhalb der 254-Host-Grenze bleibt, oder wir nehmen ein Klasse-B-Netz für jedes lokale Netzwerk her, allerdings würden wir dann mehr als 60.000 mögliche Hosts verschwenden. Erstere Herangehensweise ist zwar möglich, nervt aber mit der Zeit unglaublich, während letzte extrem verschwenderisch ist. Außerdem würde die erste Variante unnötig viel Last auf das Routing übergeben, da jedes dieser kleinen Netzwerke einen eigenen Routing-Eintrag bräuchte, der im gesamten Internet bekannt gemacht werden müßte.

Dieses grundlegende Problem existiert noch bis heute. Adressraum großzügig zu vergeben reduziert zwar die Größe der Routing-Tabelle, verschwendet aber ohnehin knappe Adressen. Eine konservative Adressallokation wiederum führt zu mehr Aufwand im Routing.

Subnetting

Um einige der oben geschilderten Probleme anzugehen, wurde da Subnetting, definiert in RFC 791, eingeführt. Es führt eine weitere Ebene innerhalb der Adressierungshierarchie ein, indem ein Subnetzteil in die IP-Adresse eingebaut wird. Das weltweite Routing blieb unverändert, da noch immer nur mit der Netzwerkadresse (Klasse A, B, oder C) gearbeitet wurde, solange bis ein Router im Netzwerk mit der passenden Netzwerkadresse erreicht wurde. Dieser Router, welcher für das Subnetting konfiguriert wurde, interpretiert die fest eingestellte Anzahl von Bits des lokalen Adressteils (der Subnetzteil), um das IP-Paket an einen weiteren Router zu übermitteln, der ähnlich konfiguriert ist. Wenn ein Router, der mit dem Zielsubnetz verbunden ist, das Paket erhält, verwendet er die übrigen Bits lokalen Adressteils, um das Ziel zu identifizieren. Übertragen auf das vorangegangene Beispiel würde die Organisation im Bestfall ein Klasse-B-Netz mit einer 6-Bit-Netzmaske wählen, so daß 62 Netzwerke mit je 1022 Hosts eingerichtet werden könnten.

Subnetting löst das Routing-Problem auf sehr elegante Weise, weil nur ein globaler Routing-Eintrag für die Organisation nötig war. Außerdem war das auch für die Konservierung von Adressräumen sehr vorteilhaft, da es eine offensichtliche Alternative zum überfüllten Klasse-B-Netz darstellt.

Da die Grenze zwischen dem Subnetzteil und dem lokalen Teil nicht aus der Adresse selbst abgeleitet werden konnte, mußten die Router der Subnetze manuell mit Hilfe einer Subnetzmaske konfiguriert werden. Zunächst wurden statische Routing-Informationen genutzt, aber später konnten Interior Routing Procols diese Informationen austauschen.

Supernetting

Innerhalb von sieben Jahren wurde klar, daß auch Subnetting auf lange Sicht nicht mehr mit dem Wachstum des Internets mithalten konnte. Der Adressraum in dem überfüllten Klasse-B-Netz wurde extrem knapp, da es keine Netzklasse gab, die eine mittelgroßen Organisation gerecht wurde, und Klasse-C-Netzwerke wiederum zu klein waren. Desweiteren überstieg die Größe der Routing-Tabellen, die Leistungsfähigkeit der Software um sie effektiv verwalten zu können. Und schließlich war da noch die allgemeine Verknappung des 32-Bit-Adressraums.

Die ersten beiden Probleme waren von hoher Wichtigkeit, da man davon ausging, daß sie in den nächsten ein bis drei Jahren die Funktionsfähigkeit des Internets ernsthaft in Gefahr bringen konnten. Die in RFC 1338 vorgeschlagene Lösung hieß Supernetting. Supernetting heißt der Abschied von den Netzklassen hin zum Classless Inter-Domain Routing (CIDR). Der Vorschlag lautete folgendermaßen:

Die Lösung des Problems sieht vor, zukünftige Adresszuweisungen hierarchisch vorzunehmen, indem die Kontrolle über Segmente des Adressraums an die verschiedenen Network Service Provider übergeben wird.

Classless Inter-Domain Routing

1993 wurde die Technik des Supernettings als Standard unter dem Namen Classless Inter-Domain Routing (CIDR) veröffentlicht. Zwei Dinge waren für CIDR essentiell: das Routing-System mußte verändert verändert und die Zuweisungsprozeduren neu erdacht werden.

Mit CIDR konnten Router nicht zwischen dem Netzwerkteil und dem Hostteil der IP-Adresse unterscheiden. Diese Information mußte nun mittels neuer Routing-Protokolle propagiert werden. Glücklicherweise gab es zu dieser Zeit nur ein Routing-Protokoll, das weite Verbreitung fand: das Border Gateway Protocol (BGP). Der Übergang von BGP-3 auf BGP-4 fand innerhalb weniger Tage statt, doch RFC 1654 wurde erst viel später als Standard veröffentlicht.

CIDR erforderte, daß die Paketweiterleitung durch die Router leicht verändert werden mußte, da der Netzwerkteil, welcher laut CIDR-Terminologie nun als Präfix bezeichnet wird, von beliebiger Länge sein kann. Das bedeutet, ein Router kann mehrere gültige Routen zu einer spezifischen 32-Bit-Zieladresse aufweisen. Die Router mußten nun immer das längste Präfix wählen, um ein Paket weiterzuleiten.

Zusätzlich zu den technischen Veränderungen kam der Erfolg auch durch eine Weiterentwicklung der administrativen Prozeduren, die nötig waren, um Adressäume so zu allokieren, das die Routen bestmöglich zusammengefaßt werden können (Route Aggregation). Auch ISPs haben sich inzwischen zu dem entwickelt, was wir heute kennen und waren nun in der Lage, ihren Kunden ebenfalls Adressbereiche zuzuweisen, die sie aus ihrem eigenen Pool entnahmen und so viel leichter zu einzelnen Routing-Einträge aggregiert werden konnten.

Der Auftritt der Regional Internet Registries

Während der Bedarf einer topologisch ausgerichteten Adressvergabe offensichtlich war, wurde auch deutlich, daß die administrativen Mechanismen der Adressverteilung weiterentwickelt werden müssen. Ein zentralisiertes System skaliert aus folgenden Gründen nicht gut:

• Die Menge der zu verwaltenden Informationen ist einfach zu groß
• Die Entfernung zwischen Adresskosument und -vergeber ist zu groß
• Es fehlt an einer globalen Finanzierungsmöglichkeit
• Es fehlt an lokaler Unterstützung durch die Community

Im August 1990 wurden diese Erkenntnisse und die Notwendigkeit eines Paradigmenwechsels in RFC 1174 formal erkannt und von dem U.S. Federal Networking Council vorangetrieben:

…it is timely to consider further delegation of assignment and registration authority on an international basis.

Die ansteigende kulturelle Vielfalt des Internets warf auch neue Herausforderungen für die Administration auf. Im Oktober 1992 veröffentlichte die Internet Engineering Task Force (IETF) RFC 1366, das den Grundstein für die Entwicklung eines Delegationsprozesses legte und ein regional verteiltes Registry-Modell vorsah. Es hob besonders den Bedarf einer Registry in jeder geographischen Region der Erde (im Sinne der Kontinente) hervor. Jeder Registry würde so ein Addressbereich aus dem globalen Pool zur weiteren Verfügung bereitgestellt werden, und die Allokierung müsse dann den aktuellen Techniken zu Adressaggregation entsprechen (hier: CIDR).

RIPE NCC

In den USA ging die regierungsseitige finanzielle und strukturelle Unterstützung weiter, was allerdings in anderen Teilen der Welt nicht so war. In Europa gründeten die Netzbetreiber das Réseaux IP Européens (RIPE), welches mit der Koordination der Registrierung beauftragt wurde. Das RIPE Network Coordination Center (NCC) wurde als deligierte Registry für Europa etabliert und setzt die Anforderungen aus RFC 1174 praktisch um.

Obwohl schnell Konsens unter den Netzbetreibern gefunden wurde, dauerte es fast zwei Jahre bis zur Einrichtung der Institution, da zunächst entsprechende Finanzmittel aufgetrieben werden mußten. Das RIPE NCC finanziert sich nun durch Mittel aus dem Topf der Gemeinschaft Europäischer Forschungsnetze (RARE) und einiger kommerzieller Zuwendungen.

Das RIPE NCC konstituiert sich aus Mitgliedschaften, das die erforderlichen administrativen Aktivitäten in Namen der Community ausführt. Das RIPE NCC befindet sich in Amsterdam und ist verantwortlich für 109 Länder im Europäischen Raum, inklusive des Mittleren Ostens, Zentralasiens und den Afrikanischen Ländern nördlich des Equators. Es besteht aus etwa 2700 ständigen Mitgliedern und führt die verwaltungstechnischen Aufgaben der Address Supporting Organization (ASO) der Internet Corporation for Assigned Names and Numbers (ICANN) aus.

APNIC

Das Asia Pacific Network Information Centre (APNIC) wurde als zweite RIR 1993 in Tokyo als Pilotprojekt des APCCIRN (Asia Pacific Coordination Committee for Intercontinental Research Networks, jetzt Asia Pacific Networking Group [APNG]) gegründet. Zunächst war es als eine Art Versuch gedacht, den lokalen NICs (Network Information Center) bei der Adressallokierung unter die Arme zu greifen. Nach erfolgreichem Test wurde das APNIC als permanente Organisation für die Adressvergabe im Asiatisch-Pazifischen Raum eingesetzt (insgesamt 62 Länder aus Zentral- und Südasien, Ozeanien und dem westlichen Pazifik).

Ursprünglich basierte das APNIC auf den Strukturen der nationalen NICs, führte aber 1996 eine Mitgliedssystem, ähnlich dem von RIPE NCC, ein.

Das APNIC, welches 1998 nach Brisbane, Australien, verlagert wurde, koordiniert die Zusammenarbeit seiner 700 Mitglieder mit fünf anderen nationalen Registries, den NIRs in Japan, China, Taiwan, Korea und Indonesien. Die NIRs übernehmen die gleiche Aufgabe wie das APNIC, allerdings auf nationaler Ebene indem sie Adressbereiche an Netzbetreiber und ISPs deligieren.

ARIN

1991 wurde die IR-Funktion dem Unternehmen Network Solutions, Inc. übertragen. Das bedeutete, daß die Registrierung von Domain-Namen, Autonomen Systemnummern (ASN), Benutzerverwaltung, die Bereitstellung der notwendigen Dienste und vieles mehr nun in der Verantwortung dieses Unternehmens lag.

Aufgrund des explosionsartigen Wachstums des Internets anfang der 90er Jahre, entschied sich die US-Regierung und die NSF für eine Trennung der Verwaltung des kommerziellen Netzes von dem des US-Verteidigungsministeriums. Zusammen mit Network Solutions, Inc. gründete die NSF 1993 das InterNIC, das die Verwaltung des IP-Adressraums und der Domain-Namen übernehmen sollte.

Nach einiger Zeit und einer sehr ausfürhlichen Beratung mit der IANA, der IETF, dem RIPE NCC, der NSF und dem Federal Networking Council (FNC), einigte man sich darauf, dem Beispiel des RIPE NCC und des APNIC zu folgen und eine neue Instanz mit den Aufgaben des InterNIC zu betrauen. Das Resultat ist die American Registry for Internet Numbers (ARIN), welche 1997 gegründet wurde und als nicht-kommerzielle Organisation mit einer Mitgliederstruktur organisiert ist.

Die ARIN befindet sich in Chanitlly, Virginia, USA. Es bedient etwa 70 Nationen in Nordamerika, Südamerika und der Karibik, sowie allen Afrikannischen Ländern südlich des Äquators. Innerhalb der ARIN gibt es zwei NIRs in Brasilien und Mexiko.

AfriNIC

AfriNIC ist die zuständige Regional Internet Registry (RIR) für Afrika.

AfriNIC, mit Sitz in Ebene City, Mauritius, wurde am 11. Oktober 2004 durch ICANN provisorisch anerkannt und nahm seinen Dienst am 22. Februar 2005 auf. Im April 2005 wurde sie schließlich offiziell anerkannt.

Damit übernimmt sie die Afrika Agenden, die zuvor RIPE NCC, ARIN und APNIC inne hatten.

LACNIC

Das Latin American and Caribbean Internet Addresses Registry (LACNIC) die RIR für den Südamarikanischen Raum und der Karibik.

Es übernimmt seit 2001 die administrativen Aufgaben der ARIN und ist in Montevideo, Uruguay, ansässig, wird aber vom Comitê Gestor da Internet no Brasil in São Paulo unterstützt.

Das RIR-System

In RFC 2050 wurden einige Punkte über die Zusammenarbeit zwischen den globalen Internet-Communities präsentiert, die genauer auf die Ziele und die Rolle der RIRs eingeht. Auch wenn die IANA die ultimative Kontrolle über den gesamten Adressraum behalten sollte, spricht RFC 2050 über die RIRs als eigenständige Organisationen, die sich nach den Bedürfnissen der regionalen Community richten sollte. Die drei Primärziele der RIRs sind:

• Konservierung: Sicherstellung der effektiven Nutzung des begrenzten Adressraums und Verhinderung von operativen Instabilitäten des Internets durch Marktstörungen.
• Aggregation: aktive Unterstützung bei der Verwaltung der Routing-Tabellen durch Verwendung CIDR-kompatibler Aggregationstechniken.
• Registration: Bereitstellung einer öffentlichen Registratur mit Dokumentation der Adressraumallokation und der Adresszuweisungen, und der damit verbundenen Sicherstellung der Einhaltung Richtlinien für die Adressvergabe.

Das Open Policy Framework (OPF)

Von Anfang an war klar, daß diese drei Ziele des öfteren miteinander in Konflikt geraten würden, da einige Individuen und Organisation unterschiedliche Zielsetzungen verfolgen würden. Auch war klar, daß durchaus unterschiedliche Herangehensweisen zur Beilegung und Vermeidung solcher Konflikte zulässig waren. So hat jede RIR innerhalb des sogenannten Global Policy Frameworks eine eigenen spezifischen Grundsätze und Verfahren entwickelt.

Auch wenn es unter den RIRs verschiedene Ansätze geben mag, basieren alle auf einem selbstregulierenden, offenen, transparenten, konsensbasierten Verfahren zur Umsetzung ihrer Aufgaben. Die Aktivitäten und Dienste einer jeden RIR werden in offenen Foren entworfen, diskutiert, ausgewertet und bei bestehendem Konsens auch ausgeführt. So sind schließlich alle an der Entscheidungsfindung beteiligt.

Um die breite Unterstützung stärken, werden in regelmäßigen Abständen öffentliche Meetings abgehalten, die in jeder Region stattfinden können. Zusätzlich kann jeder Aspekt der RIR in öffentlichen Mailinglisten diskutiert werden. Desweiteren findet reger Informationsaustausch mit anderen Communities, wie etwa der IETF, statt und die Teilname an anderen Meetings, hilft die Position der RIRs und seiner Communities zu stärken.

Der Entscheidungsprozess imd die allgemeine politische Ausrichtung ist detailliert nachlesbar unter www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.html

Welche Funktion üben RIRs aus?

Die primäre Funktion jeder RIR ist die Sicherstellung einer fairen und verantwortungsvollen Verteilung von IP-Adressen und anderen nummerischen Resourcen, die für einen stabilen und zuverlässigen Betrieb des Internets notwendig sind. Die Resourcen, welche bei einer RIR registriert, allokiert und zugewiesen werden können sind IPv4-Adressbereiche, IPv6-Adressbereiche und Autonome Systemnummern (ASNs).

Eine RIR muß die Mitglieder seiner Community auch stets über Veränderungen informieren und weiterbilden. Diese Aktivitäten werden beispielsweise über die öffentlichen Meetings, Workshops und andere Veranstaltungen oder Dienstleistungen realisiert.

RIRs, ASO und die ICANN

Die Landschaft der globalen Internet Governance erfuhr mit der Einrichtung der Internet Corporation for Assigned Names and Numbers (ICANN) 1998 einen radikalen Wechsel. Ausgegangen ist dieser Schritt von einem Regierungsdokument, das die Gründung einer nicht-kommerziellen Organisation vorsah, die aus einflussreichen Persönlichkeiten und Unternehmen des privaten Sektors bestand und die globale Politik des Internets hinsichtlich der Namens- und Adressverwaltung bestimmen sollte.

Im Herzen der ICANN stehen die sogenannten Supporting Organizations, die gegründet wurden, um bei der Entwicklung und der Kontrolle von Empfehlungen über die Politik und der Struktur der ICANN zu helfen. Im Oktober 1999 unterzeichneten die RIRs und die ICANN ein Memorandum of Understanding (MoU), das die Grundsätze für die Arbeitsweise und Struktur der Address Supporting Organizations (ASOs) festlegt. Diese Memorandum wurde erst im September diesen Jahres um zwei weitere Jahre, allerdings unter Auflagen, verlängert. Abbildung 3 zeigt die Struktur der ICANN wärhend Abbildung 4 die Hierarchie bei der Delegation der Resourcenverwaltung illustriert.

Das MoU verpflichtet jede RIR drei ihrer Mitglieder in den ICANN Address Council zu wählen, dessen Aufgabe es ist, Empfehlungen zu entwickeln und zu prüfen, die im Zusammenhang mit der IP-Adressvergabe stehen. Das soll in einem offenen und transparenten Prozess geschehen und schließlich dazu führen, dem ICANN-Vorstand (Board) beratend zur Seite zu stehen. Außerdem ist das Address Council verantwortlich für die Wahl der drei ICANN-Direktoren im Vorstand.

Zusammenarbeit zwischen RIR und ASO

Seit Gründung der ASO haben die RIRs eine wichtige Rolle bei der Wahrnehmung ihrer Aufgaben gespielt. Auf Basis gegenseitigen Einverständnisses, übernehmen die RIRs administrative Aufgaben der ASO inklusive des Hostings der ASO-Website. Zunächst übernahm die ARIN diese Aufgabe, nach einem Jahr jedoch sprang das RIPE NCC ein.

Einmal monatlich, hält das ASO Address Council Telefonkonferenzen unter Beteiligung der RIR-Repräsentanten ab. In Übereinstimmung mit dem MoU hält die ASO in regelmäßigen Abständen auch öffentliche Meetings mit den Open Policy Meetings der RIRs ab.