Puis-je créer un réseau Ethernet sans utiliser IP

Si je comprends bien du modèle ISO-OSI, les adresses MAC fonctionnent sur une couche différente de celle des adresses IP. C'est clair pour moi.

Je peux accepter qu'Ethernet (LAN) n'utilise tout simplement pas les adresses IP pour communiquer, mais utilise des adresses MAC. Je comprends que ces adresses MAC ne peuvent pas être utilisées pour le routage en dehors d'un LAN, car elles ne sont pas définies hiérarchiquement. Je comprends également que l'IP est le meilleur moyen de faire du routage sur le grand Internet. Ce dont je ne suis pas entièrement convaincu, c'est que les adresses MAC sont le meilleur moyen de communiquer sur un LAN

Mes questions sont les suivantes:

1. Ethernet ne peut-il pas utiliser les adresses IP pour envoyer des messages? Je ne dis pas que cela devrait, je demande simplement s'il aurait pu choisir de le faire.
2. Comme Ethernet utilise des adresses MAC pour la communication, pourrais-je créer un réseau Ethernet où les appareils n'auraient pas d'adresse IP, juste une adresse MAC?

Ethernet aurait-il pu utiliser des adresses IP au lieu de ses propres adresses de couche liaison de données? Certainement pas, s'il voulait être agnostique quant au protocole de couche 3 qu'il utilisait.

Nous concevons des protocoles de mise en réseau en couches afin de pouvoir mélanger et assortir les couches.

Ethernet a été initialement développé par Bob Metcalfe et alia chez Xerox PARC pour être indépendant de la couche réseau, car leur objectif n'était pas seulement l'accès TCP / IP mais également la propre pile / suite de protocoles réseau XNS propriétaire de Xerox.

DEC (Digital Equipment Corporation) est devenu un autre premier adopteur, l'utilisant principalement pour leur pile / suite de protocoles DECnet.

À la fin des années 80 et au début des années 90, il y avait beaucoup de suites de protocoles LAN concurrentes (toutes complètement indépendantes de TCP / IP) fonctionnant sur des réseaux locaux Ethernet d'entreprise. Outre XNS et DECnet, il y avait AppleTalk d'Apple (EtherTalk), IPX de Novell, Banyan VINES, NetBEUI, DLC / LLC, IBM SNA, OSI / ISO et d'autres que j'ai oubliés.

Donc, oui, vous pouvez utiliser Ethernet sans IP. Beaucoup de réseaux d'entreprise l'ont fait dans les années 80 et 90.

Parce qu'Ethernet a été conçu pour ne pas se soucier du protocole Layer-3 (couche réseau) qui y est exécuté, il était relativement facile pour ces réseaux d'entreprise de prendre en charge des mélanges d'équipements de divers fournisseurs, et il était relativement facile pour ces réseaux d'ajouter IPv4 prise en charge lorsque l'Internet a décollé entre le milieu et la fin des années 90, et il nous a été relativement facile d'ajouter la prise en charge IPv6 maintenant.

Comme Ethernet utilise des adresses MAC pour la communication, pourrais-je créer un réseau Ethernet où les appareils n'auraient pas d'adresse IP, juste une adresse MAC?

Si vous écriviez tous vos propres logiciels à partir de zéro, vous pourriez certainement le faire. Demandez simplement au logiciel d'accepter une adresse MAC n'importe où que l'homologue normal de ce programme aurait accepté une adresse IP. Utilisez tous les appels système pour envoyer des paquets Ethernet bruts plutôt que l'adresse IP et cela fonctionnera - mais ce serait un énorme problème.

Généralement, les adresses MAC sur votre réseau ne suivent aucun modèle. Ils sont gravés dans le matériel par le fabricant. Ils sont longs et volumineux. Le mien en ce moment est le C8-60-00-CA-4B-9A. L'ordinateur à côté de moi est 00-40-F4-48-1B-88.

Pour que les machines puissent vous parler, vous pouvez donner à chaque machine une liste codée en dur de toutes les adresses MAC de toutes les autres machines du réseau afin qu'elle sache où envoyer des paquets. C'est beaucoup de fautes de frappe, et chaque fois que vous changez votre matériel réseau, vous devez faire le tour et modifier toutes les listes pour refléter les nouvelles adresses MAC.

C'est un énorme problème, donc vous finirez probablement par trouver un moyen pour les machines du réseau de découvrir automatiquement les adresses MAC des autres à l'aide de paquets de diffusion. Ensuite, vous leur donneriez un moyen de s'identifier avec une adresse significative afin que vous deviez taper des commandes comme "telnet C8-60-00-CA-4B-9A".

Il s'avère que c'est exactement ce que fait IP - c'est un moyen d'utiliser des nombres significatifs pour adresser les hôtes sur un réseau plutôt que de coder en dur les adresses MAC. Ajoutez DNS sur IP et vous pouvez taper une commande comme "telnet webserver".

Ethernet ne peut-il pas utiliser les adresses IP pour envoyer des messages? Je ne dis pas que cela devrait, je demande simplement s'il aurait pu choisir de le faire.

