RFC 1958 (Français)
De EN65
(Traduction par Google)
Groupe de travail sur le réseau B. Carpenter, éditeur
Demande de commentaires: 1958 IAB
Catégorie: Information juin 1996
Principes architecturaux d'Internet
Statut de ce mémo
Ce mémo fournit des informations à la communauté Internet. Ce mémo
ne spécifie aucune norme Internet d'aucune sorte. Distribution de
ce mémo est illimité.
Abstrait
Internet et son architecture se sont développés de manière évolutive
de modestes débuts, plutôt que d'un Grand Plan. Alors que ce
processus d'évolution est l'une des principales raisons de la technologie de
succès, il semble néanmoins utile d'enregistrer un instantané de la
principes actuels de l'architecture Internet. Ceci est destiné à
d’orientation générale et d’intérêt général, et n’est nullement destiné à
être un modèle de référence formel ou invariant.
Table des matières
1. Changement constant .............................................. 1
2. Existe-t-il une architecture Internet? ........................... 2
3. Problèmes généraux de conception ........................................ 4
4. Problèmes de nom et d'adresse ...................................... 5
5. Problèmes externes .............................................. 6
6. Lié à la confidentialité et à l'authentification ....... 6
Remerciements ........................................... 7
Références................................................. .....7
Considérations de sécurité ......................................... 8
Adresse de l'éditeur ................................................ 8
1. Changement constant
En recherchant les principes architecturaux d'Internet, nous devons nous rappeler
que le changement technique est continu dans la technologie de l'information
industrie. Internet en est le reflet. Au cours des 25 années écoulées depuis
ARPANET a commencé, diverses mesures de la taille de l'Internet ont
augmenté par des facteurs entre 1000 (vitesse de la dorsale) et 1000000
(nombre d'hôtes). Dans cet environnement, quelques principes architecturaux
inévitablement changer. Des principes qui semblaient inviolables il y a quelques années
sont obsolètes aujourd'hui. Des principes qui semblent sacrés aujourd'hui seront
obsolète demain. Le principe du changement constant est peut-être
seul principe de l'Internet qui devrait survivre indéfiniment.
IAB Informational [Page 1]
RFC 1958 Principes architecturaux d'Internet Juin 1996
Le but de ce document n'est donc pas de poser des dogmes
sur la façon dont les protocoles Internet devraient être conçus, ou même sur la façon dont
ils devraient s'emboîter. Il s'agit plutôt de transmettre diverses lignes directrices
qui ont été jugées utiles dans le passé, et qui peuvent être utiles pour
ceux qui conçoivent de nouveaux protocoles ou évaluent ces conceptions.
Une bonne analogie pour le développement d'Internet est celle de
rénover constamment les rues et les bâtiments individuels d'une ville,
plutôt que de raser la ville et de la reconstruire. L'architecture
Les principes visent donc à fournir un cadre pour
la coopération et les normes, comme un petit "ensemble couvrant" de règles qui
génère un espace technologique vaste, varié et évolutif.
Certains déclencheurs techniques actuels du changement comprennent les limites
mise à l'échelle d'IPv4, le fait que les réseaux gigabit / seconde et le multimédia
présenter des défis fondamentalement nouveaux et le besoin de qualité
garanties de service et de sécurité dans l'Internet commercial.
Comme Lord Kelvin l’a déclaré en 1895, «les engins volants plus lourds que l’air sont
impossible. "Nous serions stupides d'imaginer que les principes
ci-dessous sont plus qu'un instantané de notre compréhension actuelle.
2. Existe-t-il une architecture Internet?
2.1 De nombreux membres de la communauté Internet soutiennent qu'il existe
pas d'architecture, mais seulement une tradition, qui n'a pas été écrite pour
les 25 premières années (ou du moins pas par l'IAB). Cependant, en très
En termes généraux, la communauté estime que l'objectif est la connectivité,
l'outil est le protocole Internet, et l'intelligence est de bout en bout
plutôt que caché dans le réseau.
La croissance exponentielle actuelle du réseau semble montrer que
la connectivité est sa propre récompense, et est plus précieuse que tout
application individuelle telle que le courrier ou le World-Wide Web. Cette
la connectivité nécessite une coopération technique entre les services
fournisseurs et s’épanouit dans un environnement de plus en plus libéral et
environnement commercial des télécommunications.
La clé de la connectivité mondiale est la couche d'interconnexion des réseaux. le
clé pour exploiter cette couche sur divers matériels fournissant global
la connectivité est "l'argument de bout en bout".
2.2 On estime généralement que dans une situation idéale, il devrait y avoir
un et un seul protocole au niveau Internet. Cela permet
opérations uniformes et relativement homogènes dans un environnement compétitif,
fournisseur, réseau public multi-fournisseurs. Il peut bien sûr y avoir
plusieurs protocoles pour satisfaire différentes exigences à d'autres niveaux,
et il existe de nombreux exemples réussis de grands réseaux privés avec
IAB Informational [Page 2]
RFC 1958 Principes architecturaux d'Internet Juin 1996
plusieurs protocoles de couche réseau en cours d'utilisation.
En pratique, il y a au moins deux raisons pour lesquelles plus d'un réseau
le protocole de couche peut être utilisé sur l'Internet public. Tout d'abord,
peut être un besoin de transition progressive d'une version d'IP vers
un autre. Deuxièmement, des exigences fondamentalement nouvelles pourraient
protocole fondamentalement nouveau.
Le protocole de niveau Internet doit être indépendant du matériel
adressage du support et du matériel. Cette approche permet à Internet de
exploiter toute nouvelle technologie de transmission numérique de quelque nature
découpler ses mécanismes d'adressage du matériel. Il permet au
Internet pour être le moyen facile d'interconnecter fondamentalement différent
de transmission et d'offrir une plate-forme unique pour une grande variété
des applications et des services d’infrastructure d’information. Il y a un
bonne exposition de ce modèle et d'autres éléments fondamentaux importants
questions, dans [Clark].
2.3 Il est également généralement admis que les fonctions de bout en bout peuvent être mieux
réalisé par des protocoles de bout en bout.
L'argument de bout en bout est discuté en profondeur dans [Saltzer]. le
L’argument de base est que, comme premier principe, certaines
les fonctions de bout en bout ne peuvent être exécutées correctement que par les systèmes d'extrémité
se. Un cas spécifique est que tout réseau, aussi soigneusement
conçus, seront soumis à des défaillances de transmission à certains
taux statistiquement déterminé. La meilleure façon d'y faire face est de
l'accepter et donner la responsabilité de l'intégrité de la communication
aux systèmes d'extrémité. Un autre cas spécifique est la sécurité de bout en bout.
Pour citer [Saltzer], "La fonction en question peut complètement et
correctement être mis en œuvre qu'avec la connaissance et l'aide des
application debout aux points d'extrémité du système de communication.
Par conséquent, fournir cette fonction mise en cause comme une caractéristique de la
système de communication lui-même n'est pas possible. (Parfois incomplet
la version de la fonction fournie par le système de communication peut être
utile comme amélioration des performances. ")
Ce principe a des conséquences importantes si nous avons besoin d'applications
pour survivre aux défaillances partielles du réseau. Une conception de protocole de bout en bout
ne devrait pas dépendre du maintien de l’état (c’est-à-dire des informations
l'état de la communication de bout en bout) à l'intérieur du réseau. Tel
ne devrait être maintenu que dans les points d'extrémité, de telle manière que
l'état ne peut être détruit que lorsque le point de terminaison lui-même se casse
(connu sous le nom de partage du destin). Une conséquence immédiate de ceci est que
les datagrammes sont meilleurs que les circuits virtuels classiques. Le réseau
travail consiste à transmettre les datagrammes de la manière la plus efficace et la plus flexible possible.
IAB Informational [Page 3]
RFC 1958 Principes architecturaux d'Internet Juin 1996
Tout le reste doit être fait en marge.
Pour fournir ses services, le réseau maintient un état
informations: itinéraires, QoS garantit qu'il fait, session
informations où cela est utilisé dans la compression d'en-tête, la compression
historiques pour la compression de données, etc. Cet état doit être
auto-guérison; des procédures ou protocoles adaptatifs doivent exister pour
et maintenir cet état, et le changer lorsque la topologie ou l'activité
des changements de réseau. Le volume de cet état doit être minimisé,
et la perte de l'État ne doit pas entraîner plus qu'un
déni de service étant donné que la connectivité existe. Manuellement
l'état configuré doit être maintenu à un minimum absolu.
2.4 Heureusement, personne ne possède Internet, il n'y a pas de système centralisé
contrôle, et personne ne peut le désactiver. Son évolution dépend du brut
consensus sur les propositions techniques et sur l'exécution du code.
La rétroaction de l'ingénierie à partir d'implémentations réelles est plus importante
que tous les principes architecturaux.
3. Problèmes généraux de conception
3.1 L'hétérogénéité est inévitable et doit être étayée par la conception.
Plusieurs types de matériel doivent être autorisés, par exemple la transmission
vitesses différentes d'au moins 7 ordres de grandeur, divers ordinateurs
longueurs de mots et hôtes allant de microprocesseurs affamés de mémoire
jusqu'aux supercalculateurs massivement parallèles. Plusieurs types de
protocole d'application doit être autorisé, allant du plus simple
tels que la connexion à distance aux plus complexes tels que distribués
bases de données.
3.2 S'il y a plusieurs façons de faire la même chose, choisissez-en une.
Si une conception antérieure, dans le contexte Internet ou ailleurs, a
résolu avec succès le même problème, choisissez la même solution à moins
il y a une bonne raison technique de ne pas le faire. Duplication de la même
la fonctionnalité du protocole doit être évitée autant que possible, sans
bien sûr, en utilisant cet argument pour rejeter les améliorations.
3.3 Toutes les conceptions doivent s'adapter facilement à de très nombreux nœuds par site et
plusieurs millions de sites.
3.4 Les performances et les coûts doivent être pris en compte ainsi que la fonctionnalité.
3.5 Restez simple. En cas de doute lors de la conception, choisissez la plus simple
Solution.
3.6 La modularité est bonne. Si vous pouvez séparer les choses, faites-le.
IAB Informational [Page 4]
RFC 1958 Principes architecturaux de l'Internet Juin 1996
3.7 Dans de nombreux cas, il vaut mieux adopter une solution presque complète
maintenant, plutôt que d'attendre qu'une solution parfaite soit trouvée.
3.8 Évitez autant que possible les options et les paramètres. Toutes les options et
les paramètres doivent être configurés ou négociés dynamiquement plutôt que
manuellement.
3.9 Soyez strict lors de l'envoi et tolérant lors de la réception.
Les mises en œuvre doivent suivre les spécifications précisément lors de l'envoi à
le réseau et tolérer les entrées défectueuses du réseau. Quand à
doute, éliminer silencieusement l'entrée défectueuse, sans renvoyer d'erreur
sauf si cela est requis par la spécification.
3.10 Soyez parcimonieux avec les paquets non sollicités, en particulier les multidiffusions
et émissions.
3.11 Les dépendances circulaires doivent être évitées.
Par exemple, le routage ne doit pas dépendre des recherches dans le domaine
Système de noms (DNS), car la mise à jour des serveurs DNS dépend de
routage réussi.
3.12 Les objets doivent être auto-descriptifs (inclure le type et la taille),
limites raisonnables. Seuls les codes de type et autres nombres magiques attribués
par l’Internet Assigned Numbers Authority (IANA) peut être utilisé.
3.13 Toutes les spécifications doivent utiliser la même terminologie et notation,
et la même convention d'ordre des bits et des octets.
3.14 Et peut-être le plus important: rien n'est normalisé avant
il existe plusieurs instances d'exécution de code.
4. Nom et adresse des problèmes
4.1 Évitez toute conception nécessitant un codage en dur des adresses ou
stocké sur un stockage non volatile (sauf bien sûr où il s'agit d'un
condition essentielle comme dans un serveur de noms ou un serveur de configuration).
En général, les applications utilisateur doivent utiliser des noms plutôt que des adresses.
4.2 Une seule structure de dénomination doit être utilisée.
4.3 Les noms publics (c'est-à-dire largement visibles) doivent être indépendants de la casse
ASCII. Plus précisément, cela fait référence aux noms DNS et au protocole
éléments transmis au format texte.
4.4 Les adresses doivent être sans ambiguïté (uniques dans tous les domaines où elles
peut apparaître).
IAB Informational [Page 5]
RFC 1958 Principes architecturaux de l'Internet Juin 1996
4.5 Les protocoles de la couche supérieure doivent être en mesure d'identifier les points d'extrémité
sans ambiguïté. En pratique, cela signifie que les adresses doivent être
idem au début et à la fin de la transmission.
5. Problèmes externes
5.1 Préférez la technologie non brevetée, mais si la meilleure technologie est
breveté et accessible à tous à des conditions raisonnables,
l'incorporation d'une technologie brevetée est acceptable.
5.2 L'existence de contrôles à l'exportation sur certains aspects d'Internet
la technologie n'a qu'une importance secondaire dans le choix des
technologie à adopter dans les normes. Toute la technologie
requis pour mettre en œuvre les normes Internet peuvent être fabriqués dans chaque
pays, de sorte que le déploiement mondial de la technologie Internet ne
dépendent de son exportabilité à partir d'un ou de plusieurs pays particuliers.
5.3 Toute mise en œuvre qui ne comprend pas tous les éléments requis
les composants ne peuvent pas revendiquer la conformité à la norme.
5.4 Les dessins et modèles devraient être entièrement internationaux, avec
localisation (adaptation aux jeux de caractères locaux). En particulier,
il devrait y avoir une approche uniforme de l'étiquetage des jeux de caractères pour
contenu de l'information.
6. Concernant la confidentialité et l'authentification
6.1 Toutes les conceptions doivent s'intégrer dans l'architecture de sécurité IP.
6.2 Il est hautement souhaitable que les opérateurs Internet protègent la vie privée
et l'authenticité de tout le trafic, mais ce n'est pas une exigence de la
architecture. La confidentialité et l'authentification sont les
responsabilité des utilisateurs finaux et doit être implémenté dans les protocoles
utilisé par les utilisateurs finaux. Les points de terminaison ne doivent pas dépendre du
confidentialité ou intégrité des transporteurs. Les transporteurs peuvent choisir de
fournir un certain niveau de protection, mais cela est secondaire à la
responsabilité principale des utilisateurs finaux de se protéger.
6.3 Partout où un algorithme cryptographique est requis dans un protocole,
le protocole devrait être conçu pour permettre à d'autres algorithmes
être utilisé et l'algorithme spécifique utilisé dans un particulier
la mise en œuvre doit être explicitement étiquetée. Étiquettes officielles pour
les algorithmes doivent être enregistrés par l'IANA.
(On peut faire valoir que ce principe pourrait être généralisé au-delà de la
zone de sécurité.)
IAB Informational [Page 6]
RFC 1958 Principes architecturaux d'Internet Juin 1996
6.4 Lors du choix des algorithmes, l'algorithme doit être celui qui est
largement considéré comme assez fort pour servir le but. Parmi
alternatives qui sont toutes suffisamment fortes, la préférence devrait être
donné à des algorithmes qui ont résisté à l'épreuve du temps et qui sont
pas inutilement inefficace.
6.5 Assurer l'interopérabilité entre les points d'extrémité utilisant la sécurité
services, un algorithme (ou une suite d'algorithmes) devrait être obligatoire
assurer la capacité de négocier un contexte sûr entre
implémentations. Sans cela, les implémentations pourraient autrement ne pas
avoir un algorithme en commun et ne pas pouvoir communiquer en toute sécurité.
Remerciements
Ce document est un travail collectif de la communauté Internet,
publié par l'Internet Architecture Board. Remerciements particuliers à Fred
Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, Neal
McBurnett, Masataka Ohta, Jeff Schiller et Lansing Sloan.
Références
Notez que les références ont été délibérément limitées à deux
documents fondamentaux sur l'architecture Internet.
[Clark] La philosophie de conception des protocoles Internet DARPA,
DDClark, Proc SIGCOMM 88, ACM CCR Vol 18, numéro 4, août 1988,
pages 106-114 (réimprimé dans ACM CCR Vol 25, Numéro 1, janvier 1995,
pages 102-111).
[Saltzer] Arguments de bout en bout dans la conception du système, JH Saltzer,
DPReed, DDClark, ACM TOCS, Vol 2, Numéro 4, novembre 1984, pp
277-288.
IAB Informational [Page 7]
RFC 1958 Principes architecturaux d'Internet Juin 1996
Considérations de sécurité
Les problèmes de sécurité sont abordés tout au long de ce mémo.
Adresse de l'éditeur
Brian E. Carpenter
Chef de groupe, Systèmes de communication
Division Informatique et Réseaux
CERN
Laboratoire européen de physique des particules
1211 Genève 23, Suisse
Tél: +41 22767-4967
Télécopie: +41 22767-7155
Courriel: brian@dxcoms.cern.ch
IAB Informationnel [Page 8]
