Wenn heute von der politischen Bedeutung des Internet die Rede ist, geht es zumeist um seinen Einfluß auf bestehende Formen politischer Organisation und Partizipation: Wie präsentieren die Parteien sich im Netz, wer nutzt dieses Angebot, und darf man sich vom Internet neue, direktere Formen politischer Partizipation erwarten, so etwa lauten die Fragen, die sich aus dieser Perspektive stellen (vgl. etwa Gellner & von Korff 1998; Hagen 1996; Wagner & Kubicek 1996; London 1994). Nicht die Beschaffenheit des Mediums selbst ist hierbei von Interesse, sondern die Effekte, die es in der politischen Landschaft erzielt. Wie verhält es sich aber mit der Konstitution des Netzes? Bringen die Entwicklung und Nutzung des Netzes eine eigenständige politische Dimension hervor?

Die Existenz einer binnenpolitischen Ebene im Internet hatten wir zu zunächst eher behauptet als systematisch begründet (vergl. Helmers, Hoffman & Hofmann 1996). Sinngemäß lautete das Argument, daß in einem technisch konstituierten Raum, in dem alles Handeln die Form von Datenflüssen hat, auch die gemeinsamen Angelegenheiten dieses Handelns, sozusagen die res publica, eine technische Gestalt annimmt. Politisch bedeutsam seien die Ereignisse und Objekte, die die Konstitution des Netzes und mithin die Handlungsbedingungen aller Nutzer berühren.

Aus empirischer Sicht zeigt sich die politische Qualität des Netzes sowohl in einem normativen als auch einem prozeduralen Gewande. Das Internet beruht auf der Idee einer guten Netzarchitektur und einem Satz von Regeln, die die Güte seiner Entwicklung sicherstellen sollen. Das Gute ist durchaus in einem aristotelischen Sinne zu verstehen: Vergleichbar einer Suche nach den Regeln des gerechten und guten Lebens "erfühlte" die Internetgemeinde der Gründerjahre ihren Weg zu den Prinzipien eines guten digitalen Datennetzes (Cerf, zit. nach Salus 1995, 29). Die Vorstellung davon, was ein gutes Datennetz ausmacht, korrespondiert einem praktischen, für das Internet gleichermaßen konstitutiven Ziel, das sich als globale Konnektivität umschreiben läßt: "Connectivity is the basic stuff from which the Internet is made", heißt es dazu lapidar (Mahdavi & Paxson 1997). Gut und gerecht sind demnach solche Regeln oder Techniken, die dem Projekt globaler Konnektivität dienen.

Eine Maxime wie globale Konnektivität zur politischen Leitidee zu erklären, mag auf den ersten Blick trivial erscheinen. Ist dieses Ziel durch Telefonnetze nicht längst verwirklicht worden? Verglichen mit dem Telefonsystem stellt das Internet eine Art radikalisierter Interpretation der Vernetzungsidee dar. Es versieht die physischen Kabel und Apparate, die wir aus der Telefonwelt kennen, mit einer neuen Nutzungsphilosophie, genauer: mit anderen, allein softwarebasierten übertragungstechniken, deren Kernelemente in einer Protokollfamilie namens TCP/IP (Transmission Control Protocol/Internet Protocol) zusammengefaßt sind. Der vielleicht wichtigste Unterschied zwischen dem Konnektivitätsgedanken der Telefonwelt und "IP land" besteht in der Art und dem Umfang der Bedingungen, die an die Nutzer und Nutzungsweisen der Netze gestellt werden. Im Unterschied zur klassischen "Einzweckmaschine" Telefon, die Konnektivität lange Zeit ausschließlich dem Sprachverkehr vorbehalten hat, zielt das Internet darauf, alle digitalisierbaren Kommunikationsformen und -dienste zu unterstützen.

Im Gegensatz zur proprietären, eigentumsrechtlich geschützten Technik der Telefonwelt, sind Internet Standards wie TCP/IP offen, dürfen also von jedem unbeschränkt genutzt werden. Die Konsequenzen für die Durchsetzung der guten Architektur sind weitreichender als man sich zunächst vorstellt. Offene Standards bedeuten einen Verzicht nicht nur auf Lizenzrechte, sondern auch auf jegliche Kontrolle ihrer Verwendung und vor allem ihrer Weiterentwicklung. Es steht jedem frei, neue Übertragungsverfahren oder Dienste für das Internet zu entwickeln. Weder die Internetgemeinde, als derzeit wichtigste Standardisierungsinstanz im Netz, noch andere Organisationen können die weitere Entwicklung des Internet wirksam steuern. Das Ziel globaler Konnektivität wird im Internet somit unter anderen Bedingungen, mit anderen Zielen und Folgen als in den zentralistisch angelegten, durch staatlich institutionalisierte Organisationen wie ISO (International Standards Organization) oder ITU (International Telecommunication Union) administrierten Netzen betrieben (vgl. Werle & Leib 1997). Ohne Sanktionsmittel ausgestattet, kann sich Regierungsmacht im Internet nahezu ausschließlich auf die allgemeine Anerkennung ihrer Regeln und Produkte stützen.

Die politische Dimension von "Internet Governance" (Baer 1996; Gillet & Kapor 1997; Gould 1997) zeigt sich im Streben nach einer guten netzarchitektonischen Ordnung, verstanden als ein Gemeinwohl, das der globalen Kommunikation dient - einer Ordnung, die im übrigen nicht alternativlos ist, sondern sich in ausdrücklicher Konkurrenz zu anderen Netzentwürfen, allen voran jenen der "POTs" (Plain Old Telephone Systems), entwickelt hat. Das Resultat dieses Strebens, die spezifische Architektur des Internet, bezeichnen wir als regierende Techniken.

Daß sich die Eigenschaften der Internetarchitektur in antiken politischen Kategorien beschreiben lassen, bedeutet allerdings nicht, daß auch die Träger dieses Projekts ihr Handeln als politischen Vorgang verstanden wissen wollen. Im Gegenteil, die Internetgemeinde¹ besteht auf einem Begriff von Technik, der sich durch eine scharfe Abgrenzung von Politik auszeichnet. Nach Überzeugung der Netztechniker sind die Unterschiede zwischen den Architekturen der Telefonwelt und dem Internet gar darauf zurückzuführen, daß die eine unter politischen, die andere dagegen unter technischen Gesichtspunkten entwickelt wird (vgl. Hofmann 1998a). In den Institutionen und Werthaltungen, den Ein- und Ausschlußstrategien, die den Wandel des Netzes prägen, sehen wir - wider die Selbstwahrnehmung der Akteure - eine weitere Dimension politischer Ordnungsmacht, die wir als Techniken des Regierens bezeichnen.