Les adresses MAC sont de 6 octets d'informations et les adresses IP ne sont que de 4 octets, vous ne pouvez donc pas faire de mappage 1 à 1. Vous avez besoin d'un moyen de trouver l'adresse MAC (à mettre dans le paquet) à partir d'une adresse IP (fournie par le logiciel qui veut communiquer avec un autre hôte sur le réseau).

Une façon (noyau dur) de le faire serait d'aller dans chaque machine du réseau et de changer son adresse MAC matérielle pour ressembler à une adresse IP en faisant les deux premiers octets des zéros (ou un autre nombre fixe qui est le même pour chaque machine sur le réseau) et définissez les quatre derniers octets sur "l'adresse IP" que vous souhaitez qu'ils aient sur le réseau. (La plupart des cartes réseau vous permettent d'entrer et de modifier l'adresse MAC attribuée par le fournisseur)

Pour que cela fonctionne réellement, vous devez également pirater le code de votre pile réseau pour utiliser ce système. Vous arracheriez essentiellement tout ce qui a à voir avec ARP (la méthode utilisée par IP pour traduire les adresses IP en adresse MAC). Vous arracheriez les parties qui construisent / lisent les en-têtes IP. Au lieu de cela, vous remplaceriez le tout par le code très simple qui, étant donné un paquet IP à envoyer à l'hôte à l'adresse wxyz, créerait une trame Ethernet avec l'adresse DEST définie sur 00-00-wxyz.

Vous auriez également besoin d'un moyen d'indiquer au récepteur d'un paquet à quel protocole (UDP, TCP) il est destiné. Vous pourriez probablement coller cela quelque part dans l'en-tête Ethernet en remplaçant un champ existant. Peut-être utiliser l'un des deux premiers octets de l'adresse source? Cela n'affecterait pas la capacité des machines de destination à recevoir, mais pourrait gâcher certains commutateurs. Vous pouvez également ajouter le protocole au début ou à la fin de la trame Ethernet et augmenter la taille de la charge utile d'une unité, mais cela commence à sentir comme un en-tête IP.

Alors, que vous apporterait tout ce travail?

Tout d'abord, cela vous éviterait les frais généraux d'une recherche dans la table ARP sur chaque paquet sortant. C'est probablement de l'ordre de quelques microsecondes seulement.

Vous économisez le travail de calcul des sommes de contrôle d'en-tête IP et la mémoire nécessaire pour les contenir. Ce n'est probablement pas significatif sur le matériel moderne.

Vous enregistrez 16 octets dans chaque paquet sur le réseau car il n'y aurait pas d'en-têtes IP. Cela pourrait s'additionner en fonction de l'application.

Le plus gros gain serait que vous n'auriez pas à faire de requêtes ARP. L'envoi d'un paquet IP standard à un nouvel hôte déclenche un échange ARP qui peut prendre des millisecondes et est imprévisible. Cela peut être un gain énorme pour certaines applications très sensibles à la latence et à la gigue.

Pour certaines applications très spécialisées, cela a du sens. Une fois, j'ai travaillé sur un système en temps réel qui n'utilisait que des paquets UDP diffusés pour toutes les communications interhôtes, pour la seule raison qu'il évitait le déclenchement de ces séquences ARP et ajoutait de manière imprévisible du retard et de la gigue. J'ai également travaillé sur un système embarqué à ressources limitées qui fonctionnait en envoyant directement des charges utiles UDP à l'intérieur de paquets IP (pas d'en-tête IP), car il économisait toute la complexité et la mémoire nécessaires pour implémenter tout l'ARP et le masque de réseau et des trucs de sommes de contrôle supplémentaires.

Ethernet ne peut-il pas utiliser les adresses IP pour envoyer des messages? Je ne dis pas que ça devrait, je demande juste si elle aurait pu choisir de le faire

Je suppose qu'Ethernet aurait pu utiliser des adresses à quatre octets comme IPv4 au lieu d'adresses à six octets. C'est probablement bien qu'ils ne l'ont pas fait, car ils étaient à court de chiffres, je parierais.

Comme Ethernet utilise des adresses MAC pour la communication, pourrais-je créer un réseau Ethernet où les appareils n'auraient pas d'adresse IP, juste une adresse MAC?

Vous pouvez, si vous avez des programmes qui fonctionneront avec des adresses MAC au lieu d'adresses IP. Bien sûr, vous serez coincé sur ce réseau et ne pourrez pas atteindre les autres sans un certain piratage.

Vous n'avez vraiment besoin de la couche IP que si vous prévoyez de faire du routage, en particulier si un autre réseau peut utiliser une technologie de couche 2 différente d'Ethernet, comme Token Ring, ce qui était une possibilité réelle lorsque la plupart de ces éléments ont été développés. Qui sait si une autre technologie de couche 2 pourrait devenir omniprésente à l'avenir, si c'est le cas, l'IP en est indépendante.

> Couldn't Ethernet make use of IP addresses to send messages? I'm not
> saying it should, I'm just asking if it could have chosen to do so.

