Ponieważ Ethernet używa adresów MAC do komunikacji, czy mogę stworzyć sieć Ethernet, w której urządzenia nie miałyby adresu IP, tylko adres MAC?
Jeśli pisałeś całe swoje oprogramowanie od zera, z pewnością możesz to zrobić. Wystarczy, aby oprogramowanie zaakceptowało adres MAC w dowolnym miejscu, w którym normalny odpowiednik tego programu zaakceptowałby adres IP. Użyj wszystkich wywołań systemowych, aby wysłać surowe pakiety Ethernet zamiast adresu IP i będzie działać - ale byłby to ogromny kłopot.
Zasadniczo adresy MAC w sieci nie są zgodne z żadnym wzorcem. Są wypalane na sprzęcie przez producenta. Są długie i nieporęczne. Mój obecnie to C8-60-00-CA-4B-9A. Komputer obok mnie to 00-40-F4-48-1B-88.
Aby maszyny mogły ze sobą rozmawiać, możesz nadać każdej maszynie zakodowaną listę wszystkich adresów MAC wszystkich innych komputerów w sieci, aby wiedział, gdzie wysłać pakiety. Jest to bardzo podatne na błędy pisanie, a za każdym razem, gdy zmieniasz dowolny sprzęt sieciowy, musisz obejść i zmienić wszystkie listy, aby odzwierciedlić nowe adresy MAC.
Jest to ogromny kłopot, więc prawdopodobnie skończyłbyś ze sposobem, w jaki maszyny w sieci będą automatycznie odkrywać swoje adresy MAC za pomocą pakietów rozgłoszeniowych. Następnie dasz im sposób na identyfikację się z jakimś znaczącym adresem, więc będziesz musiał wpisać polecenia takie jak „telnet C8-60-00-CA-4B-9A”.
Okazuje się, że właśnie to robi IP - jest to sposób na użycie znaczących liczb do adresowania hostów w sieci, a nie kodowania adresów MAC na stałe. Dodaj DNS nad IP i możesz wpisać polecenie takie jak „telnet webserver”.
Czy Ethernet nie mógł wykorzystywać adresów IP do wysyłania wiadomości? Nie twierdzę, że powinno, tylko pytam, czy mógł to zrobić.
Adresy MAC to 6 bajtów informacji, a adresy IP to tylko 4 bajty, więc nie można wykonać żadnego mapowania 1 do 1. Potrzebujesz sposobu na znalezienie adresu MAC (w celu umieszczenia w pakiecie) z adresu IP (dostarczonego przez oprogramowanie, które chce komunikować się z innym hostem w sieci).
Jednym ze sposobów (twardego rdzenia) byłoby przejście do każdego komputera w sieci i zmiana jego sprzętowego adresu MAC, aby wyglądał jak adres IP, poprzez ustawienie dwóch górnych bajtów na zera (lub na inny stały numer, który jest taki sam dla każdego komputera w sieci) i ustaw dolne cztery bajty na „adres IP”, który ma mieć w sieci. (Większość kart sieciowych pozwoli ci wejść i zmodyfikować adres MAC przypisany przez dostawcę)
Aby to faktycznie działało, musisz również zhakować kod ze stosu sieciowego, aby faktycznie korzystać z tego systemu. Zerwałbyś wszystko, co ma związek z ARP (metoda IP używa do tłumaczenia adresów IP na adresy MAC). Zerwałbyś części, które budują / czytają nagłówki IP. Zamiast tego zastąpiłbyś to wszystko bardzo prostym kodem, który biorąc pod uwagę pakiet IP, który ma zostać wysłany do hosta pod adresem wxyz, zbuduj ramkę Ethernet z adresem DEST ustawionym na 00-00-wxyz.
Potrzebny byłby również sposób wskazania odbiorcy pakietu, dla którego protokołu (UDP, TCP) jest on przeznaczony. Prawdopodobnie możesz to gdzieś umieścić w nagłówku ethernetowym, zastępując istniejące pole. Może użyć jednego z dwóch górnych bajtów adresu źródłowego? Nie wpłynęłoby to na zdolność odbierania komputerów docelowych, ale mogłoby zepsuć niektóre przełączniki. Możesz także dodać protokół na początku lub na końcu ramki Ethernet i zwiększyć rozmiar ładunku o jeden - ale zaczyna to pachnieć jak nagłówek IP.
Więc co by to wszystko kupiło?
Po pierwsze pozwoliłoby ci to zaoszczędzić na wyszukiwaniu w tabeli ARP na każdym wychodzącym pakiecie. Jest to prawdopodobnie rzędu zaledwie mikrosekund.
Oszczędzasz pracę przy obliczaniu sum kontrolnych nagłówka IP i pamięć potrzebną do ich przechowywania. Prawdopodobnie nie ma to większego znaczenia na nowoczesnym sprzęcie.
Zapisujesz 16 bajtów w każdym pakiecie w sieci, ponieważ nie byłoby nagłówków IP. Może się to sumować w zależności od aplikacji.
Największą korzyścią byłoby to, że nie musiałbyś wykonywać żadnych zapytań ARP. Wysłanie standardowego pakietu IP do nowego hosta uruchamia wymianę ARP, która może potrwać milisekundy i jest nieprzewidywalna. Może to być ogromny zysk w przypadku niektórych aplikacji, które są bardzo wrażliwe na opóźnienia i fluktuacje.
W przypadku niektórych bardzo specjalistycznych aplikacji ma to sens. Kiedyś pracowałem w systemie czasu rzeczywistego, który używał tylko pakietów rozgłoszeniowych UDP do całej komunikacji między hostami tylko dlatego, że unikał uruchamiania tych sekwencji ARP i nieprzewidywalnie dodaje opóźnienia i fluktuacji. Raz pracowałem również nad wbudowanym systemem o ograniczonych zasobach, który działał, wysyłając ładunki UDP bezpośrednio do pakietów IP (bez nagłówka IP), ponieważ oszczędzał całą złożoność i pamięć potrzebną do wdrożenia całej ARP i maski sieci oraz dodatkowych sum kontrolnych.