Главная страница

Порядок создания СЗПДн. Требования к сетевым устройствам


Скачать 1.38 Mb.
НазваниеТребования к сетевым устройствам
АнкорПорядок создания СЗПДн
Дата11.10.2021
Размер1.38 Mb.
Формат файлаdoc
Имя файлаrfc1122_HOST1_tr.doc
ТипПротокол
#245378
страница8 из 11
1   2   3   4   5   6   7   8   9   10   11
§3.3.5. Доставка (ретрансляция) по маршруту источника

ГВМ может функционировать как промежуточный IP-узел на маршруте доставки, который установил источник IP-пакетов, и передавать IP-пакеты на следующий промежуточный IP-узел.

Тем не менее, функционируя как шлюз, ГВМ обязана выполнять все соответствующие правила для шлюза, который ретранслирует IP-пакеты по маршруту, установленному их источником (RFC-1009). А из этого следует необходимость выполнения следующих требований:

  1. Время жизни IP-пакета (TTL). Значение в поле “TTL” должно уменьшаться на единицу при “прохождении” IP-пакета каждый ретрансляционный шлюз, а сам IP-пакет может уничтожаться, как это определено в стандарте RFC-1009;

  2. ICMP-сообщение “получатель недостижим”. ГВМ должна быть способна формировать ICMP-сообщения “получатель недостижим”, используя для этого следующие коды: “4” — (требуется фрагментация, но бит “ DF” имеет значение “1”), когда IP-пакет с маршрутом от его источника не может быть фрагментирован для последующей передачи в сеть получателя; “5” — (маршрут от источника IP-пакета не возможен) когда IP-пакет с маршрутом от его источника не может быть доставлен, например, потому, что возникла проблема маршрутизации или потому, что следующий ретрансляционный участок точного маршрута от источника IP-пакета не связан с присоединённой сетью;

  3. IP-адрес отправителя. Ретранслируемый IP-пакет с маршрутом от его источника может (и обычно будет) иметь IP-адрес отправителя, не являющийся ни одним из IP-адресов ГВМ-ретранслятора;

  4. Дополнительная функция “Регистрация маршрута” (“RecordRoute”). ГВМ, которая ретранслирует IP-пакет с маршрутом от его источника, содержащий в своём заголовке функцию “Регистрация маршрута”, обязана выполнить эту функцию, если, конечно, для этого имеется место;

  5. Дополнительная функция “Метка времени” (“Timestamp”). ГВМ, которая ретранслирует IP-пакет с маршрутом от его источника, содержащий в своём заголовке функцию “Метка времени”, обязана добавить текущую метку времени в соответствии с правилами реализации этой дополнительной функции.

Для определения правил, ограничивающих ретрансляцию ГВМ IP-пакетов с маршрутами от их источников, используется термин “локальная маршрутизация источника” (“local source-routing”), но только в том случае, когда следующий ретрансляционный участок будет “проходить” через один и тот же физический интерфейс, через который поступают IP-пакеты. В противном случае, используется термин “не локальная маршрутизация источника” (“non-local source-routing”). Правила для ГВМ по ограничению ретрансляции IP-пакетов с маршрутами от их источников следующие:

  • ГВМ разрешено осуществлять функцию локальной маршрутизации источника без ограничений;

  • ГВМ, которая реализует функцию не локальной маршрутизации источника, должна иметь настраиваемую функцию коммутации с целью отключения подфункции ретрансляции, а сама функция коммутации в режиме “по умолчанию” должна быть блокирована;

  • ГВМ должна удовлетворять всем требованиям правил настройки фильтров (RFC-1009), которые запрещают не локальную ретрансляцию.

Если ГВМ получила IP-пакет с указанием неполного маршрута от его источника и в дальнейшем не ретранслировала его по некоторой причине, то она должна направить ответное ICMP-сообщение “получатель недостижим” (с кодом “5”, то есть “Некорректный маршрут от источника” — “Source Route Failed”), за исключением случая, когда принятый IP-пакет сам является ICMP-сообщением об ошибке.
§3.3.6. Широковещательный режим доставки

Существуют следующие четыре стандартных формы широковещательных IP-адресов:

      • {номер сети -1, номер ГВМ -1}. Ограниченный широковещательный адрес (Limited Broadcast);

      • {номер сети Х, номер ГВМ -1}. Направленный широковещательный адрес для конкретной сети (Directed Broadcast);

      • {номер сети Х, номер подсети Х, номер ГВМ -1}. Направленный широковещательный адрес для конкретной подсети (Subnet Directed Broadcast);

      • {номер сети Х, номер подсети -1, номер ГВМ -1}. Направленный широковещательный адрес для всех подсетей конкретной сети, разделённой на соответствующие подсети (All-Subnets Directed Broadcast);