Si vous faites référence à Ethernet en tant que couche réseau, alors non, cela ne peut pas. La couche réseau nécessite l'adresse physique du périphérique réseau. Une adresse IP est un nombre arbitraire qui est attribué à une adresse MAC pour des raisons de simplicité. Les adresses IP sont une solution logicielle, pas une partie de la carte réseau - la solution matérielle. C'est pourquoi les adresses IP peuvent être facilement modifiées, tandis que les adresses MAC sont codées en dur sur la carte et ne peuvent pas être modifiées (nonobstant le logiciel d'usurpation d'adresse MAC, qui ne modifie toujours pas l'adresse au point de reposer sur son adresse) )

> As Ethernet uses MAC addresses for communication, could I create an
> Ethernet network where devices would not have an IP address, just a
> MAC address?

Oui, vous pourriez, mais vous n'aimeriez pas l'utiliser, car la fonctionnalité serait très limitée et pas conviviale du tout. Il y a une raison pour laquelle la couche transport a été implémentée.

Depuis WikiPedia , la couche transport contrôle la fiabilité d'une liaison donnée grâce au contrôle de flux, à la segmentation / déségrégation et au contrôle d'erreur. Certains protocoles sont orientés état et connexion. Cela signifie que la couche de transport peut suivre les segments et retransmettre ceux qui échouent. La couche de transport fournit également l'accusé de réception de la transmission de données réussie et envoie les données suivantes si aucune erreur ne s'est produite.

Ainsi, sans utiliser la couche Transport, qui signifie de nos jours le protocole TCP / IP, vous n'auriez pas la possibilité de garantir que vos données ont atteint leur destination, ni la possibilité de réinitialiser automatiquement les éléments manquants.

Il est certainement possible pour les machines d'un réseau local de communiquer sans couche de routage. Vous venez d'intégrer le message dans une trame Ethernet et espérez le meilleur. C'est un peu comme mettre une note sur une carte postale et espérer que le bureau de poste fera son travail.

Vous devez espérer que le récepteur écoute et écouter attentivement un message de réponse (potentiellement parmi beaucoup d'autres messages d'autres nœuds). Vous serez responsable de trier tous ces messages vous-même.

Si vous voulez des choses comme la messagerie 1: 1, vous aurez besoin d'un autre protocole au-dessus des trames Ethernet pour gérer toute cette écoute pour vous. Le protocole point à point (PPP) est souvent utilisé pour cela, sur Ethernet, il est connu comme PPPoE. PPPoE vous offre l'authentification et le cryptage, deux très bonnes idées sur un réseau de diffusion.

Mais sans une certaine forme d'informations de routage, vous ne pouvez communiquer qu'avec les nœuds du réseau local. Dès que vous commencez à utiliser des informations de routage pour relayer des messages (par exemple vers Internet), vous voulez une certaine forme de protocole de routage, comme IP ou IPX. Et vous voudrez probablement aussi le contrôle de transmission (TCP) ...

Les réseaux IP sont une abstraction, une couche d'indirection, c'est-à-dire qu'ils sont un réseau virtuel - non lié en permanence à une méthode ou un appareil de communication physique particulier.

Un hôte Ethernet possède une adresse MAC (par carte réseau) qui l'identifie de manière unique à l'échelle mondiale. Cependant, cet hôte pourrait appartenir simultanément à de nombreux réseaux IP, avec une adresse IP différente pour chacun, tout en utilisant toujours la même adresse MAC.

Cette séparation de l'adressage physique et logique, ou virtualisation de l'adressage, permet une certaine flexibilité, comme le déplacement d'un hôte IP (par exemple un serveur) d'une machine physique à une autre, avec une adresse MAC différente, mais sans nécessiter une reconfiguration d'autres hôtes (par exemple, logiciel client).

IP, ou le protocole Internet et Ethernet résolvent différents problèmes: Ethernet assure la communication au niveau du LAN et uniquement sur un seul LAN, peu importe à quels autres réseaux le LAN peut être connecté via un routeur. Alors que l'IP s'intéresse à l' interconnexion de réseaux et est donc indépendante du LAN. Alors, Ethernet aurait-il pu utiliser des adresses IP au lieu des adresses MAC? Bien sûr, mais cela ne vous rapporte vraiment rien puisque ces messages seraient toujours limités au LAN.

En réponse à votre deuxième question, ce type de situation existe à différents moments sur un réseau local Ethernet qui utilise le protocole DHCP (Dynamic Host Configuration Protocol) pour l'allocation d'adresses IP. Lorsqu'un nouvel hôte se connecte au LAN, il n'a pas d'adresse IP, il envoie donc une trame Ethernet diffusée à tous les appareils et attend une réponse d'un serveur DHCP. À ce stade, le client ne connaît ni l'adresse MAC du serveur DHCP ni son adresse IP, d'où la diffusion. À la réception de la demande, le serveur connaît désormais l'adresse MAC du client et peut ainsi adresser correctement la réponse.