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 unreachable 3.2.2.1 Рекомендуется
Интерпретация dest. unreachable лишь как совета 3.2.2.1 Обязательно
Redirect:
Хост посылает Redirect 3.2.2.2 Не рекомендуется
Обновление кэша маршрутов при получении Redirect 3.2.2.2 Обязательно
Обслуживание Redirect для хоста и сети 3.2.2.2 Обязательно
Отбрасывание некорректных сообщений Redirect 3.2.2.2 Рекомендуется
Source Quench:
Передача Source Quench при нехватке буферов 3.2.2.3 Возможно
Передача Source Quench на верхний уовень 3.2.2.3 Обязательно
Воздейтсвие верхнего уровня на Source Quench 3.2.2.3 Рекомендуется
Передача Time Exceeded на верхний уровень 3.2.2.4 Обязательно
Проблемы с параметрами:
Передача сообщений Parameter Problem 3.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 Reply 3.2.2.6 Обязательно
Сохранение данных в Echo Reply 3.2.2.6 Обязательно
Передача Echo Reply на верхний уровень 3.2.2.6 Обязательно
Отражение опций Record Route, Time Stamp 3.2.2.6 Рекомендуется
Инверсия и отражение опции Source Route 3.2.2.6 Обязательно
ICMP Information Request/Reply 3.2.2.7 Не рекомендуется
ICMP Timestamp/Timestamp Reply: Возможно
Минимизация вариаций задержки 3.2.2.8 Рекомендуется
Отбрасывание без уведомления широковещательных пакетов Timestamp 3.2.2.8 Возможно
Отбрасывание без уведомления групповых Timestamp 3.2.2.8 Возможно
Использование указанного адреса как отправителя TS Reply 3.2.2.8 Обязательно
Отражение опций Record Route и Timestamp 3.2.2.8 Рекомендуется
Обращение и отражение опции Source Route 3.2.2.8 Обязательно
Передача на верхний уровень 3.2.2.8 Обязательно
Выполнение правил для «стандартных значений» 3.2.2.8 Обязательно
ICMP Address Mask Request/Reply:
Настройка источника получения Address Mask 3.2.2.9 Обязательно
Поддержка статической конфигурации адресных масок 3.2.2.9 Обязательно
Динамическое получение маски при загрузке 3.2.2.9 Возможно
Получение маски с помощью Addr. Mask Request/Reply 3.2.2.9 Возможно
Повторная передача запроса при отсутствии отклика 3.2.2.9 Обязательно
Использование маски по умолчанию при отсутствии отклика 3.2.2.9 Рекомендуется
Обновление маски после получения первого отклика 3.2.2.9 Обязательно
Разумная проверка маски 3.2.2.9 Рекомендуется
Неуполномоченная передача откликов Address Mask Reply 3.2.2.9 Недопустимо
Явное указание уполномоченных агентов 3.2.2.9 Обязательно
Статическая конфигурация => флаг Addr-Mask-Authoritative 3.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 Redirect 3.3.1.2 Рекомендуется
Использование шлюза по умолчанию при отсутствии записи в кэше 3.3.1.2 Обязательно
Поддержка множества «шлюзов по умолчанию» 3.3.1.2 Обязательно
Поддержка таблицы статических маршрутов 3.3.1.2 Возможно
Флаг: возможность переписывания маршрута путем Redirect 3.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 Обязательно

Страница 52 из 86

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