À partir de la RFC 6852 et ICP-3

IEN 48

Le modèle catenet pour l'interconnexion

Vint Cerf DARPA/IPTO

Juillet 1978

Le modèle catenet pour l'interconnexion

Introduction

Le terme «catenet» a été introduit par L. Pouzin en 1974 dans son premier document sur l'interconnexion de réseaux de paquets [1]. Le projet américain de recherche DARPA sur ce sujet a adopté le terme pour signifier à peu près "la collecte de réseaux de paquets qui sont connectés ensemble." Il ne s'agit cependant pas d'une définition suffisamment explicite pour déterminer, par exemple, si un nouveau réseau est conforme aux règles d'interconnexion de réseau qui font de la fonction catenet la Confédération des réseaux de coopération. Ce document tente de définir les objectifs et les limitations du projet ARPA-interréseautage et de rendre explicite le modèle catenet sur lequel repose la stratégie d'interconnexion.

objectifs

L'objectif fondamental de ce projet est d'établir un modèle et un ensemble de règles qui permettront aux réseaux de données de fonctionnement interne très varié d'être interconnectés, permettant aux utilisateurs d'accéder à des ressources distantes et de permettre la communication interordinateur à travers le réseaux connectés.

L'une des motivations de cet objectif est de permettre à la technologie interne d'un réseau de données d'être optimisée pour l'exploitation locale, mais aussi de permettre à ces réseaux optimisés localement d'être facilement interconnectés en un catenet organisé. Le terme «local» est utilisé dans un sens vague, ici, puisqu'il signifie «particulier au réseau particulier» plutôt que «un réseau d'étendue géographique limitée». Un réseau satellitaire tel que le réseau de paquets par satellite ARPA a donc des caractéristiques «locales» (par exemple, l'exploitation de la radiodiffusion), même s'il s'étend sur plusieurs milliers de milles carrés géographiquement.

Une deuxième motivation est de permettre à la nouvelle technologie de réseautage d'être introduite dans le catenet existant tout en demeurant fonctionnellement compatible avec les systèmes existants. Cela permet l'introduction progressive de nouvelles et l'obsolescence des anciens réseaux sans nécessiter un changement global simultané.

hypothèses

L'une des premières questions qui doivent être réglées dans un projet de ce genre est "Quels types de réseaux de données devraient être inclus dans le modèle catenet?" La réponse à cette question est enracinée dans la fonctionnalité de base de chaque réseau candidat. Chaque réseau est supposé prendre en charge la saisie d'une collection d'ordinateurs programmables. Notre hypothèse essentielle est que tout réseau de données participant peut transporter un datagramme contenant pas moins de 1000 bits de données n'incluant pas d'en-tête réseau local contenant des informations de contrôle local. En outre, il est supposé que le réseau participant permet l'accès commuté de sorte que n'importe quel ordinateur source puisse rapidement entrer des datagrammes pour les ordinateurs de destination successifs et différents avec peu ou pas de retard (c.-à-d., de l'ordre de dizaines de millisecondes ou moins temps de commutation).

Dans ces hypothèses, nous pouvons facilement inclure des réseaux qui offrent des interfaces «datagrammes» aux ordinateurs hôtes abonnés. En d'autres, la commutation est effectuée par le réseau en fonction d'une adresse de destination contenue dans chaque datagramme passant par l'interface hôte à réseau.

Les hypothèses ne règlent pas nos réseaux d'interface de circuit virtuel, pas plus qu'elles n'excluent les réseaux de commutation de circuit numérique très rapides. Dans ces cas, la fonctionnalité importante est toujours qu'un datagramme peut être transporté sur un circuit réel ou virtuel de la source à l'ordinateur de destination, et que le délai de commutation est inférieur à quelques dizaines de millisecondes.

Une hypothèse administrative importante est que le format d'un datagramme Internet peut être communément accepté, ainsi qu'un plan d'adressage Internet commun. L'hypothèse de base concernant le transport de datagrammes dans réseau particulier est que le datagramme sera transporté, incorporé dans un ou plusieurs paquets, ou frames, à travers le réseau. Si la fragmentation et le remontage de datagrammes se produisent dans un réseau Il est invisible aux fins du modèle catenet. La disposition est également faite dans le format de datagramme pour la fragmentation des datagrammes en plus petits, mais des datagrammes de structure identique qui peuvent être transportés indépendamment à travers n'importe quel réseau particulier. Aucune position a priori n'est prise en ce qui concerne le choix entre la fragmentation interne (invisible) et le remontage ou la fragmentation externe (visible). Il est laissé à chaque réseau de décider. Nous reviendrons sur le sujet du format de datagramme et de l'adressage plus tard.

Il est très important de noter qu'il est explicitement supposé que les datagrammes ne sont pas nécessairement conservés dans la même séquence en quittant un réseau que lorsqu'ils sont entrés. En outre, il est supposé que les datagrammes peuvent être perdus ou même dupliqués dans le réseau. Il est laissé à des protocoles de niveau supérieur dans le modèle de catenet pour se remettre de tous les problèmes que ces hypothèses peuvent introduire. Ces hypothèses n'excluent pas les réseaux de données qui se produisent pour garder les datagrammes dans l'ordre.

Il est également supposé que les réseaux sont interconnectés les uns aux autres au moyen d'une «passerelle» logique. Au fur et à mesure que la définition du concept de passerelle se déploie, nous verrons que certains types d'interconnexions de réseau sont «invisibles» par rapport au modèle catenet. Toutes les passerelles qui sont visibles pour le modèle catenet ont la particularité de pouvoir interpréter l'adresse

champs de datagrammes Internet afin de Acheminez-les vers d'autres passerelles ou vers des destinations situées dans les réseaux directement rattachés à la passerelle (ou associées). Pour envoyer un datagramme à une destination, une passerelle peut avoir à mapper une adresse Internet dans une adresse réseau locale et à incorporer le datagramme dans un ou plusieurs paquets réseau local avant de l'injecter dans le réseau local pour le transport.

On suppose que l'ensemble des passerelles de catenet échangent entre eux au moins une certaine quantité minimale d'informations pour permettre la prise de décisions de routage, pour isoler les échecs et identifier les erreurs, et pour exercer le contrôle des flux et des embouteillages sur Internet. En outre, il est supposé que chaque passerelle catenet peut signaler un certain nombre minimum d'informations d'État à un contrôle d'interréseau Centre aux fins de identifier et isoler les échecs catenet, collecter des statistiques de performances minimales et ainsi de suite.

Un sous-ensemble de passerelles de catenet peut fournir des services d'application de contrôle d'accès. Il est supposé qu'un mécanisme commun d'application du contrôle d'accès est présent dans toute passerelle catenet qui fournit ce service. Cela n'exclut pas le contrôle d'accès local imposé par un réseau particulier. Mais pour assurer un contrôle d'accès cohérent à l'échelle mondiale, la convergence des mécanismes est essentielle.

Le contrôle d'accès est défini, à la passerelle catenet, pour signifier que le trafic permet d'entrer ou de laisser un réseau particulier. Les critères par lesquels l'autorisation d'entrée et de sortie sont décidées sont la responsabilité des «contrôleurs d'accès» du réseau qui établissent la politique de contrôle d'accès. Il est supposé que les passerelles de catenet appliquent simplement la stratégie des contrôleurs d'accès.

le modèle catenet

Il est maintenant possible d'offrir un modèle de base de fonctionnement de catenet. La figure 1 illustre les principaux composants du modèle. Les hôtes sont des ordinateurs connectés à des réseaux de données. Les interfaces hôte/réseau sont supposées être uniques à chaque réseau. Ainsi, aucune hypothèse sur les interfaces réseau communes n'est faite. Un hôte peut être connecté à plus d'un réseau et il peut avoir plus d'une connexion au même réseau, pour la fiabilité.

Les passerelles sont affichées comme si elles étaient composées de deux ou plusieurs moitiés. Chaque demi-passerelle possède deux interfaces:

1. une interface à un réseau local.

2. une interface à une autre passerelle-la moitié.

Un exemple est donné d'une passerelle avec trois «moitiés» reliant les réseaux a, B et C. À des fins de modélisation, il convient de traiter ce cas comme trois paires de moitiés de passerelle, chaque paire joignant bilatéralement une paire de réseaux.