Das Zusammenspiel aus regierenden Techniken und Techniken des Regierens im Netz dient als konzeptioneller Zugriff auf die politische Ordnungspraxis im Internet. Anhand einer Fallstudie über die Entwicklung der nächsten Generation des Internet Protocols IP bzw. IPng (next generation), dem wichtigsten unter den Internet Standards, sollte exemplarisch der Frage nach den Praktiken und Gegenständen von Governance im Internet nachgegangen werden. Wie organisiert das Internet seinen eigenen Fortbestand und welche Wahlmöglichkeiten zeigen sich darin? Uns interessierten in diesem Zusammenhang sowohl netztechnische Zielsetzungen und -konflikte, als auch die spezifischen Prozeduren der Entscheidungsfindung und -durchsetzung. Der Akzent in diesem Text wird allerdings weniger auf den Techniken des Regierens als den regierenden Techniken liegen. Beabsichtigt ist, die architektonischen Dilemmata des Internet exemplarisch zu skizzieren, um daran anknüpfend der Frage nachzugehen, wie das technisch Unentscheidbare in der IETF entschieden wird.

Für die Wahl von IP als Fallstudie schien seine grundlegende Bedeutung im Internet zu sprechen. IP umfaßt immerhin den Satz kanonischer Regeln, der Computer erst miteinander in Verbindung treten und Daten austauschen läßt, um auf diese Weise autonome Netzwerke zum Netz der Netze zusammenzuschließen.

IP definiert
• das Adressierungssystem (die Ordnung des Adreßraums im Internet),
• das charakteristische Format, in dem Daten übertragen werden (Paketvermittlung),
• den Typ der Datenübertragung (verbindungslos, d.h. von Router zu Router springend),
• und die Verläßlichkeit der Datenübertragung (bestmöglich, ohne Garantien).²

Die Ziele, Strategien und Konflikte um die Weiterentwicklung der Internetarchitektur wurden mit Hilfe vier verschiedener Quellentypen untersucht.

1. Dokumentenanalyse: Internet-Drafts und Request for Comments (RFCs), die beiden Publikationsserien der IETF, ermöglichen eine überaus ergiebige Dokumentenanalyse. Zusammen bilden sie den augenblicklichen Stand des gesamten Standardisierungsgeschehens in der Gemeinde ab - und dies aktueller als jede andere Dokumentenquelle. Gelegentlich dienen RFCs aber auch zur Verbreitung anderer Mitteilungen. Einige enthalten etwa Gedichte (vgl. RFC 1121) oder auch Aprilscherze (siehe Fußn. 19). In den letzten 18 Monaten seit Anfang 1997 hat die IETF gut 3.000 Internet-Drafts und knapp 400 RFCs veröffentlicht. Spezifikationen für IPv6 werden derzeit in 29 Internet-Drafts und 16 RFCs beschrieben.³

2. IETF-Tagungen: Eine weitere Erhebungsquelle bildeten die dreimal jährlich stattfindenden Arbeitstagungen der IETF. Das fünftägige Zusammentreffen von 2.000 bis 2.500 Ingenieuren bietet Gelegenheit, um die praktische Arbeitsweise und interne Organisationsform, die typischen Gebräuche und nicht zuletzt das Verhältnis zwischen elektronischer und realweltlicher Kommunikationsform zu studieren. Akteure, die wir zuvor nur aus ihren schriftlichen Beiträgen im Netz kannten, wurden während der Tagungen im doppelten Sinne als Figuren erkennbar. Zum einen lassen sich Namen und Meinungen einer körperlichen Erscheinung zuordnen, zum anderen aber verbinden sich mit Personen nun (Vater-, Funktionärs- oder Außenseiter-)Rollen, Ansehen und Status - elementare Ordnungselemente in der Netzentwicklung, die sich nicht allein aus der Beobachtung im Netz erschlossen hatten, jedoch hilfreich waren, um Strukturen und Verläufe elektronischer Debatten besser zu verstehen. Ein gutes Beispiel für die Ausdrucksformen von Autorität und Status in der Community bildet die Diskussionsordnung in den Arbeitsgruppensitzungen. Nicht die Schlange hinter dem Mikrophon, will sagen: die Wartezeit entscheidet nämlich über die Reihenfolge der RednerInnen, sondern die Bedeutung des Sprechenden bzw. seines beabsichtigten Beitrages. Diese Bedeutung wird zugleich beansprucht - etwa durch die Entschlossenheit, mit der das Mikrophon angesteuert wird - und bereitwillig zugestanden: Man tritt einen Schritt zurück in der Warteschlange, um dem Ranghöheren Platz zu machen.

3. Experteninterviews: Die Teilnahme an den Tagungen der IETF diente zugleich dazu, Interviews zu führen. Die Absicht der Interviews war zum einen, die aus den elektronischen Archiven rekonstruierte Entstehungsgeschichte von IPv6 um die Erinnerungen der Beteiligten zu ergänzen (vgl. dazu auch Hofmann i.E.). Zum anderen zielten die Befragungen auf die Klärung von Problemstellungen, die, wie etwa die Frage nach Alternativen zu IPv6 oder des Einflusses privater Adreßräume auf die Netzarchitektur, außerhalb oder quer zu den Arbeitsgruppen der IETF liegen.
   Überraschend für die Beobachterinnen ist, daß die IETF ihrer gewichtigen Rolle in der Regulierung des Internet zum Trotz nicht einmal näherungsweise kohärente Entwicklungsstrategien entwickelt. Debatten, die über konkrete Standardisierungsvorhaben hinausgreifen, ergeben sich allenfalls als - in der Regel schnell versiegende - Nebenarme der vergleichsweise stark reglementierten Kommunikationsflüsse in den Arbeitsgruppen: "There is a lack of a comprehensive 'business plan' within the IETF. There is no consensus or discussion within the entire IETF about the direction of an area, for example", so beschrieb eine Autorität der Gemeinde dieses Phänomen.⁴

