RFC936 Autre schéma d’adressage de sous-réseau Karels

Groupe de travail Réseau

Michael J. Karels

Request for Comments : 936

UC Berkeley

Traduction Claude Brière de L’Isle

février 1985



Autre schéma d’adressage de sous-réseau 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 à sa discussion et à des suggestions pour son amélioration. La distribution du présent mémoire n’est soumise à aucune restriction.


Introduction


Il y a eu plusieurs propositions de schémas pour permettre l’utilisation d’un seul numéro de réseau Internet pour se référer à une collection de réseaux physiques sous administration commune qui sont joignables à partir du reste de l’Internet par un chemin commun. De tels schémas permettent une vue simplifiée d’une topologie par ailleurs compliquée à partir des hôtes et des routeurs en-dehors de cette collection. Ils permettent de localiser la complexité du nombre et du type de ces réseaux, et de l’acheminement vers eux. Les ajouts et changements des configurations ne causent donc pas de changement détectable, et aucune interruption de service, du fait de la lente propagation des informations d’acheminement et autres en dehors de l’environnement local. Ces schémas simplifient aussi l’administration du réseau, car les changements n’exigent pas l’allocation de nouveaux numéros de réseau pour chaque nouveau câble installé. Le motif des sous-réseaux explicites ou implicites, plusieurs des solutions de remplacement, et les descriptions des mises en œuvre existantes de ce type ont été données en détail [1], [2]. La présente proposition discute d’un autre schéma, qui est utilisé à l’Université de Californie, à Berkeley depuis avril 1984.


Adressage de sous-réseau à Berkeley


Comme pour la proposition de Jeff Mogul dans la RFC-917, l’adressage du sous-réseau Berkeley utilise un codage de la partie hôte de l’adresse Internet. Les hôtes et les routeurs sur le réseau local sont capables de déterminer le numéro de sous réseau à partir de chaque adresse locale, et ensuite d’acheminer les paquets locaux sur la base du numéro de sous-réseau. Logiquement, la collection de sous-réseaux apparaît aux sites externes comme étant un seul réseau homogène. En interne, chaque sous-réseau se distingue cependant des autres et des autres réseaux, et les décisions d’acheminement internes se fondent sur le numéro de sous-réseau plutôt que sur le numéro de réseau.


Le codage des adresses de sous-réseau est similaire à celui proposé dans la RFC-917. En décomposant une adresse Internet en partie réseau et partie hôte, l’algorithme est modifié si le réseau est "local", c’est-à-dire, si le réseau est directement connecté sous contrôle administratif local. (Un réseau est marqué comme local ou non local au moment où l’adresse de l’interface de chaque réseau est établie à l’amorçage.) Pour les adresses locales, la partie hôte est examinée à la recherche d’un numéro de sous-réseau. Les adresses locales peuvent être sur le réseau principal, ou sur un sous-réseau. Le bit de poids fort du numéro de l’hôte est utilisé pour distinguer entre les sous-réseaux et le réseau principal. Si le bit de poids fort est établi dans le champ Hôte, le reste de l’octet de poids fort de la partie hôte est pris comme étant le numéro de sous-réseau. Si le bit de poids fort est à zéro, l’adresse est alors interprétée de façon normale. Pour les réseaux de classe A, en utilisant des champs de sous-réseau de 8 bits, cela permet un réseau avec jusqu’à 127 sous-réseaux, ayant chacun un maximum de 65 535 hôtes, et un réseau principal avec 2^23 hôtes. Les réseaux de classe B peuvent comporter 127 sous-réseaux, ayant chacun jusqu’à 255 hôtes, et 32 767 hôtes sur le réseau principal. Les réseaux de classe C ne sont pas actuellement inclus dans ce schéma. Ils pourraient être raisonnablement ajoutés, en utilisant quatre bits de la partie hôte pour désigner les sous-réseaux et quatre bits pour l’hôte, permettant 8 sous-réseaux de 15 hôtes et 126 hôtes sur le réseau principal.


La mise en œuvre actuelle n’utilise pas les numéros de sous-réseau séparément du champ de réseau, mais traite plutôt le champ de sous-réseau comme une extension du champ de réseau. Les fonctions qui retournaient précédemment le numéro de réseau à partir d’une adresse retournent maintenant un numéro de réseau ou de réseau/sous-réseau. De façon appropriée, les sous-réseaux de classe A sont distinguables des réseaux de classe B, bien que chacun soit une quantité de 16 bits, et les sous-réseaux de classe B sont disjoints des numéros de réseau de classe C. Le résultat net est que les sous-réseaux apparaissent comme des réseaux séparés, indépendants avec leurs propres entrées d’acheminement au sein du réseau, mais en-dehors du réseau, ils sont invisibles. Il n’y a actuellement aucune facilité à Berkeley pour la diffusion sur le réseau logique ; la diffusion peut être faite sur chaque sous-réseau qui utilise un matériel capable de diffusion.



Discussion


