Порядок создания СЗПДн. Требования к сетевым устройствам
 Скачать 1.38 Mb.
|
|
§3.2. Обзор протоколов сетевого уровня §3.2.1. IP-протокол (InternetProtocol) §3.2.1.1. Версия IP-протокола (RFC-791) Все IP-пакеты, содержащие в поле “Номер версии” IP-заголовка значение не равное четырём, должны уничтожаться “по умолчанию”. Это требование не затрагивает шестую версию IP-протокола. §3.2.1.2. Поверочная сумма (RFC-791) ГВМ должна в обязательном порядке проверять проверочную сумму, размещённую в соответствующем поле IP-заголовка каждого принятого IP-пакета. И в случае отрицательного результата этой проверки, IP-пакет должен уничтожаться “по умолчанию”.
Рис.4. Структура и классы IPv4-адресов §3.2.1.3. IPv4-адресация (RFC-791) В настоящее время существует пять классов IPv4-адресации (рис.4): от класса А (A-адрес) до класса Е (E-адрес). IPv4-адреса класса D (D-адрес) используются только в режиме многоадресности, в то время как класс Е зарезервирован для экспериментального применения. D-адрес представляет собой 28-битовый логический адрес, который присваивается группе ГВМ и может быть, либо постоянным, либо временным. Постоянные D-адреса распределяются IANA (Internet Assigned Number Authority, RFC-1700), хотя временные D-адреса могут присваиваться динамически для временных групп ГВМ. Состав группы определяется динамически с помощью IGMP-протокола (RFC-1112) Рассмотрим специфические варианты A-, B- и C-адресов IPv4-адресации: {номер сети 0, номер ГВМ 0}. Это одна ГВМ в конкретной сети. Этот адрес не должен передаваться кроме одного случая, то есть в качестве адреса источника в рамках процедуры инициализации, с помощью которой ГВМ определяет свой собственный IPv4-адрес; {номер сети 0, номер ГВМ Х}. Специфическая ГВМ в конкретной сети. Этот адрес не должен передаваться кроме одного случая, то есть в качестве адреса источника в рамках процедуры инициализации, с помощью которой ГВМ определяет свой полный IPv4-адрес; {номер сети -1, номер ГВМ -1}. Ограниченный широковещательный адрес. Этот адрес не должен передаваться в качестве адреса источника. IP-пакет с таким адресом получателя будет приниматься каждой ГВМ, присоединённой к физической сети, но он не будет ретранслироваться назад в эту сеть; {номер сети Х, номер ГВМ -1}. Направленный широковещательный адрес для конкретной сети. Этот адрес не должен передаваться в качестве адреса источника; {номер сети Х, номер подсети Х, номер ГВМ -1}. Направленный широковещательный адрес для конкретной подсети. Этот адрес не должен передаваться в качестве адреса источника; {номер сети Х, номер подсети -1, номер ГВМ -1}. Направленный широковещательный адрес для всех подсетей конкретной сети, разделённой на соответствующие подсети. Этот адрес не должен передаваться в качестве адреса источника; {номер сети 127, номер ГВМ любой}. Петлевой адрес внутренней ГВМ. Адреса этой формы не должны использоваться внешней ГВМ. Номер сети “{номер сети Х}” назначается административно (администратором сети), причём его значение должно быть уникальным для внешнего “Internet-пространства”. IPv4-адреса не должны иметь значение “0” или “-1” в любом из полей {номер ГВМ Х}, {номер сети Х} или {номер подсети Х} (за исключение специфических случаев, рассмотренных выше). Это означает, что каждое из полей будет длиной, по крайней мере, в два бита. ГВМ должна обеспечивать протокол разбиения сети на подсети (RFC-950). И в результате адресная маска будет иметь следующую форму: {-1,-1, 0}, — связанную с каждым локальным IP-адресом ГВМ. Когда ГВМ передаёт какой-либо IP-пакет, IP-адресом отправителя должен быть один из её IP-адресов (но не широковещательный или групповой IP-адрес). ГВМ должна в режиме “по умолчанию” уничтожать не предназначенный для неё входящий IP-пакет. Входящий IP-пакет предназначен для ГВМ, если в поле “Адрес получателя” содержится: (один из) IP-адрес(ов) ГВМ; разрешённый для присоединённой сети широковещательный IP-адрес; групповой IP-адрес, если ГВМ входит в состав этой группы, соответствующий определённому входному физическому интерфейсу. В большинстве случаев IP-пакет с широковещательным или групповым IP-адресом получателя обрабатывается только тогда, когда этот IP-адрес является одним из IP-адресов ГВМ. В дальнейшем термин “специфический IP-адрес получателя” используется в качестве эквивалента локального IP-адреса ГВМ. Специфический IP-адрес получателя размещается в поле “Адрес получателя” в заголовке IP-пакета, за исключением широковещательного или группового IP-адреса, и таком случае специфическим IP-адресом получателя является IP-адрес, присвоенный физическому интерфейсу через который поступил IP-пакет. ГВМ должна “по умолчанию” уничтожать входящие IP-пакеты, которые содержат IP-адрес отправителя, не удовлетворяющий правилам, представленным в данном параграфе. Такая проверка подлинности могла быть проведена, либо на сетевом (IP-)уровне, либо любым протоколом транспортного уровня. IP-пакет с некорректным IP-адресом мог быть следствием, либо использования широковещательного режима для однонаправленных IP-пакетов на канальном уровне, либо выхода из строя или некорректной настройки шлюза или ГВМ. С точки зрения Internet-архитектуры цель ГВМ заключалась в признании IP-адресов как 32-битовых номеров без каких-либо свойств, и в отказе от использования алгоритмов, которые требуют знание формата IP-адреса. В противном случае, любое последующее изменение формата или представления IP-адресов потребовало бы внесение изменений в ПО ГВМ. Тем не менее, проверка правомерности использования широковещательных и групповых IP-адресов аннулирует эту цель. Разработчики сетевого ПО и оборудования должны осознавать, что прикладные системы зависят от направленного во все подсети широковещательного IP-адреса (вариант “”), который может быть непригодным в некоторых сетях. В настоящее время широковещательный режим передачи во все подсети не очень широко распространён в шлюзах компаний/вендоров, и даже когда этот режим внедрён, администратор соответствующей сети может исключить его из настроек шлюза. §3.2.1.4. Фрагментация и повторная сборка (RFC-791) Пятиуровневая модель Internet-архитектуры требует, чтобы каждая ГВМ реализовывала функцию повторной сборки §3.2.1.5. идентификация (RFC-791) Если транслируется идентичная копия ранее переданного IP-пакета, то ГВМ может (как необязательная функция) сохранять одно и то же значение в поле “Идентификатор” заголовка каждого IP-пакета/копии. Некоторые эксперты и специалисты в области Internet-протоколов полагают, что когда ГВМ передаёт идентичную копию ранее переданного IP-пакета, то новая копия должна содержать тот же самое значение идентификатора, которое было в оригинале. Это предложение имеет два следующих преимущества: если IP-пакеты фрагментируются и некоторые фрагменты утеряны, то получатель может восстановить весь IP-пакет из фрагментов оригинала и копий; перегруженный шлюз может использовать поле “идентификатор” (и “Номер байта, на котором произведена очередная фрагментация исходного “большого” пакета ”) для уничтожения продублированного IP-пакет из очереди входящих IP-пакетов. Тем не менее, потеря возможных копий IP-пакета в Internet-сети не может быть полностью исключена за счёт повторной передачи фрагментов, с помощью которых при повторной сборке исходных IP-пакетов заполняются их потерянные фрагменты, в то время как другие способы (например, ТСР-протокол, который реализует способ повторной передачи за счёт повторного формирования ТСР-блоков) вообще стараются избегать повторной передачи идентичных IP-пакетов. Более того, считается, что повторная передача IP-пакета с одним и тем же значением в поле “идентификация” не является полезной. К тому же, протоколу транспортного уровня без установления соединений (UDP-протокол) могло бы потребоваться взаимодействия с прикладными программами с целью хранения одного и того же значения в поле “идентификация” в идентичных IP-пакетах. §3.2.1.6. Категория обслуживания IP-пакета (RFC-791) Октет “Категория обслуживания пакета” (“Type-of-Service”) в заголовке IP-пакета разделён на две части (рис.5): субполе “Приоритет” (3 бита). Может принимать восемь значений: от 0 (обычный приоритет) до 7 (сетевое управление); биты (субполе) “D”, “T”, “R”. Они указывают на тип транспортировки, который “запрашивает” пакет (пользователи именуют эти биты “Тип обслуживания”, TOS). Установка этих битов в состояние “1” требует соответственно низкой задержки при передаче пакета (delay), высокой пропускной способности (throughput) и высокой надежности (reliability). Последние два бита не используются.
Рис.5. Кодирование поля “Категория обслуживания пакета” Субполе “Приоритет” предназначалось для прикладных систем министерства обороны США (Department of Defense, DOD) в рамках протоколов Internet-архитектуры (в частности для системы управления и т.п.). Порядок и правила использования этого поля, исключая нулевое значение, не рассматриваются IP-протоколом. Сетевой уровень должен предоставлять транспортному уровню средства управления TOS-субполем в заголовке каждого IP-пакета, подлежащего передаче. В режиме “по умолчанию” эти биты должны быть нулевыми. Целесообразно, чтобы сетевой уровень доставлял значение TOS-субполя транспортному уровню. В настоящее время TOS-субполе играет огромную роль в обеспечении качества и надёжности доставки IP-пакетов. Это субполе используется для управления функционированием шлюзов, а именно — алгоритмами маршрутизации и формирования очереди IP-пакетов, подлежащих передаче. Значение TOS-субполя может также отображаться в идентификаторы качества обслуживания на канальном уровне. Например, такое отображение может применяться для повышения эффективности использование последовательных линий связи при передаче различных классов ТСР-трафика. §3.2.1.7. Время “жизни”IP-пакета в сети (RFC-791) ГВМ запрещается: передавать IP-пакет, если в его заголовке поле “Время “жизни”пакета в сети” (Time-to-Live, TTL) содержит нулевое значение; уничтожать IP-пакет, если в его заголовке TTL-поле содержит значение меньше двух. Сетевой уровень должен предоставлять транспортному уровню средства управления TTL-полем в заголовке каждого подлежащего передаче IP-пакета. Если в TTL-поле используется фиксированное значение, то оно должно быть настраиваемым. Рекомендуемое TTL-значение в режиме “по умолчанию” представлено в RFC-1700. TTL-поле выполняет две функции: ограничение времени “жизни” ТСР-блоков (RFC-793); предотвращение петлевых маршрутов. Несмотря на то, что изначально значение в TTL-поле представляло собой время в секундах, на практике в этом поле размещается число (в двоичной форме) ретрансляционных участков, которое разрешается “пройти” IP-пакету. А любой шлюз при прохождении через него IP-пакета должен уменьшать это число на единицу. Сущность TTL-значения заключается в том, что по его истечению IP-пакет уничтожается шлюзом, а на не ГВМ, для которой предназначен этот IP-пакет. Тем не менее, ГВМ, функционирующие как шлюзы и ретранслирующие IP-пакеты, обязаны выполнять правила использования TTL-значения, предназначенные для шлюзов. Протоколу верхнего уровня может понадобиться установка TTL-значения с целью расширения “диапазона” поиска определённых Internet-ресурсов. Такой поиск может проводиться с помощью специализированных диагностических средств, а также он может быть полезен, например, для обнаружения “ближайшего” сервера определённого класса, использующего групповую IP-адресацию. Соответствующему протоколу транспортного уровня также может потребоваться определение собственной границы максимального TTL-значения для IP-пакетов. Фиксированное TTL-значение должно быть, по крайней мере, существенно больше “Internet-диаметра”, то есть возможного самого длинного маршрута. Наиболее приемлемым значением является примерно удвоенный “Internet-диаметр”, что учитывает продолжающийся рост Internet-сети. §3.2.1.8. Дополнительные функции (RFC-791) Транспортный уровень обязан иметь средства для определения дополнительных IP-функций, которые бы указывались в передаваемых IP-пакетах. Все дополнительные IP-функции (за исключением “NOP” или “END-OF-LIST”), указанные в принимаемых IP-пакетах должны транслироваться на транспортный уровень (или на обработку в программный ICMP-модуль, если IP-пакет содержит ICMP-сообщение). Сетевой и транспортный уровни должны интерпретировать каждый свои дополнительные IP-функции, которые они “понимают” и “по умолчанию” игнорируют другие. Отправка всех дополнительных IP-функций, указанных в принятых IP-пакетах, на транспортный уровень является преднамеренное “нарушение строго разделения функций по уровням” (“violation of strict layering”), которое было разработано для последующего упрощённого встраивания новых IP-функций, затрагивающих функционирование протоколов транспортного уровня. Каждый уровень должен различать любые дополнительные IP-функции, которые касаются обработки данных на этом уровне, и игнорировать оставшиеся дополнительные IP-функции. С этой целью, описание каждой дополнительной IP-функции (за исключением “NOP” или “END-OF-LIST”) должно включать длину субполя этой функции. ГВМ, транслирующие дополнительные IP-функции в групповом режиме (групповая IP-адресация), должны быть “осведомлены” о том, что такая трансляция вносит некоторую неопределённость в содержание определённых дополнительных IP-функций, когда они передаются в комбинации с дополнительной IP-функцией “маршрутизация источника IP-пакета”. Программный модуль сетевого уровня не должен переходить в нештатный режим (не должен блокироваться) в результате приёма IP-пакета, в котором размер поля “Дополнительная IP-функция” превышает допустимый размер. Например, появление ошибочных размеров такого поля приводили некоторые встроенные программные IP-модули в режим “зацикливания”. К некоторым дополнительным IP-функциям предъявляются следующие требования: “Безопасность” (“Security Option”). Некоторые прикладные системы требуют использование этой функции в каждом IP-пакете, но правила её использования не входят в описание данного стандарта; “Идентификаторпотока” (“Stream Identifier Option”). Эта функция в настоящее время не используется, и если все-таки она используется в принятом IP-пакете, то она должна “по умолчанию” игнорироваться; “Исходный маршрут или маршрут от источника” (“Source Route Option”). ГВМ должна реализовывать функцию формирования исходного маршрута, а также должна быть способна функционировать в качестве последнего получателя IP-пакета в исходном маршруте. Если ГВМ получает IP-пакет, который содержит законченный исходный маршрут (то есть, указатель указывает на последнее поле), то IP-пакет достиг своего пункта назначения (получателя). При получении IP-пакета с этой дополнительной функцией значение последней (зафиксированный маршрут) должно быть доставлено на транспортный уровень (или ICMP-процессу обработки сообщений). Этот зафиксированный маршрут будет в дальнейшем использоваться для определения обратного исходного маршрута отправки ответных IP-пакетов. Когда обратный исходный маршрут определён, после этого он должен быть записан в корректной форме, и даже в том случае, когда зафиксированный маршрут включает ГВМ-отправитель. Передача IP-пакета с заголовком, содержащим более одного исходного маршрута, запрещена. Смысл и назначение маршрутизации с использованием нескольких значений дополнительной IP-функции “Исходный маршрут” определяется в описании конкретной прикладной системы. Если IP-пакет с исходным маршрутом фрагментируется, то каждый фрагмент должен содержать копию исходного маршрута. Так как обработка дополнительных IP-функций (включая “Исходный маршрут”) должна предшествовать процедуре повторной сборки исходного IP-пакета, последний не будет восстанавливаться до тех пор, пока он не достигнет последнего пункта назначения. Предположим, что IP-пакет с исходным маршрутом будет транслироваться от ГВМ S до ГВМ D через шлюзы G1, G2, ... Gn. Существует некоторая неопределённость при размещении значения дополнительной IP-функции “Исходный маршрут” в IP-пакете, который будет передаваться ГВМ S, при этом возможны следующие две записи: (A): {>>G2, G3, ... Gn, D} ← корректно (B): {S, >>G2, G3, ... Gn, D} ← не корректно , где символ “” означает указатель. Если будет использоваться запись А, то IP-пакет, принятый в ГВМ D, будет содержать запись: {G1, G2, ... Gn >>}, — в которой ГВМ S и ГВМ D будут иметь IP-адрес отправителя и IP-адрес получателя соответственно. Если бы использовалась запись B, то IP-пакет, принятый в ГВМ D, мог бы содержать для ГВМ S и ГВМ D один и тот же IP-адрес отправителя и IP-адрес получателя, в то время как запись могла бы иметь вид: {S, G1, ...Gn >>}, — то есть ГВМ-отправитель могла бы появиться на первом ретрансляционном участке маршрута в качестве получателя; “Регистрация маршрута” (“Record Route Option”). Данная функция является не обязательной и её использование зависит от конкретной прикладной системы; “Метка времени” (“Timestamp Option”). Данная функция является не обязательной и её использование зависит от конкретной прикладной системы. Если же эта функция используется, то следует придерживаться следующих правил: ГВМ-отправитель, у которой заранее не определены поля для IP-адресов или у которой первый заранее определённый IP-адрес не является адресом её интерфейса, должна записать значение метки времени в поле дополнительной IP-функции “Метка времени”; ГВМ-получатель должна (если это возможно) добавлять текущее значение метки времени к значению, указанному в поле дополнительной IP-функции “Метка времени”, и только потом направлять оба значения на транспортный уровень или в ICMP-процесс для их последующей обработки; значение метки времени должно формироваться по правилам, которые представлены в стандарте ICMP-протокола. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||