4. Mailinglisten: Als wichtigste Informationsquelle für die Fallstudie aber erwiesen sich Mailinglisten. Dieser verteilte Kommunikationsdienst stellt heute die wichtigste Entwicklungsstätte von Internettechnik dar. Jede der rund 100 Arbeitsgruppen in der IETF unterhält ihre eigene Mailingliste, die grundsätzlich offen für Interessierte sind. Die IPng Mailingliste wird derzeit von rund 1.400 Abonnenten gelesen; die Zahl der aktiven Mitglieder liegt jedoch weit darunter und erreicht kaum 5 % der überwiegend "lurkenden" Listenmitglieder. Seit ihrer Einrichtung vor genau vier Jahren Mitte 1994 hat sie etwa 6.000 Beiträge zu verzeichnen. Das Lesen von Mailinglisten haben wir als ein qualitativ neuartiges Fenster auf das Forschungsgelände "Technikentwicklung im Netz" bezeichnet (Hofmann i.E.). Das forschungsstrategisch Besondere der Mailingliste besteht darin, daß man dem Räsonieren der Ingenieure aus nächster virtueller Nähe zuschauen kann, ohne jedoch selbst zur Adressatin zu werden. Wie sonst vielleicht nur die Archivrecherche verschafft diese Forschungsquelle einen Zugang zum Untersuchungsfeld, der nicht einmal indirekt zu ungewollten Interventionen führt. Obwohl elektronisch so präsent wie die Protagonisten der Liste, bleiben die Zuschauerinnen von diesen unbeachtet. Bemerkbar macht sich diese Nichtbeachtung auch daran, daß keine Übersetzungs- oder Dekontextualisierungsversuche stattfinden. Auf den Mailinglisten reden die Ingenieure untereinander in der ihnen eigenen Schriftsprache, die sich durch eine strengere Ökonomie der Worte und Buchstaben (davon zeugen die zahllosen Akronyme!) wie auch durch besonderen Sprachwitz auszeichnet. Mailinglisten sind ein vielstimmiger Informant. Sie erlauben es, Konflikte um die Architektur des Netzes im Präsenz zu verfolgen. Man hat Teil an einer fortlaufenden Diskussion, in der sich die verschiedenen Positionen zum eigenen Forschungsgegenstand artikulieren. Die Mailingliste IPng, die offizielle Entwicklungsstätte des neuen Internet Protocols, wurde 1997 gar zum Opfer einer Gegengründung. Auf der "IPv6-haters list" versammeln sich die Kritiker von IPv6 wie auch die Interessenten an dieser Opposition.⁵
   Mailinglisten ersetzen zwar andere Forschungsquellen wie Interviews nicht, aber aufgrund der besonderen Beobachtungsbedingungen, die im digitalen Datennetz bestehen, erlauben sie eine Form des Dabeiseins, die umgekehrt nicht durch herkömmliche Untersuchungsmethoden erreicht wird. Zu den 'generischen', dieser Forschungsquelle zu verdankenden Einsichten über Regierungsmacht im Netz gehört die Breite des Spektrums divergierender, gleichwohl plausibler Auffassungen, die in der Community zur Internetarchitektur vertreten sind. Die Beobachtung kollektiv und öffentlich betriebener Technikentwicklung sozusagen als Live-Veranstaltung läßt erkennen, daß sich an das Projekt globaler Konnektivität verschiedene Entwicklungsoptionen knüpfen. Im Namen der guten Architektur wird darum gestritten, welche Vorgehensweise ihrer Realisierung am nächsten kommt und welche Kompromisse dabei akzeptabel sind. Um welche Probleme es dabei geht, wie diese bewertet und bearbeitet werden, wird nachfolgend in (sehr) groben Zügen anhand der Entwicklungsgeschichte einer vielleicht bald regierenden Technik rekonstruiert. Empirische Einlagen aus (anonymisierten) Interviews und Mailinglistenbeiträgen ⁶dienen hierbei zur Illustration und Plausibilitätssteigerung.

Je weiter sich das Internet ausdehnt, desto prekärer gestaltet sich zumindest eine kohärente Form der Bewältigung von Krisen, die durch sein Wachstum verursacht werden. Die Dezentralität und Offenheit des Netzes ist nämlich zugleich Grund seines Erfolges wie auch erhebliches Hindernis bei dem Versuch, neue Techniken netzweit durchzusetzen. Um 1990 schien das Netz an zwei betriebswichtigen Stellen gleichzeitig unter Druck zu geraten. Engpässe zeichneten sich zum einen in der numerischen Adressierungskapazität ab. Diese entscheidet über die Zahl möglicher Netzknoten und Nutzer, die eine weltweit eindeutige Identität im Internet erhalten können - und damit folglich über den maximalen Umfang, den das Netz erreichen kann. Wachstumsgrenzen zeigten sich zum anderen im Routingbereich. Die Zahl der Wege im Netz wuchs schneller als die Kapazität der Rechner zur Kalkulation derselben.⁷ Die Speicher- und Rechenkapazität der Router aber bestimmt letztlich die Anzahl erreichbarer Objekte im Netz, d.h. Netzknoten oder Sites, zu denen Datenrouten ermittelt werden können.

Das Projekt globaler Konnektivität war mit zwei verwickelten und zugleich bedrohlichen Skalierungsproblemen konfrontiert. Bedrohlich schien die Lage zu Beginn der 90er Jahre, insofern das Internet auf einen Kollaps zusteuerte; verwickelt, weil der Engpaß nicht in der absoluten Anzahl verfügbarer Adressen und kalkulierbarer Datenwege zwischen ihnen bestand - immerhin kann das 32 bit große Adreßfeld von IPv4 rund 4 Mrd. Hostrechner in 16,7 Netzwerken identifizieren (RFC 1752) - sondern in einem Aspekt, dem die Techniker bislang kaum Aufmerksamkeit geschenkt hatten: der Organisation des Adreßraums. Das bisherige Verfahren zur Allokation von Netzadressen erwies sich angesichts der neuen Größenordnung des Internet als zu großzügig, ja sogar als verschwenderisch und obendrein äußerst unsystematisch (vgl. Ford, Rekhter & Braun 1993, 14). Viele Netzadressen bleiben bis heute ungenutzt, weil Netzwerke bzw. Sites nur einen Bruchteil des einst erhaltenen Adreßvolumens verwenden. Schätzungen gehen davon aus, daß etwa ein Zehntel der Adressierungskapazität von IPv4 tatsächlich in Benutzung ist. ⁸ Auch das Problem der "routing explosion" hängt mit dem Wachstum des Internet nur mittelbar zusammen. Dem Adreßraum mangelte es an einer Ordnung, die die Zunahme der Datenrouten von jener der Sites entkoppelte. Aggregierbare Adressenallokation, lautete das Stichwort. Den Erinnerungen unserer Interviewpartner zufolge hatte die Struktur des Adreßraums bei der Entwicklung von IPv4 keine Rolle gespielt. Solange das Internet klein war und nur einen Backbone besaß, der faktisch den einzigen Transitweg für alle Datenpakete bildete, interessierte die Effizienz des Adressierungsverfahrens ebensowenig wie seine "Routingfreundlichkeit". Adressen dienten vorrangig zur Identifikation, nicht aber zur Lokalisierung von Netzobjekten. Bis 1993/1994 wurden IP Adressen tatsächlich sequentiell, das heißt in der Reihenfolge der Antragsteller, ohne Rücksicht auf die geographische oder topologische Position der Netze vergeben.⁹ Aus der Perspektive der Router ist der Adreßraum von IP daher ein flaches Gebilde. Weil es keine Gliederung gab, unter der sich Netzadressen zusammenfassen ließen, mußten diese alle einzeln ausgewiesen werden. Und um so mehr Netzwerke den Anschluß an das Internet suchten, desto länger wurden die Tabellen, in denen die Router Netzadressen und die Wege dorthin speichern.