ГВМ обязана распознавать любую из этих форм широковещательных IP-адресов, анализируя IP-адрес получателя в заголовке входящего IP-пакета.

Существует класс ГВМ, которые используют нестандартные формы широковещательных IP-адресов, заменяя “-1” на “0”. Целесообразно, чтобы все ГВМ распознавали и принимали на обработку любую из этих нестандартных форм широковещательных IP-адресов в качестве IP-адреса получателя в заголовке входящего IP-пакета. ГВМ дополнительно может иметь настраиваемую функцию по выбору значений “0” или “-1”, используемых в одной из форм широковещательных IP-адресов, причём для каждого физического интерфейса. Но целесообразно, чтобы в режиме по умолчанию эта функция была настроена на использование значения “-1”.

Когда ГВМ транслирует IP-пакет через канальный интерфейс с широковещательным адресом канального уровня, IP-адрес получателя должен быть разрешённым широковещательным или групповым IP-адресом.

Целесообразно, чтобы ГВМ в режиме по-умолчанию уничтожала IP-пакеты, которые поступили через канальный интерфейс с широковещательным адресом канального уровня, но в которых IP-адреса получателей не являлись разрешёнными широковещательными или групповыми IP-адресами.

ГВМ рекомендуется использовать ограниченный широковещательный адрес при передаче IP-пакетов в широковещательном режиме в присоединённую сеть.

Использование ограниченного широковещательного адреса вместо направленного широковещательного адреса для конкретной сети может привести к повышению живучести системы. Очень часто возникающие проблемы связаны с тем, что ГВМ “не понимают” множество широковещательных IP-адресов, или с тем, что ГВМ могут иметь различные представления о том, какие широковещательные IP-адреса используются. Прекрасным примером сказанного выше являются ГВМ, которые “не понимают” деление сети на подсети, в то время как сами они присоединены к сети, которая разделена на подсети. Трансляция IP-пакета с широковещательным IP-адресом для конкретной подсети в присоединённую сеть будет “приводить в недоумение” такие ГВМ, так как последние будут воспринимать этот передаваемый IP-пакет как сообщение, которое предназначено для некоторой другой ГВМ.

В Internet-сообществе прошла дискуссия о необходимости передачи со всех интерфейсов многоадресной ГВМ IP-пакетов, содержащих ограниченный широковещательный IP-адрес. Однако, данная тема осталась за пределами данного стандарта.
§3.3.7. Групповая IP-адресация

Рекомендуется, чтобы ГВМ была способна осуществлять локальную групповую IP-адресацию в интересах всех присоединённых сетей, для которых определено отображение IP-адресов класса D в адреса канального уровня. Реализация локальной групповой IP-адресации включает:

  • отправку IP-пакет с групповыми IP-адресами;

  • формирование одноадресных групп и приём IP-пакетов с групповыми IP-адресами;

  • расформирование одноадресных групп.

Эти функции реализуются всеми ГВМ, определёнными в стандарте RFC-1112, за исключением самого IGMP-протокола, применение которого является необязательным.

В настоящее время принят стандарт RFC-2236, которые определяет IGMP-протокол второй версии.

Если же всё-таки ПО ГВМ не имеет программного модуля IGMP-протокола, то целесообразно, чтобы такая ГВМ по прежнему была присоединена к группе “все ГВМ” и использовала групповой адрес “все ГВМ” (224.0.0.1), когда её программный IP-модуль находится в активном состоянии и на протяжении всего своего активного состояния остаётся участником группы.

ГВМ, присоединенная к группе “все ГВМ”, будет поддерживать только локальную групповую IP-адресацию, например, протокол поиска шлюза, даже если ПО ГВМ не имеет программного модуля IGMP-протокола.

Отображение D-адресов в локальные адреса определено для следующих типов сетей:

  • Ethernet/IEEE 802.3 (RFC-1112);

  • Любые сети, которые поддерживают широковещательный режим отправки IP-пакетов, но не применяют режим групповой IP-адресации: все D-адреса отображаются в локальные широковещательные адреса;

  • Любые типы сквозных соединений канального уровня (например, SLIP-, PPP- и HDLS-протоколы): отображение не требуется. Все IP-пакеты с групповой IP-адресацией передаются “как есть” в формате кадра канального уровня.

Целесообразно, чтобы ГВМ обладала способностью информирования протоколов верхних уровней и прикладных процессов (систем) о том какая из присоединённых к ней сетей поддерживает групповую IP-адресацию.
§3.3.8. Информирование об ошибках

Где бы то ни было на практике, ГВМ обязаны при обнаружении ошибок передавать ответные ICMP-сообщения об ошибках, за исключением тех случаев, когда сама передача ответных ICMP-сообщения об ошибках запрещена.

