Зачем так делать??
Периодическая рассылка широковещательных пакетов нежелательна. Представим сегмент Ethernet, содержащий 100 станций, каждая из которых отправляет широковещательный пакет преобразования адресов каждые 10 минут. В результате передача широковещательных пакетов будет происходить в среднем каждые 6 секунд. Это значение невелико — почему же не пойти таким путем? Рабочая станция обычно не обменивается данными со всеми другими станциями и, следовательно, не имеет в таблице все 100 записей, которые могут потребоваться. Станция обычно обменивается данными с серверами, мэйнфреймами и значительно реже — с другими станциями. Описанный здесь протокол распространяет информацию только по мере необходимости и (возможно однократно) при загрузке станции.
Описанный формат не позволяет получить преобразование для нескольких адресов с использованием одного пакета. Это сделано в целях упрощения. Если использовать мультиплексирование, формат пакетов станет существенно сложнее и много информации будет передаваться бессмысленно. Можно представить себе мост, который поддерживает 4 протокола и сообщает станциям все 4 протокольных адреса, три из которых может быть никогда не потребуются.
Предлагаемый формат позволяет повторно использовать буфер пакетов для генерации откликов — отклик иметт такой же размер, как запрос, и многие поля запроса и отклика совпадают.
Значение поля ar$hrd описываемый протокол берет из списка. В настоящее время определено только значение для сетей Ethernet 10 Мбит/с (ares_hrd$Ethernet = 1). Обсуждается также вопрос об использовании протокола для сетей Packet Radio Networks и для этого типа сетей также потребуется определить соответствующее значение поля. В будущем, когда протокол станет использоваться для других типов оборудования, потребуется определить соответствующие значения и для них.
Для сетей Ethernet 10 мбит/с значение поля протокола (ar$pro) берется из набора ether_type$. Это позволяет воспользоваться уже определенными идентификаторами типа протокола. Комбинация этого поля с типом операции (ar$op) будет позволять эффективно увеличить число протоколов, для которых может обеспечиваться преобразование адресов, но усложняет мониторинг и отладку. Будем надеяться, что число протоколов никогда не превысит 32768, но закон Мэрфи (Murphy) оставляет место для некоторых сомнений.