Eine Steigerung der Adressierungseffizienz, wie von Teilen der Internetgemeinde vorgeschlagen, mochte wohl den Adressenmangel kurzfristig beheben, drohte aber damit, den Routingengpaß gar noch zu verstärken. Umgekehrt war von einer Hierarchisierung des Adressierungssystems zwar eine Entschärfung des Routingproblems zu erwarten, zugleich aber eine weitere Senkung der ohnehin geringen Nutzungseffizienz der Adressenvergabe (vgl. dazu Huitema 1996).

Die miteinander verschränkten Skalierungsprobleme des Internet steckten den Rahmen ab für die Entfaltung widerstreitender Lösungsvorstellungen, die, gewollt oder ungewollt, zwei zentrale Regierungsfragen im Netz aufwarfen. Die eine galt der Architektur des Internet: Sind die aktuellen Skalierungsprobleme als Indiz dafür zu werten, daß das Projekt globaler Konnektivität eine von Grund auf erneuerte Netzorganisation erfordert oder bedarf es lediglich einer verbesserten Implementierung seiner Prinzipien? Die andere thematisierte die Machtverteilung in der IETF: Und wem obliegt es, darüber zu entscheiden?

Wie in frühen Tagen, als die Internetgemeinde noch klein und überwiegend akademisch war, gilt die Regel des "one man, one vote": Jeder spricht nur für sich selbst, nicht aber für die Organisation, in deren Auftrag er an der IETF mitwirken mag: "all participants in the IETF are there as INDIVIDUALS, not as companies or representatives thereof. (Whether this is a quaint fiction is an interesting discussion given enough beer, but it is certainly the historical basis of the organization. (O'Dell, 18. 12. 97, POISED)

Mehrheitsentscheidungen und Kampfabstimmungen sind verpönt. Es wird so lange diskutiert, bis sich ein breiter Konsens ("rough consensus") herausschält. Der Eindruck, daß es sich bei der IETF um eine technische Graswurzelgemeinde handelt, verstärkt sich, wenn man die bereits erwähnten Kleidungssitten der IETF betrachtet. T-Shirts, Shorts, Sandalen und die Abneigung gegen Anzüge und Krawatten spielen im Selbstverständnis der Internetcommunity eine so große Rolle, daß Neulinge explizit auf die Existenz des "dress codes" hingewiesen werden (vgl. RFC 1718). In den Konsensbildungs- und Kleidungsregeln manifestiert sich eine programmatische Haltung der Technikergemeinde zum Internet. Aus Sicht der Ingenieure spiegelt sich im Internet eine Tradition der Technikentwicklung, in der diejenigen entscheiden, die auch selbst Hand anlegen, will sagen: Programmcode schreiben. Anzüge und Krawatten symbolisieren demgegenüber eine Arbeitsteilung, in der die Entscheidungsgewalt bei Management und Marketing liegt. Das Internet, so die Vorstellung der Techniker, soll von Technikern regiert werden. Das Primat der Standardentwicklung drückt sich in der Organisationsform der Community aus:

"One of the things that no one seems to get is that voluntary standards groups are bottom-up organizations. The program of work is set by who shows up and what they want to work on. If people quit attending they have no raison d'etre. Voluntary standards are just that: 'use them if you want.' (...) Voluntary standards have weight in the market place because vendors and users decide to implement and buy products using those standards and *choose* to attend meetings of those organizations." (Day, IPv6 haters, 16.2. u. 2.3.96, 0468 u. 0540)

Im anhaltenden Wachstum der Internetgemeinde drückt sich eine Aufwertung der Netztechnik und mittelbar seiner Normungsgremien aus. Unternehmen haben die IETF als "Vehikel" (Day) zur Koordinierung innerhalb eines neuen Marktes entdeckt: "It used to be that the phone companies went to ITU and the computer companies to ISO. Now the computer companies go to the IETF and IEEE. (...) Someday the same fate will befall the IETF when they are viewed as a bunch of old farts." (Day, IPv6 haters, 2.3.96, 0540). Die Attraktivität der Internetgemeinde besteht aus Sicht der Unternehmen nicht zuletzt darin, daß die Standardentwicklung noch wenig von ihrem institutionellen Eigengewicht beeinträchtigt wird. Ihrer Größe und wirtschaftlichen Bedeutung zum Trotz, ist die IETF darum bemüht, an ihrer informellen Organisationsform und ihrer praktischen, auf funktionstüchtige Technik ausgerichteten Orientierung festzuhalten.

Auch auf der organisatorischen Ebene machen sich jedoch zunehmend Skalierungsprobleme bemerkbar. Ein Indiz dafür sind die expandierenden Arbeitsgruppen, in denen sich das Verhältnis zwischen aktiven Teilnehmern und passiven Beobachtern immer stärker in Richtung letzterer verschiebt. Die populären Arbeitsgruppen müssen ihre Treffen inzwischen in den großen Ballsälen der amerikanischen Hotels abhalten. Diskussionsbeiträge mutieren unter solchen Umständen zu Präsentationen, und eine ernsthafte Arbeitsatmosphäre will sich kaum mehr einstellen.

