RFC: 1122
Оригинал: Requirements for Internet Hosts - Communication Layers
Категория: Стандарт Интернета
Дата публикации:
Автор:
Перевод: Николай Малых
Возврат сообщений ICMP об ошибках (если не запрещено)3.3.8Обязательно
Получатель недоступен (destination unreachable):
Генерация destination unreachable (код 2 и 3)3.2.2.1Рекомендуется
Передача destination unreachable на верхние уровни3.2.2.1Обязательно
Действия верхних уровней для destination unreachable3.2.2.1Рекомендуется
Интерпретация dest. unreachable лишь как совета3.2.2.1Обязательно
Redirect:
Хост посылает Redirect3.2.2.2Не рекомендуется
Обновление кэша маршрутов при получении Redirect3.2.2.2Обязательно
Обслуживание Redirect для хоста и сети3.2.2.2Обязательно
Отбрасывание некорректных сообщений Redirect3.2.2.2Рекомендуется
Source Quench:
Передача Source Quench при нехватке буферов3.2.2.3Возможно
Передача Source Quench на верхний уовень3.2.2.3Обязательно
Воздейтсвие верхнего уровня на Source Quench3.2.2.3Рекомендуется
Передача Time Exceeded на верхний уровень3.2.2.4Обязательно
Проблемы с параметрами:
Передача сообщений Parameter Problem3.2.2.5Рекомендуется
Передача Parameter Problem на верхний уровень3.2.2.5Обязательно
Передача сообщений Parameter Problem пользователю3.2.2.5Возможно
ICMP Echo Request/Reply:
Эхо-сервер и эхо-клиент3.2.2.6Обязательно
Эхо-клиент3.2.2.6Рекомендуется
Отбрасывание Echo Request для широковещательных адресов3.2.2.6Возможно
Отбрасывание Echo Request для групповых адресов3.2.2.6Возможно
Использование указанного адреса отправителя в Echo Reply3.2.2.6Обязательно
Сохранение данных в Echo Reply3.2.2.6Обязательно
Передача Echo Reply на верхний уровень3.2.2.6Обязательно
Отражение опций Record Route, Time Stamp3.2.2.6Рекомендуется
Инверсия и отражение опции Source Route3.2.2.6Обязательно
ICMP Information Request/Reply3.2.2.7Не рекомендуется
ICMP Timestamp/Timestamp Reply:Возможно
Минимизация вариаций задержки3.2.2.8Рекомендуется
Отбрасывание без уведомления широковещательных пакетов Timestamp3.2.2.8Возможно
Отбрасывание без уведомления групповых Timestamp3.2.2.8Возможно
Использование указанного адреса как отправителя TS Reply3.2.2.8Обязательно
Отражение опций Record Route и Timestamp3.2.2.8Рекомендуется
Обращение и отражение опции Source Route3.2.2.8Обязательно
Передача на верхний уровень3.2.2.8Обязательно
Выполнение правил для «стандартных значений»3.2.2.8Обязательно
ICMP Address Mask Request/Reply:
Настройка источника получения Address Mask3.2.2.9Обязательно
Поддержка статической конфигурации адресных масок3.2.2.9Обязательно
Динамическое получение маски при загрузке3.2.2.9Возможно
Получение маски с помощью Addr. Mask Request/Reply3.2.2.9Возможно
Повторная передача запроса при отсутствии отклика3.2.2.9Обязательно
Использование маски по умолчанию при отсутствии отклика3.2.2.9Рекомендуется
Обновление маски после получения первого отклика3.2.2.9Обязательно
Разумная проверка маски3.2.2.9Рекомендуется
Неуполномоченная передача откликов Address Mask Reply3.2.2.9Недопустимо
Явное указание уполномоченных агентов3.2.2.9Обязательно
Статическая конфигурация => флаг Addr-Mask-Authoritative3.2.2.9Рекомендуется
Широковещательная передача Addr. Mask Reply при инициализации3.2.2.9Обязательно
Маршрутизация исходящих дейтаграмм:
Использование маски при выборе локальный/удаленный3.3.1.1Обязательно
Работа с подключенной сетью без шлюза3.3.1.1Обязательно
Поддержка кэша для ближайших (next-hop) шлюзов3.3.1.2Обязательно
Одинаковая трактовка Host/Net Redirect3.3.1.2Рекомендуется
Использование шлюза по умолчанию при отсутствии записи в кэше3.3.1.2Обязательно
Поддержка множества «шлюзов по умолчанию»3.3.1.2Обязательно
Поддержка таблицы статических маршрутов3.3.1.2Возможно
Флаг: возможность переписывания маршрута путем Redirect3.3.1.2Возможно
Использование в качестве ключа адреса хоста, а не сети3.3.1.3Возможно
Включение TOS в кэш маршрутов3.3.1.3Рекомендуется
Возможность обнаружения сбоев в следующем шлюзе3.3.1.4Обязательно
Предположение о постоянной доступности маршрута3.3.1.4Не рекомендуется
Непрерывное использование ping для шлюзов3.3.1.4Недопустимо
ping используется только при передаче трафика3.3.1.4Обязательно
ping используется только при отсутствии позитивных анонсов3.3.1.4Обязательно
Анонсы от верхних и нижних уровней3.3.1.4Рекомендуется
Смена «умершего» шлюза по умолчанию3.3.1.5Обязательно
Возможность ввода конфигурационных параметров вручную3.3.1.6Обязательно
2007 - 2017 © Русские переводы RFC, IETF, ISOC.