Groupe de travail Réseau |
Jeffrey Mogul |
Request for Comments : 917 |
Computer Science Department, Stanford University |
Traduction Claude Brière de L'Isle |
octobre 1984 |
Sous-réseaux de l'Internet
Statut de ce mémoire
La présente RFC suggère une proposition de protocole pour la communauté ARPA-Internet, et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.
Généralités
On discute de l'utilité de "sous-réseaux" des réseaux Internet, qui sont les sous-sections logiquement visibles d'un seul réseau de l'Internet. Pour des raisons administratives ou techniques, de nombreuses organisations ont choisi de diviser un réseau Internet en plusieurs sous réseaux, au lieu d'acquérir un ensemble de numéros de réseau Internet. On propose des procédures pour l'utilisation des sous-réseaux et on expose les approches de résolution des problèmes qui surviennent, en particulier celui de l'acheminement.
Remerciements
Cette proposition est le résultat de discussions avec plusieurs autres personnes. J. Noël Chiappa, Chris Kent, et Tim Mann, en particulier, ont fourni d'importantes suggestions.
Table des matières
2. Normes pour l'adressage de sous-réseau
2.1 Interprétation des adresses Internet
2.2 Changements des logiciels d'hôtes pour la prise en charge des sous-réseaux
2.4 Détermination de la longueur du champ de sous-réseau .
3. Méthodes d'acheminement de sous-réseau
4.3 Université Carnegie-Mellon
Annexe I. Format d'adresse ICMP
La vision originale de l'univers Internet était une hiérarchie à deux niveaux : au niveau supérieur, le catenet comme un tout, et au niveau inférieur une collection de "réseaux Internet", ayant chacun son propre numéro de réseau. (Ce qui ne veut pas dire que l'Internet a une topologie hiérarchique, mais que l'interprétation des adresses est hiérarchique.)
Bien que cette vision se soit révélée simple et puissante, un certain nombre d'organisations l'ont trouvée inadéquate et ont ajouté un troisième niveau d'interprétation des adresses Internet. De ce point de vue, un réseau Internet donné pourrait être (ou non) divisé en une collection de sous-réseaux.
La vision originale à deux niveaux emporte une forte présomption que, du point de vue d'un hôte sur un réseau Internet, ce réseau peut être vu comme une seule bordure ; pour le dire autrement, le réseau peut être traité comme une "boîte noire" à laquelle un ensemble d'hôtes est connecté. Ceci est vrai de l'ARPANET, parce que les IMP masquent l'utilisation des liaisons spécifiques à l'intérieur de ce réseau. Cela est aussi vrai de la plupart des technologies de réseau de zone locale (LAN) telles que Ethernet ou des réseaux en anneau.
Cependant, cette présomption est mise en échec dans de nombreux cas pratiques, parce que dans des organisations relativement grandes (par exemple, des universités ou des compagnies ayant plusieurs localisations) il est souvent nécessaire d'utiliser plus d'un câble de LAN pour couvrir une "zone locale". Par exemple, au moment de la rédaction du présent document, il y a dix huit câbles de ce type qui sont utilisés à l'Université Stanford, et d'autres sont prévus.
Les raisons pour lesquelles une organisation peut utiliser plus d'un câble pour couvrir un campus sont multiples :
- Des technologies différentes : en particulier dans un environnement de recherche, il peut y avoir plus d'un type de LAN en service ; par exemple, une organisation peut avoir des équipements qui prennent en charge Ethernet, et certains autres qui servent de support à un réseau en anneau.
- Les limites des technologies : la plupart des technologies de LAN imposent des limites, fondées sur des paramètres électriques, au nombre d'hôtes connectés, et à la longueur totale du câble. Il est facile de dépasser ces limites, en particulier celle sur la longueur de câble.
- L'encombrement du réseau : il est possible à un petit sous-ensemble des hôtes d'un LAN de monopoliser la plus grande partie de la bande passante. Une solution courante à ce problème est de diviser les hôtes en cliques de forte communication mutuelle, et de mettre ces cliques sur des câbles séparés.
- Liaisons point à point : parfois une "zone locale", comme un campus d'université, est partagé en deux localisations trop éloignées pour se connecter en utilisant la technologie préférée du LAN. Dans ce cas, les liaisons point à point à grande vitesse peuvent connecter plusieurs LAN.
Une organisation qui a été forcée d'utiliser plus d'un LAN a le choix entre trois solutions pour allouer les adresses Internet :
1. Acquérir un numéro de réseau Internet distinct pour chaque câble.
2. Utiliser un seul numéro de réseau pour l'organisation entière, mais allouer des numéros d'hôte sans considération du LAN sur lequel se trouve un hôte. (On appellera ce choix des "sous-réseaux transparents".)
3. Utiliser un seul numéro de réseau, et partitionner l'espace d'adresse des hôtes en allouant des numéros de sous-réseau aux LAN. ("Sous-réseaux explicites".)
Chacune de ces approches a ses inconvénients. Le premier, bien que n'exigeant aucun protocole nouveau ou modifié, résulte en une explosion de la taille des tableaux d'acheminement de l'Internet. Les informations sur les détails internes de la connexité locale sont propagées partout, bien qu'elles soient de peu ou d'aucun intérêt en dehors de l'organisation locale. En particulier lorsque certaines mises en œuvre actuelles de routeurs n'ont pas beaucoup d'espace pour les tableaux d'acheminement, il serait agréable d'éviter ce problème.
La seconde approche exige que des conventions ou un protocole fassent que la collection des LAN apparaissent comme une seul réseau Internet. Par exemple, cela peut être fait sur des LAN où chaque adresse Internet est traduite en une adresse de matériel en utilisant un protocole de résolution d'adresse (ARP), en ayant des ponts entre les LAN qui interceptent les demandes ARP pour des cibles non locales. Cependant, il n'est pas possible de faire cela pour toutes les technologies de LAN, en particulier pour celles où les protocoles ARP ne sont pas actuellement utilisées, ou si le LAN ne prend pas en charge les diffusions. Un problème plus fondamental est que les ponts doivent découvrir sur quel LAN est un hôte, peut-être en utilisant un algorithme de diffusion. À mesure que le nombre de LAN croît, le coût de la diffusion augmente aussi ; alors, la taille des antémémoires de traduction exigé dans les ponts augmente comme le nombre total des hôtes sur le réseau.
La troisième approche vise le problème clé : les normes existantes supposent que tous les hôtes sur un réseau local Internet sont sur un seul câble. La solution est de prendre en charge explicitement les sous-réseaux. Cela a un inconvénient qui est qu'il faut modifier le protocole Internet, et donc cela exige des modifications aux mises en œuvre IP déjà en service (si ces mises en œuvre sont à utiliser sur un réseau subdivisé en sous-réseaux). Cependant, on pense que ces changements sont relativement mineurs, et une fois faits, donnent une solution simple et efficace au problème. Aussi, l'approche qui sera suivie dans le présent document est d'éviter tout changement qui serait incompatible avec les hôtes existants sur les réseaux non subdivisés en sous-réseaux.
De plus, lorsque les choix de conception appropriés sont faits, il est possible aux hôtes qui pensent qu'ils sont sur un réseau non subdivisé en sous-réseaux de les utiliser sur un réseau subdivisé en sous-réseaux, comme on l'expliquera plus loin. Ceci est utile lorsqu'il n'est pas possible de modifier certains hôtes de façon à prendre en charge explicitement les sous-réseaux, ou lorqu'une transition graduelle est préférée. À cause de cela, il reste peu de raison d'utiliser la seconde approche mentionnée ci-dessus.
Le reste du présent document décrit les approches de sous réseaux des réseaux Internet.
Pour éviter les ambiguïtés ou les répétitions, on définit quelques termes, qui seront utilisés dans les paragraphes suivants :
Catenet
Réseau
Un seul réseau Internet (qui peut être ou non divisé en sous-réseaux).
Sous -réseau
Un sous-réseau d'un réseau Internet.
Numéro de réseau
Selon ce qui est indiqué en [8].
Adresse locale
Les bits qui dans une adresse Internet ne sont pas utilisés pour le numéro de réseau ; aussi appelé le "champ restant".
Numéro de sous-réseau
Numéro qui identifie un sous-réseau au sein d'un réseau.
Champ de sous-réseau
Champ binaire utilisé pour le numéro de sous-réseau dans une adresse Internet.
Champ d'hôte
Champ binaire utilisé pour noter un hôte spécifique dans une adresse Internet.
Routeur (passerelle)
Nœud connecté à deux réseaux et/ou sous-réseaux administrativement distincts ou plus, auxquels les hôtes envoient des datagrammes à transmettre.
Pont
Nœud connecté à deux ou plus sous-réseaux administrativement indistinguables mais physiquement distincts, qui transmet automatiquement les datagrammes lorsque nécessaire, mais dont l'existence n'est pas connue des autres hôtes. Aussi appelé un "répéteur logiciel".
2. Normes pour l'adressage de sous-réseau
Suivant la division présentée en [2], on observe que les sous-réseaux sont fondamentalement une question d'adressage. Dans cette section, on décrit d'abord une proposition d'interprétation de l'adressage Internet pour la prise en charge des sous réseaux. Nous exposerons ensuite l'interaction entre ce format d'adresse et la diffusion ; enfin, nous présenterons un protocole pour la découverte de l'interprétation d'adresse qui est utilisée sur un réseau donné.
2.1 Interprétation des adresses Internet
Supposons qu'un numéro de réseau Internet ait été alloué à une organisation, que ce réseau ait été ensuite redivisé en un ensemble de sous-réseaux, et qu'on veuille allouer des adresses d'hôte : comment ceci devrait-il être fait ? Comme il y a des restrictions minimales sur les allocations de la partie "adresse locale" de l'adresse Internet, plusieurs approches ont été proposées pour la représentation du numéro de sous-réseau.
1. Champ de longueur variable : tout nombre de bits de la partie adresse locale est utilisé pour le numéro de sous-réseau ; la taille de ce champ, bien que constante pour un réseau donné , varie d'un réseau à l'autre. Si la longueur du champ est de zéro, il n'y a pas de sous-réseau.
2. Champ de longueur fixe : un nombre spécifique de bits (par exemple, huit) est utilisé pour le numéro de sous-réseau, si des sous-réseaux sont utilisés.
3. Champ auto-codant de longueur variable : juste comme la longueur du champ de numéro de réseau (c'est-à-dire sa classe) est codée par ses bits de plus fort poids, la longueur du champ de sous-réseau est codée de façon similaire.
4. Champ auto-codant de longueur fixe : un nombre de bits spécifique est utilisé pour le numéro de sous-réseau. Les sous-réseaux sont utilisés si le bit de plus fort poids de ce champ est mis à un ; autrement, c'est la partie d'adresse locale toute entière qui est utilisée pour le numéro d'hôte.
Comme il semble n'y avoir aucun avantage à faire autrement, tous ces schémas placent le champ de sous-réseau dans le champ de plus fort poids de la partie d'adresse locale. Aussi, comme la partie adresse locale d'une adresse de classe C est si petite, il y a peu de raisons de prendre en charge des sous-réseaux dans des réseaux d'autres classes que A et B.
Quels critères pouvons nous utiliser pour choisir un de ces quatre schémas ? D'abord, voulons nous utiliser un schéma d'auto codage ; c'est-à-dire, devrait-il être possible de dire en examinant une adresse Internet si elle se réfère à un réseau organisé en sous-réseaux, sans référence à d'autres informations ?
Un des avantages de l'auto-codage est qu'il permet à tout un chacun de déterminer si un réseau non local a été divisé en sous-réseaux. Il n'apparaît pas clairement que cela présente une utilité quelconque. Le principal avantage, cependant, est qu'aucune information supplémentaire n'est nécessaire pour qu'une mise en œuvre détermine si deux adresses sont sur le même sous-réseau. Cependant, cela peut aussi être vu comme un inconvénient : cela peut causer des problèmes pour les réseaux qui ne sont pas organisés en sous-réseaux qui ont des numéros d'hôtes existants qui utilisent des bits arbitraires dans la partie d'adresse locale <1>. En d'autres termes, il est utile d'être capable de contrôler si un réseau est organisé en sous-réseaux indépendamment de l'allocation des adresses d'hôte. Un autre inconvénient de tout schéma d'auto-codage est que cela réduit l'espace d'adresse locale d'au moins un facteur deux.
<1> Par exemple, certains hôtes ont leurs adresses allouées en enchaînant leur numéro de réseau de classe A avec les 24 bits de moindre poids d'une adresse de matériel Ethernet de 48 bits.
Si on n'utilise pas un schéma d'auto-codage, il est clair qu'un champ de sous-réseau de longueur variable est approprié. Comme il doit dans tous les cas y avoir un "fanion" par réseau pour indiquer si des sous-réseaux sont utilisés, le coût supplémentaire d'utilisation d'un entier (la longueur du champ de sous-réseau) au lieu d'un booléen est négligeable. L'avantage de l'utilisation d'un champ de longueur variable est que cela permet à chaque organisation de choisir la meilleure façon d'allouer des bits relativement rares de l'adresse locale aux numéros de sous-réseaux et d'hôtes.
Notre proposition est donc est que les adresses Internet soient interprétées comme :
<numéro-de-réseau><numéro-de-sous-réseau><numéro-d'hôte>
où le champ <numéro-de-réseau> est comme indiqué dans [8], le champ <numéro-d'hôte> est d'au moins un bit, et la longueur du champ <numéro-de-sous-réseau> est constante pour un réseau donné. Aucune autre structure n'est exigée pour les champs <numéro-de-sous-réseau> ou <numéro-d'hôte>. Si la longueur du champ <numéro-de-sous-réseau> est de zéro, le réseau n'a alors pas de sous-réseau (c'est-à-dire que l'interprétation de [8] est utilisée.)
Par exemple, sur un réseau de classe A avec un champ de sous-réseau d'une longueur de huit bits, une adresse se décompose de la façon suivante :
0 |
1 |
2 |
3 |
|||||||||||||||||||||||||||||
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
|
0 |
Réseau |
Sous-réseau |
Numéro d'hôte |
|||||||||||||||||||||||||||||
On s'attend à ce que, pour des raisons de simplicité et d'efficacité de mise en œuvre, la plupart des organisations choisiront une longueur de champ de sous-réseau qui est un multiple de huit bits. Cependant, une mise en œuvre doit être prête à traiter d'autres longueurs possibles.
On rejette l'utilisation de "sous-réseaux récurrents", la division du champ d'hôte en parties "sous-réseau" et hôte, parce que :
- Il n'y a pas de besoin évident d'une hiérarchie à quatre niveaux.
- Le nombre de bits disponibles dans une adresse IP n'est pas assez grand pour rendre cela utile d'une façon générale.
- Le mécanisme supplémentaire nécessaire est complexe.
2.2 Changements des logiciels d'hôtes pour la prise en charge des sous-réseaux
Dans la plupart des mises en œuvre de IP, il y a un code dans le module qui traite les paquets sortants qui fait quelque chose comme :
Si ip_net_number(packet.ip_dest) = ip_net_number(my_ip_addr)
ALORS
send_packet_locally(packet, packet.ip_dest)
AUTREMENT
send_packet_locally(packet,
gateway_to(ip_net_number(packet.ip_dest)))
(Si le code prend en charge plusieurs réseaux connectés, il sera plus compliqué, mais cela n'est pas pertinent pour la discussion actuelle.)
Pour prendre en charge les sous-réseaux, il est nécessaire de mémoriser une quantité de 32 bits supplémentaire, appelée my_ip_mask. C'est un gabarit binaire avec les bits établis dans les champs qui correspondent au numéro de réseau IP, et des bits établis supplémentaires correspondant au champ de numéro de sous-réseau. Par exemple, sur un réseau de classe A utilisant un champ de sous-réseau de huit bits, le gabarit serait 255.255.0.0.
Le code devient alors :
SI bitwise_and(packet.ip_dest, my_ip_mask) = bitwise_and(my_ip_addr, my_ip_mask)
ALORS
send_packet_locally(packet, packet.ip_dest)
AUTREMENT
send_packet_locally(packet,
gateway_to(bitwise_and(packet.ip_dest, my_ip_mask)))
Bien sûr, la partie de l'expression au conditionnel peut être précalculée.
Il peut être ou non nécessaire de modifier la fonction "gateway_to", de sorte qu'elle effectue les comparaisons de la même façon.
Pour prendre en charge des hôtes à connexion multiple, le code peut être changé pour garder les quantités "my_ip_addr" et "my_ip_mask" interface par interface ; l'expression au conditionnel doit alors être évaluée pour chaque interface.
En l'absence de sous-réseaux, il y a seulement deux sortes de diffusions possibles au sein du protocole Internet <2> : la diffusion à tous les hôtes sur un réseau spécifique, ou la diffusion à tous les hôtes sur "ce réseau" ; cette dernière est utile lorsque un hôte ne sait pas sur quel réseau il se trouve.
<2> Notre exposé de la diffusion Internet se fonde sur [6].
Lorsque des sous-réseaux sont utilisés, la situation devient légèrement plus compliquée. D'abord, il existe maintenant la possibilité de diffuser sur un sous-réseau spécifique. Ensuite, la diffusion à tous les hôtes sur un réseau subdivisé en sous-réseaux exige des mécanismes supplémentaires ; en [6] l'utilisation de la "transmission sur le chemin inverse" [3] est proposée. Finalement, l'interprétation d'une diffusion à "ce réseau" est qu'elle ne devrait pas être transmis en dehors du sous-réseau original.
Les mises en œuvre doivent donc reconnaître trois sortes d'adresses de diffusion, en plus de leurs propres adresses d'hôte :
- ce réseau physique :
l'adresse de destination toute en uns (255.255.255.255) cause l'envoi du datagramme comme diffusion sur le réseau physique local ; il ne doit être transmis par aucun routeur.
- réseau spécifique
l'adresse de destination contient un numéro de réseau valide ; la partie locale de l'adresse est toute en uns (par exemple, 36.255.255.255).
- sous-réseau spécifique
l'adresse de destination contient un numéro de réseau et un numéro de sous-réseau valides ; le champ hôte est tout en uns (par exemple, 36.40.255.255).
Pour un exposé plus complet sur la diffusion sur Internet, voir [6].
Un facteur qui peut aider à décider d'utiliser ou non des sous-réseaux est qu'il est possible de diffuser à tous les hôtes d'un réseau subdivisé en sous-réseaux avec une seule opération chez l'hôte d'origine. Il n'est pas possible de diffuser, en une étape, au même ensemble d'hôtes si ils sont sur des réseaux distincts.
2.4 Détermination de la longueur du champ de sous-réseau
Comment un hôte (ou un routeur) peut-il déterminer quelle longueur de champ de sous-réseau est utilisée sur un réseau auquel il est connecté ? Le problème est analogue à plusieurs autres problèmes "d'amorçage" des hôtes Internet : comment un hôte détermine-t-il sa propre adresse, et comment localise-t-il un routeur sur son réseau local. Dans ces trois cas, il y a deux solutions de base : des informations "incorporées au matériel" et des protocoles fondés sur la diffusion.
Les informations "incorporées au matériel" sont celles qui sont disponibles à l'hôte indépendamment du réseau. Elles peuvent être compilées, ou (de préférence) mémorisées dans un fichier. Cependant, pour le cas de plus en plus courant des stations sans disque dur qui sont téléchargées à l'amorçage sur un LAN, aucune solution incorporée dans le matériel n'est satisfaisante. Au lieu de cela, comme la plupart des technologies de LAN prennent en charge la diffusion, une meilleure méthode est que l'hôte qui vient de s'amorcer diffuse une demande des informations nécessaires. Par exemple, pour les besoins de la détermination de son adresse Internet, un hôte peut utiliser le "protocole de résolution inverse d'adresse" [4].
Nous proposons d'étendre le protocole ICMP [9] en ajoutant une nouvelle paire de types de messages ICMP, "Demande de format d'adresse" et "Réponse de format d'adresse", analogue aux messages ICMP "Demande d'information" et "Réponse d'information". Elles sont décrites en détail à l'Appendice I.
L'utilisation à laquelle sont destinés ces nouveaux messages ICMP est qu'un hôte, lors de l'amorçage, diffuse un message "Demande de format d'adresse" <3>. Un routeur (ou un hôte agissant en tant que routeur) qui reçoit ce message répond par une "Réponse de format d'adresse". Si il n'y a pas d'indication dans la demande de l'hôte qui l'a envoyée (c'est-à-dire si l'adresse de source IP est zéro), la réponse est diffusée quand même. L'hôte demandeur va entendre la réponse, et à partir d'elle va déterminer la longueur du champ de sous-réseau.
<3> Si la diffusion n'est pas prise en charge, on peut présumer qu'un hôte "connaît" l'adresse d'un routeur voisin, et devrait envoyer le message ICMP à ce routeur.
Comme il n'y a qu'une seule valeur possible qui puisse être envoyée dans une "Réponse de format d'adresse" sur un LAN donné, il n'est pas nécessaire que l'hôte demandeur confronte les réponses qu'il entend à la demande qu'il a envoyée ; de même, il n'y a pas de problème si plus d'un routeur répond. On suppose que les hôtes se réamorcent peu fréquemment, de sorte que la charge de diffusion sur un réseau causée par l'utilisation de ce protocole devrait rester faible.
Si un hôte est connecté à plus d'un LAN, il doit utiliser ce protocole sur chacun, sauf si il peut déterminer (à partir d'une réponse sur un des LAN) que plusieurs des LAN font partie du même réseau, et doivent donc avoir la même longueur de champ de sous-réseau.
Un problème potentiel est ce que devrait faire un hôte si il ne reçoit aucune réponse à ses "Demandes de format d'adresse", même après un nombre raisonnable d'essais. Trois interprétations peuvent être faites de la situation :
1. Le réseau local existe isolément (permanent) de tous les autres réseaux.
2. Les sous-réseaux ne sont pas utilisés, et aucun hôte ne prend en charge cette demande ICMP.
3. Tous les routeurs sur le réseau local sont (temporairement) hors service.
La première et la seconde situation impliquent que la longueur du champ de sous-réseau est zéro. Dans la troisième situation, il 'y a aucun moyen de déterminer quelle est la valeur appropriée ; le choix le plus sûr est donc zéro. Bien que cela puisse ultérieurement se révéler faux, cela n'empêchera pas les transmissions qui auraient autrement pu être faites. Il est possible à un hôte de se remettre d'un mauvais choix : lorsqu'un routeur d'active, il devrait diffuser une "Réponse de format d'adresse" ; lorsqu'un hôte reçoit un tel message qui est en désaccord avec ce qu'il a supposé, il devrait ajuster ses structures de données pour se conformer à la valeur reçue. Aucun hôte ou routeur ne devrait envoyer une "Réponse de format d'adresse" fondée sur une valeur "supposée".
Finalement, noter qu'aucun hôte n'est obligé d'utiliser ce protocole ICMP pour découvrir la longueur du champ de sous-réseau ; il est parfaitement raisonnable qu'un hôte qui a une mémoire non volatile d'utiliser les informations mémorisées.
3. Méthodes d'acheminement de sous-réseau
Un problème auquel sont confrontés tous les hôtes de l'Internet est celui de la façon de déterminer un chemin vers un autre hôte. En présence de sous-réseaux, ce problème est seulement légèrement modifié.
L'utilisation de sous-réseaux signifie qu'il y a deux niveaux du processus d'acheminement au lieu d'un. Si l'hôte de destination est sur le même réseau que l'hôte de source, la décision d'acheminement n'implique que le routeur du sous-réseau entre les hôtes. Si la destination est sur un réseau différent, la décision d'acheminement exige alors le choix d'un routeur en dehors du réseau de l'hôte de source, et d'un chemin au sein du réseau jusqu'à ce routeur.
Heureusement, de nombreux hôtes peuvent ignorer cette distinction (et, en fait, ignorent tous les choix d'acheminement) en utilisant un routeur "par défaut" comme chemin initial vers toutes les destinations, et s'appuient sur les messages ICMP Host Redirect pour définir des chemins plus appropriés. Cependant, ce n'est pas une méthode efficace pour un routeur ou pour un hôte à rattachements multiples, car une redirection peut ne pas compenser un mauvais chois initial de chemin. De tels hôtes devraient utiliser un protocole d'échange d'informations d'acheminement, mais cela sort du domaine d'application du présent document ; dans tous les cas, le problème survient même lorsqu'on utilise pas de sous-réseaux.
Le problème pour un hôte à une seule connexion est donc de trouver au moins un routeur dans le voisinage. Il y a encore deux solutions de base pour le faire : utiliser des information incorporées dans le matériel, ou utiliser les diffusions. Nous pensons que le problème de l'acquisition du routeur du voisinage est le même avec ou sans sous-réseaux, et donc le choix d'une solution n'est pas affecté par l'utilisation de sous-réseaux.
Cependant, il reste un problème : un hôte de source doit déterminer si un datagramme pour une adresse de destination donnée doit être envoyé via un routeur, ou être envoyé directement à l'hôte de destination. En d'autres termes, l'hôte de destination est-il sur le même réseau physique que la source ? Cette phase particulière du processus d'acheminement est la seule qui demande qu'une mise en œuvre soit explicitement au courant des sous-réseaux ; en fait, si les diffusions ne sont pas utilisées, c'est le seul moment où une mise en œuvre Internet doive être modifiée pour prendre en charge les sous-réseaux.
À cause de cela, il est possible d'utiliser certaines mises en œuvre existantes sans modification en présence de sous-réseaux <4>. Pour que cela fonctionne, de telles mises en œuvre doivent :
- n'être utilisées que sur des hôtes à rattachement unique, et pas comme routeur,
- être utilisées sur un LAN acceptant la diffusion,
- utiliser un protocole de résolution d'adresse (ARP), tel que [7],
- n'être pas obligé de maintenir les connexions dans le cas d'une défaillance de routeur.
<4> C'est ce qu'on appelait auparavant la coexistence de sous-réseaux transparents et explicites sur un seul réseau.
Dans ce cas, on peut modifier le module de serveur ARP dans un routeur de sous-réseau de telle sorte que lorsqu'il reçoit une demande ARP, il vérifie l'adresse Internet cible pour voir si elle est sur le meilleur chemin vers la cible. Si elle l'est, il envoie à l'hôte demandeur une réponse ARP indiquant sa propre adresse de matériel. L'hôte demandeur estime alors qu'il connaît l'adresse matérielle de l'hôte de destination, et envoie les paquets à cette adresse. En fait, les paquets sont reçus par le routeur, et transmis à l'hôte de destination par les moyens usuels.
Cette méthode requiert un certain brouillage des couches dans les routeurs, car le serveur ARP et le tableau d'acheminement Internet ne devraient normalement avoir aucun contact. À cet égard, c'est assez peu satisfaisant. Cependant, c'est très facile à mettre en œuvre et n'a pas de coûts d'exécution significatifs. Il y a un problème si le routeur d'origine a une défaillance, car il n'y a aucun moyen pour l'hôte de source de choisir un chemin de remplacement même si il en existe un ; et donc, une connexion qui aurait pu autrement être maintenue sera brisée.
On ne devrait pas confondre cette méthode de "sous-réseautage fondés sur ARP" avec l'utilisation superficiellement similaire des ponts fondés sur ARP. Le sous-réseautage fondés sur ARP s'appuie sur la capacité d'un routeur à examiner une adresse IP et à en déduire un chemin pour la destination, sur la base d'une topologie explicite de sous-réseau. En d'autres termes, une petite partie de la décision d'acheminement a été déplacée de l'hôte de source au routeur. À l'opposé, un pont fondé sur ARP doit de quelque façon localiser chaque hôte sans l'assistance d'une transposition entre l'adresse d'hôte et la topologie. Les systèmes construits sur des ponts fondés sur ARP ne devraient pas être désignés comme étant à "sous-réseau".
N.B. : L'utilisation du sous-réseautage fondé sur ARP est compliquée par l'utilisation de la diffusion. Un serveur ARP [7] ne devrait jamais répondre à une demande dont la cible est une adresse de diffusion. Une telle demande ne peut venir que d'un hôte qui ne reconnaît pas l'adresse de diffusion comme telle, aussi honorer une telle demande conduirait presque certainement à une boucle de transmission. Si il y a N hôtes de cette sorte sur le réseau physique qui ne reconnaissent pas cette adresse comme une diffusion, alors un paquet envoyé avec une Durée de vie de T pourrait éventuellement donner lieu à T**N rediffusions parasites.
Dans cette section, nous retraçons brièvement comment les sous-réseaux ont été utilisés par plusieurs organisations.
À Stanford, les sous-réseaux ont été introduits initialement pour des raisons historiques. Stanford a utilisé les protocoles Pup [1] sur un ensemble de plusieurs Ethernets expérimentaux [5] depuis 1979, plusieurs années avant l'utilisation des protocoles Internet. Un certain nombre de routeurs Pup ont été mis en service, et tous les hôtes et routeurs ont acquis et échangé des informations de tableau d'acheminement en utilisant un protocole simple de diffusion.
Lors de l'introduction du protocole Internet, la décision a été prise d'utiliser un numéro de sous-réseau d'une longueur de huit bits ; les numéros Internet de sous-réseau ont été choisis de façon à correspondre au numéro de réseau Pup d'un Ethernet donné, et les numéros d'hôte Pup (aussi de huit bits) ont été utilisés comme champ hôte de l'adresse Internet.
Les routeurs Pup seul ont alors été modifiés pour transmettre les datagrammes Internet conformément à leur tableaux d'acheminement Pup ; ils n'avaient autrement aucune possibilité de comprendre les paquets Internet et en fait ne mettaient pas à jour le champ Durée de vie (TTL) dans l'en-tête Internet. Cela semble acceptable, car les bogues qui causent des transmission en boucle ne sont pas apparues. Les hôtes Internet qui ont des rattachements multiples et peuvent donc servir de routeurs ajustent effectivement le champ Durée de vie ; comme tous ceux là servent aussi de routeur Pup, aucun protocole d'échange d'informations d'acheminement supplémentaire n'était nécessaire.
Les mises en œuvre d'hôte Internet ont été modifiées pour qu'elles comprennent les sous-réseaux (de plusieurs façons différentes, mais avec des effets identiques). Comme tous avaient déjà des mises en œuvre Pup, les tableaux d'acheminement Internet ont été entretenus par le même processus qui entretenait les tableaux d'acheminement Pup, en traduisant simplement les numéros de réseau Pup en numéros de sous-réseau Internet
Lorsque les Ethernets à 10Mbit ont été ajoutés, les routeurs ont été modifiés pour utiliser le schéma fondé sur ARP décrit à la section précédente ; cela permettait d'utiliser des hôtes sans modification sur les Ethernets à 10 Mbit.
Les sous-réseaux IP ont été utilisés depuis 1982 ; actuellement, il y a environ 330 hôtes, 18 sous-réseaux, et un nombre similaire de routeurs de sous-réseau en service. Une fois que les routeurs seulement Pup seront convertis en vrais routeurs Internet, un protocole d'échange d'informations d'acheminement fondé sur Internet sera introduit, et Pup sera éliminé.
Le MIT a été le premier site IP à accumuler une grande collection de liaisons de réseau local. Comme cela est arrivé avant que les numéros de réseau soient divisés en classes, l'allocation à chaque liaison du MIT de son propre numéro de réseau IP aurait utilisé une portion notable de l'espace d'adresse disponible. Le MIT a décidé d'utiliser un numéro de réseau IP, et de gérer le reste de 24 bits du champ lui-même, en le divisant en trois champs de huit bits ; "sous-réseau", "réservé, doit être zéro", et "hôte". Comme le protocole CHAOS déjà utilisé au MIT utilisait un champ de numéro de sous-réseau de huit bits, il était possible d'allouer à chaque liaison le même numéro de sous-réseau dans les deux protocoles. Le champ hôte IP était établi à 8 bits car la plupart des matériels de réseau local disponibles à ce moment utilisait des adresses de 8 bits, comme le faisait le protocole CHAOS ; il a été estimé sage de réserver quelques bits pour l'avenir.
Le plan initial était d'utiliser un protocole d'acheminement dynamique entre les routeurs de sous-réseau IP ; plusieurs de ces protocoles ont été remis en scène mais personne ne s'est soucié d'en mettre un en œuvre ; les tableaux d'acheminement statiques sont toujours utilisés. Il est vraisemblable que ce changement va finalement intervenir bientôt.
Pour résoudre le problème des logiciels IP importés qui ont toujours besoin d'être modifiés pour fonctionnes dans un environnement de sous-réseaux, le MIT a cherché un modèle de fonctionnement conduisant au minimum de changement de logiciel IP d'hôte. Cela a conduit à un modèle dans lequel les routeurs IP envoient des messages ICMP "Host Redirect" plutôt que des "Network Redirect". Tous les routeurs IP internes au MIT font maintenant ainsi. Avec des hôtes qui peuvent entretenir les tableaux d'acheminement IP pour les communications non locales hôte par hôte, cela cache la plus grande partie de la structure de sous-réseau. L'"ajustement minimum" pour qu'un logiciel d'hôte fonctionne correctement aussi bien dans un environnement avec ou sans sous-réseaux est l'algorithme de gabarit binaire mentionné précédemment.
Le MIT n'a pas de plans immédiats pour passer à un seul protocole "approuvé" ; cela est partiellement dû au degré d'autonomie locale et à la quantité de logiciels installés, et en partie au manque d'un seul standard industriel prééminent. L'approche retenue a été plutôt de fournir un seul ensemble de liaisons physiques et de commutateurs de paquets, et de mettre en couches plusieurs réseaux de protocoles "virtuels" par dessus l'ensemble unique de liaisons. Le MIT avait eu quelques mauvaises expériences en essayant d'échanger des informations d'acheminement entre des protocoles et en enveloppant un protocole dans un autre ; l'approche générale est de garder les protocoles strictement séparés sauf pour le partage du matériel de base. Utiliser ARP pour cacher la structure de sous-réseau n'est pas très bien vu ; on pense que cela surcharge l'opération de résolution d'adresse. Dans un système compliqué (c'est-à-dire, un système avec des boucles, et des vitesses de liaisons différentes), un échange d'informations plus sophistiqué sera nécessaire entre les routeurs ; ce qui fait qu'il a été estimé préférable d'avoir un mécanisme explicite (mais isolé des hôtes).
4.3 Université Carnegie-Mellon
CMU utilise un réseau de classe B actuellement divisé en onze sous-réseaux physiques (deux Ethernets expérimentaux à 3 Mbits, sept Ethernets à 10 Mbits, et deux anneaux ProNet.) Bien que les numéros d'hôte soient alloués de telle sorte que toutes les adresses avec un troisième octet donné soient sur le même sous-réseau (mais pas nécessairement vice versa), c'est essentiellement une facilité administrative. Aucun logiciel ne sait actuellement les spécificités de ce mécanisme d'allocation ni ne dépend de lui pour l'acheminement entre les câbles.
On utilise plutôt un schéma de pont fondé sur ARP. Lorsque un hôte diffuse une demande ARP, tous les ponts qui le reçoivent mettent en antémémoire la transposition d'adresse de protocole originale puis transmettent la demande (après les ajustements appropriés) comme une demande de diffusion ARP sur chacun des autres câbles qui leur sont connectés. Lorsque un pont reçoit une réponse ARP non diffusée avec une adresse de protocole cible qui n'est pas la sienne propre, il consulte son antémémoire ARP pour déterminer le câble sur lequel la réponse devrait être transmise. Les ponts essayent donc d'étendre de façon transparente le protocole ARP dans un environnement multicâble hétérogène. Ils leur est donc demandé de transformer des diffusions ARP sur un seul câble en diffusions ARP sur tous les autres câbles connectés même si ils "savent mieux". Cet algorithme ne fonctionne qu'en l'absence de cycles dans le graphe de la connexité du réseau (ce qui est actuellement le cas). On travaille actuellement à remplacer cet algorithme simpliste par un protocole mis en œuvre parmi les ponts, pour prendre en charge les chemins redondants et réduire la charge des diffusions collectives. L'intention est de garder la base ARP et la transparence des hôtes, si possible.
Les mises en œuvre qui prennent en charge l'Ethernet à 3 Mbits et l'anneau proNET à 10 Mbits à CMU utilisent l'ARP de la RFC-826 (au lieu d'une transposition incorporée comme d'utiliser simplement l'adresse matérielle de 8 bits comme quatrième octet de l'adresse IP).
Comme il n'y a actuellement pas de chemins redondants entre les câbles, le problème du maintien des connexions lors des défaillances de ponts est controversé. Avec environ 150 hôtes à capacité IP sur le réseau, les antémémoires de ponts sont encore d'une taille raisonnable, et peu de bande passante est consacrée à la transmission des diffusions ARP.
Le réseau de CMU va vraisemblablement croître de sa configuration relativement petite à connexion unique centrée sur les locaux du CS/RI vers une configuration intra départementale à l'échelle du campus avec 5000 à 10000 hôtes et des connexions redondantes entre les câbles. Il est possible que le schéma de pont fondé sur ARP ne puisse pas s'adapter à cette taille, et un système de sous-réseaux explicite pourrait être nécessaire. Le but à moyen terme est cependant un environnement dans lequel des mises en œuvre IP existantes non modifiées (en particulier fondées sur l'Ethernet à 10 Mbits) peuvent être importées ; l'intention est de rester avec un mécanisme d'acheminement transparent aux hôtes (et donc fondé sur ARP) aussi longtemps que possible. CMU est préoccupé par le fait que même si les sous-réseaux font partie de la norme IP, ils ne seront pas largement mis en œuvre ; c'est l'obstacle majeur à leur utilisation à CMU.
Annexe I. Format d'adresse ICMP
Demande de format d'adresse ou réponse de format d'adresse
0 |
1 |
2 |
3 |
||||||||||||||||||||||||||||
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
0 |
1 |
Type |
Code |
Somme de contrôle |
|||||||||||||||||||||||||||||
Identifiant |
Numéro de séquence |
||||||||||||||||||||||||||||||
Champs IP :
Adresses
Champs ICMP :
Type
Code
Somme de contrôle
La somme de contrôle est le complément à un sur 16 bits de la somme des compléments à un du message ICMP commençant par le Type ICMP. Pour calculer la somme de contrôle, le champ somme de contrôle devrait être pris pour zéro. Ce calcul de somme de contrôle pourrait être modifié à l'avenir.
Identifiant
L'identifiant sert à faire correspondre demandes et réponses, il peut être à zéro.
Numéro de séquence
Un numéro de séquence sert à faire correspondre demandes et réponses, il peut être à zéro.
Description
Un routeur qui reçoit une demande de format d'adresse devrait la retourner avec le champ Code réglé au nombre de bits du numéro de sous-réseau dans les adresses IP pour le réseau auquel le datagramme était adressé. Si la demande était une diffusion, le réseau de destination est "ce réseau". La longueur du champ de sous-réseau peut aller de 0 à (31 - N), où N est la longueur en bits du champ de numéro de réseau IP (c'est-à-dire, 8, 16, ou 24).
Si l'hôte demandeur ne connaît pas sa propre adresse IP, il peut laisser le champ de source à zéro ; la réponse devrait alors être diffusée. Comme il n'y a qu'un seul format d'adresse possible pour un réseau, il n'est pas nécessaire de faire correspondre les demandes avec les réponses. Cependant, cette approche devrait être évitée si possible, car elle augmente la charge des diffusions superflues sur le réseau.
Le type A1 peut être reçu d'un routeur ou d'un hôte.
Le type A2 peut être reçu d'un routeur, ou d'un hôte agissant en qualité de routeur.
Pour ces exemples, on suppose que l'hôte demandeur a l'adresse 36.40.0.123, qu'il y a un routeur à 36.40.0.62, et que sur le réseau 36.0.0.0, un champ de sous-réseau d'une longueur de 8 bits est utilisé.
Supposons d'abord que la diffusion est permise, et que 36.40.0.123 connaît sa propre adresse. Il envoie le datagramme suivant :
Adresse de source : 36.40.0.123
Adresse de destination : 36.255.255.255
Protocole : ICMP = 1
Type : Demande de format d'adresse = A1
Code : 0
36.40.0.62 va entendre le datagramme, et devrait répondre par le datagramme suivant :
Adresse de source : 36.40.0.62
Adresse de destination : 36.40.0.123
Protocole : ICMP = 1
Type : Réponse de format d'adresse = A2
Code : 8
Pour les exemples suivants, supposons que l'adresse 255.255.255.255 note "diffusion vers ce réseau physique", comme décrit en [6].
L'exemple précédent est inefficace, parce qu'il peut éventuellement diffuser la demande sur de nombreux sous-réseaux. La méthode la plus efficace, que nous recommandons, est qu'un hôte découvre d'abord sa propre adresse (par exemple à l'aide du protocole "ARP inverse" décrit en [4]), puis d'envoyer la demande ICMP à 255.255.255.255 :
Adresse de source : 36.40.0.123
Adresse de destination : 255.255.255.255
Protocole : ICMP = 1
Type : Demande de format d'adresse = A1
Code : ²0
Le routeur peut alors répondre directement à l'hôte demandeur.
Supposons que 36.40.0.123 est une station de travail sans disque, qui ne connaît même pas son propre numéro d'hôte. Elle devrait envoyer le datagramme suivant :
Adresse de source : 0.0.0.0
Adresse de destination : 255.255.255.255
Protocole : ICMP = 1
Type : Demande de format d'adresse = A1
Code : 0
36.40.0.62 va entendre le datagramme, et devrait répondre par le datagramme suivant :
Adresse de source : 36.40.0.62
Adresse de destination : 36.40.255.255
Protocole : ICMP = 1
Type : Réponse de format d'adresse = A2
Code : 8
Noter que le routeur utilise la plus étroite diffusion possible pour répondre (c'est-à-dire qu'envoyer la réponse à 36.255.255.255 signifierait qu'elle est transmise sur de nombreux sous-réseaux, et non juste celui sur lequel elle est nécessaire). Même ainsi, la surutilisation de la diffusion représente une charge inutile pour tous les hôtes sur le sous-réseau, aussi recommandons nous que l'utilisation de l'adresse de source "anonyme" (0.0.0.0) reste à un minimum.
Si la diffusion n'est pas admise, on suppose que les hôtes ont des informations incorporées sur les routeurs du voisinage ; et donc, 36.40.0.123 devrait envoyer le datagramme suivant :
Adresse de source : 36.40.0.123
Adresse de destination : 36.40.0.62
Protocole : ICMP = 1
Type : Demande de format d'adresse = A1
Code : 0
36.40.0.62 devrait répondre exactement comme dans le cas précédent.
Références
[1] R. Boggs, J.F. Shoch, E.A. Taft, and R.M. Metcalfe. "Pup: An Internetwork Architecture." IEEE Transactions on Communications COM-28, 4, pp612-624, avril 1980.
[2] D. Clark, "Noms, adresses, accès et chemins", RFC 814, juillet 1982.
[3] Yogan K. Dalal and Robert M. Metcalfe. "Reverse Path Forwarding of Broadcast Packets." Comm. ACM 21, 12, pages 1040-1048, décembre 1978.
[4] R. Finlayson, T. Mann, J. Mogul et M. Theimer, "Protocole de résolution inverse d'adresse", RFC 903, STD 38, juin 1984.
[5] R.M. Metcalfe and D.R. Boggs. "Ethernet: Distributed Packet Switching for Local Computer Networks." Comm. ACM 19, 7, pages 395-404, juillet 1976. Aussi CSL-75-7, Xerox Palo Alto Research Center, republiée comme CSL-80-2.
[6] Jeffrey Mogul. "Diffusion des datagrammes Internet". RFC-919, Stanford University, octobre 1984.
[7] David Plummer. "Protocole de résolution d’adresses Ethernet : conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour transmission sur un matériel Ethernet", STD 37, RFC-826, septembre 1982.
[8] Jon Postel, éd., "Protocole Internet - Spécification du protocole du programme Internet DARPA", septembre 1981. RFC-791, STD 5.
[9] Jon Postel. "Protocole du message de contrôle Internet – Spécification du protocole du programme Internet DARPA", RFC-792, STD 5, septembre 1981.