Wie in der Standardentwicklung, findet sich auch für dieses Wachstumsproblem eine pragmatische Lösung. Die einstigen Arbeitstagungen der IETF durchlaufen einen Bedeutungswandel. Vor allem die großen Arbeitsgruppen entwickeln nach und nach den Charakter von Präsentationsveranstaltungen, die dazu dienen, ein breites Publikum schweigender Beobachter über den aktuellen Stand der Dinge und die noch offenen Fragen zu informieren. Die eigentliche Entwicklungsarbeit aber verlagert sich aus den Arbeitsgruppen in sogenannte "design teams" (vgl. Bradner 1998). Dabei handelt es sich um kleine, nicht öffentlich arbeitende Gruppen von rund drei Personen, die entweder vom "chair" einer Arbeitsgruppe kooptiert werden oder sich selbst konstituieren. Die Bildung von design teams läßt sich als Versuch verstehen, unter Ausschluß der öffentlichkeit die Arbeitsbedingungen der frühen Tage, als noch alle Mitglieder um einen Tisch passten, wieder herzustellen. Typischerweise erstellen design teams erste Entwürfe (in der Form von Internet drafts), die dann in den Arbeitsgruppen zur Diskussion gestellt werden. In lakonischem Ton dazu der Vorsitzende der IPng Arbeitsgruppe:

"... almost *all* protocols considered by the IETF are the work of a small number of people and, where that number is greater than 1, the result of closed design meetings/mailing lists/phone calls/whatever. IETF working groups seem to have two roles: - adding value by identifying bugs or issues that the designers overlooked and would wish to know about - subtracting value by forcing compromise and featuritis into a design against the best judgement of the designers." (Deering, Ipv6 haters, 3.2.97, 0783)

Als langfristige Maßnahme wurde die Erweiterung der Adressierungskapazität im Rahmen eines neuen Internet Protocols vorgeschlagen. Die verschiedenen Vorstellungen, die zur Frage von "bigger Internet addresses" in der Gemeinde kursierten, sollten nach Auffassung der ROAD-Gruppe durch die Gründung mehrerer Arbeitsgruppen exploriert werden. Auf den akuten Handlungsbedarf sollte bis zum Vorliegen des neuen Protocols mit einer Interimslösung reagiert werden. Unterhalb eines Eingriffs in die Netzarchitektur mußte diese die Geschwindigkeit des Adreßverbrauchs einerseits und des Wachstums der Routingtabellen andererseits verlangsamen. Die bis heute geltende Zwischenlösung stand ein Jahr später zur Verfügung: Classless Inter-Domain Routing, kurz: CIDR.

CIDR, der Name zeigt das an, bezeichnet ein Adressierungssystem, das die Lokalisierungsfunktion, d.h. die Auffindbarkeit eines Netzobjektes, in den Vordergrund stellt. Um die Wegekalkulation zu vereinfachen und die Zunahme der Routen zugleich dauerhaft von jenem der Netzwerke im Internet zu entkoppeln, ist eine Hierarchie in den Adreßraum eingezogen worden, die als "provider-basiert" bezeichnet wird: Alle nach 1994 vergebenen numerischen Netzadressen beginnen mit einem sogenannten Prefix, das, vergleichbar einer Vorwahl, auf die Identität des Internetproviders verweist. Aufgrund des Prefixes, das der Provider mit all seinen Kunden teilt, läßt sich nun die Gesamtheit der Adressen an den äußeren Enden des Netzes unter der nächst höheren (Provider-)Ebene aggregieren. (RFC 1519) Auch für den Adressierungsengpaß wurde eine vorläufige Lösung gefunden. Dank CIDR können die Adreßblöcke flexibler auf die Größe der jeweiligen Netzwerke zugeschnitten werden. ¹³ Zuständig dafür sind die Provider, was zu erheblichen Spannungen zwischen den Nachfragern und den Anbietern bzw. Treuhändern des knappen Guts Adreßraum geführt hat.

Durch CIDR ist es gelungen, ein Kollabieren des Internet zu verhindern, allerdings um den Preis neugeordneter Eigentums- und Machtverhältnisse im Netz. Internetadressen, die nach den Allokationsprinzipien von CIDR vergeben werden, wechseln nicht mehr in den Besitz der Sites über, sondern gehören faktisch denen, die sie bislang nur weiterreichten: den Providern. Damit ein permanenter Aggregationseffekt im Adressierungsbereich erzielt werden kann, müssen Netzadressen an den Provider zurückgegeben und durch neue ersetzt werden, sobald topologische Veränderungen auftreten.

Topologische Veränderungen aber treten gemäß der Logik des "provider-basierten" Adressierens immer dann auf, wenn ein Netzwerk (oder auch sein Provider) den Provider wechselt. Um so mehr Rechner eine Site umfaßt, desto höher fallen die Kosten aus, die Verschiebungen im topologischen Gefüge verursachen. Unter dem Gesichtspunkt einer gerechten und guten Architektur betrachtet, gilt CIDR als Sündenfall. Denn das Renummerierungsdiktat wälzt die Kosten des topologischen Wandels im Internet einseitig auf die unteren Netzebenen ab und behindert damit nicht nur den Wettbewerb unter den Providern, sondern institutionalisiert auch Abhängigkeiten zwischen den Hierarchiestufen des Netzes. (vgl. RFC 1518; RFC 2008; Ford, Rekhter & Braun 1993) Gleichwohl trägt CIDR bis heute zur Verlängerung der Lebensdauer von IPv4 bei und räumt auf diese Weise eine, wenn auch unbestimmte, Frist für das überdenken der Architekturfrage des Internet ein.

"When I was at MIT, I got in a protocol war (my first - wheeee :-) between CHAOS and TCP/IP. TCP/IP lost. Not for any *technical* reason, but because of installed base. With editors, if you have a 10% market share, you're OK. With communication protocols, you're dead with 10%: people want to use them to communicate, and who wants to use something that doesn't let you talk to 90% of the world? From which I deduce that you need a massive capability edge to overcome installed base. (...) In a market competition, IPv4 has the massive edge in installed base. IPv6 is a dead duck." (Chiappa, IPv6 haters-list, 18.2.96, 0497)