Общим свойством пакетных сетей дейтаграммным режимом доставки является наличие “черных дыр”: IP-пакеты отправляются, но ничего назад не возвращается. Без каких-либо IP-пакетов об ошибках пользователю весьма трудно разгадать в чём сущность проблемы.
§3.4. Интерфейс между сетевым и транспортным уровнем

(сетевой интерфейс)

Сетевой интерфейс (рис.1) должен обеспечивать полный доступ ко всем программным средствам IP-модуля, включая те, которые реализуют дополнительные функции и определяют параметры “TOS” и “TTL”. Программный модуль, реализующий функции транспортного уровня (транспортный модуль), должен быть способен, либо самостоятельно устанавливать необходимые параметры через интерфейс, либо формировать “канал” для их передачи от прикладного процесса (модуля), либо реализовывать оба этих способа.

Прикладным системам рекомендуется реализовать оба этих способа, если конечно они приемлемы, и даже тогда, когда эти способы могут быть не совсем эффективны (например, параметр “TOS”). Такой подход “заставит” эти способы стать эффективными и, следовательно, полезными, причём без огромного числа перенастроек самого ПО ГВМ.

Рассмотрим сетевой интерфейс концептуальной точки зрения, как совокупность запрашивающих процедур (set of procedure calls). Эта совокупность процедур является дополнительной информацией в той, которая представлена в стандарте RFC-791:

  • отправка IP-пакета (Send Datagram)

SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result ) ,

где представленные параметры взяты из стандарта RFC-791. Параметр Id является необязательным;

  • получение IP-пакета (Receive Datagram)

RECV(BufPTR, prot => result, src, dst, SpecDest, TOS, len, opt) .

Все параметры взяты из стандарта RFC-791, за исключениемSpecDest — специфический IP-адрес получателя в IP-пакете.

Итоговый параметр dst содержит IP-адрес получателя из IP-пакета. Так как при передаче может использоваться широковещательный или групповой режим, то обязательно должен передаваться параметр SpecDest (не указан в стандарте RFC-791). Параметр opt включает все дополнительные функции, содержащиеся в принятом IP-пакете. Все параметры должны доставляться на транспортный уровень;

  • выбор IP-адреса источника (Select Source Address)

GET_SRCADDR(remote, TOS) -> local ,

где remote — удалённый IP-адрес, TOS — категория обслуживания IP-пакета, local — локальный IP-адрес;

  • поиск максимальных размеров IP-пакета (Find Maximum Datagram Sizes)

GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S ,

где MMS_R — максимальный размер принятого транспортного блока, MMS_S — максимальный размер переданного транспортного блока;

  • уведомление об успешной доставке (Advice on Delivery Success)

ADVISE_DELIVPROB(sense, local, remote, TOS) ,

где параметр sense — однобитовый флаг, который указывает на успешную (или нет) доставку;

  • отправка ICMP-сообщения (Send ICMP Message)

SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt) -> result ,

все параметры представлены в стандарте RFC-791.

Передача параметра Id является не обязательной. Программный модуль транспортного уровня должен обеспечивать отправку некоторых ICMP-сообщений: “Порт не достижим” или любые сообщения-запросы. Конечно, эта функция могла быть представлена как отдельный случай процедуры вызова “SEND ( )”. Однако, в данном стандарте она рассмотрена отдельно для “ясности”.

  • приём ICMP-сообщения (Receive ICMP Message)

RECV_ICMP(BufPTR ) -> result, src, dst, len, opt ,

где все параметры взяты из стандарта RFC-791.

Программный IP-модуль должен транслировать некоторые ICMP-сообщения на соответствующий программный модуль транспортного уровня. Конечно, эта функция могла быть представлена как отдельный случай процедуры приёма “RECV( )”. Однако, в данном стандарте она рассмотрена отдельно для “ясности”.

При передаче ICMP-сообщения об ошибке данные, которые подлежат трансляции, должны быть включены в соответствующий IP-заголовок и плюс все октеты соответствующего сообщения, которые были включены в оригинальное ICMP-сообщение. Эти данные будут использоваться программным модулем транспортного уровня для выделения информации о состоянии соединения, если таковая имело место.

В частности, обязательной передаче подлежат следующие ICMP-сообщения:

  • Destination Unreachable” — получатель недостижим;

  • SourceQuench” — источник не отвечает;

    • Echo Reply” — Эхо-ответ на эхо-запрос (на ICMP-интерфейс пользователя, за исключением эхо-запроса, отправленного программным IP-модулем);

    • TimestampReply” — метка времени (на ICMP-интерфейс пользователя);

  • TimeExceeded” — время просрочено.

С течением времени функции сетевого интерфейса (между сетевым и транспортным уровнями) будут расширяться.
§3.5. Требования к ГВМ на сетевом (IP-)уровне