Le modèle n'exclut pas la mise en place de passerelles monolithiques joignant deux réseaux ou plus, mais toutes les fonctions et interactions de passerelle sont définies comme si les passerelles étaient composées de moitiés, chacune étant associée à un réseau spécifique.

Un aspect très important de ce modèle est qu'aucune distinction a priori n'est faite entre une interface hôte/réseau et une interface passerelle/réseau. De telles distinctions ne sont pas exclues, mais elles ne sont pas pertinentes pour le modèle de base de catenet.

En conséquence, la différence entre un hôte qui est connecté à deux réseaux et une passerelle monolithique entre les réseaux est entièrement une question de savoir si les entrées de table dans d'autres passerelles identifier l'hôte comme une passerelle, et si la fonctionnalité de passerelle standard existe dans le hôte. Si aucune autre passerelle ou hôte ne reconnaît l'hôte Dual net en tant que passerelle ou si l'hôte ne peut pas passer des datagrammes de manière transparente d'un réseau à l'autre, il n'est pas considéré comme une passerelle catenet.

Le modèle n'exclut pas la possibilité de mettre en œuvre une passerelle-moitié entièrement dans le cadre d'un noeud de commutation réseau (par exemple, comme un logiciel dans un IMP ARPANET). L'aspect important de lala moitié est la procédure et le protocole par lesquels les demi-passerelles échangent des datagrammes et des informations de contrôle.

L'interface physique entre les deux moitiés de passerelles directement connectées n'a aucune importance particulière. Pour les passerelles monolithiques, il s'agit généralement d'une mémoire partagée ou d'un mécanisme de communication interprocessus quelconque; pour les moitiés distinctes de passerelle, il peut être HDLC, VDH, toute autre procédure de contrôle de ligne, ou mécanisme de bus inter-ordinateurs.

passerelles cachées

Aucune hiérarchie de réseau explicite n'est supposée dans ce modèle. Chaque réseau est connu de toutes les passerelles de catenet et chaque passerelle catenet sait comment acheminer Internet datagrammes ainsi, ils finiront par atteindre une passerelle connectée au réseau de destination.

L'absence d'une structure hiérarchique explicite signifie que certaines sous-structures réseau peuvent être masquées de la vue des passerelles de catenet. Si un réseau est composé d'une hiérarchie de réseaux internes connectés ensemble avec les passerelles, ces «passerelles cachées» ne seront pas visibles pour les passerelles de catenet, à moins que les réseaux internes ne soient affectés à des adresses réseau globales et que leurs passerelles d'interconnexion coopèrent dans les procédures de routage global et de contrôle de flux réseau.

La figure 2 illustre une hiérarchie de réseau simple. Aux fins de l'identification, les trois passerelles de catenet ont été étiquetées g (ax), g (BX) et g (CX) pour indiquer que ces passerelles rejoignent les réseaux A et x, B et x et C et x, respectivement. Seulement g (ax), g (BX) , et G (CX) sont considérés comme des passerelles de catenet. Ainsi ils sont tous conscients des réseaux A, B, C et X et ils chaque échange d'informations de routage et de contrôle de flux d'une manière uniforme entre les moitiés directement connectés.

Le réseau X est composé de trois réseaux internes marqués u, v et w. Pour les distinguer des passerelles de catenet, les passerelles cachées de net X sont étiquetées Hg (nm) où «nm» indiquent les filets que les passerelles cachées joignent. Par exemple, Hg (VW) rejoint les filets v et w. La notation pour le Hg est symétrique, c.-à-d. Hg (VW) = Hg (WV).

Passerelles g (ax), g (BX), g (CX) connectivité d'échange et d'autres informations de contrôle de flux entre eux, via le réseau X. Pour ce faire, chaque moitié de passerelle doit connaître une adresse, locale au réseau x, ce qui permettra au réseau x de router les datagrammes de g (ax) à g (BX), par exemple.

De la figure, il est clair que G (BX) est vraiment un hôte sur le réseau B et le réseau v. Mais Network v n'est pas l'un des réseaux globalement reconnus. En outre, le trafic de g (ax) à g (BX) peut voyager de net vous à net v ou via nets vous et w à net v. Pour maintenir la fiction d'un réseau uniforme x, les moitiés de passerelle de g (ax), g (BX) et g (CX) attachées à net x doivent être conscientes des chaînes d'adresses appropriées à utiliser pour faire acheminer le trafic vers chaque passerelle catenet sur net x. Dans la section suivante, nous décrivons une philosophie d'adressage Internet de base qui permet à ces configurations de fonctionner.

passerelles locales

Un autre élément du modèle catenet est une «passerelle locale» associée à chaque hôte. La passerelle locale est capable de remontage des datagrammes Internet fragmentés, si nécessaire, et est responsable pour l'encapsulation de datagrammes Internet dans les paquets réseau local. La passerelle locale sélectionne également des passerelles Internet pour acheminer le trafic Internet et répond aux

conseils de routage et de contrôle de flux à partir du réseau local et des passerelles attachées catenet.

Par exemple, une passerelle locale peut encapsuler et envoyer un datagramme Internet à une passerelle particulière sur son chemin vers un réseau distant. La passerelle catenet peut transférer le paquet vers une autre passerelle et envoyer un message consultatif à la passerelle locale en recommandant une modification dans sa table de routage de passerelle catenet. Les passerelles locales ne participent pas à l'algorithme de routage général exécuté parmi les passerelles de catenet.

adressage Internet

Le format de datagramme Internet de base est illustré à la figure 3. Par hypothèse, chaque réseau dans le catenet qui est reconnu par les passerelles de catenet a un numéro de réseau unique. Chaque hôte de chaque réseau est identifié par une adresse 24 bits qui est préfixée par le numéro de réseau. Le même hôte peut avoir plusieurs adresses en fonction du nombre de filets auxquels il est connecté ou du nombre de lignes d'accès réseau qui le connectent à un réseau particulier.

Pour le moment, il est supposé que les adresses Internet ont la forme: net. Host. "net" est un numéro de réseau de 8 bits. "Host" est une chaîne de 24 bits identifiant un hôte sur le "net", qui peut être compris par catenet et éventuellement des passerelles cachées.

Les passerelles de catenet gèrent des tables qui permettent de mapper des adresses Internet dans des adresses réseau locales. Les passerelles locales font de même, au moins dans la mesure de mappage d'une adresse hors réseau dans l'adresse réseau local d'une passerelle catenet.

En général, les passerelles de catenet maintiennent une entrée de table pour chaque net qui indique à quels datagrammes de passerelles destinés à ce réseau doivent être envoyés. Pour chaque «net» auquel la passerelle est attachée, la passerelle maintient les tables, si nécessaire, pour permettre le mappage des adresses d'hôte Internet aux adresses hôtes réseau local. Le cas typique est qu'une moitié de passerelle est connectée à un seul réseau et n'a donc besoin de maintenir les informations d'adresse locale pour un seul réseau.

Il est supposé que chaque réseau possède ses propres conventions d'adressage spécifiques localement. Pour simplifier la traduction de l'adresse Internet à l'adresse locale, il est avantageux, si possible, de simplement concaténer un identificateur de réseau avec les adresses «hôtes» locales pour créer une adresse Internet. Cette stratégie rend potentiellement trivial de traduire d'Internet à des adresses nettes locales.

Des traductions plus élaborées sont possibles. Par exemple, dans le cas d'un réseau avec une infrastructure «cachée», la partie «hôte» de l'adresse Internet pourrait inclure une structure supplémentaire qui n'est comprise que par des passerelles cachées ou masquées attachées à ce filet.

Afin de limiter la surcharge des champs d'adresse dans l'en-tête, il a été décidé de restreindre la longueur maximale de la partie hôte de l'adresse Internet à 24 bits. La possibilité d'un adressage vrai et variable a été sérieusement envisagée. À un moment donné, il est apparu que les adresses pourraient être Tant que 120 bits chacun pour la source et la destination. Les frais généraux de la niveau supérieur les protocoles d'entretien des tables capables de traiter les tailles d'adresse maximales possibles étaient considérés comme excessifs.

Pour tous les réseaux actuellement prévus pour être une partie de l'expérience, 24 bits les adresses hôtes sont suffisantes, même dans les cas où une transformation autre que la concaténation trivial de l'adresse hôte locale avec l'adresse réseau est nécessaire pour former l'adresse hôte Internet 32 bits.

