48.
|
Передавать ICMP-сообщение “получатель недостижим” с использованием кодов 2/3
|
|
|
|
|
|
49.
|
Транслировать ICMP-сообщение “получатель недостижим” на верхний уровень
|
|
|
|
|
|
50.
|
Реагирование на верхнем уровне при получении ICMP-сообщения “получатель недостижим”
|
|
|
|
|
|
51.
|
Интерпретировать ICMP-сообщение “получатель недостижим” на верхнем уровне только как “подсказку”
|
|
|
|
|
|
52.
|
Передача главной вычислительной машиной ICMP-сообщения “перенаправление”
|
|
|
|
|
|
53.
|
Добавление данных в кэш-память о маршруте при получении ICMP-сообщения “перенаправление”
|
|
|
|
|
|
54.
|
Приём и обработка ICMP-сообщений “перенаправление”, поступивших, либо от сети, либо от другой ГВМ
|
|
|
|
|
|
55.
|
Уничтожение недействительных ICMP-сообщений “перенаправление”
|
|
|
|
|
|
56.
|
Передача ICMP-сообщения “Источник не отвечает” (Source Quench), если все буферы памяти заполнены
|
|
|
|
|
|
57.
|
Трансляция ICMP-сообщения “Источник не отвечает” на верхний уровень
|
|
|
|
|
|
58.
|
Реагирование верхнего уровня при получении ICMP-сообщения “Источник не отвечает”
|
|
|
|
|
|
59.
|
Трансляция ICMP-сообщения “время просрочено” (Time Exceeded) на верхний уровень
|
|
|
|
|
|
60.
|
Передача ICMP-сообщений “Параметрическая проблема” (Parameter Problem)
|
|
|
|
|
|
61.
|
Трансляция ICMP-сообщения “Параметрическая проблема” на верхний уровень
|
|
|
|
|
|
62.
|
Оповещение пользователя о параметрической проблеме
|
|
|
|
|
|
63.
|
Реализация в ПО ГВМ функций сервера и клиента “Эхо-контроля” (передача эхо-запросов и приём эхо-ответов)
|
|
|
|
|
|
64.
|
Реализация в ПО ГВМ только функции клиента “Эхо-контроля”
|
|
|
|
|
|
65.
|
Уничтожение эхо-запросов, переданных в широковещательном режиме
|
|
|
|
|
|
66.
|
Уничтожение эхо-запросов, переданных в групповом режиме
|
|
|
|
|
|
67.
|
Использование специфического IP-адреса получателя в качестве IP-адреса отправителя в эхо-ответах
|
|
|
|
|
|
68.
|
Передача некоторых данных в эхо-ответах
|
|
|
|
|
|
69.
|
Трансляция эхо-ответов на верхний уровень
|
|
|
|
|
|
70.
|
Отображение значений дополнительных функций “Регистрация маршрута” и “Метка времени”
|
|
|
|
|
|
71.
|
Дублирование исходного маршрута с точностью до наоборот и отображение значения дополнительной функции “Регистрация маршрута”
|
|
|
|
|
|
72.
|
Использование ICMP-запросов/ответов “Информация”
|
|
|
|
|
|
73.
|
Использование ICMP-запросов/ответов “Метка времени”
|
|
|
|
|
|
74.
|
Минимизация девиации задержки1
|
|
|
|
|
|
75.
|
Уничтожение в режиме “по умолчанию” ICMP-сообщений “Метка времени”, переданных в широковещательном режиме1
|
|
|
|
|
|
76.
|
Уничтожение в режиме “по умолчанию” ICMP-сообщений “Метка времени”, переданных в групповом режиме1
|
|
|
|
|
|
77.
|
Использование специфического IP-адреса получателя в качестве IP-адреса отправителя в ICMP-сообщениях “Метка времени”1
|
|
|
|
|
|
78.
|
Отображение значений дополнительных функций “Регистрация маршрута” и “Метка времени”1
|
|
|
|
|
|
79.
|
Дублирование исходного маршрута с точностью до наоборот и отображение значения дополнительной функции “Регистрация маршрута”1
|
|
|
|
|
|
80.
|
Трансляция ICMP-ответов “Метка времени”на верхний уровень1
|
|
|
|
|
|
81.
|
Выполнение правил, определенных для “стандартного значения”1
|
|
|
|
|
|
82.
|
Настройка способа определения адресной маски
|
|
|
|
|
|
83.
|
Реализация статической настройки адресной маски
|
|
|
|
|
|
84.
|
Динамическая настройка (получение) адресной маски в период начальной загрузки системы
|
|
|
|
|
|
85.
|
Получение адресной маски на основе обмена ICMP-сообщениями (запрос/ответ) “Адресная маска”
|
|
|
|
|
|
86.
|
Повторная передача ICMP-запроса “Адресная маска”, если не получен ответ на первый запрос3
|
|
|
|
|
|
87.
|
Использовать адресную маску для режима “по умолчанию”, если не получен ответ на первый запрос3
|
|
|
|
|
|
88.
|
Обновлять значение адресной маски только с использованием ответа на первый запрос3
|
|
|
|
|
|
89.
|
Проверка адресной маски на её допустимость (приемлемость)
|
|
|
|
|
|
90.
|
Передача ICMP-ответов “Адресная маска” не авторизованной ГВМ
|
|
|
|
|
|
91.
|
Настройка ГВМ в явном виде в качестве агента (прием/передача) адресной маски
|
|
|
|
|
|
92.
|
При статически настраиваемой адресной маске использование дополнительного флага для определения ГВМ как авторизованного агента
|
|
|
|
|
|
93.
|
Если ГВМ агент, то она передаёт ICMP-ответы “Адресная маска” в широковещательном режиме3
|
|
|
|
|
|
94.
|
Использование адресной маски при принятии решения о локальном/удалённом получателе IP-пакета
|
|
|
|
|
|
95.
|
Функционирование в присоединённой сетью в условиях отсутствия шлюзов
|
|
|
|
|
|
96.
|
Хранение в кэш-памяти маршрутов, определяющих шлюзы, расположенные на противоположных концах первых ретрансляционных участков
|
|
|
|
|
|
97.
|
ICMP-сообщение “перенаправление от сети” интерпретируется как ICMP-сообщение “перенаправление от ГВМ”
|
|
|
|
|
|
98.
|
При отсутствии кэш-записи о маршруте доставки выбирается шлюз из перечня шлюзов “по умолчанию”
|
|
|
|
|
|
99.
|
Наличие информации о нескольких шлюзах “по умолчанию”
|
|
|
|
|
|
100.
|
Наличие таблицы статических маршрутов
|
|
|
|
|
|
101.
|
Статический маршрут (в таблице) содержит “флаг”, указывающий на возможность его отмены с помощью ICMP-сообщений “перенаправление”
|
|
|
|
|
|
102.
|
При отсутствии IP-адреса использование в ГВМ кэш-записи о маршруте
|
|
|
|
|
|
103.
|
Включение в кэш-запись о маршруте данных о категории обслуживания (TOS)
|
|
|
|
|
|
104.
|
Способность обнаружения неисправного шлюза, расположенного на противоположной стороне первого ретрансляционного участка
|
|
|
|
|
|
105.
|
Предполагать, что маршрут является хорошим “вечно”
|
|
|
|
|
|
106.
|
Непрерывное проведение процедуры эхо-контроля
|
|
|
|
|
|
107.
|
Проведение процедуры эхо-контроля только при наличии трафика, подлежащего передаче
|
|
|
|
|
|
108.
|
Проведение процедуры эхо-контроля только при отсутствии позитивных данных о нормальном функционировании
|
|
|
|
|
|
109.
|
Уведомлять верхний и нижний уровни Internet-архитектуры
|
|
|
|
|
|
110.
|
Переключение с неисправного шлюза, используемого в режиме по умолчанию, на другой шлюз, используемый также в режиме по умолчанию
|
|
|
|
|
|
111.
|
Возможность применения ручного способа настройки
|
|
|
|
|
|
112.
|
Способность повторной сборки входящих IP-пакетов
|
|
|
|
|
|
113.
|
IP-пакеты всегда должны быть длиной, по крайней мере, 576 октета или больше
|
|
|
|
|
|
114.
|
Параметр EMTU_R должен быть, либо настраиваемым, либо неограниченным
|
|
|
|
|
|
115.
|
Транспортный уровень должен быть способен определить значение параметра MMS_R
|
|
|
|
|
|
116.
|
Передача ICMP-сообщений “время просрочено” по истечении тайм-аута повторной сборки
|
|
|
|
|
|
117.
|
Фиксированное значение тайм-аута повторной сборки
|
|
|
|
|
|
118.
|
Трансляция значения параметра MMS_R на верхние уровни
|
|
|
|
|
|
119.
|
Локальная фрагментация исходящих IP-пакетов
|
|
|
|
|
|
120.
|
Если локальная фрагментация исходящих IP-пакетов не предусмотрена, то запрет передачи последних, у которых длина превышает значение параметра MMS_R
|
|
|
|
|
|
121.
|
Передавать IP-пакет длиной не более 576, если IP-адрес получателя не идентифицирует присоединённую сеть
|
|
|
|
|
|
122.
|
Использование флага настройки “All-Subnets-MTU”
|
|
|
|
|
|
123.
|
Если IP-пакет передаётся в ответ на принятый IP-пакет, то IP-адрес источника в ответном IP-пакете должен быть IP-адресом получателя в запросе
|
|
|
|
|
|
124.
|
Предоставление возможности прикладному программному модулю (процессу) выбора локального IP-адреса
|
|
|
|
|
|
125.
|
Уничтожение по умолчанию IP-пакета, в котором IP-адрес получателя не соответствует физическому интерфейсу, через который он поступил
|
|
|
|
|
|
126.
|
Передача IP-пакета только через физический интерфейс, который соответствует IP-адресу получателя в этом IP-пакете4
|
|
|
|
|
|
127.
|
Ретрансляция IP-пакета с маршрутом доставки, который установил источник IP-пакета1
|
|
|
|
|
|
128.
|
Выполнение всех правил функционирования, установленных для шлюза1
|
|
|
|
|
|
129.
|
Значение в поле “TTL” должно обновляться в соответствие с правилами для шлюза1
|
|
|
|
|
|
130.
|
Способность формирования ICMP-сообщения “получатель недостижим”, используя для этого коды “4” и “5”1
|
|
|
|
|
|
131.
|
Ретранслируемый IP-пакет с маршрутом от его источника имеет IP-адрес отправителя, не являющийся ни одним из IP-адресов ГВМ-ретранслятора1
|
|
|
|
|
|
132.
|
При ретрансляции IP-пакета с маршрутом от его источника, содержащего в своём заголовке функции “Метка времени” и “Регистрация маршрута”, обработка этого IP-пакета в соответствии с правилами реализации этих дополнительных функций1
|
|
|
|
|
|
133.
|
Наличие настраиваемой функции коммутации IP-пакетов при реализации функции не локальной маршрутизации источника1
|
|
|
|
|
|
134.
|
Блокировка функции коммутации в режиме “по умолчанию”1
|
|
|
|
|
|
135.
|
Выполнение всех правил доступа к шлюзу при не локальной маршрутизации источника1
|
|
|
|
|
|
136.
|
Если IP-пакет не был ретранслирован по некоторой причине, то следует направить ответное ICMP-сообщение “получатель недостижим” (с кодом “5”, то есть “Некорректный маршрут от источника” — “Source Route Failed”)2
|
|
|
|
|
|
137.
|
Использование широковещательного IP-адреса в качестве IP-адреса отправителя
|
|
|
|
|
|
138.
|
Прием IP-пакетов с нестандартными формами широковещательных IP-адресов (замена “-1” на “0”)
|
|
|
|
|
|
139.
|
Наличие настраиваемой функции по выбору значений “0” или “-1”, используемых в одной из форм широковещательных IP-адресов
|
|
|
|
|
|
140.
|
В режиме по умолчанию функция по выбору значений “0” или “-1” настроена на использование значения “-1”
|
|
|
|
|
|
141.
|
Распознавание всех форматов широковещательных IP-адресов
|
|
|
|
|
|
142.
|
Использование разрешённого широковещательного или группового IP-адреса получателя при трансляции IP-пакета через канальный интерфейс с широковещательным адресом канального уровня
|
|
|
|
|
|
143.
|
Уничтожение в режиме по умолчанию IP-пакетов, которые поступили через канальный интерфейс с широковещательным адресом канального уровня, но в которых IP-адреса получателей не являлись разрешёнными широковещательными или групповыми IP-адресами.
|
|
|
|
|
|
144.
|
Использование ограниченного широковещательного адреса при передаче IP-пакетов в широковещательном режиме в присоединённую сеть
|
|
|
|
|
|
145.
|
Реализация локальной групповой IP-адресацию в интересах всех присоединённых сетей (RFC-1112, RFC-2236)
|
|
|
|
|
|
146.
|
Поддержка IGMP-протокола (RFC-1112, RFC-2236)
|
|
|
|
|
|
147.
|
Присоединение к группе “все ГВМ” при включении
|
|
|
|
|
|
148.
|
Информирование протоколов верхних уровней о том какая из присоединённых к ней сетей поддерживает групповую IP-адресацию
|
|
|
|
|
|
149.
|
Предоставление транспортному уровню полного доступа ко всем программным средствам IP-модуля
|
|
|
|
|
|
150.
|
Трансляция на транспортный уровень идентификатора интерфейса
|
|
|
|
|
|
151.
|
Трансляция значений всех дополнительных IP-функций на транспортный уровень
|
|
|
|
|
|
152.
|
Транспортный уровень может транслировать определённые ICMP-сообщения
|
|
|
|
|
|
153.
|
Трансляция на транспортный уровень определённых ICMP-сообщений
|
|
|
|
|
|
154.
|
При передаче ICMP-сообщения об ошибке включение в соответствующий IP-заголовок данных, которые подлежат трансляции, и плюс 8 или более октетов из соответствующего ICMP-сообщения
|
|
|
|
|
|
155.
|
Способность формирования “сквозного канала” доставки данных до прикладного программного модуля (процесса)
|
|
|
|
|
|
Скачать 1.38 Mb.