На рис.7 представлена таблица с общими требованиями к ГВМ на сетевом (IP-)уровне.




п/п

Содержание требования

(функция)

Обязательная

Рекомендуемая

Возможная

Не

целесообразная

Запрещённая

1.

Реализация IP- и ICMP-протоколов















2.

Управление удалённой настройкой многоадресного режима на прикладном уровне















3.

Поддержка локального многоадресного режима















4.

Удовлетворять спецификации шлюзов, если ретранслирует IP-пакеты















5.

Настройка параметров коммутации для встроенного программного шлюза1















6.

Настройка параметров коммутации в режиме “по умолчанию” — “не шлюз”1















7.

Автоматическая настройка основана на числе интерфейсов1















8.

Способность регистрировать уничтожаемые IP-пакеты















9.

Запись в счётчик















10.

Уничтожение в режиме “по умолчанию” всех IP-пакетов, у которых указана версия не равная 4 или 6















11.

Проверка контрольной суммы, при не совпадении — уничтожение IP-пакета в режиме “по умолчанию”















12.

Адресация подсетей (RFC-950)















13.

IP-адрес источника должен быть собственный IP-адрес ГВМ















14.

Уничтожение IP-пакета в режиме “по умолчанию” при обнаружении не корректного IP-адреса получателя















15.

Уничтожение IP-пакета в режиме “по умолчанию” при обнаружении не корректного IP-адреса отправителя















16.

Реализация процедуры фрагментации и сборки















17.

Сохранение в поле IP-заголовка одно и тоже значение идентификатора в идентичных IP-пакетах















18.

Разрешать транспортному уровню устанавливать значение “Категория обслуживания” (TOS)















19.

Трансляция принятого значения “Категория обслуживания” (TOS) на транспортный уровень















20.

Использование параметров канального уровня (RFC-795) для отображения в значение “Категория обслуживания” (TOS)















21.

Передача IP-пакета со значением “Время жизни” (TTL), равным нулю















22.

Уничтожение принятых IP-пакетов со значением “Время жизни” (TTL) < 2















23.

Разрешать транспортному уровню устанавливать значение “Время жизни” (TTL)















24.

Фиксированное значение “Время жизни” (TTL) должно быть настраиваемым















25.

Разрешать транспортному уровню транслировать на сетевой уровень дополнительные IP-функции















26.

Трансляция всех дополнительных IP-функции, принятых для верхнего уровня















27.

Сетевой уровень должен в режиме “по умолчанию” игнорировать неизвестные дополнительные IP-функции















28.

Применение дополнительной IP-функции “Безопасность” (Security)















29.

Применение дополнительной IP-функции “Идентификатор потока” (Stream Identifier) при передаче IP-пакета















30.

Игнорирование в режиме “по умолчанию” дополнительной IP-функции “Идентификатор потока” (Stream Identifier)















31.

Применение дополнительной IP-функции “Регистрация маршрута” (Record Route)















32.

Применение дополнительной IP-функции “Метка времени” (Timestamp)















33.

Применение отправителем и получателем дополнительной IP-функции “Маршрут от источника” (Source Route)















34.

Трансляция IP-пакета с завершённым маршрутом от источника на транспортный уровень















35.

Формирование корректного (приемлемого) обратного маршрута















36.

Передача нескольких значений дополнительной IP-функции “Маршрут от источника” (Source Route) в одном IP-заголовке















37.

Уничтожение в режиме “по умолчанию” ICMP-сообщения неизвестного типа















38.

Включение в ICMP-сообщение более 8 октетов из принятого IP-пакета















39.

Включаемые в ICMP-сообщение октеты должны полностью совпадать с принятыми















40.

Транслировать программному модулю, реализующему протокол транспортного уровня, ICMP-сообщение об ошибке, связанной с демультиплексированием (Demux)















41.

Передавать ICMP-сообщение об ошибке, если значение “Категория обслуживания” (TOS) равно нулю















42.

Передавать ICMP-сообщение об ошибке, если получено ICMP-сообщение об ошибке















43.

Передавать ICMP-сообщение об ошибке, если получен IP-пакет с широковещательным или групповым IP-адресом















44.

Передавать ICMP-сообщение об ошибке, если получен IP-пакет, переданный в широковещательном режиме на канальном уровне















45.

Передавать ICMP-сообщение об ошибке, если был получен IP-пакет, содержащий не начальный фрагмент, раньше IP-пакета с последним















46.

Передавать ICMP-сообщение об ошибке, если получен IP-пакет с не однозначным IP-адресом отправителя















47.

Передавать ICMP-сообщения об ошибках во всех иных не запрещённых случаях














1   2   3   4   5   6   7   8   9   10   11


написать администратору сайта