L'un des principaux arguments en faveur de l'adressage de longueur variable est de prendre en charge ce qu'on appelle «routage source». La structure de l'information dans l'«adresse» identifie vraiment un itinéraire (par exemple, par un séquence particulière des réseaux et des passerelles). Une telle capacité pourrait appuyer des interconnexions de réseaux ad hoc dans lesquelles un hôte sur deux réseaux pourrait servir de passerelle privée. Bien qu'il ne participerait pas aux procédures de routage ou de contrôle de flux catenet, tout hôte qui connaît cette passerelle privée pourrait envoyer des datagrammes Internet «acheminés par source» à cet hôte.

Pour prendre en charge les expériences avec le routage source, le datagramme Internet inclut une option spéciale qui permet à une source de spécifier un itinéraire. Le format d'option est illustré à la figure 4. Le code d'option identifie l'option et la longueur détermine son étendue. Le champ pointeur indique quelle adresse de destination intermédiaire doit être atteinte en regard de l'itinéraire sélectionné par la source.

Le routage source peut être utilisé pour permettre aux interconnexions de réseau ad hoc de se produire avant qu'un nouveau net n'ait été assigné à un identificateur de réseau global.

En général, les passerelles catenet ne peuvent interpréter que les adresses Internet du formulaire net. Host. Les passerelles privées peuvent interpréter d'autres adresses locales pour les destinations souhaitées. Si une source connaissait les adresses locales de chaque passerelle privée intermédiaire, elle pourrait construire un itinéraire source qui est la concaténation des adresses locales de chaque hôte intermédiaire.

Les adresses locales et Internet peuvent être mélangées dans un seul itinéraire source Tant que les passerelles de catenet n'avaient qu'à interpréter les adresses Internet complètes lorsque le datagramme routé par source est apparu pour être réparé. Les passerelles privées peuvent interpréter les adresses locales et Internet, comme vous le souhaitez.

Étant donné que la source ou la destination d'un datagramme routé par source peut ne pas avoir d'adresse Internet, il peut être nécessaire de fournir un itinéraire de retour pour les réponses. Cela peut être fait en modifiant le contenu de l'itinéraire d'origine pour contenir «pointeur arrière» vers des destinations intermédiaires. Notez que l'adresse locale d'une passerelle privée dans un réseau est généralement différente de son adresse locale dans le réseau adjacent.

En général, une source crée un itinéraire qui contient d'abord l'adresse Internet de l'hôte ou de la passerelle la plus proche de la destination souhaitée. L'adresse suivante de l'itinéraire serait l'adresse locale de la destination. La figure 5 illustre cette notion. Hôte A.a veut pour communiquer avec l'hôte Z. Mais Z n'est pas attaché à un réseau officiellement reconnu.

Pour atteindre son objectif, l'hôte a. a peut émettre des paquets routés par source avec l'itinéraire: "B. y, Z. " B. y identifie l'hôte (passerelle privée) entre net B et le nouveau réseau comme premier arrêt intermédiaire. La passerelle privée utilise les informations «Z» pour remettre le datagramme à la destination. Lorsque le datagramme arrive, son itinéraire doit contenir "y, un. a "si la passerelle privée sait interpréter a. a ou" y, W, a. a "si la passerelle privée ne connaît que les adresses locales au réseau B.

autres questions

Le modèle catenet doit prévoir que les messages d'erreur provenant d'un réseau doivent être reportés utilement à la source. Un encodage global des messages d'erreur ou des messages d'État est nécessaire.

On suppose que les demi-passerelles d'un réseau donné ont un mécanisme commun de Reporting, d'écoulement et de contrôle de la congestion. Cependant, les moitiés sur différents filets peuvent fonctionner différemment. Il devrait y avoir une interface définie entre les moitiés de passerelle qui permet d'exercer le flux Internet, la congestion et le contrôle des erreurs.

Un centre de surveillance de passerelle [3] est postulé qui peut collecter, corréler et afficher l'état actuel de la passerelle. Un tel centre ne devrait pas être nécessaire pour les protocoles Internet pour fonction, mais pourrait être utilisé pour gérer un environnement Internet.

La comptabilité, la reddition de comptes et les procédures de contrôle d'accès doivent être définies pour le référentiel global.

References

1. Pouzin, L., "une proposition pour l'interconnexion des réseaux de commutation de paquets," Proceedings of EUROCOMP, Massimo cosse University, 1974 mai, pp. 1023-36.

2. Postel, J. «InterNetwork Datagram Protocol Specification», version 4, expérience interréseau note no 41, section 2.3.2.1, Internet Experience Notebook, juin 1978.

3. Davidson, John, «catenet Monitoring and Control: un modèle pour le composant Gateway», ien #32, section 2.3.3.12, Internet Notebook, avril 1978. \ r \ n

Affirmation du paradigme moderne pour les normes

Abstrait

Le 29 août 2012, les dirigeants de l'IEEE Standards Association, le L'IAB, l'IETF, l'Internet Society et le W3C ont signé une déclaration affirmant l'importance d'un ensemble de principes développés en commun établir un paradigme moderne pour des normes ouvertes et globales. Celles-ci principes sont devenus connus comme les principes "OpenStand". Ce Le document contient le texte de l'affirmation qui a été signée.

Statut de ce mémo

Ce document n'est pas une spécification Internet Standards Track; c'est publié à titre informatif.

Ce document est un produit de l'Internet Architecture Board (IAB) et représente les informations que l'IAB a jugées utiles prévoir un enregistrement permanent. Il représente le consensus du Internet Architecture Board (IAB). Documents approuvés pour publication par l'IAB ne sont pas un candidat pour n'importe quel niveau d'Internet La norme; voir la section 2 de la RFC 5741.

Informations sur l'état actuel de ce document, toute errata, et comment fournir des commentaires sur celui-ci peut être obtenu à http://www.rfc-editor.org/info/rfc6852.

Copyright

Copyright (c) 2013 IETF Trust et les personnes identifiées comme auteurs de documents. Tous les droits sont réservés.

Ce document est soumis à BCP 78 et à l'IETF Trust's Legal Dispositions relatives aux documents de l'IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez consulter ces documents attentivement, car ils décrivent vos droits et vos restrictions à ce document.

1. Introduction

Le 29 août 2012, les dirigeants de l'IEEE Standards Association, le L'IAB, l'IETF, l'Internet Society et le W3C ont signé une déclaration affirmant l'importance d'un ensemble de principes développés en commun établir un paradigme moderne pour des normes ouvertes et globales. Celles-ci principes sont devenus connus comme les principes "OpenStand".

La section 2 de ce document décrit les cinq principes OpenStand. La section 3 de ce document contient le texte de la affirmation des cinq principes OpenStand. La section 4 contient un appelez les autres à soutenir les cinq principes OpenStand.

2. Paradigme moderne pour les normes

Au cours des dernières décennies, l'économie mondiale a réalisé un énorme générosité due à Internet et au World Wide Web. Ceux-ci ne pourraient pas ont été possibles sans les innovations et la normalisation de de nombreuses technologies sous-jacentes. Cette normalisation s'est produite avec grande vitesse et efficacité seulement en raison des principales caractéristiques de un paradigme de normes mondiales modernes. L'affirmation ci-dessous caractérise les principes qui ont conduit à ce succès comme moyen assurer l'acceptation des activités de normalisation qui adhèrent à la des principes.

Nous embrassons un paradigme moderne pour les normes où l'économie de les agoras mondiaux, alimentés par les progrès technologiques, conduisent mondiale déploiement de normes, quel que soit leur statut officiel.

Dans ce paradigme, les normes soutiennent l'interopérabilité, la concurrence, sont développés à travers un processus participatif ouvert, et sont volontairement adoptés globalement. Ces normes volontaires servent blocs de construction pour les produits et services destinés à besoins du agora et du consommateur, favorisant ainsi l'innovation. L'innovation contribue à son tour à la création de nouveaux agoras et à la croissance et l'expansion des agoras existants.

La participation au paradigme moderne exige:

1. Coopération

1. Coopération respectueuse entre les normes organisations, chacune respectant l'autonomie, l'intégrité, processus, et les règles de propriété intellectuelle des autres.

2. L'adhésion aux principes. L'adhésion aux cinq fondamentaux principes d'élaboration de normes:

