RFC: 826
Оригинал: An Ethernet Address Resolution Protocol
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 826, Страница 10 из 10

Связанные вопросы

Может возникнуть потребность в организации контроля возраста записей в таблицах трансляции и/или таймаутов. Реализация этих функций выходит за пределы данной спецификации. Более детальное рассмотрение этоих вопросов приведено ниже (спасибо [email protected] @MIT-MC).

При перемещении хоста любые инициируемые соединения будут работать в предположении, что таблица преобразования адресов этого хоста была очищена (сброшена) при перемещении. Однако соединения, инициированные другими хостами, не имеют веских причин для корректировки своих таблиц трансляции адресов. Предполагается, что 48-битовые адреса Ethernet являются фиксированными, т. е., не могут изменяться. Однако хост может “перенести” свое имя (и некоторые протокольные адреса) на другое оборудование. Из опыта также известно, что большую опасность представляет некорректная маршрутная информация, переданная в результате аппаратной или программной ошибки — такие случаи просто недопустимы. Возможно при отказе в организации соединения с хостом передавать модулю преобразования адресов сигнал о необходимости удаления из таблицы информации о недоступном хосте — этот хост может быть выключен или старое отображение адресов перестало быть корректным. Можно также при получении пакета от хоста сбрасывать таймер для соответствующей записи в таблице трансляции адресов, используемый для удаления записи по возрасту (запись удаляется, если в течение заданного времени от хоста не было получено ни одного пакета). Однако просмотр таблицы при получении каждого пакета может вызвать чрезмерную загрузку процессора. Для предотвращения перегрузки могут использоваться механизмы хэширования или индексации.

Предложенный механизм приема пакетов трансляции адресов пытается в течение некоторого времени услышать перенесенный хост. Напомним, что при наличии в таблице преобразования пары <тип протокола, протокольный адрес отправителя> в этой записи будет заменяться поле аппаратного адреса отправителя запроса. Следовательно, в сети Ethernet, где широковещательные запросы слышат все станции, каждая станция будет получать новый аппаратный адрес.

Другим вариантом является использование демона, отслеживающего тайм-ауты. По истечение определенного времени такой демон рассматривает вопрос удаления записи из таблицы трансляции. Демон сначала передает (при необходимости с небольшим числом повторов) пакет трансляции адреса с кодом операции для запроса (REQUEST) по адресу Ethernet, имеющемуся в таблице. Если в течение заданного времени отклика не приходит, запись удаляется из таблицы трансляции. Запрос передается напрямую, чтобы не загружать работой каждую станцию Ethernet. Простое удаление записей из таблицы будет приводить к бессмысленной потере информации, поэтому его следует избегать.

Поскольку хост передает информацию только о себе, перезагрузка хоста не ведет к необходимости замены связанной с этим хостом записи в таблице трансляции. Некорректная информация не должна никаким способом перемещаться от одной машины к другой — единственный случай допустимости существования некорректной информации допустим лишь тогда, когда хост еще не знает об изменении 48-битового адреса Ethernet другого хоста. Возможно, что в таких случаях достаточно будет сбросить (очистить) вручную таблицу трансляции.

Этот вопрос требует дополнительного рассмотрения, если важность его достаточно велика. Вопрос может быть связан с любыми протоколами, подобными трансляции адресов.

Страница 10 из 10

2007 - 2022 © Русские переводы RFC, IETF, ISOC.