"I do not believe the Internet needs a new internet-layer architecture. The current architecture has proven remarkably flexible and robust, due to its minimal requirements from lower layers, its minimal service 'promises' to upper layers, and its simple, stateless, datagram routing and forwarding model. As a result, it has survived the introduction of many new lower-layer technologies and many new applications." (Deering, big I, 15.5.94, 0789)

"One of the reasons I was personally trying to get CLNP accepted - I wasn't the only person to believe this - but I was convinced that IP itself is inherently simple. It has to be. What is really interesting and what we should have been spending a lot of time on is not mucking around with the header format for IP, but thinking about the way the routing protocols (...) needed to be made. (...)Those technical advances that had been made in the IETF would have been different in very minor ways, whether in CLNP or IPv6. (...) The Internet protocol itself is not the important thing, what is important is all the stuff that supports its operation." (L.C.)

"The main point of using CLNP is that it allows us to make use of the installed CLNP base, including existing specifications, implementations, deployment plans, deployed routers, etc. Probably the most important part of this is that CLNP is currently available in products. Using CLNP also means that we don't have to sit down and argue about the design of a new protocol, and that we will be sticking with a basic communications paradigm that we understand and know works (given that CLNP design is based on IP)." (Ross Callon, big I, 22.6.92, 203)

"... the political repercussions could well end the Internet as we now know it. (...) It means that once the network can fully route CLNP traffic there will no longer be any reason for the TCP/IP stack to exist. (...) It is also a kiss-of-death for all the emerging internet technology companies. The OSI marketing droids will have a field-day with this. Gee, I hope this is all wrong." (O'Dell, big I, 3.7.92, 0487)

Daß der 32 bit große Adreßraum von IPv4 selbst bei einer geschickteren Allokationspolitik der verbliebenen Adressen auf Dauer zu klein werden würde, akzeptierten auch die skeptischsten Stimmen in der IETF. Sehr umstritten war unter den Befürwortern einer fixen Adreßlänge jedoch, wie groß ein künftiges Adreßfeld vernünftigerweise sein sollte. Die gute Architektur ließ auch hier entgegengesetzte Positionen plausibel erscheinen. Auf der einen Seite verlangte sie ein möglichst kleines, höchstens doppelt so großes Adreßfeld wie das von IPv4, um die zusätzliche digitale Fracht, die ein jedes Datenpaket als "header" mit sich trägt, klein und den Verbrauch von Bandbreite gering zu halten. Denn lange Adressen diskriminieren nicht nur zeitkritische Anwendungen über weniger leistungsfähige Leitungen, sie verteuern auch den Datenverkehr. Kritiker eines großzügig bemessenen Adreßraums warnen daher bis heute davor, daß betriebliche Anwender schon aus Kostengründen die Verwendung eines neuen Internet Protocols ablehnen könnten. (vgl. Baker, IPng 12.11.97, 4787) Auf der anderen Seite verlangt globale Konnektivität Adressierungskapazität auf Vorrat, weil andernfalls ungewollt künftige Dienste und Serviceleistungen ausgeschlossen werden könnten, deren Adreßbedarf gegenwärtig noch gar nicht absehbar ist. Für ein großes Adreßfeld im Umfang von 128 bit wurde darüber hinaus auch die Möglichkeit der "Autokonfiguration" von Hostadressen angeführt.¹⁸ Die anhaltende Uneinigkeit über die optimale Adreßlänge ironisiert ein "First of April RFC".¹⁹

Konnektivitätskosten, die CIDR den Nutzern bzw. den Sites in Rechnung stellt, bürdet das geographische Adressierungsmodell den Providern auf. Denn um den Datenfluß innerhalb und auch zwischen den Regionen zu gewährleisten, bedarf es sogenannter Datenaustauschpunkte, deren Erreichbarkeit wiederum durch Router zwischen diesen sichergestellt werden muß. Datenaustauschpunkte wie Router hätten den Status quasi-öffentlicher Güter, für die es aber, so drücken Hoffman & Claffy (1997, 302) dies aus, bislang keine "befriedigenden Geschäftsmodelle" gibt. (vgl. auch Chinoy & Salo 1997) Niemand aber kann Provider dazu zwingen, sich einer topologischen Ordnung zu unterwerfen, deren kommerzielle Aussichten unklar sind: "The Internet has no mechanism for enforcing topology control, and it's probably 'politically' infeasible to create such a network." (Chiappa, IPv6-haters, 16.1.96, 0206) Die Erfolgschancen des neuen Adressierungssystems lassen sich somit durch die technische Qualität des Standards nur bedingt beeinflussen. Und solange sich für die Steuerung des Datenflusses im Internet kein stabiles Geschäftsmodell durchgesetzt hat, kann die Normierung des Adreßformats nur Sorge dafür tragen, daß zumindest durch die Gestaltung des Adreßformats keine Variante topologischer Ordnung ausgeschlossen wird.

"It's a little hard to say why it works, but part of the thing that made the IETF work in the first place was that if people couldn't agree on between two or three proposals, you'd just send them off in two or three working groups and let the folks do whatever they wanted to do, (...) and you'd just end up with alternatives (...) I mean, frankly, democracy does not necessarily produce the best results, if you have to vote up front as to what's the best approach (...) A much better approach is to just allow the technical proposals to get done in detail and figure out which one works. You know, deploy them on at least experimental basis. People may find they may learn things; they may learn things that apply to the other proposals. (R. C.)

Running code verkörpert ein legendenumranktes Konsensbildungsverfahren und zugleich das wohl wichtigste Merkmal, durch das sich die IETF von anderen Standardisierungsorganisationen unterschieden wissen will:

"In the IETF world we produce running code that has documents that describe it. A lot of other standards organizations produce documents and that's the end of it." (M. D.)

"Probably, the most fundamental difference is that in the ISO community, the highest goal is global consensus. (...) In the Internet community, the highest goal was interoperability and getting something to work. Something that worked was its own advertisement." (L. C.)

"We reject presidents, kings and voting,
we believe in rough consensus and running code." (Dave Clark)

"What I think the IAB should have done, was [to] follow the IETF tradition of allowing alternative proposals to go forward to the point where you could actually tell what proposals made sense technically and what didn't, with the basis that technical reality should be the ruling factor and not what some group of people think." (R. C.)

"The problems of too few IP addresses and too many Internet routes are real and immediate, and represent a clear and present danger to the future successful growth of the worldwide Internet. The IAB was therefore unable to agree with the IESG recommendation to pursue an additional six-month program of further analysis before deciding on a plan for dealing with the ROAD problems. (...) However, we believe that the normal IETF process of "let a thousand [proposals] bloom", in which the "right choice" emerges gradually and naturally from a dialectic of deployment and experimentation, would in this case expose the community to too great a risk that the Internet will drown in its own explosive success before the process had run its course. The IAB does not take this step lightly, nor without regard for the Internet traditions that are unavoidably offended by it." (Chapin , big I, 1.7.92, 0450)

Der IAB hatte sich für CLNP entschieden - nicht weil er dieses Protokoll als technisch überlegen betrachtete, sondern weil er sich von CLNP eine schnelle Lösung versprach. Die Wahl von CLNP löste in der IETF eine Protestwelle bislang unbekannten Ausmaßes aus. Nicht nur die Entscheidung selbst, auch die Art ihres Zustandekommens und die institutionellen Strukturen, die derartige Verstöße gegen die" bottom-up" Tradition der Gemeinde zuließen, waren Gegenstand der Kritik. (vgl. etwa Rose, big I, 7.7.92, 0631)

Angesichts der heraufziehenden Existenzbedrohung des Internet kreuzte sich die Frage nach der guten Architektur mit jener nach der Definitionsmacht über diese. Die Krise der Netzarchitektur weitete sich zu einer Krise seiner Regulierung aus: "One dimension was technical: What is the best course for evolving the IP protocol? (...) The other dimension was political: Who makes decisions within the Internet Community? Who chooses who makes these decisions?" (RFC 1396) Unabhängig davon, ob man sich dieser Unterscheidung zwischen Technik (Protokoll) und Politik (Verfahren) anschließen will, die IETF war, gegen ihren Willen zwar, aber doch unumgänglich mit der Machtfrage in der Entwicklung des Internet konfrontiert.

Der sich auf den einschlägigen Mailinglisten artikulierende Widerspruch gegen die Verkündung des IAB erwies sich als so groß, daß das Votum für CLNP zunächst abgeschwächt und wenig später auf der folgenden Tagung der IETF ganz revidiert wurde. Als Folge des gescheiterten Versuchs einer schnellen Festlegung auf ein Modell wurde der Findungsprozeß wieder geöffnet und sogar über die Grenzen der IETF ausgedehnt. Ein "Call for White Papers" zielte darauf, "the broadest possible understanding of the requirements for a data networking protocol with the broadest possible application" zu gewinnen. (RFC 1550)

Zugleich gründete die Internetgemeinde eine neue, in ihrer Geschichte einmalige Arbeitsgruppe: POISED (The Process for Organization of Internet Standards Working Group; vgl. RFC 1396). Der Auftrag von POISED lautete, die Entscheidungsstrukturen und Regeln der Personalrekrutierung in der IETF zu untersuchen. Die Mailingliste von POISED entwickelte sich zu einem Ort, an dem die Gemeinde ausgiebig über ihre Konstitution reflektierte: "An estimated 20 MB of messages filled up disks all over the world" zwischen August und Mitte November 1992. (RFC 1396) Das Ergebnis von POISED war eine Umverteilung und Formalisierung der Entscheidungskompetenzen in der IETF. Der Einfluß des Internet Architecture Board (IAB) wurde verringert zugunsten eines Gremiums, dem größere Nähe zur Technikentwicklung nachgesagt wird: die Internet Engineering Steering Group (IESG), die sich aus den "Area Directors" der IETF zusammensetzt (zur Organisationsstruktur der IETF vgl. RFC 2028). Zugleich wurden formelle Nominierungsverfahren für die Besetzung der "ämter" in der Community eingeführt. (vgl. RFC 1603 u. RFC 2027) ²¹

Kobe, der Ort in Japan, an dem der IAB sein Votum für CLNP verkündet hatte, ist zum Inbegriff für eine traumatische Erfahrung in die Geschichte der IETF geworden. Das Traumatische daran liegt weniger im Ausmaß des Streits, als in der Gemengelage der Gründe, die ihn auslösten. Die Entstehungsgeschichte von IPng - angefangen mit der Diagnose des bevorstehenden Zusammenbruchs bis hin zur Entscheidung für IPv6 - wird heute mit politicking assoziiert. Politicking bezeichnet ein Verhalten, das die Hegemonie des technischen Diskurses durch außertechnische Kalküle unterläuft. Die technische Argumentation wird gewissermaßen durch andere Interessen in Dienst genommen - mit allen erdenklichen negativen Auswirkungen auf die Qualität der Produkte. ²²

Der Glaube an die "technisch exzellente Lösung" (Huitema 1995), die den rough consensus quasi aus sich selbst heraus generiert, mag ein Grund dafür sein, warum den Regeln der Standardentwicklung so viel, denen der Selektionsverfahren dagegen bis dato fast keine Aufmerksamkeit gewidmet worden war. Der schlußendliche Entscheidungsprozeß verlief zweistufig. Zunächst fand eine öffentliche Verständigung über die technischen Selektionskriterien statt, auf deren Grundlage dann als zweiter Schritt die Bewertung der einzelnen Vorschläge erfolgte.(RFC 1752)

Die wichtigste änderung des Adreßfelds bestand in seiner Erweiterung auf 128 bit. Akzeptabel schien dies, weil sich die Größe des Datenpaketenkopfs trotz der Vervierfachung der Adreßlänge lediglich verdoppeln sollte. Darüber hinaus war vorgesehen, das Adreßfeld durch ein Kompressionsverfahren weiter zu reduzieren. Autokonfiguration, Sicherheits- und Authentifikationsmaßnahmen, ein neuer Adreßtyp namens "anycast address" sowie die Möglichkeit, zusätzliche Header ("extension header") an den Kopf des Datenpakets anzuhängen, gehörten zu den weiteren, eher maßvoll gehaltenen Neuerungen von SIPP. (ausf.: RFC 1752)

In den folgenden Jahren, die eigentlich zum Spezifizieren und Testen von IPv6 gedacht waren, kam es allerdings noch zu einigen unvorhergesehenen, grundlegenden änderungen am Entwurf. Die ersten vier IPv6 spezifizierenden Internet Drafts, haben daher erst ein Jahr später als geplant, im August 98, den Rang von "Draft - Standards" erreicht (vgl. RFC 2300 u. RFC 2400). Anstöße für die Reformulierung von IPv6 kamen unter anderem aus dem Routingbereich, der sich mit Verfahren zur Bandbreitenreservierung und zur übertragung zeitkritischer Dienste beschäftigt. Damit Datenpakete künftig in den Genuß solcher Formen der Sonderbehandlung gelangen können, muß ihr Kopf mit speziellen Feldern zur Kennzeichnung von Datentypen ("Traffic Class") und -flüssen ("Flow Label") ausgestattet sein (vgl. Deering & Hinden 1998). Auf diese Weise lassen sich dann Serviceanforderungen formulieren, die von den Routern verarbeitet werden, sofern sie dazu irgendwann in der Lage sind.

1997, das Jahr, in dem die "core specifications" von IPv6 zum "Draft Standard" avancieren sollten, wurden auch noch einmal erhebliche änderungen am Format des Adreßfeldes eingeklagt. Dabei handelte es sich um den wohl vorläufig letzten Versuch, die Identifizierungs- und Lokalisierungsfunktion der IP-Adresse voneinander zu trennen, um zum einen die unerwünschten Nebenwirkungen der derzeitigen Adressierungsschemas zu beseitigen, zum anderen, um eine noch stärkere Hierarchisierung des Adreßraums zu erzielen. (vgl. O'Dell 1997; Crawford et al. 1998; Hofmann i. E.) Die Initiative war zwar nicht erfolgreich, führte aber doch zu einer neuen Partitionierung des Adreßfeldes. Diese näher anzuschauen lohnt, weil sie unmittelbar anschaulich macht, daß und wie durch das Design von IP in die Raumordnung des Netzes eingriffen wird. Das Adreßfeld ist in einzelne Abschnitte unterteilt, die die vorgesehenen Hierarchiestufen im Adreßraum repräsentieren. Sein pyramidenförmiger Aufbau entspricht wiederum der erwünschten Rangordnung unter den Serviceanbietern und -nutzern im Netz (vgl. RFC 2374): The aggregatable global unicast address format is as follows:

      | 3|  13 | 8 |   24   |   16   |          64 bits               |
      +--+-----+---+--------+--------+--------------------------------+
      |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
      |  | ID  |   |  ID    |  ID    |                                |
      +--+-----+---+--------+--------+--------------------------------+

      <--Public Topology---> Site
                                      <-------->
                                        Topology
                                                   <------Interface
                                                   Identifier----->

      Where        FP Format Prefix(001)
      TLA ID       Top-Level Aggregation Identifier
      RES          Reserved for future use
      NLA ID       Next-Level Aggregation Identifier
      SLA ID       Site-Level Aggregation Identifier
      INTERFACE ID Interface Identifier

Das erste, drei bits umfassende, Feld gibt den Typ der Adresse an, gewissermaßen als Leseanleitung für alle nachfolgenden Bits. ²³Die verbleibenden 125 bits sind in eine öffentliche und einer private Topologie unterteilt - eine Grenzziehung im Datenraum, die IPv4 nicht kennt. öffentlich gemäß der Philosophie von IPv6 ist der "Transitbereich" der Daten, d.h. die Ebenen der Netzhierarchie, die allein zur Weiterleitung des Datenstroms dienen; privat sind dagegen alle Orte ohne Durchgangsverkehr. Die private Sphäre, sozusagen das Innere einer Site, wird durch zwei Felder in der IP-Adresse kodiert: dem Identifier bzw. Namen, der die Schnittstelle zwischen Rechner und Netz kennzeichnet, sowie dem Site-Level Aggregator, einem Feld zur Gliederung großer lokaler Netze. Die Felder zur Beschreibung der öffentlichen Topologie ordnen zugleich die Beziehung unter den Providern. Im Adreßfeld sind dafür zwei Hierarchiestufen vorgesehen, wovon die untere mit komfortablen 24 bits ausgestattet ist, um die Hierarchie unter den Providern in einer Weise abbilden zu können, "that maps well to the current ISP industry, in which smaller ISPs subscribe to higher level ISPs" (King 1998). Während das rangniedrigere Feld der öffentlichen Topologie die gegenwärtige Konstellation unter den Providern gewissermaßen nachempfindet, ist das Feld an der Spitze der Adreßpyramide bewußt darauf ausgerichtet, den Internetanbietern eine bestimmte Ordnung aufzuoktroyieren. Der 13 bit große Adreßraum beschränkt die Anzahl derjenigen Organisationen, die sich in der "default-free region" ansiedeln können, auf maximal 8.192. (vgl. Löffler, Sand & Wessendorf 1998) Unter dem Gesichtspunkt der Datenflußsteuerung bedeutet dies, daß die Router auf der obersten Hierarchieebene des Kommunikationsraums Verbindungen zwischen höchstens 8.192 Objekten im Netz berechnen können müssen. Durch die Größe des obersten Adessfeldes läßt sich somit der Umfang topologischer Komplexität im Internet kontrollieren. Aus Sicht der Zugangsanbieter bedeuten diese 13 bits freilich "significant constraints on operations, business models and address space allocation policies" (Karrenberg, IPng, 4996, 1. 12. 97). Nicht zuletzt deshalb wurden von Seiten der IETF Erkundigungen darüber eingezogen, ob solch schwerwiegende Eingriffe in die ökonomie des Netzes überhaupt zulässig sind:

"I asked the lawyers that do work for the IESG what restrictions in flexibility we (the IETF) have in the area of defining rules and technology that restricts ISP practices. I was told that the only time we can be restrictive is when there is no other technically reasonable option ." (Bradner, IPng, 4997, 1. 12. 97)

"if anyone expects a magic formula which says '13' and not something else, you won't get it. (...) would 14 work? - certainly. Like everything else, 13 is an engineering compromise - chosen to balance one set of considerations against a bunch of others, and after ruminating over it a long time, the consensus was 13 was the best choice." (O'Dell, IPng 5000, 2. 12. 97)

Gegenwärtig scheint sich die Entwicklung von IPv6 ihrem Ende zu nähern. Nicht nur haben die wichtigsten Komponenten von IPv6 die vorletzte Stufe im Standardisierungsprozeß erreicht, Anzeichen für eine bevorstehende Fertigstellung sind auch die große Zahl von Implementationen und der expandierende Probebetrieb im Testbed "6 bone" ²⁴. Zugleich mehren sich die Spekulationen über das Verhalten der Hersteller. Denn nur Standards, für die Produkte entwickelt und die von bestehenden Produkten unterstützt werden, können in Konkurrenz um die bestehende Installationsbasis treten.