• Due processus. Les décisions sont prises avec équité et équité entre participants Aucune partie ne domine ou guide les normes développement. Les processus de normalisation sont transparents et il existe des possibilités de faire appel des décisions. Processus pour périodiques l'examen et la mise à jour des normes sont bien définis.

• Large consensus. Les processus permettent de considérer toutes les vues et traitées, de sorte qu'un accord puisse être trouvé sur une gamme d'intérêts.

• Transparence. Les organismes de normalisation fournissent des avis publics avis d'activités d'élaboration de normes proposées, la portée du travail à entreprendre et des conditions de participation. Des registres facilement accessibles des décisions et des matériaux utilisés atteindre ces décisions sont fournies. Périodes de commentaires publics sont fournis avant l'approbation et l'adoption des normes définitives.

• Équilibre. Les activités de normalisation ne sont pas exclusivement dominées par toute personne, société ou groupe d'intérêt particulier.

• Ouverture Les processus de normalisation sont ouverts à tous parties informées.

3. Autonomisation collective. Engagement en affirmant des normes organisations et leurs participants à l'autonomisation collective par s'efforcer de normes qui:

• sont choisis et définis en fonction du mérite technique, tel que jugé par l'expertise apportée par chaque participant;

• fournir l'interopérabilité globale, l'évolutivité, la stabilité et élasticité;

• permettre la concurrence mondiale;

• servir de base pour d'autres innovations; et

• contribuer à la création de communautés mondiales, en bénéficiant humanité.

4. Disponibilité. Les spécifications des normes sont rendues accessibles à tous pour la mise en œuvre et le déploiement. Affirmer des normes organisations ont défini des procédures pour développer des spécifications qui peut être mis en œuvre dans des conditions équitables. Étant donné la diversité du agora, Des conditions équitables peuvent varier de redevance à juste, raisonnable, et termes non discriminatoires (FRAND).

5. Adoption volontaire. Les normes sont volontairement adoptées et le succès est déterminé par le agora.

3. Affirmation

Nous embrassons un paradigme moderne pour les normes où l'économie de les agoras mondiaux, alimentés par les progrès technologiques, conduisent mondiale déploiement de normes, quel que soit leur statut officiel.

Dans ce paradigme, les normes soutiennent l'interopérabilité, la concurrence, sont développés à travers un processus participatif ouvert, et sont volontairement adoptés globalement. Ces normes volontaires servent blocs de construction pour les produits et services destinés à besoins du agora et du consommateur, favorisant ainsi l'innovation. L'innovation contribue à son tour à la création de nouveaux agoras et à la croissance et l'expansion des agoras existants.

En signant cette déclaration, nous affirmons notre soutien et notre adhésion à ces principes.

4. Appel d'endossement

Nous invitons d'autres organismes de normalisation, gouvernements, sociétés et les innovateurs technologiques à l'échelle mondiale pour soutenir ces principes. Toi peut montrer publiquement votre soutien à <http://www.open-stand.org>.

5. Considérations de sécurité

Rien dans ce document n'a d'incidence directe sur la sécurité de L'Internet.

6. Membres du CCI au moment de l'approbation

Membres du Conseil d'architecture Internet au moment où ce document a été approuvé étaient:

ICP 3

Abstrait

Ce document réaffirme l'engagement de l'ICANN à une racine publique unique et faisant autorité pour le système de noms de domaine Internet (DNS) et à la gestion de cette racine unique dans l'intérêt public conformément aux politiques développées à travers les processus communautaires. Cet engagement est fondé sur les conseils techniques et autres de la communauté et est incorporé dans la politique existante de l'ICANN.

Le DNS est destiné à fournir un moyen pratique de se référer aux sites disponibles sur Internet. En offrant aux utilisateurs un moyen simple et fiable de se référer sans ambiguïté aux sites Web, aux serveurs de courrier électronique et aux nombreux autres services Internet, le DNS a aidé Internet à tenir sa promesse de moyen de communication mondial pour le commerce, la recherche, l'éducation et les activités culturelles et autres activités expressives.

Le DNS est une base de données distribuée globalement d'informations de nom de domaine (et autres). L'un de ses principaux objectifs de conception est de fournir de manière fiable les mêmes réponses aux mêmes requêtes provenant de n'importe quelle source sur l'Internet public, permettant ainsi un routage prévisible des communications Internet. La réalisation de cet objectif de conception nécessite un espace de nom public globalement unique dérivé d'une seule racine DNS unique au monde.

Bien qu'Internet permette un niveau élevé d'activités décentralisées, la coordination de la fonction d'assignation par une autorité unique est nécessaire lorsque des valeurs de paramètres uniques sont techniquement requises. En raison de l'exigence d'unicité, le contenu et le fonctionnement de la racine DNS doivent être coordonnés par une entité centrale.

Lorsqu'une coordination centrale est nécessaire, elle doit être effectuée par une organisation dédiée à servir l'intérêt public et agissant selon des politiques élaborées à travers des processus élaborés grâce à la participation des parties prenantes concernées. Traditionnellement, la responsabilité de l'exécution des fonctions centrales de coordination de l'Internet mondial pour le bien public, y compris la gestion de la racine DNS publique unique, a été assurée par l'Internet Assigned Numbers Authority (l'IANA). La principale mission de l'ICANN est de poursuivre le travail de l'IANA dans un cadre plus formalisé et globalement représentatif, afin de garantir que les opinions de toutes les parties prenantes d'Internet soient prises en compte dans la réalisation de cette confiance publique.

Au cours des dernières années, certaines organisations privées ont établi des racines DNS comme alternatives à la racine faisant autorité. Certaines utilisations de ces racines alternatives ne compromettent pas la stabilité du DNS. Par exemple, certains sont des racines purement privées opérant à l'intérieur des institutions et sont soigneusement isolés du DNS. D'autres sont purement expérimentales dans les meilleures traditions d'Internet et sont soigneusement gérés pour ne pas interférer avec le fonctionnement du DNS. Ces deux fonctionnent dans les normes établies par la communauté.

Fréquemment, cependant, ces racines alternatives ont été établies pour soutenir les registres de noms de domaine de premier niveau ou de pseudo-niveau supérieur qui sont exploités à des fins lucratives. Pourtant, d'autres racines alternatives ont été établies par certains individus pour protester contre les politiques développées par les processus communautaires plus larges pour la gestion de la racine autoritaire, ou pour exprimer leur désintérêt à participer à ces processus. Ces racines alternatives n'ont pas été lancées à travers les processus de consensus de l'ICANN, elles n'ont donc pas été entrées dans la racine officielle gérée par l'IANA ou l'ICANN.

Ces racines alternatives remplacent généralement les préoccupations insulaires à la place des processus communautaires qui régissent la gestion de la racine faisant autorité. Leurs opérateurs décident d'inclure des domaines de premier niveau dans ces racines alternatives qui n'ont pas été soumises aux tests de support communautaire et de conformité avec les processus de consensus - coordonnés par l'ICANN - qui permettraient leur inclusion dans la racine faisant autorité. Ces décisions des opérateurs alternatifs ont été prises sans égard apparent pour le souci fondamental d'intérêt public de la stabilité d'Internet. L'utilisation répandue des noms de domaine actifs dans ces racines alternatives pourrait en effet nuire à l'unicité du mécanisme de résolution de noms faisant autorité et, partant, à la stabilité du DNS.

Le mandat de l'ICANN de préserver la stabilité du DNS exige qu'il évite d'encourager la prolifération de ces racines alternatives qui pourraient causer des conflits et de l'instabilité. Cela signifie que l'ICANN continue d'adhérer aux processus communautaires dans ses décisions concernant le contenu de la racine faisant autorité. Dans le cadre de sa politique actuelle, l'ICANN ne peut donner aucune préférence à ceux qui choisissent de travailler en dehors de ces processus et en dehors des politiques engendrées par cette confiance publique.

Rien de tout cela n'empêche l'expérimentation faite d'une manière qui ne menace pas la stabilité de la résolution de noms dans le DNS faisant autorité. L'expérimentation responsable est essentielle à la vitalité d'Internet. Il n'empêche pas non plus l'introduction finale de nouvelles architectures qui pourraient finalement éviter le besoin d'une racine unique et autoritaire. Mais la traduction des expériences en production et l'introduction de nouvelles architectures nécessitent des approches communautaires et ne sont pas compatibles avec les efforts individuels pour obtenir un avantage exclusif.

