Порядок создания СЗПДн. Требования к сетевым устройствам
 Скачать 1.38 Mb.
|
|
§3.3.5. Доставка (ретрансляция) по маршруту источника ГВМ может функционировать как промежуточный IP-узел на маршруте доставки, который установил источник IP-пакетов, и передавать IP-пакеты на следующий промежуточный IP-узел. Тем не менее, функционируя как шлюз, ГВМ обязана выполнять все соответствующие правила для шлюза, который ретранслирует IP-пакеты по маршруту, установленному их источником (RFC-1009). А из этого следует необходимость выполнения следующих требований: Время жизни IP-пакета (TTL). Значение в поле “TTL” должно уменьшаться на единицу при “прохождении” IP-пакета каждый ретрансляционный шлюз, а сам IP-пакет может уничтожаться, как это определено в стандарте RFC-1009; ICMP-сообщение “получатель недостижим”. ГВМ должна быть способна формировать ICMP-сообщения “получатель недостижим”, используя для этого следующие коды: “4” — (требуется фрагментация, но бит “ DF” имеет значение “1”), когда IP-пакет с маршрутом от его источника не может быть фрагментирован для последующей передачи в сеть получателя; “5” — (маршрут от источника IP-пакета не возможен) когда IP-пакет с маршрутом от его источника не может быть доставлен, например, потому, что возникла проблема маршрутизации или потому, что следующий ретрансляционный участок точного маршрута от источника IP-пакета не связан с присоединённой сетью; IP-адрес отправителя. Ретранслируемый IP-пакет с маршрутом от его источника может (и обычно будет) иметь IP-адрес отправителя, не являющийся ни одним из IP-адресов ГВМ-ретранслятора; Дополнительная функция “Регистрация маршрута” (“RecordRoute”). ГВМ, которая ретранслирует IP-пакет с маршрутом от его источника, содержащий в своём заголовке функцию “Регистрация маршрута”, обязана выполнить эту функцию, если, конечно, для этого имеется место; Дополнительная функция “Метка времени” (“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-)уровне.
|