Поскольку Ethernet использует для связи MAC-адреса, могу ли я создать сеть Ethernet, в которой у устройств не будет IP-адреса, а просто MAC-адрес?
Если бы вы писали все свое программное обеспечение с нуля, то вы, безусловно, могли бы сделать это. Просто попросите программное обеспечение принять MAC-адрес в любом месте, где обычный аналог этой программы принял бы IP-адрес. Используйте все системные вызовы для отправки сырых пакетов Ethernet, а не IP-адреса, и это будет работать, но это будет огромной проблемой.
Как правило, MAC-адреса в вашей сети не соответствуют какой-либо схеме. Они сожжены в аппаратное обеспечение производителем. Они длинные и громоздкие. Мой прямо сейчас это C8-60-00-CA-4B-9A. Рядом со мной компьютер 00-40-F4-48-1B-88.
Чтобы машины могли общаться друг с другом, вы могли бы дать каждой машине жестко запрограммированный список всех MAC-адресов всех других машин в сети, чтобы она знала, куда отправлять пакеты. Это много ошибок при наборе текста, и каждый раз, когда вы меняете любое сетевое оборудование, вам придется обходить и изменять все списки, чтобы отразить новые MAC-адреса.
Это огромная проблема, так что вы, вероятно, в конечном итоге найдете способ для машин в сети автоматически обнаруживать MAC-адреса друг друга с помощью широковещательных пакетов. Затем вы дадите им способ идентифицировать себя по какому-то значимому адресу, поэтому вам придется вводить команды, такие как «telnet C8-60-00-CA-4B-9A».
Оказывается, это именно то, что делает IP - это способ использовать значимые числа для адресации хостов в сети, а не жестко кодировать MAC-адреса. Добавьте DNS поверх IP, и вы можете ввести команду, например, "telnet webserver".
Разве Ethernet не может использовать IP-адреса для отправки сообщений? Я не говорю, что должен, я просто спрашиваю, мог ли бы он сделать это.
MAC-адреса представляют собой 6 байтов информации, а IP-адреса - только 4 байта, поэтому вы не можете выполнять какое-либо сопоставление от 1 до 1. Вам нужен какой-то способ нахождения MAC-адреса (для помещения в пакет) по IP-адресу (предоставленному программным обеспечением, которое хочет связываться с другим хостом в сети).
Один (жесткий основной) способ сделать это состоит в том, чтобы перейти на каждую машину в сети и изменить ее аппаратный MAC-адрес, чтобы он выглядел как IP-адрес, сделав верхние два байта равными нулям (или некоторому другому фиксированному числу, которое совпадает для каждой машины в сети) и установите нижние четыре байта в «IP-адрес», который вы хотите, чтобы они были в сети. (Большинство сетевых карт позволят вам войти и изменить назначенный поставщиком MAC-адрес)
Чтобы это действительно работало, затем вам также придется взломать код в сетевом стеке, чтобы фактически использовать эту систему. Вы бы в основном разорвали все, что связано с ARP (метод, который IP использует для преобразования IP-адресов в MAC-адреса). Вы извлекли бы части, которые строят / читают заголовки IP. Вместо этого вы бы заменили все это на очень простой код, который, учитывая IP-пакет для отправки на хост по адресу wxyz, создает кадр Ethernet с адресом DEST, установленным в 00-00-wxyz.
Вам также потребуется способ указать получателю пакета, для какого протокола (UDP, TCP) он предназначен. Возможно, вы могли бы вставить это где-нибудь в заголовок Ethernet, переопределив существующее поле. Может быть, использовать один из двух верхних байтов адреса источника? Это не повлияет на способность получателей получать, но может испортить некоторые коммутаторы. Вы также можете добавить протокол в начало или конец кадра Ethernet и увеличить размер полезной нагрузки на единицу - но это начинает пахнуть как заголовок IP.
Так что же ты купишь всю эту работу?
Во-первых, это сэкономит вам затраты на поиск в таблице ARP для каждого исходящего пакета. Это, вероятно, порядка только микросекунд.
Вы сохраняете работу по вычислению контрольных сумм заголовков IP и памяти, необходимой для их хранения. Это, вероятно, не важно для современного оборудования.
Вы сохраняете 16 байтов в каждом пакете в сети, так как не было бы заголовков IP. Это может сложиться в зависимости от приложения.
Самым большим преимуществом будет то, что вам не придется выполнять запросы ARP. Отправка стандартного IP-пакета на новый хост запускает обмен ARP, который может занять миллисекунды и является непредсказуемым. Это может быть огромным преимуществом для некоторых приложений, которые очень чувствительны к задержке и дрожанию.
Для некоторых очень специализированных приложений это действительно имеет смысл. Однажды я работал с системой реального времени, которая использовала только широковещательные UDP-пакеты для всех коммуникаций между хостами, по единственной причине, что она избегала включения этих последовательностей ARP и непредсказуемо добавляла задержку и дрожание. Я также однажды работал над встроенной системой с ограниченными ресурсами, которая работала, посылая полезные нагрузки UDP внутри IP-пакетов напрямую (без заголовка IP), потому что это сохраняло всю сложность и память, необходимые для реализации всего ARP и маски масок и дополнительных контрольных сумм.