Plusieurs méthodes ont été proposées antérieurement pour permettre que plusieurs réseaux physiques partagent une désignation de réseau Internet, et pour fournir un acheminement au sein de ce réseau logique. La RFC-917 propose un moyen pour coder la partie hôte de chaque adresse locale de telle sorte que les hôtes, ou les routeurs qui les connectent, soient capables de déterminer le réseau physique pour l’hôte. La proposition actuelle est très similaire à ce schéma ; les différences sont exposée en détail ci-dessous.


Une autre proposition (RFC-925) implique l’utilisation de routeurs intelligents pour effectuer l’acheminement pour des hôtes non modifiés, en utilisant un protocole de résolution d’adresse (ARP, Address Resolution Protocol) [2]. Cela présente l’avantage de placer toutes les modifications dans les routeurs, mais va vraisemblablement exiger des protocoles d’acheminement supplémentaires et des mécanismes de mise en antémémoire dans les routeurs afin d’éviter des diffusions excessives pour la résolution d’adresse. Une modification de cette méthode est d’effectuer le codage des sous-réseaux au sein des adresses d’hôtes par convention pour simplifier l’acheminement chez les routeurs, sans modifier le logiciel des hôtes pour reconnaître des adresses de sous-réseau. Ces techniques n’ont pas été prises en compte pour une utilisation à Berkeley, parce que toute la transmission de paquet est faite par des hôtes multi rattachement, qui fonctionnent tous sur le même logiciel que les hôtes mono rattachement (Unix 4.2BSD).


La proposition la plus récente, la RFC-932 [3], assure le sous-réseautage en codant la partie réseau de l’adresse Internet plutôt que la partie hôte. Les hôtes ordinaires n’ont pas besoin de connaître cette convention, ce qui élimine le besoin de modification du logiciel d’hôte. Les routeurs seraient capables de tirer parti de ce codage pour compresser les informations d’acheminement pour la collection de réseaux en une seule entrée. Malheureusement, la mise en œuvre de ce schéma exigerait une transition très bien concertée par les routeurs de l’Internet, ou la période de transition submergerait vraisemblablement les tableaux d’acheminement dans les routeurs existants. Tous les hôtes sur les plus grands réseaux seraient forcés de changer les adresses de leurs adresses actuelles de classe A ou B en adresses "B 1/2". Il y a un nombre limité (4096) de blocs d’adresses de classe C disponibles en utilisant ce codage. Le nombre d’universités et autres organisations qui ont déjà mis en œuvre des sous-réseau ou qui envisagent leur installation plaide en faveur d’un schéma plus extensible, ainsi que capable d’être mis en œuvre plus rapidement.


La proposition actuelle est très similaire à celle de la RFC-917 ; bien sûr, les deux mises en œuvre sont presque compatibles. Il y a deux différences significatives. D’abord, l’utilisation d’un bit pour distinguer les adresses de sous-réseau des adresses qui ne sont pas dans un sous-réseau permet à la fois de plus petits sous-réseaux et un réseau principal (physique ou logique) plus grand. La moitié des adresses d’hôte au sein d’un réseau de classe A ou B sont réservées pour être utilisées dans les sous-réseaux, l’autre moitié est disponible pour le réseau principal. Cela peut se révéler utile lorsque on utilise un matériel moyen qui est capable de prendre en charge un grand nombre d’hôtes ou pour une mise en sous-réseau transparente (par exemple, en utilisant des ponts fondés sur ARP). L’inconvénient correspondant est que moins de sous-réseaux peuvent être pris en charge. L’allocation de bits entre le numéro de sous-réseau et le champ d’hôte pourrait être ajustée, mais pour les réseaux de classe B, aucun des deux n’est excessivement large. Étant donné l’espace d’adresses limité de l’adressage Internet actuel, c’est un choix difficile.


La seconde différence est que la largeur du champ de sous-réseau est fixée à l’avance. Cela simplifie le code déjà trop compliqué pour interpréter les adresses Internet, et évite le problème de l’amorçage. Si la largeur du champ de sous-réseau doit être déterminée de façon dynamique, une certaine fraction des hôtes d’un réseau doit être prête à spécifier cette valeur, et la situation sera inextricable si un de ces hôtes ne fait pas le choix correct ou si aucun n’est accessible lorsque les autres machines s’activent. De plus, la procédure de récupération proposée par la RFC-917 semble inutilement compliquée et encline à l’échec. La découverte dynamique de cette valeur dépend aussi d’une autre modification, l’ajout d’une nouvelle demande ICMP. Les solutions de remplacement sont de spécifier une taille de champ standard, ou d’exiger de chaque mise en œuvre qu’elle soit configurable à l’avance (par exemple, avec une option de compilation système ou l’utilisation d’un correctif système installé lors de l’initialisation d’un hôte. L’utilisation d’une largeur de champ standard semble préférable, et un champ de 8 bits permet les mises en œuvre les plus efficaces sur la plupart des architectures. Pour les réseaux de classe C, un champ de 4 bits semble le seul choix pour une division standard.


Références


[1] [RFC0917] J. Mogul, "Sous-réseaux Internet", octobre 1984.


[2] [RFC0925] J. Postel, "Résolution d'adresse dans les multi-LAN", octobre 1984.


[3] [RFC0932] D. Clark, "Schéma d'adressage de sous-réseau", janvier 1985.

page - 2 -