Une racine unique et faisant autorité pour le DNS

(9 juillet 2001)

1. Le besoin technique d'une racine unique faisant autorité

Le DNS a été initialement déployé au milieu des années 1980 comme un moyen amélioré de mapper des noms faciles à mémoriser (par exemple, "example.com") aux adresses IP (par exemple "128.9.176.32") par lequel les paquets sont acheminés. l'Internet. Il s'agit d'une base de données distribuée qui contient ces informations de mappage (ainsi que divers autres types d'informations techniques concernant les ordinateurs sur Internet) dans les "enregistrements de ressources". Le DNS fournit ces enregistrements de ressources en réponse aux requêtes qu'il reçoit de programmes appelés "résolveurs" sur des ordinateurs individuels sur Internet. Les résolveurs traduisent les noms de domaine en adresses IP correspondantes.

Depuis le début du DNS, son objectif de conception le plus fondamental a été de fournir les mêmes réponses aux mêmes requêtes émises depuis n'importe quel endroit sur Internet. Comme indiqué dans RFC 1034, la spécification de base des "Concepts and Facilities" du DNS (P. Mockapetris nov. 1987), "L'objectif principal [design] est un espace de nom cohérent qui sera utilisé pour faire référence aux ressources." Et comme répété dans la RFC 2535, «Extensions de sécurité du système de noms de domaine» (D. Eastlake mars 1999), «La philosophie de conception du DNS implique que les données qu'il contient sont publiques et que le DNS donne les mêmes réponses. tous les demandeurs. "

Le DNS est hiérarchique. Par conception, la hiérarchie commence par un groupe de serveurs de noms racine (souvent appelés simplement «serveurs racine»), qui sont des ordinateurs spécialement désignés sous une coordination commune fournissant des informations sur les autres ordinateurs faisant autorité sur les domaines de premier niveau du DNS. structure de nommage. Cet ensemble de serveurs racine héberge la "racine faisant autorité". Ainsi, un résolveur recherchant des informations concernant un nom de domaine tel que "www.example.com" obtient l'un des enregistrements de ressources des serveurs racine sur .com, qui indique au résolveur quels ordinateurs ont des informations faisant autorité sur les noms au-dessus du .com. domaine. Le résolveur interroge ensuite un de ces serveurs de noms .com faisant autorité sur example.com, pour localiser les serveurs de noms pour "example.com". Une requête est alors faite à l'un de ces serveurs de noms pour obtenir l'adresse IP de l'ordinateur désigné par le nom "www.example.com".

Le principal avantage de cette structure hiérarchique est qu'elle permet à différentes parties de la base de données de dénomination d'être gérées par différentes entités. Selon la conception du DNS, chaque domaine devait être administré par une seule entité. Voir la RFC 920, "Domain Requirements" (J. Postel et J. Reynolds oct. 1984).

Lorsque le DNS a été déployé au milieu des années 1980, un ensemble de serveurs de noms racine a été désigné et plusieurs domaines de premier niveau ont été créés. Ces serveurs de noms racine (il y en a maintenant 13 répartis dans le monde entier) sont destinés à fournir des informations faisant autorité sur les serveurs de noms qui contiennent les informations de dénomination pour chacun des domaines de premier niveau. Puisque les serveurs de noms racine faisant autorité fonctionnent en haut de la hiérarchie, les résolveurs les trouvent en se référant aux adresses IP pré-stockées sur des ordinateurs locaux sur Internet.

Au cours des dernières années, certains groupes ont établi des serveurs de noms racine alternatifs sur l'Internet public qui distribuent des informations différentes des informations distribuées par les serveurs de noms racine faisant autorité. Ces groupes cherchent ensuite à persuader les FAI et les utilisateurs d'Internet de remplacer les adresses IP pré-stockées des serveurs de noms racine faisant autorité par celles de leurs serveurs secondaires. Pour diverses raisons, ces racines alternatives n'ont pas encore atteint un niveau d'utilisation significatif sur Internet.

Heureusement, l'utilisation rare de racines alternatives a jusqu'à présent limité leur effet pratique sur Internet. Si ces racines alternatives devenaient prédominantes, elles pourraient sérieusement perturber le fonctionnement fiable du DNS. Certaines des conséquences comprennent:

1. Fournir le mauvais emplacement: La présence de racines DNS publiques alternatives peut entraîner des réponses différentes à la même requête DNS émise par différents ordinateurs sur Internet, selon que l'ordinateur interrogateur est programmé pour accéder à la racine faisant autorité ou à un l'une des racines alternatives (ou plus précisément un résolveur de nom de domaine associé à l'un ou l'autre d'entre eux). L'objectif de conception DNS fondamental de fournir des réponses cohérentes aux requêtes DNS est donc frustré.1

2. Atteindre le mauvais ordinateur: La conséquence principale de ces données incohérentes est que le même nom de domaine peut identifier différents ordinateurs en fonction de l'endroit où le nom est utilisé. Autrement dit, les localisateurs de ressources uniformes (URL) ne sont plus uniformes. Ainsi, saisir une adresse de site Web sur deux ordinateurs différents configurés pour référencer des racines différentes peut aboutir à des sites Web différents - une possibilité particulièrement troublante si, par exemple, l'argent change de mains ou si la confidentialité est violée . De même, le même courrier électronique envoyé à la même adresse à partir des deux ordinateurs peut être dirigé vers des destinataires différents. Le retour de données DNS incohérentes va à l'encontre de la résolution globalement cohérente des noms de domaine vitaux pour Internet, réalisant ainsi sa promesse de support universel de communications et d'applications pour le commerce, la recherche, l'éducation, les échanges culturels, les activités expressives et autres usages.

3. Conséquences imprévisibles pour la plupart des utilisateurs: L'ensemble des réponses DNS qui seront reçues (de la racine faisant autorité ou de l'une des racines secondaires) n'est pas prévisible par la plupart des utilisateurs finaux. La plupart des utilisateurs sur Internet utilisent un résolveur DNS local configuré par une autre personne. Peu d'utilisateurs sont susceptibles d'apprécier l'importance de la configuration DNS du résolveur; encore moins sont susceptibles d'avoir une connaissance détaillée de cette configuration. À mesure que le nombre d'utilisateurs sur Internet a augmenté, la proportion d'utilisateurs connaissant bien les concepts techniques tels que les résolveurs DNS et les serveurs racine a diminué. Pourtant, ces utilisateurs non techniques sont précisément ceux pour qui l'Internet en général - et le DNS en particulier - offre les plus grands avantages potentiels.

4. Hôtes intermédiaires Ajouter à la confusion: De plus, certains services Internet dépendent des actions des résolveurs DNS employés par les hôtes intermédiaires. Des racines alternatives introduisent la possibilité que la réponse DNS obtenue par l'hôte intermédiaire modifie le caractère du service d'une manière inattendue. Un phénomène similaire peut se produire lorsqu'un utilisateur envoie à une autre une référence à une URL, telle qu'une adresse de réponse par courrier électronique ou un lien sur un site Web. Si le destinataire d'un e-mail ou le visiteur du site Web utilise un ordinateur qui utilise une racine DNS différente de celle prévue par l'expéditeur de l'e-mail ou le concepteur du site Web, des résultats inattendus sont susceptibles de se produire. Par exemple, l'e-mail pourrait se retrouver avec la mauvaise personne.

5. Empoisonnement du cache: d'autres racines introduisent également la possibilité d'activités Internet mal orientées en raison du phénomène connu sous le nom d'empoisonnement du cache. Pour des raisons de performances, la conception DNS demande que les enregistrements de ressources soient transmis entre les serveurs de noms sur Internet, de sorte qu'un résolveur puisse obtenir un accès plus rapide à une copie locale de l'enregistrement de ressource. Parce que le DNS suppose un système à racine unique, les enregistrements de ressources ne sont pas marqués pour les distinguer en fonction de la racine à partir de laquelle ils émanent. Ainsi, la présence de racines alternatives introduit la possibilité que les activités Internet de ceux qui ont l'intention d'utiliser la racine faisant autorité puissent être mal dirigées par un enregistrement de ressource parasite émanant d'une racine alternative. En effet, certaines attaques de piratage malveillantes ont été basées sur ce principe, ce qui a amené l'Internet Engineering Task Force à proposer une série d'améliorations non encore implémentées, appelées "DNS-Security".

(Il convient de noter que la conception originale du DNS offrait un moyen d'utiliser des racines alternatives d'une manière qui ne compromet pas la stabilité (voir la section 5 ci-dessous pour plus de détails).

Ces effets potentiellement destructeurs des racines alternatives ont longtemps été acceptés par la grande majorité des ingénieurs Internet. Malgré cette large reconnaissance, certains ont cherché à justifier les racines alternatives en minimisant ces effets. En réponse, et pour documenter ce qu'il appelle «certains des problèmes inhérents à une famille de propositions techniquement naïves récurrentes», l'IAB (Internet Architecture Board) a publié en mai 2000 la RFC 2826 intitulée «Commentaire technique de l'IAB sur le DNS unique». Racine." Le CCI a résumé ses commentaires (dans la partie pertinente) comme suit:

"Résumé

"Pour rester un réseau global, Internet nécessite l'existence d'un espace de nom public globalement unique.L'espace de noms DNS est un espace de nom hiérarchique dérivé d'une seule racine globalement unique.Cette contrainte technique est inhérente à la conception du DNS Par conséquent, il n'est techniquement pas possible d'avoir plus d'une racine dans le DNS public, cette racine devant être prise en charge par un ensemble de serveurs racine coordonnés administrés par une autorité de dénomination unique.

"En d'autres termes, le déploiement de plusieurs racines DNS publiques soulèverait une très forte probabilité que les utilisateurs de différents FAI qui cliquent sur le même lien sur une page Web puissent se retrouver dans des destinations différentes, contre la volonté des concepteurs de pages Web."

(Pour quelques exemples concrets de défaillances et d'instabilités potentielles qui résulteraient vraisemblablement de racines alternées fréquemment utilisées sur l'Internet public, voir le projet Internet «Alt-Roots, Alt-TLD» (K. Crispin, mai 2001).

Face aux conséquences déstabilisatrices des racines alternatives, telles qu'énoncées par l'IAB et d'autres, la principale directive de l'ICANN de préserver la stabilité d'Internet et du DNS exige un engagement indéfectible pour promouvoir la prévalence continue d'une seule racine faisant autorité pour le DNS public. Toute autre action de l'ICANN serait irresponsable.

2. La confiance du public dans les fonctions d'affectation coordonnées

Le bon fonctionnement d'Internet nécessite l'attribution de valeurs uniques à divers identifiants pour différents ordinateurs ou services sur Internet. Pour être efficaces, ces valeurs assignées doivent être largement diffusées et leur signification doit être respectée par les nombreuses personnes responsables du fonctionnement d'Internet. Par exemple, chaque ordinateur sur l'Internet public est assigné une adresse IP unique; cette adresse est connue des routeurs sur Internet pour que les paquets TCP / IP ayant cette adresse de destination soient acheminés vers l'ordinateur prévu. Sans un commun accord pour respecter la mission, Internet ne transmettrait pas de manière fiable les communications à leurs destinations prévues.

Début jusqu'en 1998: la coordination centrale en tant que confiance publique

Dès les débuts de l'Internet, la communauté technique a reconnu la nécessité d'une coordination centrale de l'attribution unique des valeurs d'identifiants. L'Internet Assigned Numbers Authority (l'IANA, désormais gérée par l'ICANN) a été créée pour répondre à ce besoin; il effectue maintenant des affectations de valeurs uniques pour environ 120 types d'identifiants différents. Cette responsabilité a toujours été comprise comme une confiance publique, et l'IANA a depuis longtemps adopté la devise: "Consacrée à la préservation des fonctions centrales de coordination de l'Internet mondial pour le bien public".

Le plus connu des identifiants uniques attribués à Internet, bien sûr, sont les noms de domaine. Depuis le déploiement du DNS, la communauté Internet a confié à l'IANA la responsabilité de la coordination et de la gestion globales du système de noms de domaine (DNS), et en particulier de la délégation de parties de l'espace nommée domaines de premier niveau. RFC 1591, "Structure et délégation du système de noms de domaine" (J. Postel mars 1994). Comme dans le cas de ses autres responsabilités, le rôle de l'IANA est d'agir dans l'intérêt du public, de manière neutre et sans motifs exclusifs.

La concurrence comme valeur guidant la gestion technique d'Internet

Dans les premières années d'Internet, à quelques exceptions près, les activités quotidiennes d'enregistrement des noms de domaine ont été réalisées par une seule société (première SRI et plus tard Network Solutions) sous la direction de l'IANA.

Vers le milieu des années 1990, cependant, la croissance et la commercialisation croissante d'Internet ont conduit les publications américaines Green2 et White3 du gouvernement américain à noter l'émergence d'une «insatisfaction généralisée quant à l'absence de concurrence dans l'enregistrement des noms de domaine». Cette insatisfaction a incité les Livres verts et blancs à inclure la promotion de la concurrence dans les services d'enregistrement comme l'une des quatre valeurs (stabilité, concurrence, coordination ascendante privée et représentation) qui devraient guider la gestion technique d'Internet. Les deux documents précisaient que, parmi ces quatre valeurs, la préservation de la stabilité devait être primordiale.

S'appuyant sur le modèle IANA d'une entité à but non lucratif qui assure la confiance du public pour remplir les fonctions essentielles de coordination centrale, le gouvernement américain a concilié la nécessité d'assurer la stabilité d'Internet avec le désir d'introduire des services d'enregistrement de noms de domaine compétitifs.

«Conformément à ces principes, nous divisons les fonctions de nom et de numéro en deux groupes, ceux qui peuvent être transférés à un système concurrentiel et ceux qui devraient être coordonnés. Gérer les fonctions coordonnées selon des critères objectifs largement acceptés Nous suggérons ensuite les étapes nécessaires pour passer à des agoras compétitifs dans les domaines qui peuvent être axés sur le agora. »4

Cette dichotomie reconnaît qu'Internet est, après tout, un réseau (même s'il s'agit d'un réseau de réseaux) et que les réseaux requièrent une coordination entre leurs participants pour fonctionner de manière stable et efficace. Cela reflète également le succès phénoménal de la tradition Internet de normes ouvertes et non exclusives développées en coopération. Ces normes ont créé un environnement de systèmes hautement interopérables qui ont permis à la concurrence et à l'innovation de s'épanouir.

L'ICANN assume la confiance du public

Après des commentaires publics sur le livre vert, le gouvernement des États-Unis a publié le livre blanc, qui énonçait la charte de base sur laquelle l'ICANN a été fondée et continue de fonctionner. Le Livre blanc a mis l'accent sur la première directive de stabilité et, à cette fin, sur la nécessité d'éviter la création de racines alternatives:

«L'introduction d'un nouveau système de gestion ne devrait pas perturber les opérations actuelles ou créer des systèmes racinaires concurrents: pendant la transition et par la suite, la stabilité d'Internet devrait être la première priorité de tout système de gestion DNS.

Le gouvernement des États-Unis a ensuite invité la communauté Internet à constituer une société sans but lucratif pour exercer les «fonctions coordonnées» qui devraient être traitées comme une question de confiance du public, plutôt que selon un régime concurrentiel qui ne favoriserait pas la stabilité. . Parmi les «fonctions coordonnées» figuraient la gestion du système de serveur racine et les décisions d'introduire de nouveaux TLD:

"De même, la coordination du réseau du serveur racine est nécessaire pour que tout le système fonctionne correctement et que les tâches opérationnelles quotidiennes, telles que le fonctionnement et la maintenance des serveurs racine Internet, puissent être dispersées, Le contrôle des TLD et du système de serveur racine Internet devrait être confié à une seule organisation représentative des utilisateurs d'Internet dans le monde entier.

"En outre, les changements apportés à l'administration ou au nombre de gTLD contenus dans le système racine autoritaire auront un impact considérable sur les utilisateurs d'Internet à travers le monde.Pour promouvoir la continuité et la prévisibilité raisonnable des fonctions liées à la zone racine, le développement des politiques pour l'ajout, l'attribution et la gestion de gTLD et l'établissement de registres de noms de domaine et de noms de domaine pour héberger des gTLD, il conviendrait de les coordonner. "6

En réponse à cette invitation à la création d'une organisation à but non lucratif basée sur la communauté Internet, l'ICANN a été créée en 1998. L'ICANN a ensuite été sélectionnée par le gouvernement des États-Unis parmi plusieurs propositions soumises précisément parce qu'elle était ouverte, consensuelle et ancré dans la communauté Internet. La création de l'ICANN a fait l'objet de dialogues approfondis entre différents groupes de la communauté Internet pour s'assurer que l'ICANN puisse répondre aux besoins de ces différents groupes.

L'ICANN, parmi ses autres responsabilités, agit maintenant en tant que coordinateur pour le fonctionnement du système racine-serveur faisant autorité et le forum politique pour les décisions concernant les politiques régissant les TLD qui doivent être inclus dans la racine DNS faisant autorité.7

En liant la formation de l'ICANN à la communauté Internet mondiale, le Livre blanc a établi une confiance publique qui exigeait que le DNS soit administré dans l'intérêt public en tant que base de données unique pour les noms de domaine qui fournit un système d'adressage stable. par la communauté Internet mondiale. Cet engagement à une racine unique et faisant autorité est un élément clé de la confiance du public en général - pour réaliser les fonctions centrales de coordination d'Internet pour le bien public - c'est la raison d'être de l'ICANN.

3. La confiance du public et l'introduction de nouveaux TLD

Il est essentiel que les fonctions coordonnées au niveau central soient exécutées dans l'intérêt du public, et non en raison de motivations exclusives ou d'intérêts personnels. Pour cette raison, l'ICANN a été fondée en tant qu'organisation à but non lucratif à but non lucratif, responsable devant la communauté Internet. Les principes Internet de longue date exigent également que les politiques guidant les fonctions coordonnées soient établies ouvertement sur la base des délibérations et des contributions de la communauté. Pour ces raisons, la structure de l'ICANN est représentative de la diversité géographique et fonctionnelle d'Internet et repose, dans la mesure du possible, sur des méthodes ascendantes du secteur privé.

Comme le souligne le Livre blanc, les décisions concernant l'introduction de nouveaux TLD sont prises dans ce cadre ouvert, non exclusif et largement représentatif, plutôt que par des individus ou des entités qui ne rendent pas compte à la communauté et agissent habituellement pour leurs propres intérêts. :

«Comme les noms Internet ont de plus en plus une valeur commerciale, la décision d'ajouter de nouveaux domaines de premier niveau ne peut pas être prise de manière ponctuelle par des entités ou des individus qui ne sont pas formellement responsables devant la communauté Internet.

Dans le cadre de son engagement envers un système racinaire unique et la stabilité d'Internet, l'ICANN a lancé l'année dernière un processus visant à introduire avec soin plusieurs nouveaux TLD génériques dans le DNS. Cette introduction a été conçue comme une preuve de concept de la faisabilité technique et commerciale d'introduire plus de TLD dans le DNS. Procéder à une première validation de principe répondait à l'avis de l'Organisation de soutien au Protocole (OSP) de l'ICANN et de son Organisation de soutien aux noms de domaine (DNSO) de procéder prudemment et de manière ordonnée. Le PSO et le DNSO représentent les opinions consensuelles des communautés techniques et des utilisateurs / entreprises / autres institutions, respectivement. Les TLD génériques n'avaient pas été introduits depuis de nombreuses années, et il y avait et il y a encore de sérieuses questions quant à l'effet de l'introduction de nouveaux TLD sur la stabilité et la fiabilité du DNS; et de nombreuses questions sur ce que devrait être le contexte contractuel et commercial approprié.

En réponse à une demande de propositions, quarante-sept institutions et groupes ont soumis des propositions pour l'établissement de nouveaux TLD. Ils ont choisi de travailler dans le cadre du processus communautaire de l'ICANN, même s'ils savaient que seul un «nombre limité» de TLD serait sélectionné - au moins au premier tour. En fait, sept ont été sélectionnés et, conformément à une méthodologie qui a permis une contribution considérable de la communauté, des contrats ont été ou seront signés sous peu avec ces sept premiers. L'ICANN attend avec impatience l'introduction réussie de ces nouveaux TLD et travaillera avec la communauté pour surveiller leur performance afin qu'une décision communautaire puisse être prise sur l'introduction de plus de TLD, si cela devait être la conclusion de la preuve de concept.

4. En dehors du processus

Certaines organisations privées ont établi des racines DNS comme alternatives à la racine faisant autorité. Certaines utilisations de ces racines alternatives ne compromettent pas la stabilité du DNS. Par exemple, beaucoup sont des racines purement privées opérant dans des institutions et sont soigneusement isolées du DNS. D'autres sont purement expérimentales dans les meilleures traditions d'Internet et sont soigneusement gérés pour ne pas interférer avec le fonctionnement du DNS. Ces deux fonctionnent dans les normes établies par la communauté.

Fréquemment, cependant, ces racines alternatives ont été établies pour soutenir les registres de noms de domaine de premier niveau ou de pseudo-niveau supérieur qui sont exploités à des fins lucratives. Pourtant, d'autres racines alternatives ont été établies par certains individus pour protester contre les politiques développées par les processus communautaires plus larges pour la gestion de la racine autoritaire, ou pour exprimer leur désintérêt à participer à ces processus. Ces racines alternatives n'ont pas été lancées à travers les processus de consensus de l'ICANN, elles n'ont donc pas été entrées dans la racine officielle gérée par l'IANA ou l'ICANN.

Ces racines alternatives remplacent généralement les préoccupations insulaires à la place des processus communautaires qui régissent la gestion de la racine faisant autorité. Leurs opérateurs décident d'inclure des domaines de premier niveau dans ces racines alternatives qui n'ont pas été soumises aux tests de support communautaire et de conformité avec les processus de consensus - coordonnés par l'ICANN - qui permettraient leur inclusion dans la racine faisant autorité. Ces décisions des autres opérateurs ont été prises sans égard apparent pour le souci fondamental d'intérêt public de la stabilité d'Internet. L'introduction généralisée de noms de domaine actifs dans ces racines alternatives pourrait en fait nuire à l'unicité du mécanisme de résolution de noms faisant autorité et, partant, à la stabilité du DNS.

En fait, certains des opérateurs de ces racines alternatives affirment que la stabilité n'est pas un attribut important pour le DNS. Cette thèse, pour des raisons déjà exposées, est en contradiction fondamentale avec la politique de l'ICANN telle qu'incarnée dans ses documents fondateurs. Certains de ces opérateurs et leurs partisans affirment que leur présence même sur le agora leur confère le droit préférentiel d'autoriser les TLD à l'avenir par l'ICANN. Ils travaillent selon la philosophie selon laquelle s'ils arrivent d'abord avec quelque chose qui ressemble à un TLD et invitent de nombreux participants à participer, l'ICANN sera obligé, par sa présence même et sa force de chiffres, de reconnaître à perpétuité ces pseudo TLDs, inhibant ainsi les nouveaux TLDs. le même nom de niveau supérieur d'être lancé à travers les processus de la communauté.

Aucune politique actuelle ne permettrait à l'ICANN d'accorder de tels droits préférentiels. Pour ce faire, l'ICANN aurait le mandat d'introduire de nouveaux TLD d'une manière ordonnée dans l'intérêt public pour ceux qui saisiraient simplement tous les noms de TLD qui semblent avoir une valeur de agora, contournant ainsi les processus communautaires que l'ICANN doit suivre. Pour l'ICANN de céder son mandat serait une violation de la confiance publique en vertu de laquelle l'ICANN a été créé et en vertu de laquelle il doit fonctionner. Si c'était pour accorder de tels droits préférentiels, l'ICANN abandonnerait cette confiance publique, ancrée dans la communauté, à ceux qui agissent seulement pour leur propre bénéfice. En effet, l'octroi de droits préférentiels pourrait compromettre la stabilité du DNS, violant ainsi le mandat fondamental de l'ICANN.

D'autres racines mettent en péril la stabilité du DNS, c'est-à-dire qu'elles créent le risque réel que les résolveurs de nom ne puissent pas déterminer à quelle adresse numérique un nom donné doit pointer. Cela viole la conception fondamentale du DNS et porte atteinte à l'utilité d'Internet en tant que moyen de communication mondial omniprésent. Certains de ces systèmes alternatifs utilisent également des technologies spéciales qui, aussi ingénieuses soient-elles, peuvent entrer en conflit avec les futures générations de normes Internet établies par la communauté. En effet, peut-il y avoir une garantie que ces technologies propriétaires peuvent ou seront adaptées aux futures modifications des normes Internet?

5. Expérimentation

L'expérimentation a toujours été une composante essentielle de la vitalité d'Internet. Travailler dans le système n'exclut pas l'expérimentation, y compris l'expérimentation avec des racines DNS alternatives. Mais ces activités doivent être menées de manière responsable, d'une manière qui ne perturbe pas les activités en cours des autres et qui est géré selon des protocoles expérimentaux.

Les expériences DNS devraient être encouragées. Cependant, les expériences ont presque, par définition, certaines caractéristiques pour éviter les dommages: (a) elles sont clairement étiquetées comme expériences; (b) il est bien entendu que ces expériences peuvent se terminer sans établir d'affirmations préalables sur les directions futures, (c) elles sont (d) les expérimentateurs s'engagent à s'adapter aux normes consensuelles lorsqu'elles émergent de l'ICANN et d'autres processus communautaires. Ceci est très différent du lancement d'entreprises commerciales qui donnent aux utilisateurs un sentiment de permanence sans avoir la moindre idée des obligations ou des éventualités qui précèdent.

En outre, il est essentiel que les opérations expérimentales impliquant d'autres racines DNS soient menées de manière contrôlée, afin qu'elles ne nuisent pas à ceux qui n'ont pas consenti à y participer. Compte tenu de la conception du DNS, et en particulier des problèmes d'empoisonnement de l'hôte intermédiaire et de l'antémémoire décrits dans la section 1 ci-dessus, il faut veiller tout particulièrement à isoler le DNS des effets de l'autre racine. Par exemple, les racines secondaires sont généralement exploitées par de grandes organisations au sein de leurs réseaux privés sans effets néfastes, étant donné que des précautions sont prises pour empêcher le flux des enregistrements de ressources alternatifs sur l'Internet public.

Il convient de noter que la conception initiale du DNS offre une possibilité de futures extensions qui permet de déployer en toute sécurité plusieurs racines sur l'Internet public à des fins expérimentales et autres. Comme indiqué dans la RFC 1034, le DNS inclut une balise "class" sur chaque enregistrement de ressource, ce qui permet de distinguer les enregistrements de ressources de différentes classes même s'ils sont mélangés sur l'Internet public. Pour les enregistrements de ressources dans le système racine-serveur faisant autorité, cette balise de classe est définie sur "IN"; d'autres valeurs ont été standardisées pour des utilisations particulières, y compris 255 valeurs possibles désignées pour un "usage privé" particulièrement adaptées à l'expérimentation.10

Comme décrit dans une proposition récente au sein de l'IETF11, cette fonction «classe» permet à un espace de noms DNS alternatif d'être exploité à partir de serveurs racine différents d'une manière qui n'interfère pas avec le fonctionnement stable du système racine-serveur existant. Pour tirer parti de cette fonctionnalité, il faut noter l'utilisation d'un logiciel client ou d'application développé pour l'espace de noms alternatif (vraisemblablement déployé après un test responsable), plutôt que le logiciel existant développé pour interopérer avec la racine faisant autorité. Ceux qui exploitent des racines alternatives à des fins commerciales mondiales, cependant, n'ont pas suivi ce cours.

Dans un Internet en constante évolution, il se peut qu'il y ait de meilleures architectures pour faire le travail là où le besoin d'une racine unique et fiable ne sera pas un problème. Mais ce n'est pas le cas aujourd'hui. Et la transition vers une telle architecture, si elle devait émerger, nécessiterait des approches communautaires. En attendant, l'expérimentation responsable devrait être encouragée, mais elle ne devrait pas être faite d'une manière qui affecte ceux qui ne consentent pas après avoir été informé du caractère de l'expérience.

Conclusion

Le succès d'Internet et la garantie de la stabilité de l'Internet reposent sur les activités de coopération de milliers, voire de millions, de personnes et d'institutions qui collaborent dans le monde entier en vue d'une fin commune. Cet effort communautaire extraordinaire - même sans précédent - a contribué à stimuler la croissance incroyable d'Internet. Beaucoup de ces personnes et institutions se livrent une concurrence intense entre elles tout en acceptant de le faire dans un cadre commun pour le bien public en général. Leurs efforts collectifs fournissent un cadre politique pour l'innovation technique et entrepreneuriale, et l'avancement des objectifs économiques, sociaux et éducatifs.

La plupart des membres de la communauté mondiale et la plupart des institutions avec lesquelles ils sont associés reconnaissent qu'il est dans leur meilleur intérêt à long terme de travailler dans ces processus communautaires, même si cela signifie renoncer aux avantages à court terme pour des individus ou groupes particuliers. Les principes généraux décrits dans ce document l'emportent sur l'intérêt exclusif et étroit.

Le développement de politiques communautaires n'est pas parfait. Il peut aller plus lentement que certains le souhaiteraient. L'introduction de nouveaux TLD s'est déroulée à des vitesses délibérées. L'impatience dans le contexte d'Internet est parfaitement compréhensible. Le résultat de processus ordonnés basés sur les souhaits de la communauté, cependant, est l'assurance qu'Internet continuera à fonctionner d'une manière stable et holistique qui profite à la communauté mondiale, et ne soit pas capturé par les intérêts personnels de quelques-uns. Cela, dans l'esprit de la plupart, est un prix qui vaut la peine d'être payé.

L'ICANN, par respect pour sa confiance publique, continuera à collaborer avec ces citoyens de la communauté Internet pour faire avancer les notions d'un système racinaire unique en tant que condition préalable à la stabilité d'Internet et pour s'assurer que les politiques communautaires prévalent. L'ICANN encourage l'expérimentation responsable conçue pour faire progresser l'Internet en tant que moyen utile, stable et accessible pour le bien public.

Remarques:

1. Ironiquement, pour éviter les conflits de noms dans un système à racines multiples, un système à racine unique devrait être créé, en ajoutant un niveau supérieur à la hiérarchie.

2. Amélioration de la gestion technique des noms et adresses Internet (Livre vert), 63 Fed. Reg. 8825, 8827 (20 février 1998).

3. Gestion des noms et adresses Internet (Livre blanc), 63 Fed. Reg. 31741, 31742 (10 juin 1998).

4. Livre vert, 63 Fed. Reg. à 8827.

5. Livre blanc, 63 Fed. Reg. à 31749. Les Livres vert et blanc ont tous deux fait des références supplémentaires à la nécessité d'un seul système racinaire faisant autorité. Par exemple, en réponse aux commentaires reçus du livre vert, le livre blanc note:

"En l'absence d'un système racine autoritaire, le risque de collisions de noms entre des sources concurrentes pour un même nom de domaine pourrait compromettre le bon fonctionnement et la stabilité d'Internet."

6. Livre blanc, 63 Fed. Reg. 31749 (soulignement ajouté).

7. La charte d'entreprise de l'ICANN souligne son rôle dans la supervision du fonctionnement de la racine DNS unique:

«[...] la Société doit [...] poursuivre les objectifs charitables et publics [...] de promouvoir l'intérêt public mondial dans la stabilité opérationnelle d'Internet par ... (iv) superviser le fonctionnement du système de serveur racine Internet DNS faisant autorité. ... "

Articles de constitution de l'ICANN, para. 3. L'expression "le système de serveur racine Internet DNS faisant autorité" est décidément au singulier.

8. Le mémorandum d'accord entre le gouvernement des États-Unis et l'ICANN qui régit le transfert des responsabilités du Département du Commerce des États-Unis à l'ICANN fait également référence à la racine faisant autorité au singulier, pas au pluriel:

"Dans le projet DNS, les parties vont concevoir, développer et tester conjointement les mécanismes, méthodes et procédures pour exécuter les fonctions de gestion DNS suivantes:

b) Supervision du fonctionnement du système de serveur racine faisant autorité;

"c) Supervision de la politique pour déterminer les circonstances dans lesquelles de nouveaux domaines de premier niveau seraient ajoutés au système racine."

9. Livre blanc, 63 Fed. Reg. au 31742.

10. RFC 2929, «Considérations relatives à l'IANA du système de noms de domaine (DNS)», section 3.2 (D. Eastlake, E. Brunner-Williams et B. Manning sept. 2000).

11. Internet Draft, «Internationalisation de la nouvelle classe DNS-A» (J. Klensin déc. 2000).