Протоколы Internet
Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
10.11 Адреса серверов ведущих фирм, работающих в сфере телекоммуникаций
Семенов Ю.А. (ГНЦ ИТЭФ)
Фирма
Продукт
URL
Максимальный размер поля данных для
4.4.1.1 Адресация IPv6
Семенов Ю.А. (ГНЦ ИТЭФ)
Адресное пространство IPv6 будет распределяться IANA(Internet Assigned Numbers Authority - комиссия по стандартным числам в Интернет [RFC-1881]). В качестве советников будут выступать IAB (internet architecture board - совет по архитектуре Интернет) и IESG (Internet Engineering Steering Group - инженерная группа управления Интернет).
IANA будет делегировать права выдачи IP-адресов региональным сервис-провайдерам, субрегиональным структурам и организациям. Отдельные лица и организации могут получить адреса непосредственно от регионального распределителя или сервис провайдера.
Передача адресного пространства от IANA не является необратимым. Если по мнению IANA распорядитель адресного пространства допустил серьезные ошибки, IANA может аннулировать выполненное ранее выделение.
IANA в этом случае должна сделать все возможное, чтобы не отзывать адреса, находящиеся в активном использовании, за исключением случаев, когда это диктуется техническими соображениями.
Оплата за распределение адресов должна использоваться исключительно на деятельность, непосредственно связанную с выделением адресов, поддержанием соответствующих баз данных и т.д. Адресное пространство само по себе не должно стоить ничего.
Следует избегать монополизации и любых злоупотреблений при распределении IP-v6 адресов. IANA разработает план первичного распределения IPv6 адресов, включая автоматическое выделение адресов индивидуальным пользователям.
IPv6 представляет собой новую версию протокола Интернет (RFC-1883), являющуюся преемницей версии 4 (IPv4; RFC-791). Изменения IPv6 по отношению к IPv4 можно поделить на следующие группы:
Расширение адресации
В IPv6 длина адреса расширена до 128 бит (против 32 в IPv4), что позволяет обеспечить больше уровней иерархии адресации, увеличить число адресуемых узлов, упростить авто-конфигурацию. Для расширения возможности мультикастинг-маршрутизации в адресное поле введено субполе "scope" (группа адресов). Определен новый тип адреса "anycast address" (эникастный), который используется для посылки запросов клиента любой группе серверов. Эникаст адресация предназначена для использования с набором взаимодействующих серверов, чьи адреса не известны клиенту заранее.
Спецификация формата заголовков
Некоторые поля заголовка IPv4 отбрасываются или делаются опционными, уменьшая издержки, связанные с обработкой заголовков пакетов с тем, чтобы уменьшить влияние расширения длины адресов в IPv6.
Улучшенная поддержка расширений и опций
Изменение кодирования опций IP-заголовков позволяет облегчить переадресацию пакетов, ослабляет ограничения на длину опций, и делает более доступным введение дополнительных опций в будущем.
Возможность пометки потоков данных
Введена возможность помечать пакеты, принадлежащие определенным транспортным потокам, для которых отправитель запросил определенную процедуру обработки, например, нестандартный тип TOS (вид услуг) или обработка данных в реальном масштабе времени.
Идентификация и защита частных обменов
В IPv6 введена спецификация идентификации сетевых объектов или субъектов, для обеспечения целостности данных и при желании защиты частной информации.
Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885.
1. Терминология
Узел |
Оборудование, использующее IPv6. |
Маршрутизатор |
Узел, который переадресует пакеты ipv6, которые не адресованы ему непосредственно. |
ЭВМ |
Любой узел, который не является маршрутизатором. |
Верхний уровень |
Протокольный уровень, расположенный непосредственно поверх. В качестве примеров можно привести транспортные протоколы TCP и UDP, протокол управления ICMP, маршрутные протоколы типа OSPF (RFC-2740), а также интернетовские или другие протоколы нижнего уровня инкапсулированные в IPv6, например, IPX, Appletalk, или сам IPv6. |
| Канал | Средство коммуникации или среда, через которую узлы могут взаимодействовать друг с другом на связном уровне, т.е., уровень непосредственно под IPv6. Примерами могут служить Ethernet; PPP; X.25, Frame Relay, или ATM; а также Интернет "туннели", такие как туннели поверх IPv4 или IPv6. |
| Соседи | Узлы, подключенные к общему каналу. |
| Интерфейс | Средство подключения узла к каналу. |
| Адрес | Идентификатор IPv6-уровня для интерфейса или набора интерфейсов. |
| Пакет | Заголовок и поле данных IPv6. |
| MTU канала | Максимальный размер пакета в канале |
| MTU пути | Минимальный MTU канала для пути от узла источника до получателя. |
| Эникастный адрес | Идентификатор набора интерфейсов (обычно принадлежащих разным узлам). Пакет, посланный по такому адресу, доставляется ближайшему интерфейсу (согласно метрики маршрутного протокола) из числа идентифицированных этим адресом. |
/p> Замечание: допустимо (хотя и необычно), что устройство с несколькими интерфейсами может быть сконфигурировано для переадресации пакетов, приходящих через один или несколько интерфейсов. Пакеты, приходящие через остальные интерфейсы, могут при этом отбрасываться. Такие устройства должны выполнять требования протоколов маршрутизации. При получении пакетов, адресованных этому устройству, оно должно вести себя как обычная ЭВМ.
2. Формат заголовка IPv6
Рис. 4.4.1.1.1. Формат заголовка пакета IPv6
| Версия | 4-битный код номера версии Интернет протокола (версия Интернет протокола для IPv6= 6) |
|
Приор . |
4-битный код приоритета |
| Метка потока | 24-битный код метки потока (для мультимедиа) |
| Размер поля данных | 16-битовое число без знака. Несет в себе код длины поля данных в октетах, которое следует сразу после заголовка пакета. Если код равен нулю, то длина поля данных записана в поле данных jumbo, которое в свою очередь хранится в зоне опций. |
| Следующий заголовок | 8-битовый разделитель. Идентифицирует тип заголовка, который следует непосредственно за IPv6 заголовком. Использует те же значения, что и протокол IPv4 [RFC-1700]. |
| Предельное число шагов | 8-битовое целое число без знака. Уменьшается на 1 в каждом узле, через который проходит пакет. При предельном числе шагов, равном нулю, пакет удаляется. |
| Адрес отправителя | 128-битовый адрес отправителя пакета. См. RFC-1884. |
| Адрес получателя | 128-битовый адрес получателя пакета (возможно не конечный получатель, если присутствует маршрутный заголовок). См. RFC-1884. |
Существует три типа адресов:
| unicast: | Идентификатор одиночного интерфейса. Пакет, посланный по уникастному адресу, доставляется интерфейсу, указанному в адресе. |
anycast: |
Идентификатор набора интерфейсов (принадлежащих разным узлам). Пакет, посланный по эникастному адресу, доставляется одному из интерфейсов, указанному в адресе (ближайший, в соответствии с мерой, определенной протоколом маршрутизации). |
| multicast: | Идентификатор набора интерфейсов (обычно принадлежащих разным узлам). Пакет, посланный по мультикастинг-адресу, доставляется всем интерфейсам, заданным этим адресом. |
/p> В IPv6 не существует широковещательных адресов, их функции переданы мультикастинг-адресам.
В IPv6, все нули и все единицы являются допустимыми кодами для любых полей, если не оговорено исключение.
4. Модель адресации
ipv6 адреса всех типов ассоциируются с интерфейсами, а не узлами. Так как каждый интерфейс принадлежит только одному узлу, уникастный адрес интерфейса может идентифицировать узел.
IPv6 уникастный адрес соотносится только с одним интерфейсом. Одному интерфейсу могут соответствовать много IPv6 адресов различного типа (уникастные, эникастные и мультикстные). Существует два исключения из этого правила:
Одиночный адрес может приписываться нескольким физическим интерфейсам, если приложение рассматривает эти несколько интерфейсов как единое целое при представлении его на уровне Интернет.
Маршрутизаторы могут иметь ненумерованные интерфейсы (например, интерфейсу не присваивается никакого IPv6 адреса) для соединений точка-точка, чтобы исключить необходимость вручную конфигурировать и объявлять (advertise) эти адреса. Адреса не нужны для соединений точка-точка маршрутизаторов, если эти интерфейсы не используются в качестве точки отправления или назначения при посылке IPv6 дейтограмм. Маршрутизация здесь осуществляется по схеме близкой к используемой протоколом CIDR в IPv4.
IPv6 соответствует модели IPv4, где субсеть ассоциируется с каналом. Одному каналу могут соответствовать несколько субсетей.
4.1. Представление записи адресов (текстовое представление адресов)
Существует три стандартные формы для представления ipv6 адресов в виде текстовых строк:
Основная форма имеет вид x:x:x:x:x:x:x:x, где 'x' шестнадцатеричные 16-битовые числа.
Примеры:
fedc:ba98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200C:417A
Заметьте, что ненужно писать начальные нули в каждом из конкретных полей, но в каждом поле должна быть, по крайней мере, одна цифра (за исключением случая, описанного в пункте 2.).
Из-за метода записи некоторых типов IPv6 адресов, они часто содержат длинные последовательности нулевых бит. Для того чтобы сделать запись адресов, содержащих нулевые биты, более удобной, имеется специальный синтаксис для удаления лишних нулей. Использование записи "::" указывает на наличие групп из 16 нулевых бит. Комбинация "::" может появляться только при записи адреса. Последовательность "::" может также использоваться для удаления из записи начальных или завершающих нулей в адресе. Например:
| 1080:0:0:0:8:800:200c:417a | уникаст-адрес |
| ff01:0:0:0:0:0:0:43 | мультикаст адрес |
| 0:0:0:0:0:0:0:1 | адрес обратной связи |
| 0:0:0:0:0:0:0:0 | неспецифицированный адрес |
| 1080::8:800:200c:417a | уникаст-адрес |
| ff01::43 | мультикаст адрес |
| ::1 | адрес обратной связи |
| :: | не специфицированный адрес |
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38
или в сжатом виде:
::13.1.68.3
::FFFF:129.144.52.38
4.2. Представление типа адреса
Специфический тип IPv6 адресов идентифицируется лидирующими битами адреса. Поле переменной длины, содержащее эти лидирующие биты, называется префиксом формата (Format Prefix - FP). Исходное назначение этих префиксов следующее (табл. 4.4.1.1.1):
Таблица 4.4.1.1.1
| Назначение | Префикс (двоичный) | Часть адресного пространства |
| Зарезервировано | 0000 0000 | 1/256 |
| Не определено | 0000 0001 | 1/256 |
| Зарезервировано для NSAP | 0000 001 | 1/128 |
| Зарезервировано для IPX | 0000 010 | 1/128 |
| Не определено | 0000 011 | 1/128 |
| Не определено | 0000 1 | 1/32 |
| Не определено | 0001 | 1/16 |
| Не определено | 001 | 1/8 |
| Провайдерские уникаст-адреса | 010 | 1/8 |
| Не определено | 011 | 1/8 |
| Зарезервировано для географических уникаст-адресов | 100 | 1/8 |
| Не определено | 101 | 1/8 |
| Не определено | 110 | 1/8 |
| Не определено | 1110 | 1/16 |
| Не определено | 1111 0 | 1/32 |
| Не определено | 1111 10 | 1/64 |
| Не определено | 1111 110 | 1/128 |
| Не определено | 1111 1110 0 | 1/512 |
| Локальные канальные адреса | 1111 1110 10 | 1/1024 |
| Локальные адреса (site) | 1111 1110 11 | 1/1024 |
| Мультикаст-адреса | 1111 1111 | 1/256 |
Данное распределение адресов поддерживает прямое выделение адресов провайдера, адресов локального применения и мультикастинг-адресов. Зарезервировано место для адресов NSAP, IPX и географических адресов. Оставшаяся часть адресного пространства зарезервирована для будущего использования. Эти адреса могут использоваться для расширения имеющихся возможностей (например, дополнительных адресов провайдеров и т.д.) или новых приложений (например, отдельные локаторы и идентификаторы). Пятнадцать процентов адресного пространства уже распределено. Остальные 85% зарезервированы.
Уникастные адреса отличаются от мультикастных значением старшего октета: значение FF (11111111) идентифицирует мультикастинг-адрес; любые другие значения говорят о том, что адрес уникастный. Эникастные (anycast) адреса берутся из уникастного пространства, и синтаксически неотличимы от них.
4.3. Уникастные адреса
IPv6 уникастный адреса, сходны с традиционными IPv4 адресами при бесклассовой междоменной маршрутизации (Class-less InterDomain Routing - CIDR).
Существует несколько форм присвоения уникастных адресов в IPv6, включая глобальный уникастный адрес провайдера (global provider based unicast address), географический уникастный адрес, NSAP адрес, IPX иерархический адрес, Site-local-use адрес, Link-local-use адрес и IPv4-compatible host address. В будущем могут быть определены дополнительные типы адресов.
Узлы IPv6 могут иметь существенную или малую информацию о внутренней структуре IPv6 адресов, в зависимости от выполняемой узлом роли, (например, ЭВМ или маршрутизатор). Как минимум, узел может считать, что уникастный адрес (включая его собственный адрес) не имеет никакой внутренней структуры. То есть представляет собой 128 битовый неструктурированный образ.
ЭВМ может дополнительно знать о префиксе субсети для каналов, c которыми она соединена, где различные адреса могут иметь разные значения n:
Рис. 4.4.1.1.2
Более сложные ЭВМ могут использовать и другие иерархические границы в уникастном адресе. Хотя простейшие маршрутизаторы могут не знать о внутренней структуре IPv6 уникастных адресов, маршрутизаторы должны знать об одной или более иерархических границах для обеспечения работы протоколов маршрутизации. Известные границы для разных маршрутизаторов могут отличаться и зависят от того, какое положение занимает данный прибор в иерархии маршрутизации.
4.3.1. Примеры уникастных адресов
Примером уникастного адресного формата, который является стандартным для локальных сетей и других случаев, где применимы MAC адреса, может служить:
Рис. 4.4.1.1.3
Где 48-битовый идентификатор интерфейса представляет собой IEEE-802 MAC адрес. Использование IEEE 802 mac адресов в качестве идентификаторов интерфейсов будет стандартным в среде, где узлы имеют IEEE 802 MAC адреса. В других средах, где IEEE 802 MAC адреса не доступны, могут использоваться другие типы адресов связного уровня, такие как E.164 адреса, в качестве идентификаторов интерфейсов.
Включение уникального глобального идентификатора интерфейса, такого как IEEE MAC адрес, делает возможным очень простую форму авто-конфигурации адресов. Узел может узнать идентификатор субсети, получая информацию от маршрутизатора в виде сообщений оповещения, которые маршрутизатор посылает связанным с ним партнерам, и затем сформировать IPv6 адрес для себя, используя IEEE MAC адрес в качестве идентификатора интерфейса для данной субсети.
Другой формат уникастного адреса относится к случаю, когда локальная сеть или организация нуждаются в дополнительных уровнях иерархии. В этом примере идентификатор субсети делится на идентификатор области и идентификатор субсети. Формат такого адреса имеет вид:
Рис. 4.4.1.1.4
Эта схема может быть развита с тем, чтобы позволить локальной сети или организации добавлять новые уровни внутренней иерархии. Может быть, желательно использовать идентификатор интерфейса меньше чем 48-разрядный IEEE 802 MAC адрес, с тем, чтобы оставить больше места для полей, характеризующих уровни иерархии. Это могут быть идентификаторы интерфейсов, сформированные администрацией локальной сети или организации.
4.4. Не специфицированный адрес
Адрес 0:0:0:0:0:0:0:0 называется не специфицированным адресом. Он не должен присваиваться какому-либо узлу. Этот адрес указывает на отсутствие адреса. Примером использования такого адреса может служить поле адреса отправителя любой IPv6 дейтограммы, посланной инициализируемой ЭВМ до того, как она узнала свой адрес.
Не специфицированный адрес не должен использоваться в качестве указателя места назначения IPv6 дейтограмм или в IPv6 заголовках маршрутизации.
4.5. Адрес обратной связи
Уникастный адрес 0:0:0:0:0:0:0:1 называется адресом обратной связи. Он может использоваться для посылки IPv6 дейтограмм самому себе. Его нельзя использовать в качестве идентификатора интерфейса.
Адрес обратной связи не должен применяться в качестве адреса отправителя в IPv6 дейтограммах, которые посылаются за пределы узла. IPv6 дейтограмма с адресом обратной связи в качестве адреса места назначения не может быть послана за пределы узла.
4.6. IPv6 адреса с вложенными IPv4 адресами
Алгоритмы IPv6 включают в себя механизм (для ЭВМ и маршрутизаторов) организации туннелей для IPv6 пакетов через маршрутную инфраструктуру IPv4. Узлам IPv6, которые используют этот метод, присваиваются специальные IPv6 уникастные адреса, которые в младших 32 битах содержат адрес IPv4. Этот тип адреса называется "IPv4-compatible IPv6 address" и имеет формат, изображенный на рис. 4.4.1.1.5:
Рис. 4.4.1.1.5
Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется "IPv4-mapped IPv6 address" и имеет формат показанный на рис. 4.4.1.1.6:
Рис. 4.4.1.1.6
4.7. NSAP адреса
Соответствие NSAP адреса IPv6 адресам выглядит следующим образом (рис. 4.4.1.1.7):
Рис. 4.4.1.1.7
4.8. IPX Адреса
Соответствие IPX и IPv6 адресов показано ниже на рис. 4.4.1.1.8:
Рис. 4.4.1.1.8
4.9. Провайдерские глобальные уникаст-адреса
Глобальный уникаст-адрес провайдера имеет назначение, описанное в [ALLOC]. Исходное назначение этих уникаст-адресов аналогично функции IPv4 адресов в схеме CIDR [см. CIDR]. Глобальный IPv6 уникаст-адрес провайдера имеет формат, отображенный ниже на рис. 4.4.1.1.9:
Рис. 4.4.1.1.9. Глобальный адрес провайдера
Старшая часть адреса предназначена для определения того, кто определяет часть адреса провайдера, подписчика и т.д.
Идентификатор регистрации определяет регистратора, который задает провайдерскую часть адреса. Термин "префикс регистрации" относится к старшей части адреса, включая поле идентификатор регистрации (ID).
Идентификатор провайдера задает специфического провайдера, который определяет часть адреса подписчика. Термин "префикс провайдера" относится к старшей части адреса включая идентификатора провайдера.
Идентификатор подписчика позволяет разделить подписчиков, подключенных к одному и тому же провайдеру. Термин "префикс подписчика" относится к старшей части адреса, включая идентификатор подписчика.
Часть адреса интра-подписчик определяется подписчиком и организована согласно местной топологии Интернет подписчика. Возможно, что несколько подписчиков пожелают использовать область адреса интра-подписчик для одной и той же субсети и интерфейса. В этом случае идентификатор субсети определяет специфический физический канал, а идентификатор интерфейса - определенный интерфейс субсети.
4.10. Локальные уникаст-адреса IPv6
Существует два типа уникастных адресов локального использования. Имеется локальные адреса сети и канала. Локальный адрес канала предназначен для работы с одним каналом, а локальный адрес сети - с одной локальной сетью (site). Локальный IPv6 уникаст-адрес канала имеет формат, отображенный ниже на рис. 4.4.1.1.10:
Рис. 4.4.1.1.10. Локальный адрес канала
Локальные адреса канала предназначены для обращения через определенный канал, например, для целей авто-конфигурации адресов, поиска соседей или в случае отсутствия маршрутизатора. Маршрутизаторы не должны переадресовывать пакеты с локальными адресами отправителя. Локальный адрес сети имеет формат, показанный на рис. 4.4.1.1.11:
Рис. 4.4.1.1.11. Локальный адрес сети
Локальные адреса сети могут использоваться для локальных сетей или организаций, которые (пока еще) не подключены к глобальному Интернет. Им не нужно запрашивать или “красть” префикс адреса из глобального адресного пространства Интернет. Вместо этого можно использовать локальный адрес сети IPv6. Когда организация соединяется с глобальным Интернет, она может сформировать глобальные адреса путем замещения локального префикса сети префиксом подписчика.
Маршрутизаторы не должны переадресовывать пакеты с локальными адресами сети отправителя.
4.11. Эникаст-адреса
Эникаст-адрес IPv6 является адресом, который приписан нескольким интерфейсам (обычно принадлежащим разным узлам), при этом пакет, посланный по эникастному адресу, будет доставлен ближайшему интерфейсу в соответствии с метрикой протокола маршрутизации.
Эникастные адреса выделяются из уникастного адресного пространства, и используют один из известных уникастных форматов. Таким образом эникастные адреса синтаксически неотличимы от уникастных адресов. Когда уникастный адрес приписан более чем одному интерфейсу, он превращается в эникастный адрес и узлы, которым он приписан, должны быть сконфигурированы так, чтобы распознавать этот адрес.
Для любого эникастного адреса существует адресный префикс P, который определяет топологическую область, где находятся все соответствующие ему интерфейсы. В пределах области, заданной P, каждый член эникастной (anycast) группы должен быть объявлен, как отдельный вход в маршрутной системе; вне области, заданной P, эникастный адрес может быть занесен в маршрутную запись для префикса p.
Заметим, что в худшем случае префикс P эникастной группы (anycast set) может быть нулевым, т.e., члены группы могут не иметь никакой топологической локальности. В этом случае эникастный адрес должен объявляться как отдельная маршрутная единица (separate routing entry) по всему Интернет, что представляет собой серьезное ограничение, так как число таких "глобальных" эникастных адресов не может быть большим.
Одним ожидаемым приложением эникастных адресов является идентификация набора маршрутизаторов, принадлежащих Интернет сервис провайдеру. Такие адреса в маршрутном заголовке IPv6 могут использоваться в качестве промежуточных, чтобы обеспечить доставку пакета через определенного провайдера или последовательность провайдеров. Другим возможным приложением может стать идентификация набора маршрутизаторов, связанных с определенной субсетью, или набора маршрутизаторов, обеспечивающих доступ в определенный домен.
Существует ограниченный опыт широкого применения эникастных Интернет адресов, некоторые возможные осложнения и трудности рассмотрены в [anycst]. Имеются следующие ограничения при использовании эникастных IPv6 адресов:
Эникастный адрес не может использоваться в качестве адреса отправителя в ipv6 пакете.
Эникастный адрес не может быть приписан ЭВМ IPv6, таким образом, он может принадлежать только маршрутизатору.
4.11.1. Необходимые эникаст-адреса
Эникаст-адрес маршрутизатора субсети предопределен и имеет формат, отображенный на рис. 4.4.1.1.12:
Рис. 4.4.1.1.12
Префикс субсети в эникастном адресе является префиксом, который идентифицирует определенный канал. Этот эникастный адрес является синтаксически идентичным уникастному адресу для интерфейса канала с идентификатором интерфейса равным нулю.
Пакеты, посланные группе маршрутизаторов с эникастным адресом, будут доставлены всем маршрутизатам субсети. При этом все маршрутизаторы субсети должны поддерживать работу с эникастными адресами. Реальный обмен будет осуществлен лишь с тем маршрутизатором, который ответит первым.
Эникастный адрес маршрутизатора субсети предполагается использовать в приложениях, где необходимо взаимодействовать с одним из совокупности маршрутизаторов удаленной субсети. Например, когда мобильный хост хочет взаимодействовать с одним мобильным агентом в его “домашней” субсети.
4.12. Мульткаст-адреса
Мультикастинг-адрес IPv6 является идентификатором для группы узлов. Узел может принадлежать к любому числу мультикастинг групп. Мультикастинг-адреса имеют следующий формат (рис. 4.4.1.1.13):
Рис. 4.4.1.1.13
11111111 в начале адреса идентифицирует адрес, как мультикатинг-адрес.
Рис. 4.4.1.1.14
Старшие 3 флага зарезервированы и должны быть обнулены.
t = 0 указывает на то, что адрес является стандартным ("well-known") мультикастным, официально выделенным для глобального использования в Интернет.
T = 1 указывает, что данный мультикастинг-адрес присвоен временно ("transient").
Поле scope представляет собой 4- битовый код мультикастинга, предназначенный для определения предельной области действия мультикастинг-группы. Допустимые значения:
0 зарезервировано
1 Область действия ограничена локальным узлом
2 Область действия ограничена локальным каналом
3 (не определено)
4 (не определено)
5 Область действия ограничена локальной сетью
6 (не определено)
7 (не определено)
8 Область действия ограничена локальной организацией
9 (не определено)
A (не определено)
B (не определено)
C (не определено)
D (не определено)
E глобальные пределы (global scope)
F зарезервировано
Идентификатор группы идентифицирует мультикастинг-группы, постоянной или переходной (transient), в пределах заданных ограничений (scope).
Значение постоянно присвоенного мультикастинг-адреса не зависит от значения поля scope. Например, если "NTP servers group" присвоен постоянный мультикастинг адрес с идентификатором группы 43 (hex), тогда:
ff01:0:0:0:0:0:0:43 означает, что все ntp серверы одного и того же узла рассматриваются как отправители.
FF02:0:0:0:0:0:0:43 означает, что все NTP серверы работают с тем же каналом, что и отправитель.
FF05:0:0:0:0:0:0:43 означает, что все NTP серверы принадлежат той же сети, что и отправитель.
FF0E:0:0:0:0:0:0:43 означает, что все NTP серверы находятся в Интернет.
Непостоянно выделенные мультикаст-адреса имеют значение только в пределах данного ограничения (scope). Например, группа, определенная непостоянным локальным мультикаст-адресом FF15:0:0:0:0:0:0:43, не имеет никакого смысла для другой локальной сети или непостоянной группы, использующей тот же групповой идентификатор с другим scope, или для постоянной группы с тем же групповым ID.
Мультикастинг адреса не должны использоваться в качестве адреса отправителя в IPv6 дейтограммах или встречаться в любых заголовках маршрутизации.
4.12.1. Предопределенные мультикаст-адреса
Приведенные ниже мультикаст-адреса являются зарезервированными (предопределенными):
ff00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0
Перечисленные выше мультикаст-адреса зарезервированы и не будут присваиваться каким-либо мультикаст-группам.
Адреса для обращения ко всем узлам:
FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1
Приведенные выше адреса идентифицируют группу, включающую в себя все IPv6 узлы в пределах группы 1 (локальные узлы) или 2 (локально связанные узлы).
Адреса всех маршрутизаторов:
FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
Приведенные выше мультикаст-адреса идентифицируют группу всех IPv6 маршрутизаторов в пределах области 1 (локальные узлы) или 2 (связанные локально узлы).
DHCP server/relay-agent: FF02:0:0:0:0:0:0:C
Приведенные выше мультикастинг-адреса идентифицируют группу всех IPv6 DHCP серверов и транзитных агентов в пределах области (scope) 2 (локальный канал).
Адрес активного узла (solicited-node): FF02:0:0:0:0:1:xxxx:xxxx
Приведенный выше мультикаст-адрес вычислен как функция уникастного и эникастного адресов узла. Мультикаст-адрес активного узла (solicited-node) сформирован из младших 32 бит адреса (уникастного или эникастного) добавлением 96 битного префикса FF02:0:0:0:0:1. В результате получен мультикастинг адрес, охватывающий интервал:
ff02:0:0:0:0:1:0000:0000
до
FF02:0:0:0:0:1:FFFF:FFFF
Например, код мультикаст-адреса активного узла (solicited node), соответствующий IPv6 адресу 4037::01:800:200E:8C6C, равен FF02::1:200E:8C6C. IPv6 адреса, которые отличаются только старшими разрядами, например, из-за множественных старших префиксов, соответствующих разным провайдерам, будут совпадать с адресом активного узла, что сокращает число мультикаст-групп, к которым узел должен присоединиться.
4.13. Необходимые адреса узлов
ЭВМ должна распознавать следующие адреса, как обращенные к нему:
Её локальный адрес канала для каждого из интерфейсов
Выделенные уникаст-адреса
Адрес обратной связи
Мультикастинг-адрес для обращения ко всем узлам
Мультикастинг-адрес активного узла (solicited-node multicast address) для каждого из приписанных ей уникаст и эникастных адресов
Мультикаст-адреса всех групп, к которым принадлежит ЭВМ.
Маршрутизатор должен распознавать следующие адреса (as identifying itself):
Его локальный адрес канала для каждого из интерфейсов
Выделенные уникаст-адреса
Адрес обратной связи
Эникастные адреса маршрутизатора субсети для каналов, где он имеет интерфейсы.
Все другие эникастные адреса, которые использовались при маршрутизации.
Мультикастинг-адрес для обращения ко всем узлам
Мультикастинг-адрес для обращения ко всем маршрутизаторам
Мультикаст-адрес активного узла (solicited-node multicast address) для каждого приписанного ему уникаст и эникастного адресов.
Мультикастные адреса всех прочих групп, принадлежащих маршрутизатору.
Приложение должно предопределить только следующие адресные префиксы:
Не специфицированный адрес
Адрес обратной связи
Мультикаст-префикс (ff)
Локально используемые префиксы (link-local и site-local)
Предопределенные мультикаст-адреса
Префиксы, совместимые с IPv4
Приложения должны считать все остальные адреса уникастными, если противоположное не оговорено при конфигурации (например, эникастные адреса).
5. Заголовки расширения IPv6
В IPv6, опционная информация уровня Интернет записывается в отдельных заголовках, которые могут быть помещены между IPv6 заголовком и заголовком верхнего уровня пакета. Существует небольшое число таких заголовков, каждый задается определенным значением кода поля следующий заголовок. В настоящее время определены заголовки: маршрутизации, фрагментации, аутентификации, инкапсуляции, опций hop-by-hop, места назначения и отсутствия следующего заголовка. Как показано в примерах ниже, IPv6 пакет может нести нуль, один, или более заголовков расширения, каждый задается предыдущим полем следующий заголовок (рис. 4.4.1.1.15):
Рис. 4.4.1.1.15. Структура вложения пакетов для IPv6
Заголовки расширения не рассматриваются и не обрабатываются узлами по пути доставки. Содержимое и семантика каждого заголовка расширения определяет, следует или нет обрабатывать следующий заголовок. Следовательно, заголовки расширения должны обрабатываться строго в порядке их выкладки в пакете. Получатель, например, не должен просматривать пакет, искать определенный тип заголовка расширения и обрабатывать его до обработки предыдущих заголовков.
Единственное исключение из этого правила касается заголовка опций hop-by-hop, несущего в себе информацию, которая должна быть рассмотрена и обработана каждым узлом по пути доставки, включая отправителя и получателя. Заголовок опций hop-by-hop, если он присутствует, должен следовать непосредственно сразу после IPv6-заголовка. Его присутствие отмечается записью нуля в поле следующий заголовок заголовка IPv6.
Если в результате обработки заголовка узлу необходимо перейти к следующему заголовку, а код поля следующий заголовок не распознается, необходимо игнорировать данный пакет и послать соответствующее сообщение ICMP (parameter problem message) отправителю пакета. Это сообщение должно содержать код ICMP = 2 ("unrecognized next header type encountered " - встретился нераспознаваемый тип следующего заголовка) и поле - указатель на не узнанное поле в пакете. Аналогичные действия следует предпринять, если узел встретил код следующего заголовка равный нулю в заголовке, отличном от IPv6-заголовка.
Каждый заголовок расширения имеет длину кратную 8 октетам. Многооктетные поля в заголовке расширения выравниваются в соответствии с их естественными границами, т.е., поля с шириной в n октетов помещаются в n октетов, начиная с начала заголовка, для n = 1, 2, 4 или 8.
IPv6 включает в себя следующие заголовки расширения:
Опции hop-by-hop
Маршрутизация (routing;тип 0)
Фрагмент
Опции места назначения
Проверка прав доступа (authentication)
Поле безопасных вложений (encapsulating security payload)
Последние два описаны в RFC-1826 и RFC-1827.
5.1. Порядок заголовков расширения
Когда используется более одного заголовков расширения в одном пакете, рекомендуется помещать их в следующем порядке:
IPv6 заголовок
Заголовок опций hop-by-hop
Заголовок опций места назначения (destination options header, (1) )
Заголовок маршрутизации
Заголовок фрагмента
Заголовок authentication (2)
Заголовок безопасных вложений (encapsulating security payload, (2) )
Заголовок опций места назначения (destination options header (3) )
Заголовок верхнего уровня.
(1) для опций, которые должны обрабатываться по адресу, указанному в поле IPv6 destination address и во всех узлах, перечисленных в заголовке маршрутизации.
(2) дополнительные рекомендации относительно порядка заголовков authentication и encapsulating security payload приведены в RFC-1827.
(3) для опций, которые должны обрабатываться при достижении пакетом конечной точки маршрута.
Каждый заголовок расширения должен встречаться не более одного раза, исключение представляет собой заголовок опций места назначения, который должен быть представлен дважды (один раз перед заголовком маршрутизации и второй раз перед заголовком верхнего уровня).
Если заголовок верхнего уровня представляет собой еще один IPv6 заголовок (в случае туннелирования IPv6 или инкапсуляции в IPv6), за ним может следовать его собственный заголовок расширения.
Узлы IPv6 должны принимать и пытаться обработать заголовки расширения в любом порядке, встречающиеся любое число раз в пределах одного пакета, за исключением заголовка опций типа hop-by-hop, который может появляться только непосредственно за IPv6 заголовком.
6. Опции
Два из определенных в настоящее время заголовков расширения - заголовок опций hop-by-hop и заголовок опций места назначения - несут в себе переменное число TLV-кодированных (type-length-value) опций следующего формата (Рис. 4.4.1.1.16):
Рис. 4.4.1.1.16 Формат опций
| Тип опции | 8-битовый идентификатор типа опции. |
| Длина опции | 8-битовое целое число без знака. Длина поля данных опции в октетах. |
| Данные опции | Поле переменной длины. Данные зависят от типа опции. |
/p> Последовательность опций в заголовке должна обрабатываться строго в соответствии с их порядком записи.
Идентификаторы типа опций кодируются так, что их старшие два бита характеризуют операцию, которая должна быть выполнена, если узел не узнает тип опции:
| 00 | обойти эту опцию и продолжить обработку заголовка. |
| 01 | выбросить данный пакет. |
| 10 | выбросить данный пакет и вне зависимости от того, является ли адрес назначения мультикастинговым, послать отправителю ICMP-пакет с кодом parameter problem (код=2), с указателем на не узнанный код опции. |
| 11 | выбросить данный пакет и, если адрес места назначения не мультикастинговый, послать отправителю icmpпакет с кодом parameter problem (код=2) с указателем на не узнанный код опции. |
0 - Данные опции не меняют маршрута
1 - Информация опции может изменить маршрут.
Отдельные опции могут требовать определенного выравнивания, с тем, чтобы обеспечить выкладку мультиоктетного значения данных поля опции. Требование выравнивания опции описывается с помощью выражения xn+y, означающего, что поле тип опции должно находиться через целое число, кратное x октетам плюс y октетов (отсчет от начала заголовка). Например:
| 2n | означает любое двухоктетное смещение от начала заголовка. |
| 8n+2 | означает любое 8-октетное смещение от начала заголовка плюс 2 октета. |
Опция Pad1 (выравнивание не требуется)
Опция Pad1 используется для введения одного октета заполнителя в зону опций заголовка. Если требуется более одного октета, используется опция Padn.
Опция padn (выравнивание не требуется)
Рис. 4.4.1.1.17
Опция Padn используется для введения двух и более октетов заполнителей в поле опций заголовка. Для n октетов заполнителя поле OPT data Len содержит значение n-2, а поле данных опции состоит из n-2 нулевых октетов
6.1. Опции заголовка Hop-by-Hop (шаг за шагом)
Заголовок опций hop-by-hop (шаг за шагом) используется для опционной информации, которая просматривается каждым узлом по пути доставки. Заголовок опций hop-by-hop идентифицируется кодом поля следующий заголовок 0 в IPv6 заголовке и имеет формат (рис. 4.4.1.1.18):
Рис. 4.4.1.1.18. Формат заголовка опций hop-by-hop
| Следующий заголовок | 8-битовый селектор. Определяет тип заголовка, который следует непосредственно за заголовком опций hop-by-hop. Использует те же значения поля протоколов, что и IPv4 [RFC-1700] |
| HDR EXT LEN | 8-битовое число без знака. Длина заголовка поля опций hop-by-hop в октетах, исключая первые 8 октетов. |
| Опции | Поле переменной длины. Содержит один или более TLV-закодированных опций. |
| Опция Jumbo Payload | (необходимо выравнивание: 4n + 2) |
Рис. 4.4.1.1.19.
Опция Jumbo payload используется для посылки пакетов IPv6 с полем данных, превосходящим 65535 октетов. Длина Jumbo Payload характеризует длину пакета в октетах, исключая заголовок IPv6, но включая заголовок опций hop-by-hop; Это поле должно содержать код более чем 65535. Если получен пакет с опцией Jumbo payload, содержащей код длины меньше или равный 65535, посылается сообщение ICMP (parameter problem, код 0) с указателем на старший октет поля длины Jumbo payload.
Поле длины Payload length IPv6 заголовка должно быть равно нулю для каждого пакета с опцией Jumbo payload. Если получен пакет с корректным значением опции Jumbo Payload и ненулевым кодом длины поля данных, посылается сообщение ICMP (parameter problem код 0) с указателем на поле тип опции.
Опция Jumbo payload не может использоваться в пакетах, которые несут в себе заголовок фрагмента. Если заголовок фрагмента встретится в пакете, содержащем корректную опцию jumbo payload, посылается сообщение ICMP (parameter problem, код 0) с указателем на первый октет заголовка фрагмента.
Приложения, которые не поддерживают опцию Jumbo Payload, не могут иметь интерфейсы для каналов с MTU больше 65575 (40 октетов IPv6 заголовка плюс 65535 октетов данных).
7. Маршрутный заголовок
Заголовок маршрутизации используется отправителем, чтобы заставить пакет посетить один или более промежуточных узлов на пути к месту назначения. Эта функция схожа с опцией принудительной маршрутизации в протоколе IPv4. Заголовок маршрутизации идентифицируется кодом 43 поля следующий заголовок предыдущего заголовка и имеет формат:
| Следующий заголовок | 8-битовый селектор. Определяет тип заголовка, который следует непосредственно за заголовком маршрутизации. Использует те же коды протоколов, что и IPv4 [RFC-1700]. |
| hdr ext len | 8-битовое целое без знака. Длина заголовка маршрутизации выражается в 8-октетных блоках, и не включает в себя первые 8 октетов. |
| Тип маршрутизации | 8-битовый идентификатор конкретного варианта маршрутизации |
| Оставшиеся сегменты | 8-битовое число без знака. Число остающихся сегментов пути, т.e. число промежуточных узлов, которые должны быть посещены пакетом по пути к месту назначения. |
| Данные, зависящие от типа | Поле переменной длины, формат зависит от кода поля тип маршрутизации, а длина определяется заголовком маршрутизации и кратна 8 октетам. |
Если число оставшихся сегментов пути равно нулю, узел должен проигнорировать заголовок маршрутизации и продолжить работу со следующим заголовком, чей тип указан в поле следующий заголовок заголовка маршрутизации.
Если число оставшихся сегментов пути не равно нулю, узел должен выбросить пакет и послать сообщение ICMP (parameter problem, код 0) с указателем на поле не узнанного типа маршрутизации. Заголовок маршрутизации типа 0 имеет следующий формат (рис. 4.4.1.1.20):
Рис. 4.4.1.1.20. Формат заголовка маршрутизации типа 0
| Следующий заголовок | 8-битовый селектор. Идентифицирует тип заголовка, следующего непосредственно за заголовком маршрутизации. Использует те же коды протоколов, что и IPv4 [RFC-1700]. |
| hdr ext len | 8-битовое целое без знака. Длина заголовка маршрутизации в 8-октетных блоках, исключая первые 8 октетов. Для заголовков маршрутизации типа 0 hdr ext len равна удвоенному числу адресов в заголовке, должно быть четным числом меньше или равным 46. |
| Тип маршрутизации | 0. |
| Оставшиеся сегменты | 8-битовое целое без знака. Число оставшихся сегментов пути, т.e., число узлов, которые следует посетить на пути к месту назначения. Максимально допустимое число = 23 |
| Резерв | 8-битовое поле резерва. Инициализируется нулем при передаче и игнорируется при приеме. |
| strict/loose bit map | 24-битовый код-маска, биты пронумерованы, начиная с 0 до 23, слева направо. Для каждого из сегментов пути указывает должен ли следующий узел быть соседом: 1 означает strict (должен быть соседом), 0 означает пропустить (не должен быть соседом). |
| Адрес[1..n] | Вектор 128-битовых адресов, пронумерованных с 1 до n. |
/p> Мультикастинг-адреса не должны встречаться в заголовке маршрутизации типа 0, или в поле места назначения IPv6 пакета, несущего в себе заголовок маршрутизации типа 0.
Если бит 0 поля Strict/loose bit map имеет значение 1, поле адреса места назначения IPv6 заголовка в исходном пакете должно идентифицировать соседа. Если бит 0 имеет значение 0, отправитель может использовать любой легальный не мультикастинговый адрес в качестве адреса места назначения.
Биты с номерами более n, где n - число адресов в заголовке маршрутизации, должны быть обнуляться отправителем и игнорироваться получателем.
Заголовок маршрутизации не рассматривается и не анализируется до тех пор, пока пакет не достигнет места назначения, указанного в поле IPv6 заголовка. Узел, указанный в поле следующий заголовок заголовка, которому принадлежит модуль заголовка маршрутизации, реализует следующий алгоритм:
Если оставшееся число сегментов = 0
{ продолжить обработку следующего заголовка пакета, чей тип задан полем следующий заголовок заголовка маршрутизации }
else если HDR ext len является нечетным или больше 46,
{посылается сообщение ICMP (parameter problem, код 0) с указателем на поле HDR #EXT LEN, пакет выбрасывается}
else
{ вычислить n, число адресов в заголовке маршрутизации, для этого код HRD EXT LEN делится на 2
Если число оставшихся сегментов пути больше n,
{послать сообщение ICMP (parameter problem, код 0) с указанием на поле числа оставшихся сегментов пути }
else
{ уменьшить число оставшихся сегментов пути на 1;
Вычислить i, индекс следующего адреса, который следует посетить, для этого вычесть число оставшихся сегментов пути из n
Если адрес [i] или адрес места назначения IPv6 являются мультикастинговыми
{ выбросить пакет }
else { поменять местами адрес места назначения IPv6 и адрес[i]
если бит i поля strict/loose bit map имеет значение 1 и новый адрес места назначения не является адресом узла соседа
{ послать сообщение ICMP destination unreachable -- not a neighbor
и выбросить пакет }
else если код IPv6 hop limit меньше или равен 1
{послать сообщение icmp time exceeded -- hop limit exceeded in transit message и выбросить пакет }
else { уменьшить hop limit на 1
повторно направить пакет модулю IPv6 для отправки новому адресату }
}
}
}
В качестве примера работы приведенного выше алгоритма, рассмотрим случай, когда узел отправителя s посылает пакет получателю D, используя заголовок маршрутизации, чтобы заставить пакет пройти через промежуточные узлы I1, I2 и I3. Значения кодов полей заголовка IPv6 и заголовка маршрутизации для каждого из сегментов пути принимают следующие значения:
При движении пакетов от S к I1:
| Адрес отправителя = S | Hdr Ext Len = 6 |
| Адрес получателя = I1 | Число оставшихся сегментов пути = 3 |
| Адрес[1] = I2 | |
|
Если бит 0 bit map равен 1, s и i1 должны быть соседями; это проверяется узлом S |
Адрес[2] = I3 Адрес[3] = d |
| Адрес отправителя = s | Hdr Ext Len = 6 |
| Адрес получателя = I2 | Число оставшихся сегментов пути = 2 |
| Адрес[1] = I1 | |
|
Если бит 1 bit map равен 1, I1 и I2 должны быть соседями; это проверяется узлом I1 |
Адрес[2] = i3 Адрес[3] = D |
| Адрес отправителя = S | Hdr Ext Len = 6 |
| Адрес получателя = I3 |
Число оставшихся сегментов пути = 1 Адрес[1] = I1 |
|
Если бит 2 bit map равен 1, I2 и I3 должны быть соседями; это проверяется узлом I2 |
Адрес[2] = I2 |
| Адрес[3] = D |
| Адрес отправителя = S | Hdr Ext Len = 6 |
| Адрес получателя = D |
Число оставшихся сегментов пути = 0 Адрес[1] = I1 |
| Если бит 3 bit map равен 1, I3 и D должны быть соседями; это проверяется узлом I3 |
Адрес[2] = I2 Адрес[3] = i3 |
Заголовок фрагмента используется отправителем IPv6 для посылки пакетов длиннее, чем MTU пути до места назначения. (Замечание: в отличие от IPv4, фрагментация в IPv6 выполняется только узлами-отправителями, а не маршрутизаторами вдоль пути доставки). Заголовок фрагментации идентифицируется кодом поля следующий заголовок, равным 44 и имеет следующий формат (рис. 4.4.1.1.21):
Рис. 4.4.1.1.21. Формат заголовка фрагментации
| Следующий заголовок | 8- битовый селектор. Идентифицирует тип исходного заголовка фрагментируемой части исходного пакета. Использует те же коды протоколов, что и IPv4 [RFC-1700]. |
| Резерв | 8-битовое резервное поле. Инициализируется нулем при передаче и игнорируется при приеме. |
| Fragment offset | 13-битовое число без знака. Смещение в 8-октетном блоке, для данных, которые следуют за этим заголовком, началом отсчета является начало фрагментируемой части исходного пакета. |
| Резерв (второй) | 2-битовое резервное поле. Инициализируется нулем при передаче и игнорируется при приеме. |
| m флаг | 1 = есть еще фрагменты; 0 = последний фрагмент. |
| Идентификация | 32 бита |
Для каждого пакета, который должен быть фрагментирован, узел-отправитель генерирует код идентификации. Этот код должен отличаться от аналогичных кодов идентификации, используемых для других фрагментируемых пакетов, которые пересылаются в данный момент. Под "данным моментом" подразумевается период времени жизни пакета, включая время распространения кадра от источника до получателя и время, необходимое для сборки исходного (оригинального) пакета получателем. Однако не предполагается, чтобы отправитель знал максимальное время жизни пакета. Скорее предполагается, что данное требование будет удовлетворено с помощью простого 32-разрядного счетчика, инкрементируемого всякий раз, когда очередной пакет должен быть фрагментирован. Схема реализации генератора кода идентификации оставляется на усмотрение приложения. Если присутствует заголовок маршрутизации, под адресом получателя подразумевается конечное место назначения.
Под исходным большим, не фрагментированным пакетом подразумевается “оригинальный” пакет. Предполагается, что он состоит из двух частей, как показано на рисунке 4.4.1.1.22:
Исходный пакет:
Рис. 4.4.1.1.22.
Не фрагментированная часть состоит из IPv6 заголовка плюс любых заголовков расширения, которые должны быть обработаны узлами по пути до места назначения. Таким образом, нефрагментированная часть включает в себя все заголовки вплоть до заголовка маршрутизации, если таковой присутствует, или до заголовка опций hop-by-hop, если он присутствует.
Фрагментируемая часть представляет собой остальную часть пакета, т.е. включает в себя заголовки расширений, которые должны быть обработаны в узле места назначения, заголовок верхнего уровня и данные.
Фрагментируемая часть оригинального пакета делится на фрагменты с длиной кратной 8 октетам. Фрагменты пересылаются независимо с помощью пакетов-фрагментов. Как показано на рис. Рис. 4.4.1.1.23
Исходный пакет:
Пакеты-фрагменты:
oo
o
Рис. 4.4.1.1.23.
Каждый пакет-фрагмент состоит из:
(1) Не фрагментируемой части оригинального пакета, с длиной поля данных оригинального IPv6 заголовка, измененной для того чтобы соответствовать длине фрагмента пакета (исключая длину самого IPv6-заголовка), а код поля следующий заголовок последнего заголовка не фрагментируемой части меняется на 44.
(2) Заголовка фрагмента, включающего в себя:
Код поля следующий заголовок, идентифицирующий первый заголовок фрагментируемой части оригинального пакета.
Смещение фрагмента, выражаемое в 8-октетных блоках и отсчитываемое от начала фрагментируемой части оригинального пакета. Смещение первого фрагмента (самого левого) равно нулю.
Код M-флага равен нулю, если фрагмент является последним (самым правым), в противном случае флаг равен 1.
(3) Сам фрагмент.
Длина фрагментов должна выбираться такой, чтобы пакеты-фрагменты соответствовали значению MTU для маршрута к месту назначения (назначений). В узле места назначения из пакетов-фрагментов восстанавливается оригинальный пакет в не фрагментированной форме.
Восстановленный оригинальный пакет:
Рис. 4.4.1.1.24.
В процессе восстановления должны выполняться следующие правила:
Оригинальный пакет восстанавливается из фрагментов, которые имеют одни и те же адреса отправителя и получателя, а также код идентификации.
Не фрагментируемая часть восстанавливаемого пакета состоит из всех заголовков вплоть до (но не включая) заголовок фрагмента первого пакета-фрагмента (пакет со смещением равным нулю). При этом производятся следующие изменения:
Поле следующий заголовок последнего заголовка не фрагментируемой части берется из поля следующий заголовок заголовка первого фрагмента.
Длина поля данных восстановленного пакета вычисляется с использованием длины не фрагментируемой части, а также длины и смещения последнего фрагмента. Например, формула расчета длины поля данных восстановленного пакета имеет вид:
pl.orig = pl.first - fl.first - 8 + (8 * fo.last) + fl.last
где
pl.orig - поле длины данных восстановленного пакета.
pl.first - поле длины данных первого пакета-фрагмента.
fl.first - длина фрагмента, следующего за заголовком первого пакета-фрагмента.
fo.last - Поле смещения фрагмента в заголовке последнего пакета-фрагмента.
fl.last - длина фрагмента, следующего за заголовком фрагмента последнего пакета-фрагмента.
Фрагментируемая часть восстановленного пакета состоит из частей, следующих за заголовками в каждом из пакетов-фрагментов. Длина каждого фрагмента вычисляется путем вычитания из длины поля данных длины заголовков, размещенных между IPv6 заголовком и самим фрагментом. Их относительное положение в фрагментируемой части вычисляется на основе значения смещения фрагмента. Заголовок фрагмента отсутствует в восстановленном пакете.
В процессе сборки могут возникнуть следующие ошибки:
Если в пределах 60 секунд после прихода первого фрагмента получено недостаточно фрагментов для завершения сборки, процедура сборки должна быть прервана и все полученные фрагменты выкинуты. Если первый фрагмент (т.e., пакет с нулевым смещением) получен, посылается ICMP сообщение “Time exceeded -- Fragment reassemble time exceeded”.
Если длина фрагмента, полученная из поля длины данных пакета, не является кратным 8 октетам, а M флаг фрагмента равен 1, фрагмент должен быть выброшен и должно быть послано сообщение ICMP (parameter problem, код 0) с указателем на поле длины данных пакета-фрагмента.
Если длина и смещение фрагмента таковы, что восстановленная длина поля данных фрагмента превосходит 65,535 октетов, фрагмент выбрасывается, посылается сообщение ICMP (parameter problem, код 0) с указателем на поле смещения фрагмента пакета-фрагмента.
Следующие условия не должны реализоваться, но они также рассматриваются как ошибка, если это произойдет:
Число и содержимое заголовков, предшествующих заголовку фрагмента, отличаются для разных фрагментов одного и того же исходного пакета. Какие бы заголовки ни предшествовали, заголовку фрагмента, они обрабатываются по прибытии на место назначения до постановки фрагментов в очередь на восстановление. Только эти заголовки из пакета с нулевым смещением сохраняются в восстановленном пакете.
Значение поля следующий заголовок в заголовках фрагментов различных фрагментов исходного пакета могут отличаться. Для последующей сборки используется только значение из пакета-фрагмента с нулевым смещением.
9. Заголовок опций места назначения
Заголовок опции места назначения используется для передачи опционной информации, которая должна анализироваться только узлом (узлами) назначения. Заголовок опции места назначения идентифицируется кодом поля следующий заголовок равным 60 предшествующего заголовка и имеет формат (рис. 4.4.1.1.25):
Рис. 4.4.1.1.25. Формат заголовка опции места назначения
Следующий заголовок - 8-битовый селектор. Идентифицирует тип заголовка, который непосредственно следует за заголовком опций места назначения. Использует те же коды протокола, что и IPv4 [RFC-1700].
Hdr Ext Len - 8-битовое целое без знака. Длина заголовка опций места назначения в 8-октетных блоках, исключая первые 8 октетов.
Опции - поле переменной длины, кратное 8 октетам. Содержит одну или более TLV-закодированных опций.
Здесь определены только две опции места назначения Pad1 и padn. Обратите внимание, что существует два способа кодировки опционной информации места назначения для пакетов IPv6: в заголовке опций места назначения, или в виде отдельного заголовка расширения. Заголовок фрагмента и заголовок идентификации являются примерами последнего подхода. Какой из подходов будет применен, зависит от того, какая операция желательна в узле места назначения:
если желательно, чтобы узел назначения уничтожил пакет и, если адрес места назначения не является мультикастинговым, отправителю посылается сообщение ICMP unrecognized type, затем информация может быть закодирована в отдельном заголовке или в опции места назначения с кодом типа опции, равным 11 в старших двух битах. Выбор может зависеть от таких факторов как число необходимых октетов, проблема выравнивания или более простой анализ пакета.
если желательна какая-либо иная операция, информация должна быть закодирована в виде опции места назначения с типом опции 00, 01 или 10 в старших двух битах.
10. Отсутствие следующего заголовка
Код 59 в поле следующий заголовок IPv6 заголовка или любой другой заголовок расширения указывает, что за этим заголовком ничего не следует. Если поле длина данных заголовка IPv6 указывает на присутствие октетов после конца заголовка, содержащего код 59 в поле следующий заголовок, эти октеты должны быть проигнорированы и переданы без изменений при переадресации пакета.
11. О размере пакетов
Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.
Для каждого канала, с которым связан узел непосредственно, он должен быть способен принимать пакеты с размером MTU данного канала. В каналах, которые можно конфигурировать, например, PPP [RFC-1661], должно быть установлено MTU не менее 576 октетов; рекомендуется устанавливать максимально возможное MTU, чтобы позволить инкапсуляцию (туннелирование) без привлечения фрагментации.
Настоятельно рекомендуется, чтобы узлы IPv6 использовали механизм определения MTU пути [RFC-1191] для использования преимущества большого значения MTU. Однако в минимальной конфигурации IPv6 (например, в BOOT ROM) может ограничивать себя в пределах 576 октетов и не использовать path MTU discovery.
Для того чтобы послать пакет длиннее чем MTU канала, узел может использовать заголовок фрагментации IPv6. Однако использование такой фрагментации заблокировано в приложениях, где используется настройка по измеренному значению MTU пути.
Узел должен быть способен принимать фрагментированные пакеты, которые после сборки имеют размер 1500 октетов, включая IPv6 заголовок. Узлу позволено принимать пакеты, которые после сборки имеют размер более 1500 октетов. Однако узел не должен посылать фрагменты, которые после сборки образуют пакеты длиннее 1500 октетов, если он не уверен, что получатель способен их воспринять и дефрагментировать.
В ответ на IPv6 пакет, посланный IPv4 адресату (т.e., пакет, который подвергается преобразованию из IPv6 в IPv4), узел отправитель IPv6 может получить ICMP сообщение packet too big, предупреждающее о том, что MTU следующего узла меньше 576. В этом случае узел IPv6 не должен уменьшать размер пакетов до 576 октетов, он должен включить в эти пакеты заголовок фрагментации, так чтобы маршрутизатор, выполняющий трансляцию IPv6-IPv4, мог получить приемлемый код идентификации, чтобы использовать полученные IPv4 фрагменты. Заметьте, что это означает сокращение длины поля данных до 528 октетов (576 минус 40 для IPv6-заголовка и 8 для заголовка фрагментации), и меньше, если имеются другие заголовки расширения.
Замечание: Анализ MTU пути должно проводиться даже в случае, когда узел “думает”, что адресат находится на том же канале что и сам узел.
Замечание: В отличие от IPv4, в IPv6 не нужно устанавливать флаг "don't fragment" (не фрагментировать) в заголовках пакетов, для того чтобы выполнить операцию определения величины mtu канала; так как это является атрибутом любого IPv6 пакета по умолчанию. Части процедур из RFC-1191, которые включают в себя использование таблиц MTU, не применимы к IPv6, так как версия сообщения IPv6 "datagram too big" всегда указывает на точное значение MTU, которое следует использовать.
12. Метки потоков
24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая например, как нестандартная QoS или "real-time " сервис. Этот аспект IPv6 является пока экспериментальным и может быть изменен позднее. Для ЭВМ или маршрутизаторов, которые не поддерживают функцию пометки потоков, это поле должно быть обнулено при формировании пакета, сохраняться без изменения при переадресации и игнорироваться при получении.
Поток это последовательность пакетов, посылаемых отправителем определенному адресату, при этом предполагается, что все пакеты данного потока должны быть подвергнуты определенной обработке. Характер этой специальной обработки может быть передан маршрутизатору посредством протокола управления или внутри самих пакетов, например, в опции hop-by-hop.
Допускается несколько потоков между отправителем и получателем, а также обмен, не ассоциированный ни с одним из потоков. Поток однозначно описывается комбинацией адреса отправителя и ненулевой меткой потока. Пакеты, не принадлежащие ни одному из потоков, имеют метку равную нулю.
Метка потока присваивается потоку узлом отправителя. Новые метки потоков должны выбираться псевдослучайным образом из диапазона чисел 1 - ffffff. Целью псевдослучайного выбора метки является возможность использования любого набора бит поля метки потока в качестве хэш ключа маршрутизаторами для контроля состояния соответствующего потоку.
Все пакеты, принадлежащие одному потоку, должны быть посланы одним отправителем, иметь один и тот же адрес места назначения, приоритет и метку потока. Если какой-либо из этих пакетов включает в себя заголовок опций hop-by-hop, тогда все они должны начинаться с одного и того же содержания заголовка опций hop-by-hop (исключая поле следующий заголовок заголовка опций hop-by-hop). Если любой из этих пакетов включает заголовок маршрутизации, тогда все они должны иметь идентичные заголовки расширения, включая заголовок маршрутизации но исключая поле следующий заголовок заголовка маршрутизации. Маршрутизаторы и узлы-адресаты могут проверять эти требования (хотя это и необязательно). Если обнаружено нарушение, должно быть послано ICMP сообщение отправителю (problem message, код 0) с указателем на старший октет поля метка потока (т.e., смещение 1 в IPv6 пакете).
Маршрутизаторы могут произвольно варьировать способ обработки потоков данных, даже когда имеется какая-либо информация о потоке со стороны протокола управления, опции hop-by-hop или другого источника. Например, при получении пакетов от какого-то источника с неизвестной ненулевой меткой, маршрутизатор может обрабатывать их IPv6-заголовок и любой необходимый заголовок расширения так, как если бы метка равнялась нулю. Такая обработка может включать выявление интерфейса следующего шага и другие действия, такие как актуализация опции hop-by-hop, перемещение указателя и адресов в заголовке маршрутизации и т.д.. Маршрутизатор может запомнить результаты такой обработки, занеся их в кэш (адрес отправителя и метка образуют ключ кэша). Последующие пакеты с тем же адресом отправителя и меткой потока могут обрабатываться с использованием информации из кэша без детального просмотра всех полей, которые, согласно уже описанному, должны быть идентичными.
Режим обработки пакетов с использованием кэш должен быть аннулирован не позднее 6 секунд после своей установки вне зависимости от того, продолжают ли поступать пакеты данного потока. Если приходит другой пакет от того же отправителя с той же меткой после того как кэш режим отменен, он подвергается обычной обработке (как если бы имел нулевую метку), такая ситуация может быть причиной повторного формирования кэш режима.
Время жизни режима обработки потока задается явно в процессе конфигурации, например, через протокол управления или опцию hop-by-hop, и может превышать 6 секунд.
Отправитель не должен использовать старую метку для нового потока в пределах времени жизни любого потока. Так как режим обработки потока на 6 секунд может быть установлен для любого потока, минимальный интервал между последним пакетом одного потока и первым пакетом нового, использующего ту же метку, должно быть равно 6 секундам. Метки потока, которые используются для потоков, существующих более продолжительное время не должны использоваться соответственно дольше.
Когда узел останавливает или перезапускает процесс (например, в случае сбоя), он должен позаботиться о том, чтобы метка потока была уникальной и не совпадала с другой еще действующей меткой. Это может быть сделано путем записи используемых меток в стабильную память, так чтобы ею можно было воспользоваться даже после серьезного сбоя в системе. Если известно минимальное время перезагрузки системы (time for rebooting, обычно более 6 секунд), это время можно использовать для задания времени жизни меток потоков.
Не требуется, чтобы все или даже большинство пакетов принадлежали потокам с ненулевыми метками. Например, было бы неумно сконструировать маршрутизатор так, чтобы он работал только с пакетами, принадлежащими к тому или иному потоку, или создать схему сжатия заголовков, которая работает только с помеченными потоками.
13. Приоритет
4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов “реального времени”, посылаемых с постоянной частотой.
Для трафика, управляемого сигналами перегрузки, рекомендуются следующие значения приоритета для конкретных категорий приложений (см. таблицу 4.4.1.1.2).
Таблица 4.4.1.1.2. Значения кодов приоритета
| Код приоритета | Назначение |
| 0 | Нехарактеризованный трафик |
| 1 | Заполняющий трафик (например, сетевые новости) |
| 2 | Несущественный информационный трафик (например, электронная почта) |
| 3 | Резерв |
| 4 | Существенный трафик (напр., FTP, HTTP, NFS) |
| 5 | Резерв |
| 6 | Интерактивный трафик (напр. telnet, x) |
| 7 | Управляющий трафик Интернет (напр., маршрутные протоколы, snmp) |
Для трафика, не контролируемого на перегрузки, нижнее значение приоритета (8) должно использоваться для тех пакетов, которые отправитель разрешает выбросить в случае перегрузки (например, видео трафик высокого качества), а высшее значение (15) следует использовать для пакетов, которые отправитель не хотел бы потерять (напр., аудио трафик с низкой надежностью). Не существует связи между относительными приоритетами обменов с и без контроля перегрузки.
14. О протоколе верхнего уровня
14.1 Контрольные суммы верхнего уровня
Любой транспортный или другой протокол верхнего уровня, который включает адреса IP-заголовка в свою контрольную сумму, должен быть модифицирован, чтобы работать с 128-битовыми IPv6адресами вместо 32-битовых IPv4. В частности, ниже показаны псевдо-заголовки для TCP и UDPв IPv6 (рис. 4.4.1.1.26):
Рис. 4.4.1.1.26. Формат псевдо-заголовков для TCP и UDP
Если пакет содержит заголовок маршрутизации, в качестве адреса места назначения в псевдо-заголовке используется оконечный адрес. В исходном узле этот адрес будет последним элементом заголовка маршрутизации; для узла получателя он будет находиться в поле адрес места назначения IPv6 заголовка.
Код поля следующий заголовок в псевдо- заголовке идентифицирует протокол верхнего уровня (например, 6 для TCPили 17 для UDP). Он будет отличаться от кода поля следующий заголовок в IPv6 заголовке, если имеются заголовки расширения между заголовком IPv6 и заголовком протокола верхнего уровня.
В качестве кода длины поля данных в псевдо-заголовке используется длина пакета протокола верхнего уровня, включая заголовок верхнего уровня. Он будет меньше длины поля данных в заголовке (или в опции Jumbo Payload), если имеются заголовки расширения между IPv6 заголовком и заголовком верхнего уровня.
В отличие от IPv4, при формировании udp пакетов в IPv6 узле, контрольная сумма не является опционной. Поэтому при формировании UDP-пакета IPv6 узел должен вычислить контрольную UDP сумму пакета и псевдо-заголовка и, если вычисление дает в качестве результата нуль, он должен быть заменен на ffff для помещения в UDP заголовок. IPv6-получатели должны выбрасывать UDP пакеты, содержащие нулевую контрольную сумму и фиксировать при этом состояние ошибки.
IPv6 версия ICMP-пакетов [RFC-1885] включает псевдо-заголовок в вычисление контрольной суммы; это отличается от IPv4 версии ICMP, которая не включает псевдо-заголовок в контрольную сумму. Причина изменения связана с попыткой защитить ICMP от некорректной доставки или искажений важных полей в IPv6 заголовке, который в отличие от IPv4 не защищен контрольным суммированием на интернет-уровне. Поле следующий заголовок в псевдо-заголовке для ICMP содержит код 58, который идентифицирует IPv6 версию ICMP.
15. Максимальное время жизни пакета
В отличие от IPv4, узлы IPv6 не требуют установки максимального времени жизни пакетов. По этой причине поле IPv4 "time to live" (TTL) переименовано в "hop limit" (предельное число шагов) для IPv6. На практике очень немногие IPv4 приложения, используют ограничения по TTL, так что фактически это не принципиальное изменение.
16. Максимальный размер поля данных для протоколов высокого уровня
При вычислении максимального размера поля данных, доступного для протокола верхнего уровня, должен приниматься во внимание большой размер заголовка IPv6 относительно IPv4. Например, в IPv4, mss опция TCP вычисляется как максимальный размер пакета (значение по умолчанию или величина полученная из MTU) минус 40 октетов (20 октетов для минимальной длины IPv4 заголовка и 20 октетов для минимальной длины TCP заголовка). При использовании TCP поверх IPv6, MSS должно быть вычислено как максимальная длина пакета минус 60 октетов, так как минимальная длина заголовка IPv6 (т.e., IPv6 заголовок без заголовков расширения) на 20 октетов больше, чем для IPv4.
17. Приложение a. Рекомендации по формированию опций
Это приложение дает некоторые советы, как выкладывать поля, при формировании новых опций, предназначенных для использования в заголовке опций hop-by-hop или в заголовке опций места назначения. Эти рекомендации базируются на следующих предположениях:
Желательно, чтобы любые многооктетные поля в пределах данных опции были выровнены на их естественные границы, т.e., поля с длиной в n октетов следует помещать со смещением по отношению к началу заголовка (hop-by-hop или destination options), кратным n октетам, для n = 1, 2, 4 или 8.
Другим желательным требованием является минимальное место, занимаемое hop-by-hop или опциями места назначения, а длина заголовка должна быть кратной 8 октетам.
Можно предположить, что когда присутствует какой-то заголовок, содержащий опции, он несет в себе небольшое число опций, обычно одну.
Эти предположения определяют следующий подход к выкладке полей опций: порядок опций от коротких к длинным без внутреннего заполнения. Требования выравнивания границ для всей опции определяется требованием выравнивания наиболее длинного поля (до 8 октетов). Этот подход иллюстрируется на следующих примерах:
Пример 1
Если опция x требует двух полей данных, одно длиной 8 октетов, а другое длиной 4 октета, ее формат будет иметь вид (рис. 4.4.1.1.27):
Рис. 4.4.1.1.27.
Требование выравнивания соответствует 8n+2, для того чтобы гарантировать начало 8-октетного поля со смещением, кратным 8, от начала последнего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из этих опций будет иметь формат (рис. 4.4.1.1.28):
Рис. 4.4.1.1.28
Пример 2
Если опция y требует трех полей данных, одно длиной 4 октета, одно - 2 октета и одно - длиной один октет, она будет уложена следующим образом (рис. 4.4.1.1.29):
Рис. 4.4.1.1.29
Требование выравнивания выглядит как 4n+3, и призвано гарантировать, что 4-октетное поле начнется со смещением кратным 4 по отношению к началу завершающего заголовка. Полный заголовок (hop-by-hop или destination options), содержащий одну из указанных опций будет иметь вид (рис. 4.4.1.1.30):
Рис. 4.4.1.1.30
Пример 3
Заголовок с опциями hop-by-hop или destination options, содержащий обе опции x и y из примеров 1 и 2, будет иметь один из приведенных ниже форматов, в зависимости от того, какая из опций встречается первой (рис. 4.4.1.1.31, 4.4.1.1.32):
Рис. 4.4.1.1.31
Рис. 4.4.1.1.32
18. Соображения безопасности
Заголовок IP идентификации [RFC-1826] и безопасная IP инкапсуляция [RFC-1827] будут использоваться в IPv6, в соответствии с безопасной архитектурой протоколов Интернет [RFC-1825].
19. Расширение DNS для поддержки IP-версии 6 (DNS Extensions to Support IP Version 6. S. Thomson. RFC-1886)
Существующая поддержка записи адресов Интернет в DNS (Domain Name System) [1,2] не может быть легко расширена для поддержки IPv6-адресов [3], так как приложение предполагает, что адресный запрос вернет только 32-битовый IPv4-адрес.
Для того чтобы запоминать IPv6-адреса, определены следующие расширения:
Определен новый тип ресурсной записи, для того чтобы установить соответствие между именами доменов и адресами IPv6.
Определен новый домен, предназначенный для обработки запросов по новым адресам.
Существующие запросы, которые выполняют выявление IPv4-адресов, переопределены для получения как IPv4, так и IPv6-адресов.
Изменения выполнены так, чтобы быть совместимыми с имеющимся программным обеспечением. Существующая поддержка IPv4-адресов сохраняется. Переходное состояние осуществования IPv4 и IPv6-адресов обсуждается в [4].
19.1. Определение новой ресурсной записи и домена
Определен новый тип ресурсной записи для хранения IPv6-адреса ЭВМ. Если ЭВМ имеет более одного IPv6-адреса, тогда используется более одной такой ресурсной записи.
Тип ресурсной записи aaaa является специфическим для класса Интернет и служит для записи одного IPv6-адреса. Код типа равен 28 (десятичное).
128-битовый IPv6-адрес записывается в информационной части ресурсной записи aaaa, придерживаясь порядка байт, используемого в сети (старший байт первый).
Запрос aaaa для конкретного имени домена в классе Интернет возвращает в качестве отклика все ресурсные записи, соответствующие ресурсной секции aaaa. Запрос типа aaaa не выполняет никакой дополнительной обработки этой секции.
Текстовое представление информационной секции ресурсной записи aaaa, используемое в файле базы данных имеет формат, описанный в [3], а также в текущем разделе.
Определен специальный домен, который предназначен для установления соответствия между именами и IPv6-адресами. Домен имеет имя ip6.int.
IPv6-адрес представляется в виде имени в домене ip6.int. Это имя выглядит как последовательность символов, разделенных точками, завершающаяся суффиксом .ip6.int. Последовательность символов записывается в обратном порядке, т.е. младший по порядку символ записывается первым и т.д... Каждый из символов представляет собой шестнадцатеричную цифру. Например, запрос, соответствующий адресу
4321:0:1:2:3:4:567:89ab
будет выглядеть как
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int.
19.2. Модификации существующих типов запроса
Все существующие типы запросов, которые выполняют дополнительную обработку секции a, т.е. типы запросов, относящиеся к серверу имен (ns), почтовому серверу (MX) и почтовому ящику (MB), для осуществления обработки как секции типа a, так и типа aaaa должны быть переопределены. Эти новые определения означают, что сервер имен, обрабатывая один из указанных запросов, должен добавить в соответствующую секцию запроса какие-то подходящие адреса IPv4 и какие-то адреса IPv6 доступные локально.
20. Протокол управляющих сообщений (ICMPv6) для спецификации IPv6 (a. conta. internet control message protocol (ICMPv6) for the internet protocol version 6 (IPv6) specification. RFC-1885)
Протокол IPv6 является новой версией IP. IPv6использует протокол управляющих сообщений (ICMP) так, как это определено для IPv4 [RFC-792], но с некоторым количеством изменений. Протокол подключения к группам (IGMP), специфицированный для IPv4 [RFC-1112] был также пересмотрен и включен в протокол ICMP для IPv6. Результирующий протокол называется ICMPv6, и имеет код следующего заголовка 58.
20.1. ICMPv6 (ICMP для IPv6)
ICMPv6 используется узлами IPv6 для сообщений об ошибках при обработке пакетов, и для выполнения других функций уровня Интернет, таких как диагностика (ICMPv6 "ping") и сообщение об участии в мультикастинг группах. Протокол ICMPv6 является интегрированной частью IPv6 и должен реализовываться каждым узлом, поддерживающим IPv6.
20.2. Общий формат сообщений
Сообщения ICMPv6 образуют два класса: сообщения об ошибках и информационные сообщения. Сообщения об ошибках идентифицируются по нулю в старшем бите поля тип. Таким образом, сообщения об ошибках могут иметь код поля тип от 0 до 127; информационные сообщения имеют коды поля тип от 128 до 255.
В данном документе определены форматы для следующих сообщений ICMPv6:
Сообщения об ошибках ICMPv6:
1 destination unreachable (место назначения недоступно)
2 packet too big (пакет слишком велик)
3 time exceeded (время превышено)
4 parameter problem (проблема с параметрами)
Информационные сообщения ICMPv6:
128 echo request (Запрос эхо)
129 echo reply (Эхо-отклик)
130 group membership query (запрос участия в группе)
131 group membership report (отчет об участии в группе)
132 group membership reduction (сокращение числа участников в группе)
Каждое сообщение ICMPv6 начинается с заголовка IPv6, за которым следует нуль или более заголовков расширения IPv6. Заголовок ICMPv6 идентифицируется кодом следующего заголовка 58 в предыдущем заголовке. (Заметим: этот код отличается от значения, принятого для ICMP IPv4.)
Сообщения ICMPv6 имеют следующий общий формат (рис. 4.4.1.1.33):
Рис. 4.4.1.1.33. Общий формат сообщений ICMPv6
Поле тип указывает на тип сообщения. Его значение определяет формат последующих данных.
Поле код зависит от типа сообщения. Оно используется для создания дополнительного уровня структуризации сообщения. Поле контрольная сумма используется для обнаружения повреждений сообщения ICMPv6 и заголовка IPv6.
Узел отправитель сообщения ICMPv6 должен определить IPv6-адреса отправителя и получателя до вычисления контрольной суммы. Если узел имеет более одного уникастного адреса, то он должен выбрать адрес отправителя следующим образом:
Если сообщение является откликом на сообщение, полученное по одному из уникаст адресов, адресом отправителя должен стать именно этот адрес.
Если сообщение является откликом на мультикаст- или эникаст-сообщение группе, в которую входит данный узел, адресом отправителя должен стать никастный адрес интерфейса, откуда пришло сообщение-первопричина отклика.
Если сообщение является откликом на сообщение, посланное по адресу, который не принадлежит данному узлу, в качестве адреса отправителя следует выбрать уникаст адрес, принадлежащий узлу и обещающий наибольшую диагностическую полезность. Например, если сообщение является откликом на операцию переадресации пакета, которая не может быть завершена успешно, в качестве адреса отправителя должен быть взят уникаст-адрес интерфейса, переадресация на который не удалась.
В противном случае, должна быть просмотрена таблица маршрутизации узла и выяснено, какой интерфейс должен быть использован для достижения места назначения сообщения. Уникастный адрес этого интерфейса и должен быть выбран в качестве адреса отправителя.
Контрольная сумма является 16-битным дополнением по модулю 1 суммы всего сообщения ICMPv6, начиная с поля тип сообщения ICMPv6, дополненного полями псевдозаголовка IPv6. Код поля следующий заголовок для псевдозаголовка выбирается равным 58. (Заметим: включение псевдозаголовка в контрольную сумму ICMPv6 является изменением по отношению к протоколу IPv4; обоснование причин этого см. в [IPv6]). Перед вычислением контрольной суммы поле контрольная сумма обнуляется.
Приложения должны следовать следующим правилам при обработке сообщений ICMPv6 (из [RFC-1122]):
Если получено сообщение о неизвестной ошибке ICMPv6, оно должно быть передано верхнему уровню.
Если получено информационное сообщение ICMPv6 неизвестного типа, оно должно быть выброшено.
Каждое ICMPv6 сообщение об ошибке (тип < 128) включает в себя целиком или частично IPv6 пакет, вызвавший ошибку, при условии, что сообщение об ошибке превысит 576 октетов.
В тех случаях, когда протокол интернет-уровня нуждается в передаче сообщения об ошибке ICMPv6 вышерасположенному уровню, тип протокола верхнего уровня извлекается из исходного пакета (содержащегося в теле сообщения об ошибке ICMPv6) и используется для выбора соответствующего протокола верхнего уровня при последующей обработке сообщения об ошибке.
Если исходный пакет имеет необычно большое число заголовков расширения, возможно, что тип протокола верхнего уровня может отсутствовать в сообщении ICMPv6, из-за укорочения исходного пакета до уровня 576 октетов. В этом случае сообщение об ошибке отбрасывается после обработки уровня IPv6.
Сообщение об ошибке ICMPv6 не должно посылаться в качестве результата получения:
(e.1) сообщения об ошибке ICMPv6, или
(e.2) пакета, направленного по IPv6 мультикаст-адресу (существует два исключения из этого правила: (1) сообщения packet too big - пакет слишком велик) – чтобы позволить скорректировать MTU прохода, и (2) сообщения parameter problem (проблема с параметрами), Код 2, оповещающий о нераспознанной опции), или
(e.3) мультикастинг-пакета канального уровня, (исключения пункта e.2 применимы и здесь), или
(e.4) широковещательного пакета канального уровня, (исключения пункта e.2 применимы и здесь), или
(e.5) пакета, чей адрес отправителя не однозначно определяет какой-то узел, например, не специфицированный адрес IPv6, мультикаст-адрес IPv6 или эникаст-адрес.
(f) Наконец, узел IPv6 должен ограничить частоту посылки сообщений об ошибке, если адресат на них не реагирует. Это ограничит загрузку канала.
Существует много способов ограничения частоты посылки сообщений, например:
(f.1) Таймерный метод. Передача сообщений производится не чаще, чем раз за указанное число T миллисекунд.
(f.2) Метод полосы пропускания. Сообщения об ошибке должны занимать не более определенной доли F полосы пропускания канала.
Ограничивающие параметры (например, T или F в вышеприведенных примерах) должны задаваться узлом со значениями по умолчанию (напр., T = 1 сек, и F = 2%, не 100%!).
20.3. Сообщения об ошибках ICMPv6
Рис. 4.4.1.1.34. Формат сообщения о недостижимости адресата
Поля IPv6:
Адрес места назначения копируется из поля адрес отправителя пакета, вызвавшего ошибку.
Поля ICMPv6:
Тип = 1
Код = 0 – нет маршрута до места назначения
1 – связь с адресатом административно запрещена
2 – не сосед
3 – адрес не достижим
4 – порт не достижим
Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем.
Описание
Сообщение адресат не достижим (destination unreachable) должно генерироваться маршрутизатором, или уровнем IPv6 узла-отправителя, в случае, когда пакет не может быть доставлен адресату не по причине перегрузки. (Сообщение ICMPv6 не должно посылаться при потере пакета из-за перегрузки).
Если причиной потери пакета является недостаток места в маршрутной таблице узла, поле код должно принять значение 0 (Заметим, что такая ошибка может произойти только при наличии в таблице маршрута по умолчанию).
Если причиной потери пакета является административный запрет, например, Firewall, поле код принимает значение 1.
Если причиной потери пакета является то, что следующий узел в маршрутной таблице не является соседом данного узла, то поле код принимает значение 2.
Если имеет место какая-то другая причина недоставки пакета, в поле код заносится значение 3.
Узел места назначения может посылать сообщение “адресат не достижим” с кодом 4, когда транспортный протокол пакета (напр., UDP) не имеет получателя, а другого метода, уведомить об этом отправителя нет.
Узел, получивший сообщение ICMPv6 “ адресат не достижим” должен уведомить об этом протокол вышележащего уровня.
Рис. 4.4.1.1.35. Сообщение packet too big (пакет слишком велик)
Поля IPv6:
Адрес места назначения копируется из поля адрес отправителя пакета, вызвавшего ошибку.
Поля ICMPv6:
Тип 2
Код 0
mtu mtu следующего шага.
Описание
Сообщение packet too big (пакет слишком велик) должно посылаться маршрутизатором в ответ на получение пакета, который не может быть переадресован, из-за того, что он длиннее, чем MTU выходного канала. Информация в этом сообщении используется в качестве части процесса определения MTU прохода [RFC-1191].
Пришедшее сообщение packet too big должно быть передано протоколу верхнего уровня.
Формат сообщения о превышении времени аналогичен формату сообщения о недостижимости адресата (рис. 4.4.1.1.33).
Поля ICMPv6:
Тип 3
Код 0 – при передаче превышен лимит числа шагов
1 – превышено время восстановления сообщения из фрагментов.
Не используется. Это поле не используется при всех значениях поля код. Оно должно быть обнулено отправителем и игнорироваться получателем.
Описание
Если маршрутизатор получает пакет с предельным значением числа шагов равным нулю (hop limit = 0), или маршрутизатор после декрементации получил нулевое значение поля hop limit, он должен выбросить такой пакет и послать отправителю пакета сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным 0. Это указывает на зацикливание маршрута или на слишком малое значение поля hop limit.
Посылая сообщение ICMPv6 о превышении времени (time exceeded) со значением поля код равным нулю, маршрутизатор должен рассматривать входной интерфейс, в соответствии с правилом выбора адреса отправителя (d).
Пришедшее сообщение time exceeded должно быть передано протоколу верхнего уровня.
Рис. 4.4.1.1.36. Сообщение о конфликте параметров
Поля ICMPv6:
Тип 4
Код 0 – встретилась ошибка в поле заголовка
1 – встретился неопознанный код поля следующий заголовок
2 – встретилась неопознанная опция IPv6
Указатель. Идентифицирует смещение в октетах в пакете, вызвавшем ошибку.
Указатель отмечает позицию в пакете, если размер пакета ICMPv6 не позволяет поместить его в отклик полностью, а ошибочное поле в сообщение не поместилось.
Описание
Если узел IPv6, обрабатывающий пакет, обнаруживает какую-то проблему с одним из полей заголовка или заголовков расширения, такую, что дальнейшая обработка невозможна, он должен выбросить пакет и послать сообщение ICMPv6 parameter problem (проблема с параметрами) отправителю пакета с указанием типа и позиции ошибки.
Поле указатель идентифицирует октет заголовка исходного пакета, где обнаружена ошибка. Например, сообщение ICMPv6 с полем тип = 4, полем код = 1 и полем указатель = 40 указывает на то, что заголовок расширения IPv6, следующий за заголовком IPv6 исходного пакета содержит нераспознанный код следующего заголовка.
20.4. Информационные сообщения ICMPv6
Рис. 4.4.1.1.37. Сообщение запрос эхо
Поля IPv6:
Адрес места назначения – любой легальный IPv6-адрес
Поля ICMPv6:
Тип 128
Код 0
Идентификатор. Идентификатор, который помогает друг с другом связать запрос эхо и эхо-отклик. Может равняться нулю.
Номер по порядку
Номер по порядку имеет целью связать друг с другом запрос эхо и эхо-отклик. Может равняться нулю.
Информация. Нуль или более октетов произвольных данных.
Описание
Каждый узел должен реализовать функцию эхо-отклика ICMPv6 при получении запроса эхо. Узлу следует также предоставить пользовательский интерфейс для посылки запросов эхо и получения эхо-откликов для целей диагностики.
Формат сообщения эхо-отклик идентичен формату запроса эхо (рис. 20.5).
Поля IPv6:
Адрес места назначения копируется из поля адрес отправителя пакета запрос эхо.
Поля ICMPv6:
Тип 129
Код 0
Идентификатор. Идентификатор из исходного запроса эхо (echo request).
Номер по порядку. Номер по порядку из исходного запроса эхо.
Информация. Данные из исходного запроса эхо.
Описание
Каждый узел должен иметь встроенную функцию отклика ICMPv6, которая получает запросы эхо и посылает соответствующие эхо-отклики. Узел должен также реализовать интерфейс прикладного уровня для посылки запросов эхо и получения эхо-откликов для диагностических целей.
Адрес отправителя эхо-отклика, посылаемого в ответ на уникастный запрос эхо должен быть тем же самым, что и адрес места назначения в запросе эхо.
Эхо-отклик должен быть послан в ответ на запрос эхо, посланный по мультикастному адресу. Адрес отправителя в отклике должен быть уникастным адресом, принадлежащим интерфейсу, через который был получен мультикастный запрос эхо.
Информация, полученная в ICMPv6 сообщении запроса эхо, должна быть полостью возвращена без модификации в ICMPv6 эхо-отклике, если эхо-отклик не превысит MTU обратного прохода, в противном случае пакет укорачивается.
Оповещение верхнего уровня
Сообщения эхо-отклик должны передаваться пользовательскому интерфейсу ICMPv6, если соответствующий запрос эхо исходит не из IP-уровня.
Сообщение о членстве в группе имеет следующий формат:
Рис. 4.4.1.1.38. Сообщения участия в группе
Поля IPv6:
Адрес места назначения
В сообщении-запросе о членстве в группе запрашивается мультикаст-адрес группы.
В отчете о членстве в группе или в сообщении о сокращении членства в группе сообщается мультикаст-адрес группы.
Поле Hop Limit = 1 (предельное число шагов)
Поля ICMPv6:
Тип 130 – Запрос членства в группе
131 – Отчет о членстве в группе
132 – Сокращение членства в группе
Код 0
Максимальное время отклика
В сообщениях запросах - это максимальное время в миллисекундах, на которое может задержаться сообщение-отчет. В сообщениях-отчетах и сообщениях о сокращении в это поле отправитель записывает нуль, а получатель его игнорирует.
Не используется. Отправитель записывает нуль, получатель игнорирует.
Мультикаст-адрес
Адрес мультикаст-группы, сообщение о которой послано. В сообщениях-запросах поле мультикаст-адреса может равняться нулю, что означает запрос ко всем группам.
Описание
Сообщения ICMPv6 о членстве в группе используются для передачи информации о членстве в мультикаст-группе от узлов к их ближайшим маршрутизаторам. Подробности их использования можно найти в [RFC-1112].
Литература
| [1] | Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, USC/Information Sciences Institute, November 1987. |
| [2] | Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987. |
| [3] | Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995. |
| [4] | Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", Work in Progress. |
| [ALLOC] | Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast Address Allocation", RFC 1887, cisco Systems, December 1995 |
| [ANYCST] | Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, BBN, November 1993. |
| [CIDR] | Fuller, V., Li, T., Varadhan, K., and J. Yu, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cisco, Merit, OARnet, June 1992. |
| [IPV6] | Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC, Ipsilon Networks, December 1995. |
| [IPv6-ADDR] | Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995. |
| [IPv6-DISC] | Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", Work in Progress |
| [MULT] | Deering, S., "Host Extensions for IP multicasting", STD 5, RFC 1112, Stanford University, August 1989 |
| [NSAP] | Carpenter, B., Editor, "Mechanisms for OSIN SAPs, CLNP and TP over IPv6", Work in Progress. |
| [RFC-791] | Postel, J., "Internet Protocol", STD 5, RFC 791, USC/Information Sciences Institute, September 1981. |
| [RFC-792] | Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, USC/Information Sciences Institute, September 1981 |
| [RFC-1112] | Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, Stanford University, August 1989. |
| [RFC-1122] | Braden, R., "Requirements for Internet Hosts -Communication Layers", STD 3, RFC 1122, USC/Information Sciences Institute, October 1989 |
| [RFC-1191] | Mogul, J., and S. Deering, "Path MTU Discovery", RFC1191, DECWRL, Stanford University, November 1990. |
| [RFC-1661] | Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994. |
| [RFC-1700] | Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. |
| [RFC-1825] | Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995. |
| [RFC-1826] | Atkinson, R., "IP Authentication Header", RFC 1826, Naval Research Laboratory, August 1995. |
| [RFC-1827] | Atkinson, R., "IP Encapsulating Security Protocol (ESP)", RFC 1827, Naval Research Laboratory, August 1995 |
| [RFC-1885] | Conta, A., and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885, Digital Equipment Corporation, Xerox PARC, December 1995. |
| [RFC-1884] | Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December 1995 |
| [RFC-1933] | Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan & E. Nordmark. April 1996 |
| [RFC-1970] | Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark & W. Simpson. August 1996. |
| [RFC-1971] | IPv6 Stateless Address Autoconfiguration. S. Thomson & T. Narten. August 1996. |
| [RFC-1972] | A Method for the Transmission of IPv6 Packets over Ethernet Networks. M. Crawford. August 1996. |
| [RFC-2019] | Transmission of IPv6 Packets Over FDDI. M. Crawford. October 1996. |
| [RFC-2030] | Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. D. Mills. October 1996. |
| [RFC-2080] | RIPng for IPv6. G. Malkin, R. Minnear. January 1997. |
| [RFC-2133] | Basic Socket Interface Extensions for IPv6. R. Gilligan, S. Thomson, J. Bound, W. Stevens. April 1997. |
Алгоритм DES
6.4.1 Алгоритм DES
Семенов Ю.А. (ГНЦ ИТЭФ)
Исходные идеи алгоритма шифрования данных DEA (data encryption algorithm) были предложены компанией IBM еще в 1960-х годах и базировались на идеях, описанных Клодом Шенноном в 1940-х годах. Первоначально эта методика шифрования называлась lucifer (разработчик Хорст Фейштель, название dea (см. http/:snoopy.falkor.gen.nz/~rae/des.html) она получила лишь в 1976 году. Lucifer был первым блочным алгоритмом шифрования, он использовал блоки размером 128 бит и 128-битовый ключ. По существу этот алгоритм являлся прототипом DEA. В 1986 в Японии (NIT) разработан алгоритм FEAL(Fast data Encipherment ALgorithm), предназначенный для использования в факсах, модемах и телефонах (длина ключа до 128 бит). Существует и ряд других разработок.
DEA (ANSI x3.92-1981; www.cryptosoft.com/html/fips46-2.htm) оперирует с блоками данных размером 64 бита и использует ключ длиной 56 бит. Такая длина ключа соответствует 1017 комбинаций, что обеспечивало до недавнего времени достаточный уровень безопасности. В дальнейшем можно ожидать расширения ключа до 64 бит (например, LOKI) или вообще замены DES другим стандартом.
Входной блок данных, состоящий из 64 бит, преобразуется в выходной блок идентичной длины. Ключ шифрования должен быть известен, как отправляющей так и принимающей сторонам. В алгоритме широко используются перестановки битов текста.
Вводится функция f, которая работает с 32-разрядными словами исходного текста (А) и использует в качестве параметра 48-разрядный ключ (J). Схеме работы функции f показана на рис. 6.4.1.1. Сначала 32 входные разряда расширяются до 48, при этом некоторые разряды повторяются. Схема этого расширения показана ниже (номера соответствуют номерам бит исходного 32-разрядного кода).
32 1 2 3 4 5
4 5 6 7 8 9
8 9 10 11 12 13
12 13 14 15 16 17
16 17 18 19 20 21
20 21 22 23 24 25
24 25 26 27 28 29
28 29 30 31 32 1
Для полученного 48-разрядного кода и ключа выполняется операция исключающее ИЛИ (XOR). Результирующий 48-разрядный код преобразуется в 32-разрядный с помощью S-матриц. На выходе S-матриц осуществляется перестановка согласно схеме показанной ниже (числа представляют собой порядковые номера бит).
16 7 20 21
29 12 28 17
1 15 23 26
5 18 31 10
2 8 24 14
32 27 3 9
19 13 30 6
22 11 4 25
Рис. 6.4.1.1. Алгоритм работы функции f
Преобразование начинается с перестановки бит (IP – Initial Permutation) в 64-разрядном блоке исходных данных. 58-ой бит становится первым, 50-ый – вторым и т.д. Схема перестановки битов показана ниже.
58 50 42 34 26 18 10 2
60 52 44 36 28 20 12 4
62 54 46 38 30 22 14 6
64 56 48 40 32 24 16 8
57 49 41 33 25 17 9 1
59 51 43 35 27 19 11 3
61 53 45 37 29 21 13 5
63 55 47 39 31 23 15 7
Полученный блок делится на две 32-разрядные части L0 и R0. Далее 16 раз повторяются следующие 4 процедуры:
Преобразование ключа с учетом номера итерации i (перестановки разрядов с удалением 8 бит, в результате получается 48-разрядный ключ)
Пусть A=Li, а J – преобразованный ключ. С помощью функции f(A,J) генерируется 32-разрядный выходной код.
Выполняется операция XOR для Ri f(A,J), результат обозначается Ri+1.
Выполняется операция присвоения Li+1=Ri.
Структурная схема реализации алгоритма dea показана на рис. 6.4.1.2.
Рис. 6.4.1.2. Структурная схема реализации алгоритма DEA
Инверсная перестановка разрядов предполагает следующее размещение 64 бит зашифрованных данных (первым битом становится 40-ой, вторым 8-ой и т.д.).
40 8 48 16 56 24 64 32
39 7 47 15 55 23 63 31
38 6 46 14 54 22 62 30
37 5 45 13 53 21 61 29
36 4 44 12 52 20 60 28
35 3 43 11 51 19 59 27
34 2 42 10 50 18 58 26
33 1 41 9 49 17 57 25
S-матрицы представляют собой таблицы содержащие 4-ряда и 16 столбцов. Матрица S(1) представлена ниже (эта матрица, также как и те, что приведены в ссылке 2, являются рекомендуемыми).
No. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0 14 4 13 1 2 15 11 8 3 10 6 12 5 9 0 7
1 0 15 7 4 14 2 13 1 10 6 12 11 9 5 3 8
2 4 1 14 8 13 6 2 11 15 12 9 7 3 10 5 0
3 15 12 8 2 4 9 1 7 5 11 3 14 10 0 6 13
Исходный 48-разрядный код делится на 8 групп по 6 разрядов. Первый и последний разряд в группе используется в качестве адреса строки, а средние 4 разряда – в качестве адреса столбца. В результате каждые 6 бит кода преобразуются в 4 бита, а весь 48-разрядный код в 32-разрядный (для этого нужно 8 S-матриц). Существуют разработки, позволяющие выполнять шифрование в рамках стандарта DES аппаратным образом, что обеспечивает довольно высокое быстродействие.
Преобразования ключей Kn (n=1,…,16; Kn = KS(n,key), где n – номер итерации) осуществляются согласно алгоритму, показанному на рис. 6.4.1.3.
Рис. 6.4.1.3. Алгоритм вычисления последовательности ключей Kn
Для описания алгоритма вычисления ключей Kn (функция KS) достаточно определить структуру “Выбора 1” и “Выбора 2”, а также задать схему сдвигов влево (табл. 6.4.1.2). “Выбора 1” и “Выбора 2” представляют собой перестановки битов ключа (PC-1 и PC-2; табл. 6.4.1.1). При необходимости биты 8, 16,…, 64 могут использоваться для контроля четности.
Для вычисления очередного значения ключа таблица делится на две части С0 и D0. В С0 войдут биты 57, 49, 41,…, 44 и 36, а в D0 – 63, 55, 47,…, 12 и 4. Так как схема сдвигов задана (табл. 6.4.1.2) C1,D1; Cn, Dn и так далее могут быть легко получены из C0 и D0. Так, например, C3 и D3 получаются из C2 и D2 циклическим сдвигом влево на 2 разряда
Таблица 6.4.1.1
PC-1 (Выбор 1)
PC-2 (Выбор 2)
Номер итерации |
Число сдвигов влево |
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
| 4 | 2 |
| 5 | 2 |
| 6 | 2 |
| 7 | 2 |
| 8 | 2 |
| 9 | 1 |
| 10 | 2 |
| 11 | 2 |
| 12 | 2 |
| 13 | 2 |
| 14 | 2 |
| 15 | 2 |
| 16 | 1 |
Алгоритм Диффи-Хелмана
6.4.6 Алгоритм Диффи-Хелмана
Семенов Ю.А. (ГНЦ ИТЭФ)
Алгоритм Диффи-Хелмана (1976 год) использует функцию дискретного возведения в степень и похож на метод Эль-Гамаля.
Сначала генерируются два больших простых числа n и q. Эти два числа не обязательно хранить в секрете. Далее один из партнеров P1 генерирует случайное число x и посылает другому участнику будущих обменов P2 значение
A = qx mod n
По получении А партнер P2 генерирует случайное число у и посылает P2 вычисленное значение
B = qy mod n
Партнер P1, получив В, вычисляет Kx = Bx mod n, а партнер P2 вычисляет Ky = Ay mod n. Алгоритм гарантирует, что числа Ky и Kx равны и могут быть использованы в качестве секретного ключа для шифрования. Ведь даже перехватив числа А и В, трудно вычислить Kx или Ky.
Алгоритм Диффи-Хелмана, обеспечивая конфиденциальность передачи ключа, не может гарантировать того, что он прислан именно тем партнером, который предполагается. Для решения этой проблемы был предложен протокол STS (station-to-station). Этот протокол для идентификации отправителя использует технику электронной подписи. Подпись шифруется общим секретным ключом, после того как он сформирован. Подпись включает в себя идентификаторы как P1, так и P2. (см. также RFC-2786 "Diffie-Helman USM Key Management Information Base and Textual Convention. M. St. Johns. March 2000".)
Алгоритм Эль Гамаля
6.4.5 Алгоритм Эль Гамаля
Семенов Ю.А. (ГНЦ ИТЭФ)
Алгоритм Эль-Гамаля может использоваться для формирования электронной подписи или для шифрования данных. Он базируется на трудности вычисления дискретного логарифма. Для генерации пары ключей сначала берется простое число p и два случайных числа g и x, каждое из которых меньше p. Затем вычисляется:
y = gx mod p
Общедоступными ключами являются y, g и p, а секретным ключом является х. Для подписи сообщения M выбирается случайное число k, которое является простым по отношению к p-1. После этого вычисляется a = gk mod p. Далее из уравнения M = (xa + kb) mod (p-1) находим b. Электронной подписью для сообщения M будет служить пара a и b. Случайное число k следует хранить в секрете. Для верификации подписи необходимо проверить равенство:
yaab mod p = gM mod p.
Пара a и b представляют собой зашифрованный текст. Следует заметить, что зашифрованный текст имеет размер в два раза больше исходного. Для дешифрования производится вычисление:
M = b/ax mod p
Алгоритм шифрования RSA
6.4.2 Алгоритм шифрования RSA
Семенов Ю.А. (ГНЦ ИТЭФ)
Алгоритм RSA предполагает, что посланное закодированное сообщение может быть прочитано адресатом и только им. В этом алгоритме используется два ключа – открытый и секретный. Данный алгоритм привлекателен также в случае, когда большое число субъектов (N) должно общаться по схеме все-со-всеми. В случае симметричной схемы шифрования каждый из субъектов каким-то образом должен доставить свои ключи всем остальным участникам обмена, при этом суммарное число используемых ключей будет достаточно велико при большом значении N. Применение асимметричного алгоритма требует лишь рассылки открытых ключей всеми участниками, суммарное число ключей равно N.
Сообщение представляется в виде числа M. Шифрование осуществляется с помощью общедоступной функции f(M), и только адресату известно, как выполнить операцию f-1. Адресат выбирает два больших простых (prime) числа p и q, которые делает секретными. Он объявляет n=pq и число d, c (d,p-1)=(d,q-1)=1 (один из возможных способов выполнить это условие, выбрать d больше чем p/2 и q/2). Шифрование производится по формуле:
f(M) є Md mod n,
где M и f(M) оба Ј n-1. Как было показано, может быть вычислено за разумное время, даже если M, d и n содержит весьма большое число знаков. Адресат вычисляет M на основе Md, используя свое знание p и q. В соответствие со следствием 6, если
dc є(p-1)1, тогда (Md)eє p1.
Исходный текст M получается адресатом из зашифрованного F(M) путем преобразования: M = (F(M))e (mod pq). Здесь как исходный текст, так и зашифрованный рассматриваются как длинные двоичные числа.
Аналогично (Md)e є qM, если dc є (q-1)1. e удовлетворяет этим двум условиям, если cd є (p-1) (q-1)1. Теорема 1 гласит, что мы можем позволить e=x, когда x является решением уравнения dx + (p-1)(q-1)y = 1.
Так как (Md)e – M делимо на p и q, оно делимо и на pq, следовательно, мы можем определить M, зная Md, вычислив его значение в степени e и определив остаток от деления на pq. Для соблюдения секретности важно, чтобы, зная n, было нельзя вычислить p и q. Если n содержит 100 цифр, подбор шифра связан с перебором ~1050 комбинаций. Данная проблема изучается уже около 100 лет. RSA-алгоритм запатентован (20 сентября 1983, действует до 2000 года).
Теоретически можно предположить, что возможно выполнение операции f-1, не вычисляя p и q. Но в любом случае задача эта не проста и разработчики считают ее трудно факторизуемой.
Предположим, что мы имеем зашифрованный текст f(M) и исходный текст M, и мы хотим найти значения p и q. Нетрудно показать, что таких исходных данных для решения задачи недостаточно – надо знать все возможные значения Mi.
Проясним использование алгоритма RSA на конкретном примере. Выбираем два простые числа p=7; q=17 (на практике эти числа во много раз длиннее). В этом случае n = p*q будет равно 119. Теперь необходимо выбрать e, выбираем e=5. Следующий шаг связан с формированием числа d так, чтобы d*e=1 mod [(p-1)(q-1)]. d=77 (использован расширенный алгоритм Эвклида). d – секретный ключ, а e и n характеризуют открытый ключ. Пусть текст, который нам нужно зашифровать представляется M=19. С = Memod n. Получаем зашифрованный текст C=66. Этот “текст” может быть послан соответствующему адресату. Получатель дешифрует полученное сообщение, используя М= Cdmod n и C=66. В результате получается M=19.
На практике общедоступные ключи могут помещаться в специальную базу данных. При необходимости послать партнеру зашифрованное сообщение можно сделать сначала запрос его открытого ключа. Получив его, можно запустить программу шифрации, а результат ее работы послать адресату. На использовании общедоступных ключей базируется и так называемая электронная подпись, которая позволяет однозначно идентифицировать отправителя. Сходные средства могут применяться для предотвращения внесения каких-либо корректив в сообщение на пути от отправителя к получателю. Быстродействующие аппаратные 512-битовые модули могут обеспечить скорость шифрования на уровне 64 кбит в сек. Готовятся ИС, способные выполнять такие операции со скоростью 1 Мбайт/сек. Разумный выбор параметра e позволяет заметно ускорить реализацию алгоритма.
Алгоритм шифрования SAFER
6.4.8 Алгоритм шифрования SAFER
Семенов Ю.А. (ГНЦ ИТЭФ)
Алгоритм шифрования SAFER (Secure And Fast Encryption Routine; http://fn2.freenet.edmonton.ab.ca/~jsavard/co0403.html) не использует разбивку исходного текста на блоки (как это делается в DES или IDEA). Здесь исходный текст пропускается через S-матрицы, которые заменяются на обратные версии при дешифровании. В SAFER используется 8 циклов. Первый шаг цикла заключается в использовании первого субключа для преобразования 8 байт исходного текста. То, как используется субключ, зависит от номера байта в группе. Так для 1-го, 4-го, 5-го и 8-го для этого служит операция XOR, а для 2-го, 3-го, 6-го и 7-го байтов применяется операция сложения.
Затем при обработке текста в S-матрице байты, для которых было применено исключающее ИЛИ, поступают на обычную матрицу, для остальных применяется инвертированная. s-матрицы представляют собой таблицы байтов, которые получаются по формуле 45N mod 257, где N –номер кода в таблице (после чего выделяются 8 младших разрядов).
1 45 226 147 190 69 21 174
120 3 135 164 184 56 207 63
8 103 9 148 235 38 168 107
189 24 52 27 187 191 114 247
64 53 72 156 81 47 59 85
227 192 159 216 211 243 141 177
255 167 62 220 134 119 215 166
17 251 244 186 146 145 100 131
241 51 239 218 44 181 178 43
136 209 153 203 140 132 29 20
129 151 113 202 95 163 139 87
60 130 196 82 92 28 232 160
4 180 133 74 246 19 84 182
223 12 26 142 222 224 57 252
32 155 36 78 169 152 158 171
242 96 208 108 234 250 199 217
0 212 31 110 67 188 236 83
137 254 122 93 73 201 50 194
249 154 248 109 22 219 89 150
68 233 205 230 70 66 143 10
193 204 185 101 176 210 198 172
30 65 98 41 46 14 116 80
2 90 195 37 123 138 42 91
240 6 13 71 111 112 157 126
16 206 18 39 213 76 79 214
121 48 104 54 117 125 228 237
128 106 144 55 162 94 118 170
197 127 61 175 165 229 25 97
253 77 124 183 11 238 173 75
34 245 231 115 35 33 200 5
225 102 221 179 88 105 99 86
15 161 49 149 23 7 58 40
Обратная матрица при этом имеет вид.
128 0 176 9 96 239 185 253
16 18 159 228 105 186 173 248
192 56 194 101 79 6 148 252
25 222 106 27 93 78 168 130
112 237 232 236 114 179 21 195
255 171 182 71 68 1 172 37
201 250 142 65 26 33 203 211
13 110 254 38 88 218 50 15
32 169 157 132 152 5 156 187
34 140 99 231 197 225 115 198
175 36 91 135 102 39 247 87
244 150 177 183 92 139 213 84
121 223 170 246 62 163 241 17
202 245 209 23 123 147 131 188
189 82 30 235 174 204 214 53
8 200 138 180 226 205 191 217
208 80 89 63 77 98 52 10
72 136 181 86 76 46 107 158
210 61 60 3 19 251 151 81
117 74 145 113 35 190 118 42
95 249 212 85 11 220 55 49
22 116 215 119 167 230 7 219
164 47 70 243 97 69 103 227
12 162 59 28 133 24 4 29
41 160 143 178 90 216 166 126
238 141 83 75 161 154 193 14
122 73 165 44 129 196 199 54
43 127 67 149 51 242 108 104
109 240 2 40 206 221 155 234
94 153 124 20 134 207 229 66
184 64 120 45 58 233 100 31
146 144 125 57 111 224 137 48
После обработки с помощью S-матрицы используется второй субключ, который воздействует на блок преобразуемых данных. В этом случае используется другая последовательность операций: ADD, XOR, XOR, ADD, ADD, XOR, XOR, ADD (сравните с порядком операций, указанным в первом абзаце главы). Далее байты группируются: второй байт заменяется суммой первого байта и второго, первый – суммой нового значения второго байта и первого, четвертый – суммой третьего и четвертого, третий – суммой нового значения четвертого и третьего и т.д. вплоть до 8 байта включительно (см. рис. 6.4.8.1). При суммировании в результате операции учитываются только младшие 8 бит. По завершении этой процедуры байты выкладываются в следующем порядке (цифры означают старое положений байтов):
3 5 7 2 4 6 8
Рис. 6.4.8.1. Блок-схема реализации цикла алгоритма SAFER
После этого процедуры группирования и суммирования и перемешивания байтов повторяются.
Дешифровка в рамках алгоритма SAFER реализуется для каждой из процедур (путем замены их на обратные), примененной при шифровании независимо.
В качестве первого 64-битного субключа используется основной ключ шифрования. Для генерации последующих ключей используется циклический сдвиг влево на 3 бита. Полученные результаты объединяются с определенной константой (специфичной для каждого цикла) с помощью операции исключающее ИЛИ (XOR). Для первого субключа эта константа равна нулю. Далее используются константы, приведенные ниже:
16733B1E8E70BD86
477E2456F1778846
B1BAA3B7100AC537
C95A28AC64A5ECAB
C66795580DF89AF6
66DC053DD38AC3D8
6AE9364943BFEBD4
9B68A0655D57921F
715CBB22C1BE7BBC
63945F2A61B83432
FDFB1740E6511D41
8F29DD0480DEE731
7F01A2F739DA6F23
FE3AD01CD1303E12
CD0FE0A8AF82592C
7DADB2EFC287CE75
1302904F2E723385
8DCFA981E2C4272F
7A9F52E115382BFC
42C708E409555E8C
Алгоритм Зива-Лемпеля
2.6.1 Алгоритм Зива-Лемпеля
Семенов Ю.А. (ГНЦ ИТЭФ)
Большинство алгоритмов сжатия базируется на последовательной схеме сжатия Лемпеля-Зива (Lempel-Ziv, 1977). Этот алгоритм используется, в частности, стандартной процедурой UNIX Compress. Методики со статистическим моделированием могут обеспечить лучшее сжатие, но они заметно медленнее. Но существует алгоритм, который совмещает в себе лучшие из черт названных выше. Этот алгоритм не предусматривает последовательной обработки входных данных, а обрабатывает текст по-блочно. Здесь используется обратимое преобразование блока данных к виду, который позволяет эффективно сжать данные с помощью простых алгоритмов. Преобразование имеет целью сгруппировать символы так, чтобы вероятность появления последовательностей идентичных символов значительно возросла. Такой текст может быть легко сжат посредством локально-адаптивных алгоритмов в сочетании с кодировкой Хафмана и арифметической кодировкой.
Последовательность S, содержащая N символов ({S(0),… S(N-1)}), подвергается N циклическим сдвигам (вращениям), лексикографической сортировке, а последний символ при каждом вращении извлекается. Из этих символов формируется строка L, где i-ый символ является последним символом i-го вращения. Кроме строки L создается индекс I исходной строки S в упорядоченном списке вращений. Существует эффективный алгоритм восстановления исходной последовательности символов S на основе строки L и индекса I. Процедура сортировки объединяет результаты вращений с идентичными начальными символами. Предполагается, что символы в S соответствуют алфавиту, содержащему K символов.
Для пояснения работы алгоритма возьмем последовательность S= “abraca” (N=6), алфавит X = {‘a’,’b’,’c’,’r’}.
1. Формируем матрицу из N*N элементов, чьи строки представляют собой результаты циклического сдвига (вращений) исходной последовательности S, отсортированных лексикографически. По крайней мере одна из строк M содержит исходную последовательность S. Пусть I является индексом строки S. В приведенном примере индекс I=1, а матрица M имеет вид:
Номер строки |
|
0 |
aabrac |
1 |
abraca |
2 |
acaabr |
3 |
bracaa |
4 |
caabra |
5 |
racaab |
2. Пусть строка L представляет собой последнюю колонку матрицы M с символами L[0],…,L[N-1] (соответствуют M[0,N-1],…,M[N-1,N-1]). Формируем строку последних символов вращений. Окончательный результат характеризуется (L,I). В данном примере L=’caraab’, I =1.
Процедура декомпрессии использует L и I. Целью этой процедуры является получение исходной последовательности из N символов (S).
1. Сначала вычисляем первую колонку матрицы M (F). Это делается путем сортировки символов строки L. Каждая колонка исходной матрицы M представляет собой перестановки исходной последовательности S. Таким образом, первая колонка F и L являются перестановками S. Так как строки в M упорядочены, размещение символов в F также упорядочено. F=’aaabcr’.
2. Рассматриваем ряды матрицы M, которые начинаются с заданного символа ch. Строки матрицы М упорядочены лексикографически, поэтому строки, начинающиеся с ch упорядочены аналогичным образом. Определим матрицу M’, которая получается из строк матрицы M путем циклического сдвига на один символ вправо. Для каждого i=0,…, N-1 и каждого j=0,…,N-1,
M’[i,j] = m[i,(j-1) mod N]
В рассмотренном примере M и M’ имеют вид:
Строка |
M |
M’ |
0 |
aabrac |
caabra |
1 |
abraca |
aabraс |
2 |
acaabr |
racaab |
3 |
bracaa |
abraca |
4 |
caabra |
acaabr |
5 |
racaab |
bracaa |
Подобно M каждая строка M’ является вращением S, и для каждой строки M существует соответствующая строка M’. M’ получена из M так, что строки M’ упорядочены лексикографически, начиная со второго символа. Таким образом, если мы рассмотрим только те строки M’, которые начинаются с заданного символа ch, они должны следовать упорядоченным образом с учетом второго символа. Следовательно, для любого заданного символа ch, строки M, которые начинаются с ch, появляются в том же порядке что и в M’, начинающиеся с ch. В нашем примере это видно на примере строк, начинающихся с ‘a’. Строки ‘aabrac’, ‘abraca’ и ‘acaabr’ имеют номера 0, 1 и 2 в M и 1, 3, 4 в M’.
Используя F и L, первые колонки M и M’ мы вычислим вектор Т, который указывает на соответствие между строками двух матриц, с учетом того, что для каждого j = 0,…,N-1 строки j M’ соответствуют строкам T[j] M.
Если L[j] является к-ым появлением ch в L, тогда T[j]=1, где F[i] является к-ым появлением ch в F. Заметьте, что Т представляет соответствие один в один между элементами F и элементами L, а F[T[j]] = L[j]. В нашем примере T равно: (4 0 5 1 2 3).
3. Теперь для каждого i = 0,…, N-1 символы L[i] и F[i] являются соответственно последними и первыми символами строки i матрицы M. Так как каждая строка является вращением S, символ L[i] является циклическим предшественником символа F[i] в S. Из Т мы имеем F[T[j]] = L[j]. Подставляя i =T[j], мы получаем символ L[T(j)], который циклически предшествует символу L[j] в S.
Индекс I указывает на строку М, где записана строка S. Таким образом, последний символ S равен L[I]. Мы используем вектор T для получения предшественников каждого символа: для каждого i = 0,…,N-1 S[N-1-i] = L[Ti[I]], где T0[x] =x, а Ti+1[x] = T[Ti[x]. Эта процедура позволяет восстановить первоначальную последовательность символов S (‘abraca’).
Последовательность Ti[I] для i =0,…,N-1 не обязательно является перестановкой чисел 0,…,N-1. Если исходная последовательность S является формой Zp для некоторой подстановки Z и для некоторого p>1, тогда последовательность Ti[I] для i = 0,…,N-1 будет также формой Z’p для некоторой субпоследовательности Z’. Таким образом, если S = ‘cancan’, Z = ‘can’ и p=2, последовательность Ti[I] для i = 0,…,N-1 будет [2,4,0,2,4,0].
Описанный выше алгоритм упорядочивает вращения исходной последовательности символов S и формирует строку L, состоящую из последних символов вращений. Для того, чтобы понять, почему такое упорядочение приводит к более эффективному сжатию, рассмотрим воздействие на отдельную букву в обычном слове английского текста.
Возьмем в качестве примера букву “t” в слове ‘the’ и предположим, что исходная последовательность содержит много таких слов. Когда список вращений упорядочен, все вращения, начинающиеся с ‘he’, будут взаимно упорядочены. Один отрезок строки L будет содержать непропорционально большое число ‘t’, перемешанных с другими символами, которые могут предшествовать ‘he’, такими как пробел, ‘s’, ‘T’ и ‘S’.
Аналогичные аргументы могут быть использованы для всех символов всех слов, таким образом, любая область строки L будет содержать большое число некоторых символов. В результате вероятность того, что символ ‘ch’ встретится в данной точке L, весьма велика, если ch встречается вблизи этой точки L, и мала в противоположном случае. Это свойство способствует эффективной работе локально адаптивных алгоритмов сжатия, где кодируется относительное положение идентичных символов. В случае применения к строке L, такой кодировщик будет выдавать малые числа, которые могут способствовать эффективной работе последующего кодирования, например, посредством алгоритма Хафмана.
Ссылки
J.Ziv and A.Lempel. A universal algorithm for sequential data compression. IEEE Transactions on Information Theory. Vol. IT-23, N.3, May 1977, pp. 337-343.
J.Ziv and A.Lempel. Compression of individual sequences via variable rate coding. IEEE Transactions on Information Theory. Vol. IT-24. N.5, September 1978, pp. 530-535.
M.Burrows and D.J.Wheeler. A block-sorting Lossless Data Compression Algorithm. Digital Systems Research Center. SRC report 124. May 10, 1994.
J.L.Bently, D.D.Sleator, R.E.Tarjan, and V.K.Wei. A locally adaptive data compression algorithm. Communications of the ACM, Vol. 29, No. 4, April 1986, pp. 320-330
http://www.ics.uci.edu/~dan/pubs/DataCompression.html (Saleem Bhatti)
http://www.speednet/~spenser/ted/DataCompression.html
http://www.iicm.edu/jucs_1_8/differencial_ziv_lempel_text/html/paper.html
AppleTalk
4.2.2 AppleTalk
Семенов Ю.А. (ГНЦ ИТЭФ)
Сеть APPLETALK разработана компанией apple computer inc. (ЭВМ Macintosh, 1987 г) Эти сети могут работать в среде Ethernet, Token Ring, FDDI и localtalk (собственная сеть apple, использующая скрученные пары). В AppleTalk специфицирован собственный стек протоколов, которые управляют потоком данных в сети. Для целей маршрутизации AppleTalk использует модифицированную версию внутреннего протокола маршрутизации IGRP. Стек протоколов appletalk phase ii включает в себя (схема структуры стека протоколов показана на рис. 4.2.2.1; смотри http://bbs-win.uniinc.msk.ru/product/bay/routers/protocol, а также RFC-1378, -1419, -1504, -1742):
Протокол доступа к каналу Tokentalk (TLAP - Tokentalk link access protocol)
Протокол доступа к каналу Ethertalk (ELAP - Ethertalk link access protocol)
Протокол доступа к каналу Localtalk (LLAP - Localtalk link access protocol)
Протокол доставки дейтограмм (DDP - datagram delivery protocol)
протокол поддержки маршрутных таблиц (RTMP - routing table maintenance protocol)
Протокол определения адресов Appletalk (AARP - appletalk address resolution protocol)
Протокол работы с именами (NBP - name binding protocol)
Протокол для работы с зонной информацией (ZIP - zone information protocol)
Протокол откликов в Appletalk (AEP - appletalk echo protocol)
Протокол актуализации маршрутной информации (AURP - Appletalk update routing protocol)
Протокол управления потоком данных (adsp - appletalk data stream protocol)
Протокол сессий (ASP - Appletalk session protocol)
Протокол доступа к принтеру (PAP - printer access protocol)
Протокол операций (ATP - Appletalk transaction protocol)
Файловый протокол (AFP - Appletalk filing protocol)
Из рисунка 4.2.2.1 видно, что стек протоколов appletalk полностью согласуется с семиуровневой схемой OSI. DDP представляет собой протокол передачи данных, не ориентированный на соединение. Дейтограмма DDP использует 13-байтовый заголовок, который включает в себя:
поле числа маршрутизаторов (число шагов), через которые прошел пакет; поле длины дейтограммы; поле контрольной суммы; поля сети назначения и отправителя и т.д. (см. рис. 4.2.2.2. - смотри http://www.stanford.edu/group/networking/adminatalk/atalk_3.html).
Вслед за заголовком следует информация, которая может содержать до 586 байт. Максимальный размер пакета (MTU) равен 599 байтам. Число узлов в сети может достигать 16 миллионов.
Рис. 4.2.2.1. Диаграмма стека протоколов appletalk
Протокол adsp позволяет двум программам обмениваться потоками информации в полном дуплексном режиме с гарантией доставки. Протоколы TLAP, ELAP и LLAP служат для обеспечения сопряжения с соответствующими физическими протоколами (Token Ring, Ethernet и Arcnet), скрывая от программ других уровней специфические особенности используемого сетевого оборудования. Протокол ATP надежно передает запросы и отклики, детектирует ошибки и организует пакетный обмен. Этот протокол используется в свою очередь протоколами ZIP, ASP и PAP, что видно из рис. 4.2.2.1. Протокол AFP является протоколом поддержки приложений и позволяет пользователям ЭВМ Macintosh работать с общими файлами. Программное обеспечение Netware для Macintosh включает в себя файл AFP NLMtm, который обеспечивает поддержку Netware-серверов. Протокол AURP (appletalk update-based routing protocol) служит для целей маршрутизации, но в отличии от некоторых других протоколов передает маршрутную информацию только в случае изменения ситуации. Он поддерживает также IP-туннели.
Рис. 4.2.2.2. Формат пакетов в сети Apple Talk Phase II (в скобках указаны размеры полей в байтах)
Адрес отправителя и получателя имеют по 24 бита, из них 16 бит составляет адрес сети. Идентификатор узла назначения (локальная часть адреса) выбирается произвольно самой рабочей станции при установлении связи. ЭВМ берет случайное 8-битовое число в качестве локального адреса и посылает его в сеть. Если какая-то ЭВМ использует этот адрес, она откликается, тогда код меняется и делается повторная попытка. Процесс продолжается пока не будет найден свободный адрес. Протокол RTMP является протоколом маршрутизации, где в качестве метрики используется вектор расстояния до адресата, этот протокол собирает маршрутную информацию и предоставляет ее протоколу DDP для обеспечения транспортировки пакетов по сети. Маршрутные таблицы RTMP хранятся в каждом из маршрутизаторов AppleTalk и базируются на номерах сетей адресатов. Таблица содержит в себе расстояние до адресата, измеренное в шагах (hop), идентификатор порта маршрутизатора, через который достижим адресат, и статус маршрута.
Маршрутизаторы AppleTalk формируют и актуализируют маршрутные таблицы, посылая регулярно (раз в 10 сек) широковещательные RTMP-пакеты соседним узлам и сетям. Запись в маршрутной таблице, своевременно не подтвержденная, спустя определенное время стирается. Записи в маршрутной таблице попадают в разряд “подозреваемых” при отсутствии отклика от них в течение 20 сек, в разряд “умирающих” - спустя 40 сек, в категорию “умерших” - через 60 сек. Запись удаляется из таблицы, если отклик не удается получить в течение 80 сек.
Адреса сетевого уровня ставятся в соответствие адресам MAC-уровня с помощью адресного протокола AARP. Узлы сети Apple Talk хранят эту информацию в специальных таблицах (AMT - Address Mapping Table). Таблица просматривается всякий раз, когда AppleTalk посылает пакет. Если поиск не увенчался успехом, узел-отправитель посылает широковещательный AARP-запрос. При получении отклика на этот запрос вносятся коррективы в AMT-таблицу. Особенностью сети AppleTalk является согласование при присвоении локальных адресов объектам сети. При инициализации узла ему присваивается временный адрес. Протокол AARP проверяет, не принадлежит ли данный адрес кому-то еще, для этого он посылает 10 AARP-запросов. Если данный временный адрес уже используется, инициализируемому узлу присваивается новый временный адрес и процедура проверки повторяется до тех пор, пока узлу не будет присвоен уникальный адрес. Протокол NBP преобразует локальные AppleTalk адреса в имена, присвоенные сетевому объекту пользователем и наоборот. Это избавляет пользователя от необходимости помнить полный сетевой адрес принт- или файл-сервера, почтового сервера и т.д..
Протокол ZIP допускает логическое группирование оконечных сетевых узлов в некоторые объединения, называемые зонами, что позволяет ЭВМ, принадлежащие к одному отделу, но расположенные в разных зданиях, находиться в одной зоне (субсети). Зона может представлять собой комбинацию локальных сетей, а в случае EtherTalk Phase II - часть локальной сети. Информация о зонах хранится в маршрутизаторах в виде специальных таблиц (ZIT - Zone Information Table). Таблица содержит по одной записи на сетевой сегмент. Запись включает в себя номер сетевого сегмента и список объектов, входящих в зону. Протокол ZIP отслеживает изменения в RTMP-таблицах и при появлении в них записей, относящихся к новым объектам или сетям, маршрутизатор посылает ZIP -запрос и на основе полученной информации корректирует ZIT-таблицу.
Протокол AEP выполняет отладочные и диагностические функции, предоставляя возможность выполнения процедур ping (до какой-то степени это аналог протокола ICMP). При необходимости проверить состояние сети или какого-либо узла посылается AEP-дейтограмма, а зондируемый узел, который при ее получении должен послать отклик отправителю исходного запроса. Протокол позволяет проверить время распространения пакетов между узлами сети. Протокол может использоваться в начале любой сессии для проверки доступности того или иного сетевого объекта.
Протокол AURP является внешним протоколом сетевой маршрутизации и служит для взаимодействия сетей AppleTalk c Интернет. Протокол поддерживает технологию IP-туннелей с использованием UDP/IP инкапсуляции. Рассылка сетевой информации осуществляется AURP только при возникновении каких-либо изменений в состоянии сети. Протокол AURP поддерживает гибкую систему переадресаций, исключая конфликты адресов при подключении новых сетей AppleTalk, и выявляет маршрутные петли. Существуют специальные фильтры, которые позволяют разделять пакеты по приоритетам, что бывает важно, например, при передаче мультимедиа информации. Сети AppleTalk хорошо согласуются с другими сетями, например, NetWare. Следует иметь в виду, что ЭВМ, работающие с протоколами Phase I и Phase II, могут работать друг с другом только через специальные мосты, так как форматы пакетов для этих протоколов не совместимы.
Управление сетями Apple Talk осуществляется с помощью протокола SNMP и управляющей базы данных MIB.
Архитектура сетей Ethernet
4.1.1.1 Архитектура сетей Ethernet
Семенов Ю.А. (ГНЦ ИТЭФ)
Не трудно видеть, что все перечисленные физические среды используют последовательный формат передачи информации. К этой разновидности относится и Ethernet (10 Мбит/с ±0,01%). Фирма Ксерокс осуществила разработку протокола Ethernet в 1973 году, а в 1979 году объединение компаний Ксерокс, Интел и DEC (DIX) предоставило документ для стандартизации протокола в IEEE. Предложение с небольшими изменениями было принято комитетом 802.3 в 1983 году. Кадр Ethernet имеет формат, показанный на рис. 4.1.1.1.1.
Рис. 4.1.1.1.1 Формат кадра сетей ethernet (цифры в верхней части рисунка показывают размер поля в байтах)
Поле преамбула содержит 7 байт 0хАА и служит для стабилизации и синхронизации среды (чередующиеся сигналы CD1 и CD0 при завершающем CD0), далее следует поле SFD (start frame delimiter = 0xab), которое предназначено для выявления начала кадра. Поле EFD (end frame delimiter) задает конец кадра. Поле контрольной суммы (CRC - cyclic redundancy check), также как и преамбула, SFD и EFD, формируются и контролируются на аппаратном уровне. В некоторых модификациях протокола поле efd не используется. Пользователю доступны поля, начиная с адреса получателя и кончая полем информация, включительно. После crc следует межпакетная пауза (IPG - interpacket gap – межпакетный интервал) длиной 9,6 мксек или более. Максимальный размер кадра равен 1518 байт (сюда не включены поля преамбулы, SFD и EFD). Интерфейс просматривает все пакеты, следующие по кабельному сегменту, к которому он подключен, ведь определить, корректен ли принятый пакет и кому он адресован, можно лишь приняв его целиком. Корректность пакета по CRC, по длине и кратности целому числу байт производится после проверки адреса места назначения. Вероятность ошибки передачи при наличии crc контроля составляет ~2-32. При вычислении CRC используется образующий полином:
G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1.
Алгоритм вычисления CRC сводится к вычислению остатка от деления кода M(x), характеризующего кадр, на образующий полином G(x) (Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specification. Published by IEEE (802.3-1985). Wiley-Interscience, John & sons, inc.). CRC представляет собой дополнение полученного остатка R(x). CRC пересылается, начиная со старших разрядов. Схема взаимодействия различных субуровней при реализации протокола IEEE 802.3 показана на рис 4.1.1.1.2. Выше llc размещаются верхние субуровни, включая прикладной. Через AUI данные передаются с использованием манчестерского кода.
Рис. 4.1.1.1.2. Схема взаимодействия субуровней 802.3 (CSMA/CD)
Манчестерский код объединяет в бит-сигнале данные и синхронизацию. Каждый бит- символ делится на две части, причем вторая часть всегда является инверсной по отношению первой. В первой половине кодируемый сигнал представлен в логически дополнительном виде, а во второй – в обычном. Таким образом, сигнал логического 0 – CD0 характеризуется в первой половине уровнем HI, а во второй LO. Соответственно сигнал CD1 характеризуется в первой половине бит-символа уровнем LO, а во второй – HI. Примеры форм сигналов при манчестерском кодировании представлены на рис. 4.1.1.1.3.
Рис. 4.1.1.1.3 Примеры кодировки с использованием манчестерского кода
Ниже в таблице 4.1.1.1.1 приведены ограничения, налагаемые на сеть Ethernet в целом и на отдельные ее фрагменты.
Таблица 4.1.1.1.1.
Возможности различных схем реализации ethernet
Тип кабеля
Толстый
(10base5)
Тонкий
(10base2)
Скрученная
пара (10baset)
и 4 повторителя
и 4 повторителя
4*tr (задержка, вносимая повторителями, при их максимальном числе =4; tr - задержка сигнала в репитере, ~20 бит-тактов)
4,5нсек/м*5*500м (задержка пяти кабельных сегментов)
4нсек/м*2*50м (задержка, вносимая двумя кабелями aui, первого и последнего сегментов)
задержки сетевых интерфейсов и трансиверов (~2*20 бит-тактов)
В сумме это соответствует ~220 бит-тактам. Минимальная длина пакета должна быть больше удвоенного значения этой задержки (выбрано 64 байта = 512 тактов). Если размер пакета меньше 64 байт, добавляются байты-заполнители, чтобы кадр в любом случае имел соответствующий размер. При приеме контролируется длина пакета и, если она превышает 1518 байт, пакет считается избыточным и обрабатываться не будет. Аналогичная судьба ждет кадры короче 64 байт. Любой пакет должен иметь длину, кратную 8 бит (целое число байт). Если в поле адресата содержатся все единицы, адрес считается широковещательным, то есть обращенным ко всем рабочим станциям локальной сети. Пакет ethernet может нести от 46 до 1500 байт данных. Формат адреса получателя или отправителя (MAC) показан на рис. 4.1.1.1.4. Для передачи данных на физическом уровне используется манчестерский код.
Рис. 4.1.1.1.4. Формат mac-адреса
В верхней части рисунка указана длина полей адреса, в нижней – нумерация разрядов. Субполе I/G представляет собой флаг индивидуального или группового адреса. I/G=0 – указывает на то, что адрес является индивидуальным адресом сетевого объекта. I/G=1 характеризует адрес как мультикастинговый, в этом случае дальнейшее разбиение адреса на субполя теряет смысл. Субполе UL является флагом универсального или местного управления (определяет механизм присвоения адреса сетевому интерфейсу). U/L=1 указывает на локальную адресацию (адрес задан не производителем и ответственность за уникальность лежит на администраторе LAN). U/L=I/G=0 характерно для стандартных уникальных адресов, присваиваемых интерфейсу его изготовителем. Субполе OUI (organizationally unique identifier) позволяет определить производителя сетевого интерфейса. Каждому производителю присваивается один или несколько OUI. Размер субполя позволяет идентифицировать около 4 миллионов различных производителей. За корректность присвоения уникального адреса интерфейса (OUA – organizationally unique address) несет ответственность производитель. Двух интерфейсов одного и того же производителя с идентичными номерами не должно существовать. Размер поля позволяет произвести примерно 16 миллионов интерфейсов. Комбинация oui и oua составляют UAA (universally administrated address = IEEE-адрес).
Если в поле кадра протокол/тип записан код менее 1500, то это поле характеризует длину кадра. В противном случае – это код протокола, пакет которого инкапсулирован в кадр Ethernet.
Доступ к каналу Ethernet базируется на алгоритме CSMA/CD (carrier sense multiple access with collision detection). В Ethernet любая станция, подключенная к сети, может попытаться начать передачу пакета (кадра), если кабельный сегмент, к которому она подключена, свободен. Свободен ли сегмент, интерфейс определяет по отсутствию “несущей” в течение 9,6 мксек. Так как первый бит пакета достигает остальных станций сети не одновременно, может случиться, что попытку передачи совершат две или более станций, тем более что задержки в повторителях и кабелях могут достигать достаточно больших величин. Такие совпадения попыток называются столкновениями. Столкновение (коллизия) распознается по наличию в канале сигнала, уровень которого соответствует работе двух или более трансиверов одновременно. При обнаружении столкновения станция прерывает передачу. Возобновление попытки может быть произведено после выдержки (кратной 51,2 мксек, но не превосходящей 52 мсек), значения которой является псевдослучайной величиной и вычисляется каждой станцией независимо (t= RAND(0,2min(n,10)), где n – содержимое счетчика попыток, а число 10 - backofflimit).
После выдержки станция увеличивает на единицу счетчик попыток и начинает очередную передачу. Предельное число попыток по умолчанию равно 16, если число попыток исчерпано, связь прерывается и выдается соответствующее сообщение. Передаваемый длинный кадр способствует “синхронизации” начала передачи пакетов несколькими станциями. Ведь за время передачи с заметной вероятностью может возникнуть необходимость передачи у двух и более станций. В момент, когда они обнаружат завершение пакета, будут включены таймеры IPG. К счастью информация о завершении передачи пакета доходит до станций сегмента не одновременно. Но задержки, с которыми это связано, являются также причиной того, что факт начала передачи нового пакета одной из станций не становится известным немедленно. При вовлечении в столкновение нескольких станций они могут уведомить остальные станции об этом, послав сигнал “затора” (jam - не менее 32 бит). Содержимое этих 32 бит не регламентируется. Такая схема делает менее вероятным повторное столкновение. Источником большого числа столкновений (помимо информационной перегрузки) может служить запредельная суммарная длина логического кабельного сегмента, слишком большое число повторителей, обрыв кабеля, отсутствие терминатора (50-омного согласователя кабеля) или неисправность одного из интерфейсов. Но сами по себе столкновения не являются чем-то негативным – это механизм, регулирующий доступ к сетевой среде.
Под логическим кабельным сегментом (иногда называемым областью столкновений) подразумевается один или несколько кабельных сегментов, объединенных повторителями. Анализ столкновений является одним из средств эффективной диагностики сети. Локальные столкновения (столкновения на сегменте, к которому непосредственно подключена рабочая станция) порождают укороченные пакеты-фрагменты (ведь их передача прерывается) с длиной менее 64 октетов. Большинство трансиверов и репитеров имеют на своих передних панелях индикаторы столкновений. Блок-схема реализации протокола CSMA/CD показана на рис. 4.1.1.1.4. Особое внимание я бы хотел обратить на влияние сигнала jam. В процессе пересылки столкнувшихся пакетов и за время передачи сигнала jam другие узлы могли захотеть что-то передать. Если таких узлов больше одного, то это приведет к синхронизации начала передачи этими узлами и к увеличению вероятности столкновения. Практически такую “синхронизацию” может осуществить любой достаточно длинный пакет. Такая синхронизация является причиной “коллапса” сети при большой загрузке.
Рис. 4.1.1.1.5 Блок-схема реализации алгоритма доступа к сетевой среде CSMA/CD
Метод CSMA/ CD создает неопределенность времени доступа к сети, что делает ее неудобной для решения некоторых задач управления в реальном масштабе времени, где требуется малое время реакции системы на внешнее воздействие.
Рис. 4.1.1.1.6 Схема некоторых возможных вариантов подключения рабочих станций к Ethernet
Исторически первой появилась схема подключения к толстому 50-омному коаксиальному кабелю (сегмент 1 на рис. 4.1.1.1.6; Z=50 ±2 Ом) через трансивер и многожильный кабель типа AUI (attachment unit interface, максимальная длина 50 м). Трансивер подключается к кабелю методом “наколки”, то есть во внешней оплетке и изоляции сверлится с помощью специального инструмента отверстие и через него осуществляется контакт трансивера с центральной жилой кабеля и экраном. Кабель по возможности не должен содержать сросток, в противном случае его предельная длина должна быть сокращена. Кабельный сегмент должен быть согласован с обоих сторон с помощью терминаторов (50 Ом ±1%). Позднее стала популярной схема соединений через тонкий коаксиальный кабель и t-образные коаксиальные разъемы (волновое сопротивление 50 Ом). В настоящее время наибольшее применение находит схема со специальными многовходовыми повторителями-концентраторами (Hub) и подключением оконечного оборудования через скрученные пары. Для подключения используется 8-контактный разъем RJ-45 (см. приложение 10.17 Разводка разъемов). Этому способствует удешевление категорированных скрученных пар, соответствующих повторителей, а также большая надежность и лучшая ремонтоспособность таких сетей. Следует иметь в виду, что предельные длины для коаксиальных кабелей, приведенные в таблице 4.1.1.1.1 относятся к зарубежным типам, в частности в случае тонкого кабеля - это rg-58. Отечественные разновидности кабеля, например РК-50-2-11, допускают (при максимальной загрузке) длины примерно в 1,3-1,5 раз меньше. Это связано с меньшим сечением центральной жилы и большей вариацией волнового сопротивления. Если же число ЭВМ подключенных к кабельному сегменту много меньше предельного, допускается использование и запредельных длин кабельных сегментов, но это не рекомендуется. Пропускная способность сети с методом доступа csma/cd снижается по мере роста загрузки из-за увеличения вероятности столкновений. По этой причине даже использование 100-мегагерцного ethernet не может гарантировать большей пропускной способности (по сравнению с обычным, см. рис. 4.1.1.1.8) при условии высоких загрузок и, как следствие, высоких вероятностей столкновений. ethernet-интерфейс перед началом передачи контролирует состояние кабельного сегмента (наличие несущей), выжидает некоторое время, если сегмент занят, после чего производит попытку передачи с контролем возможности столкновения.
Если в поле адресата содержатся все единицы, адрес считается широковещательным, то есть обращенным ко всем рабочим станциям локальной сети. Пакет ethernet может нести от 46 до 1500 байт данных. Схема интерфейса на уровне mau в упрощенном виде имеет вид, показанный на рис. 4.1.1.1.7.
Рис. 4.1.1.1.7. Схема интерфейса на уровне mau
Схема signal quality регистрирует коллизии и другие искажения сигнала и выдает в этом случае флаг SQE (signal quality error). sqe представляет собой сигнал CS0, посылаемый от MAU к DTE (точнее PMA к PLS, см. рис. 4.1.1.1.2). Сигнал SQE посылается mau также в случае завершения процесса передачи (output_idle). Узел isolate служит для блокировки передачи данных в сетевую среду, при этом DTE передает mau сигнал CS0. Суммарная емкостная нагрузка, вносимая mau, не должна превышать 4 пф. Входное сопротивление должно быть более 100 ком, а ток утечки должен лежать в пределах +2 мкА –25мкА. Выходной драйвер mau при передаче выдает в кабель –90 ±4мa (эквивалентно –2,05В на нагрузке 25 Ом). Предельное ослабление сигнала на длине 500 м не должно превышать 8,5 дБ (на частоте 10МГц).
При передаче сигнал распространяется в обоих направлениях по кабелю от точки подключения интерфейса. При использовании тонкого кабеля интерфейс должен иметь максимально большое входное сопротивление и минимально возможную входную емкость, чтобы вносить минимальные искажения для сигналов, распространяющихся по сегменту. В случае работы со скрученными парами на “кабельный сегмент” подключается только один интерфейс. Максимальное время прохождения сигнала между узлами сети, принадлежащих одному сегменту, называется окном коллизий и является важной рабочей характеристикой.
Помимо столкновений в сети может быть зарегистрировано появление ложной несущей (FCE – false carrier event) – битовая последовательность не имеет байта SFD, соответствующего конкретному типу физической среды. Появление ложной несущей обычно связано с состоянием кабеля или шумами. Если фиксируется появление двух ложных несущих подряд, повторитель должен отключить порт (перевести в состояние link unstable) и послать сигнал jam во все остальные порты. Сигнал jam должен продолжаться до конца потока данных, вызвавшего появление ложной несущей. Если канал восстановлен, повторитель переводит порт в нормальное состояние. Отключение порта возможно также при возникновении множественных коллизий (ECE – excessive collision error) – более 60 коллизий подряд. После блокировки порта он будет восстановлен, если в течении 500 тактов коллизии не обнаружены или при повторном включении повторителя. Если рассмотреть зависимость пропускной способности сети L от ее суммарной загрузки Lin, мы для Ethernet получим кривую, показанную на рис. 4.1.1.1.8.
Рис. 4.1.1.1.8. Зависимость пропускной способности lin сети со схемой доступа CSMA/CD от суммарной загрузки l
Вначале эта зависимость линейна и на участке А пропускная способность удовлетворительна. Но при больших входных загрузках из-за коллизий сначала наступает насыщение, а затем и резкий спад (Ethernet collapse). Это свойство сетей с CSMA/CD дает определенные преимущества сетям с маркерным доступом: Token Ring, FDDI и др..
При диагностировании сетей не всегда под руками может оказаться настоящий сетевой тестер типа Wavetek, и часто приходится довольствоваться обычным авометром. В этом случае может оказаться полезной таблица 4.1.1.1.2, где приведены удельные сопротивления используемых сетевых кабелей. Произведя измерение сопротивления сегмента, вы можете оценить его длину.
Таблица 4.1.1.1.2 Сопротивление кабеля по постоянному току
(Handbook of LAN Cable Testing. Wavetek Corporation, California)
|
Коаксиал |
Ом/сегмент |
Максимальная длина сегмента |
| 10base5 | 5 | 500 м |
| 10base2 | 10 | 185 м |
|
Скрученная пара |
Ом/100 м |
|
| 24 awg | 18,8 | |
| 22 awg | 11,8 |
Помимо уже описанных модификаций сетей ethernet в последнее время получили распространение сети для частот 100 Мбит/с, которые базируются на каналах, построенных из скрученных пар или оптоволоконных кабелей. Оптические связи используются и в обычном 10-мегагерцном ethernet (10base-FL, стандарт разработан в 1980 году, см. рис. 4.1.1.1.9).
Оптоволоконная версия ethernet привлекательна при объединении сегментов сети, размещенных в различных зданиях, при этом увеличивается надежность сети, так как ослабляется влияние электромагнитных наводок, исключается влияние различия потенциалов земли этих участков сети. Облегчается переход от 10- к 100-мегагерцному Ethernet, также можно использовать уже имеющиеся оптоволоконные каналы, ведь они будут работать и на 100 Мбит/с (возможна реализация сетей со смешанной структурой, где используется как 100- так и 10-мегагерцное оборудование). На программном уровне 10- и 100-МГц ethernet не различимы. Требования к параметрам опто-волоконных кабелей не зависят от используемого протокола (FDDI, Token Ring, Fast Ethernet и т.д.) и определяются документом EN 50173 (European norm). Это утверждение не относится к топологии кабельных связей, которые в общем случае зависят от используемого протокола. При работе с оптоволоконными системами необходимы специальные тестеры, способные измерять потери света и отражения методом OTDR (рефлектометрия с использованием метода временных доменов). При пассивной звездообразной схеме длины оптоволоконных сегментов могут достигать 500 метров, а число подключенных ЭВМ - 33. Для передачи сигналов используются многомодовые волокна (MMF) с диаметром ядра 62,5 микрон и клэдинга 125 микрон. Длина волны излучения равна 850 (или 1350) нанометров при ослаблении сигнала в кабельном сегменте не более 12,5 дБ. Обычный кабель имеет ослабление 4-5 дБ/км. Оптические разъемы должны соответствовать требования стандарта ISO/IEC BFOC/2,5 и вносить ослабление не более 0,5 - 2,0 дБ. Количество используемых mau в логическом сегменте не должно превышать двух.
Рис. 4.1.1.1.9. Схема 10-мегагерцного оптоволоконного Ethernet.
На данном рисунке видно, что соединения повторителя с FOMAU является дуплексным, аналогичные возможности предоставляют многие современные переключатели. Полно дуплексное подключение оборудование во многих случаях может обеспечить практическое удвоение скорости обмена и, что возможно более важно, исключить столкновения пакетов. Схема полно дуплексного соединения показана на рис. 4.1.1.1.10.
Рис. 4.1.1.1.10. Схеме реализации полно дуплексного канала Ethernet. (Буква К с цифрой отмечает номера ножек контактов разъема)
При практической реализации локальной сети обычно возникает проблема защиты и заземления. Если этой проблеме не уделить внимание в самом начале она даст о себе знать позднее и обойдется ее решение дороже. Можно выделить три аспекта. Безопасность персонала, работающего с ЭВМ и сетевым оборудованием, устойчивость к внешним наводкам и помехам, а также безопасность самого сетевого оборудования (противостояние грозовым разрядам или резким скачкам в сети переменного тока (обычно ~220 В)). Безопасность персонала обеспечивается тем, что все объекты, за которые может взяться человек, должны иметь равные потенциалы и в любом случае разница потенциалов не должна превышать 50 вольт. При работе с коаксиальным кабелем существуют рекомендации его заземления в одной точке. Возникает вопрос, что делать с заземлением экранов в случае использования экранированных скрученных пар? Этой проблеме посвящена, например, статья в журнале LANline Special Juli/August 2002 страницы 27-32. Следует сразу заметить, что нужно избегать совмещения применения экранированных и неэкранированных скрученных пар в пределах одной системы. Представляется также естественной и разумной зонная концепция, рассматриваемая в упомянутой статье. На рис. 1. показана схема защиты. Эта схема содержит защитные выключатели на случай грозы или бросков напряжения (линия L). Буквой N обозначена нулевая (нейтральная) шина, а буквами PE - защитная шина.
Рис. 4.1.1.1.11. Схема защиты для случая использования экранированных скрученных пар
Рис. 4.1.1.1.12. Зоны заземлений
Земли-экраны соседних зон соединяются только в одной точке. Между зонами могут включаться пограничные устройства фильтрации, предназначенные для снижения уровня шумов и помех. В пределах зоны все устройства должны быть эквипотенциальны. Это достигается за счет подключения к общему экрану.
Аутентификация в Интернет
6.4.9 Аутентификация в Интернет
Семенов Ю.А. (ГНЦ ИТЭФ)
1. Введение
Аутентификационные требования вычислительных систем и сетевых протоколов варьируются в весьма широких пределах. Пароли, которые уязвимы для атак пассивного типа, не могут удовлетворить требованиям современного Интернет [CERT94]. А помимо пассивных атак в сетевой среде сплошь и рядом предпринимаются активные методы [Bellovin89, Bellovin92, Bellovin93, CB94, Stoll90].
2. Определения и терминология, используемые в данном документе
Активная атака
. Попытка некорректной модификации данных с целью аутентификации или авторизации с помощью вставления ложных пакетов в поток данных или их модификации.
Асимметричная криптография
. Криптографическая система, которая использует различные ключи для шифрования и дешифрования. Эти два ключа являются математически связанными. Называется также криптографией с общедоступным ключом.
Аутентификация
. Идентификация источника информации.
Авторизация
. Предоставление прав доступа на основе аутентификации.
Конфиденциальность
. Защита информации, так чтобы лицо, не авторизованное для доступа к данным, не могло их читать, даже если имеется доступ к соответствующему каталогу или сетевому пакету.
Шифрование
. Механизм, используемый для обеспечения конфиденциальности.
Целостность
. Защита информации от неавторизованной модификации.
Сертификат ключа
. Информационная структура, состоящая из общедоступного ключа, идентификатора лица, системы и информации, аутентифицирующей ключ и ассоциацию общедоступного ключа с идентификатором. Ключи, используемые PEM, являются примером сертификата ключа [Kent93].
Пассивная атака
. Атака на систему аутентификации, которая не предполагает введения каких-либо данных в поток, но базируется на возможности мониторинга информации, которой обмениваются другие партнеры. Эта информация может быть использована позднее.
Исходный текст (Plain-text
). Незашифрованный текст.
Атака воспроизведения (Replay Attack)
. Атака на систему аутентификации путем записи и последующего воспроизведения ранее посланных корректных сообщений или их частей. Любая неизменная информация, такая как пароль или биометрические данные могут быть записаны и использованы позднее для имитации аутентичности.
Симметричная криптография
. Система шифрования, которая использует один и тот же ключ для шифрования и дешифрования. Иногда называется криптографией с секретным ключом.
3. Аутентификационные технологии
Существует некоторое число различных классов аутентификации, начиная с полного ее отсутствия до очень строгих механизмов контроля. Для различных целей могут использоваться разные виды аутентификации.
3.1. Отсутствие аутентификации
Простейшая аутентификационная система не имеет аутентификации вовсе. Изолированная от сети частная персональная ЭВМ является примером, где аутентификация не нужна. Другим примером может служить автономная общедоступная рабочая станция, обслуживающая некоторые конференции, где раскрытие информации или ее модификация не являются критическими.
3.2. Аутентификационные механизмы, уязвимые для пассивных атак
Простая проверка пароля является наиболее общей формой аутентификации. Простые аутентификационные проверки имеют различные формы: ключ может быть паролем, запомненным пользователем, он может быть физическим или электронным объектом, принадлежащим пользователю, он может быть уникальной биологической характеристикой. Простые аутентификационные системы считаются "раскрывающими", так как, если ключ передается по сети, он может быть перехвачен злоумышленником. Имеются сообщения об успешных пассивных атаках в Интернет с помощью “расколотых” уже ЭВМ [CERT94]. Механизмы раскрывающей аутентификации уязвимы для атак “воспроизведения”. Ключи доступа могут быть запомнены в атакуемой машине и при наличии бреши в системе безопасности можно получить доступ ко всем паролям. Обычно форма хранения паролей допускает их сверку, но не чтение.
3.3. Аутентификационные механизмы, уязвимые для активных атак
Не раскрывающие парольные системы созданы для предотвращения атак воспроизведения. Разработано несколько систем для генерации не раскрываемых паролей. Система аутентификации S/Key (TM), разработанная в Bellcore генерирует много одноразовых паролей из одного секретного ключа [Haller94]. Она не использует физических объектов (token), поэтому удобна для аутентификации машина-машина. Аутентификация S/Key не требует запоминания секретного ключа пользователя, что является преимуществом при работе с ненадежными вычислительными системами. В ее сегодняшнем виде система S/Key уязвима для переборных атак со словарем в случае неудачного выбора пароля. Система CHAP протокола PPP не является раскрывающей, но применима только локально [LS92, Simpson93].
3.4. Аутентификационные механизмы, не уязвимые для пассивных атак
По мере расширения применения сетей растет необходимость более жесткой аутентификации. В открытых сетях большое число пользователей могут получить доступ к информации, переносимой по сети. При желании пользователь может сымитировать ситуацию, при которой посланная им информация будет восприниматься, как посланная другим сетевым объектом.
Более мощные аутентификационные системы используют вычислительные возможности партнеров, участвующих в процессе аутентификации. Аутентификация может быть однонаправленной, например аутентификация пользователей в вычислительной системе, или она может быть взаимной, когда оба партнера должны идентифицировать друг друга. Некоторые системы аутентификации используют криптографические методы и формируют общий секретный код (например, ключ сессии), который может быть использован при последующем обмене. Например, пользователю после завершения процесса аутентификации может быть предоставлен аутентификационный билет, который может быть использован для получения других услуг без дополнительной аутентификации. Эти системы аутентификации могут также обеспечить, когда требуется, конфиденциальность (используя шифрование) при передаче данных по незащищенным сетям.
4. Криптография
Криптографические механизмы широко используются для осуществления аутентификации в современных сетях. Существует два базовых вида криптографии (симметричная и асимметричная). Одной из фундаментальных проблем для криптографии является транспортировка секретных ключей.
4.1. Симметричная криптография
Симметричная криптография включает в себя все системы, которые используют один и тот же ключ для шифрования и дешифрования. Таким образом, если кто-либо получит ключ, он сможет дешифровать и читать информацию, зашифрованную с его помощью. Такое лицо сможет шифровать и посылать любые данные, выдавая их за информацию, посланную легальным владельцем этого секретного ключа. Это означает, что знание ключа нежелательным третьим лицом полностью компрометирует конфиденциальность системы. Следовательно, используемые ключи должны доставляться безопасным способом, либо курьером, либо с применением специального протокола пересылки ключей, лучшим из которых является алгоритм Нидхэма-Шрёдера [NS78, NS87]. Широко используется алгоритм DES (Data Encryption Standard), который был стандартизован для защиты правительственной информации в США. Он представляет собой один из лучших симметричных алгоритмов шифрования [NBS77].
Хорошо известной системой, работающей в открытых сетях, является система аутентификации Kerberos (TM), которая была разработана в рамках проекта Athena в MIT [SNS88, BM91, KN93]. Система Kerberos базируется на алгоритме DES и использует специальный сервер, который хранит секретные ключи всех пользователей и услуг. Он может генерировать коды, которые позволяют пользователям и процессам идентифицировать себя в других системах. Как в любой схеме с распределенной аутентификацией, эти верительные коды работают в пределах местного административного домена. Следовательно, если пароль пользователя раскрыт, злоумышленник будет способен маскироваться под этого пользователя и проникнуть в любую систему, обслуживаемую Kerberos. Так как сервер Kerberos знает все секретные ключи, он должен быть достаточно безопасным. Ключи сессии Kerberos могут использоваться для обеспечения конфиденциальности при обмене между любыми объектами в пределах зоны действия сервера.
4.2. Асимметричная криптография
В конце 1970, главным прорывом в криптографии стала разработка асимметричной криптографии. Здесь для шифрования и дешифрования используются разные ключи, которые генерируются совместно. Наилучшая асимметричная система базируется на алгоритме, предложенном Rivest, Shamir и Adleman, и называется по инициалам авторов RSA [RSA78].
SPX представляет собой экспериментальную систему, которая преодолевает ограничения системы Kerberos путем применения криптографии с общедоступным ключом RSA [TA91]. SPX предполагает глобальную иерархию сертифицирующих узлов по одному или более для каждого из партнеров. Она использует цифровую подпись, которая состоит из строки кодов, зашифрованных секретным ключом отправителя, и которая может быть проверена с помощью соответствующего общедоступного ключа. Общедоступные ключи предполагаются правильными, так как получены с сертифицирующей подписью. Критические секции аутентификационного обмена шифруются посредством общедоступных ключей получателя, что препятствует атаке воспроизведения.
4.3. Криптографические контрольные суммы
Криптографические контрольные суммы являются одним из наиболее важных средств разработчиков криптографических протоколов. Криптографическая контрольная сумма или MIC (message integrity checksum) служат для контроля целостности сообщений и аутентификации. Например, Secure SNMP и SNMPv2 вычисляют криптографическую контрольную сумму MD5 для совместного секретного блока данных и информации, которая должна быть аутентифицирована [Rivest92, GM93]. Это служит для того, чтобы аутентифицировать источник данных при этом предполагается, что эту сумму крайне трудно фальсифицировать. Она не указывает на то, что сами посланные данные корректны, а лишь на то, что они посланы именно данным отправителем. Криптографические контрольные суммы могут использоваться для получения относительно эффективной аутентификации, и особенно полезны при обмене ЭВМ-ЭВМ. Главная трудность реализации - передача ключей.
4.4. Цифровые подписи (сигнатуры)
Цифровая подпись представляет собой криптографический механизм, который является аналогом рукописной подписи. Она служит для аутентификации блока данных и подтверждает то, что она получена от отправителя. Цифровая подпись, использующая асимметричную криптографию (общедоступные ключи) может быть полезной для определения источника сообщения даже в случае, когда отправитель отрицает свое авторство. Цифровая подпись обеспечивает аутентификацию без конфиденциальности, так как текст самого сообщения не шифруется. Цифровая подпись использована в системе конфиденциальной почты PEM (Privacy Enhanced Mail) [Linn93, Kent93, Balenson93, Kaliski93].
5. Аутентификация пользователя на ЭВМ
Существует много различных подходов к проблеме аутентификации пользователя в удаленных ЭВМ. Имеется две угрозы при доступе к удаленной ЭВМ. Во-первых, злоумышленник может перехватить идентификатор и пароль пользователя и позднее воспользоваться ими при атаке "воспроизведения". Во-вторых, сама форма пароля позволяет хакеру попытаться его угадать.
В настоящее время большинство систем используют открытый текст для передачи паролей по сетевым каналам, что сильно упрощает их перехват [Anderson84, Kantor91]. Такая система не обеспечивает адекватной защиты от атак воспроизведения, когда злоумышленник сумел заполучить идентификатор и пароль удаленного пользователя.
5.1. Защита против пассивной атаки является необходимой
Отсутствие, по крайней мере, не раскрывающей парольной системы, означает предоставление неограниченного доступа любому, кто имеет физический доступ к сети. Например, всякий кто имеет доступ к кабелю Ethernet
Минимальной защитой против пассивных атак, таких как прослушивание сети, является применение не раскрывающей системы паролей. Такая система может функционировать на пассивном терминале или в качестве коммуникационной программы (напр., Crosstalk или PROCOMM), которая эмулирует пассивный терминал на персональной ЭВМ. Использование более строгой аутентификационной системы защитит против пассивных атак со стороны удаленных систем за счет ограничения использования простых терминалов. Разумно ожидать, что производители коммуникационных программ и не программируемых пользователем терминалов (таких как Х-терминалы) встроят систему не раскрываемых паролей или более строгие аутентификационные системы. Одним из преимуществ Kerberos является то, что при правильном использовании пароль пользователя никогда не покидает пределов рабочей станции. Вместо этого они используются для расшифровки билетов пользователя Kerberos.
5.2. Защита периметра
Защита периметра применяется все шире. В этих системах пользователь сначала осуществляет аутентификацию в определенном объекте сети, например, в ЭВМ "firewall", используя систему не раскрываемых паролей. Пользователь затем использует вторую систему для аутентификации в каждой ЭВМ или в группе ЭВМ, где он хотел бы получить доступ к определенным услугам.
В защите периметра существует несколько недостатков, по этой причине эту систему следует рассматривать как временное решение. Сетевой шлюз не прозрачен на IP-уровне и по этой причине работа с каждым видом сервиса должна производиться независимо. Использование двойной аутентификации является трудно осуществимым или невозможным для связи ЭВМ-ЭВМ. Протоколы точка-точка, которые являются обычными для Интернет механизмов без установления связи, легко уязвимы. Защита периметра должна быть плотной и полной, так как в случае ее прорыва внутренняя защита оказывается слабой и легко преодолимой.
Частой формой защиты периметра является передача приложений. Так как эти передачи являются протокольно зависимыми, IP-коннективность ЭВМ в пределах периметра с внешним миром оказывается нарушенной и часть преимуществ Интернет пропадает.
Административное преимущество защиты периметра заключается в том, что число ЭВМ, которые могут быть подвергнуты атаке, достаточно мало. Эти машины могут быть тщательно проверены с точки зрения угроз безопасности. Но достаточно трудно или даже невозможно создать достаточно "герметичную" систему. Безопасность системы защиты периметра достаточно сложна, так как шлюз должен пропускать некоторые типы трафика, например, электронную почту. Другие сетевые услуги, такие как NTP (Network Time Protocol) и FTP могут также оказаться желательными [Mills92, PR85, Bishop]. Более того, шлюзовая система периметра должна быть способна пропускать весь трафик всего домен, заключенного в данный периметр.
5.3. Защита от активных атак является крайне желательной
В обозримом будущем потребуются достаточно мощные системы, способные противостоять активным атакам. Многие корпоративные сети, базирующиеся на широковещательной технологии, такой как Ethernet, вероятно нуждаются в такой методике. Чтобы защититься от активных атак, или обеспечить конфиденциальность, необходимо использовать протокол с шифрованием сессии, например, Kerberos, возможно использование аутентификационного механизма, который защищает от атаки воспроизведения. В системе Kerberos, пользователи получают коды доступа от сервера Kerberos и используют их для аутентификации, чтобы осуществить доступ к услугам других ЭВМ сети. Вычислительная мощность локальной рабочей станции может быть использована для дешифрования кодов доступа (используя ключ, извлеченный из пароля, введенного пользователем) и запоминания на время пока это требуется. Если протокол безопасности базируется на синхронизации часов, тогда может быть полезен протокол NTPv3, так как он распространяет временные метки для большого числа ЭВМ и является одним из немногих протоколов Интернет, которые содержат механизмы аутентификации [Bishop, Mills92].
Другим подходом для доступа к сетевым ЭВМ является введение для всех внешних машин общего секретного кода Kerberos KDC. Это делает эти машины "серверами", а не рабочими станциями. Этот общий секретный код может быть затем использован для шифрования всех обменов между машинами, обеспечивая безопасную передачу аутентификационной информации KDC.
Наконец, рабочие станции, которые удаленно доступны, могут использовать асимметричную криптографическую технологию для шифрования телекоммуникаций. Общедоступный ключ рабочей станции будет предоставлен всем клиентам. Пользователь может применить общедоступный ключ для шифрования пароля, а удаленная система дешифрует его и аутентифицирует пользователя без угрозы раскрытия пароля при транспортировке. Ограничением этой системы безопасности, ориентированной на рабочую станцию заключается в том, что она не аутентифицирует индивидуальных пользователей, а только индивидуальные рабочие станции. В некоторых средах, например, в многоуровневых правительственных системах безопасности необходима аутентификация пользователь-пользователь.
6. Раздача ключей и управление
Управление доступом для ключей является самой тяжелой проблемой, с которой приходится сталкиваться при обеспечении аутентификации в больших сетях Интернет. Протокол Нидхема-Шрёдера [NS78, NS87], который используется в системе Kerberos, базируется на централизованном сервере ключей. В больших корпоративных сетях требуется значительное число таких ключевых серверов, по крайней мере, один ключевой сервер на каждый административный домен. Существует также нужда в механизмах для отдельных ключевых серверов, необходимых для координирования генерации ключей сессий участников в различных административных доменах.
Большинство алгоритмов шифрования с использованием общедоступных ключей требуют достаточно больших вычислительных мощностей и по этой причине они неидеальны для шифрования пакетов в сети. Однако асимметричное свойство делает их очень полезными в начале сессии для получения симметричных ключей сессии. На практике, коммерческий сектор, вероятно, использует асимметричный алгоритм для цифровых подписей и пересылки ключей, но не для массового шифрования данных. Для целей пересылки ключей можно использовать алгоритмы RSA и Диффи-Хелмана [DH76]. Преимуществом асимметричной методики является отсутствие необходимости иметь центральный сервер для хранения и рассылки ключей. Система PEM использует цифровые подписи для аутентификации общедоступных ключей пользователей [Kent93]. Результатом этой операции является сертификат, который содержит общедоступный ключ партнера. Сертификаты ключей могут рассылаться различными способами. В одном из вариантов рассылка ключей встраивается в существующие службы каталогов. Это может быть сделано, например, путем расширения возможностей DNS и включения ключа ЭВМ в ресурсную запись нового типа.
Для мультикастных сессий, управление рассылкой ключей сложнее, так как число обменов, необходимых для широко используемых методик пропорционально числу участников.
7. Аутентификация сетевых услуг
Кроме необходимости аутентификации пользователей и ЭВМ друг другу, многие сетевые услуги сами нуждаются в аутентификации.
Наиболее общий случай в настоящее время - это отсутствие поддержки в протоколе какой-либо аутентификации. Bellovin и другие документировали многие случаи, когда существующие протоколы могут использоваться для атаки удаленной ЭВМ, так как там не существует встроенной процедуры аутентификации [Bellovin89].
Некоторые протоколы предоставляют возможность передачи незащищенных паролей совместно с протокольной информацией. Исходные протоколы SNMP использовали этот метод, многие маршрутные протоколы продолжают его использовать и сейчас [Moy91, LR91, CFSD88]. Этот метод полезен, так как несколько повышает безопасность передачи.
Существует много протоколов, которые нуждаются в поддержке более строгих аутентификационных механизмов. Например, известно, что протокол SNMP нуждается в существенном усилении аутентификации. Это вызвало разработку протоколов Secure SNMP, которые поддерживают опционную аутентификацию, используя цифровую подпись и опционное шифрование с привлечением алгоритма DES. Цифровые подписи, используемые в Secure SNMP, базируются на добавлении криптографической контрольной суммы к SNMP-информации. Криптографическая контрольная сумма вычисляется с использованием алгоритма MD5 и секретного кода, используемого совместно обоими партнерами обмена.
Технология цифровой подписи должна рассматриваться как необходимое средство при разработке новых технологий аутентификации (но не конфиденциальности). Цифровые подписи могут использовать ключи и методы как симметричной, так и асимметричной криптографии. Если доступна централизованная система распределения ключей, опционная поддержка цифровой подписи может быть обеспечена для большинства протоколов с минимальными издержками. Каждый протокол может столкнуться проблемой пересылки ключей и установки параметров обмена, и это приведет к усложнению использования техники цифровой подписи.
Для случаев, когда требуется аутентификация и конфиденциальность для схемы коммуникации ЭВМ-ЭВМ, может быть применено шифрование, базирующееся на симметричной или асимметричной схеме, или даже на их комбинации. Использование асимметричной криптографии упрощает управление раздачей ключей. Каждая ЭВМ шифрует свою информацию перед отправкой, безопасность же внутри машины обеспечивается средствами операционной системы ЭВМ.
В некоторых случаях, возможно включающих электронную почту, может оказаться желательным обеспечить безопасность в пределах приложения на уровне пользователь-пользователь, а не ЭВМ-ЭВМ. Безопасная почта PEM использует именно этот подход [Linn93, Kent93, Balenson93, Kaliski93].
8. Будущие направления
Просматривается тенденция внедрения все более строгих механизмов аутентификации. Следует ожидать введения не раскрывающей пароли аутентификации и более широкого использования механизмов с общедоступным ключом. Растет важность аутентификации сессий и процессов, проблема целостности и конфиденциальности сообщений при передаче по сетевым каналам. Так как коммуникации ЭВМ-ЭВМ становятся все более важными, протоколы связи человек-машина становятся менее существенными.
Использование криптосистем с общедоступным ключом для аутентификации пользователь-ЭВМ упрощает многие аспекты, но хранение простых паролей, а также общедоступных и секретных ключей остается актуальной проблемой. Следует учитывать, что размер общедоступного ключа, используемого в настоящее время, по меньшей мере, составляет 500 бит. В будущем, вероятно, будут применяться еще более длинные ключи. Таким образом, пользователи могут хранить свои ключи в виде пригодном для электронного считывания. Использование ROM, такой как флоппи-диск или магнитная карточка может решить эту проблему, но тогда пользователь неизбежно доверяет свои ключи считывающему устройству. Применение смарт-карты, совмещающей память и программу, более предпочтительно. Такие приборы могут обеспечить аутентификацию без риска разглашения секретных кодов, которые они хранят. Они могут также взаимодействовать с пользователем, осуществляя простую аутентификацию при разблокировании карты. Применение криптосистем с общедоступным ключом при аутентификации ЭВМ-ЭВМ лишено проблем запоминания ключей, которые характерны для интерфейсов человек-машина. Многопользовательская ЭВМ может запоминать свои ключи в области памяти, защищенной от доступа пользователей.
Если рассматривать существующие симметричные алгоритмы как одно-ключевые, а асимметричные, такие как RSA в качестве двухключевых систем, можно предположить появление в будущем N-ключевых методик (где N больше 2). Если бы такая N-ключевая технология существовала, она могла бы использоваться для реализации масштабируемых протоколов для рассылки ключей в случае мультикастинга. В настоящее время ведется разработка технологии CBT (Core Based Tree), предназначенной для решения подобной задачи [BFC93].
Ссылки
Автономные системы
4.4.11.6 Автономные системы
Семенов Ю.А. (ГНЦ ИТЭФ)
Базовым элементом технологии Интернет является модуль IP. Его центральной частью является таблица маршрутов, используемая для принятия решения о направлении IP-пакета по тому или иному пути. Формат таблицы маршрутов задается используемым протоколом маршрутизации, а содержание - определяет администратор сети. Прямая маршрутизация имеет место при обмене пакетами между машинами, входящими в одну сеть. Большинство современных протоколов маршрутизации являются динамическими, то есть такими, где таблицы маршрутизации изменяются по мере изменения структуры и параметров окружающей сети. Такие протоколы заметно повышают надежность сети в целом, так как при выходе из строя какого-либо узла или канала связи поток пакетов может быть автоматически направлен в обход по резервному маршруту. При этом пользователи сети не должны ожидать момента, когда администратор сети вернется из отпуска, проснется или вернется из кафетерия и сам внесет необходимые коррективы.
Автономной системой называют такую локальную сеть или систему сетей, которые имеют единую администрацию и общую маршрутную политику.
Пользователь, связанный только с одним сервис-провайдером, должен принадлежать к общей с ним AS. Автономная система должна обязательно создаваться, когда оператор сети связан с более чем одной AS с отличной от его маршрутной политикой. Если же пользователь обращается к услугам двух или более сервис-провайдеров, придерживающихся различных маршрутных политик, то он должен создать свою независимую AS. Общим правилом является использование максимально возможного числа маршрутов. Это повышает надежность и способствует перераспределению нагрузки между каналами.
Внедрение идеологии автономных систем сделали возможным существенно облегчить процедуру маршрутизации, сократить требуемое число IP-адресов и создать гибкую и эффективную схему описания маршрутной политики.
Базовые протоколы Internet
10.15 Базовые протоколы Internet
Семенов Ю.А. (ГНЦ ИТЭФ)
Протокол удаленного доступа
Бесклассовая интердоменная маршрутизация (CIDR)
4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)
Семенов Ю.А. (ГНЦ ИТЭФ)
Вряд ли отцы-создатели Интернет предполагали, что когда-либо, тем более при их жизни возникнет дефицит IP-адресов. Уже в 1996 году было зарегистрировано более 100000 сетей. Разбивка сетей на три класса A, B и С уже не может отвечать современным требованиям. Сеть класса А с ее 16000000 адресов слишком велика, а класса С с 254 адресами, как правило, слишком мала. Сети класса B с 65536 машинами может показаться оптимальными, но на практике каждая из этих сетей не обеспечивает оптимального использования адресного пространства и всегда остаются неиспользованные адреса (для классов B и A количество пустующих адресов оказывается обычно значительным). Адресные блоки заказываются администраторами, которые полагают, что однажды их организация или фирма станет великой с тысячами ЭВМ (пока же у них есть всего несколько машин). Надо сказать, что такие оптимистические прогнозы сбываются крайне редко. Проблема маршрутизации может быть решена путем реализации более глубокой структурной иерархии, где каждый IP-адрес имеет код страны, региона, города, сети, но при этом размер адреса должен существенно превышать 32 разряда, так как адреса неизбежно будут использоваться крайне не эффективно - ведь Китаю и Монако будут выделены равные адресные зоны. Это может стать возможным при внедрении технологии IPv6.
Если бы в адресах класса С для кода номера ЭВМ было выделено 10 или 11 бит (1024-2048), ситуация была бы более приемлемой. Маршрутизатор рассматривает IP-адресную среду на двух уровнях - адрес сети и адрес ЭВМ, при этом практически они работают только с адресами сетей. Число записей в маршрутной таблице должно будет быть равным половине миллиона записей (по числу блоков С-адресов).
Проблема может быть решена, если забыть про разбиение всей совокупности IP-адресов на классы. Такая модель реализуется в рамках протокола CIDR (Classless InterDomain Routing). В этой модели каждой сети ставится в соответствие определенное число смежных блоков по 256 адресов. Далее используется известное географическое зонное распределение IP-адресов (см. Ethernet в Интернет, а также RFC-1519). Протокол при просмотре маршрутных таблиц предполагает применение специальных масок и индексных механизмов.
Беспроводные (радио) каналы и сети
3.3 Беспроводные (радио) каналы и сети
Семенов Ю.А. (ГНЦ ИТЭФ)
Применение электромагнитных волн для телекоммуникаций имеет уже столетнюю историю. Спектр используемых волн делится на ряд диапазонов, приведенных в таблице 3.3.1.
Таблица 3.3.1.
Номер
Название диапазона
Частота
Длина волны
Далее следуют диапазоны видимого света, ультрафиолета, рентгеновских и гамма-лучей. Диапазоны часто, используемые различными каналами связи показаны на рис. 3.3.1.
Рис. 3.3.1. Диапазоны частот различных телекоммуникационных каналов.
Если не используется направленная антенна и на пути нет препятствий, радиоволны распространяются по всем направлениям равномерно и сигнал падает пропорционально квадрату расстояния между передатчиком и приемником (удвоение расстояния приводит к потерям 6дБ). Радио каналы для целей передачи информации используют частотные диапазоны 902-928 МГц (расстояния до 10 км, пропускная способность до 64кбит/с), 2,4 ГГц и 12 ГГц (до 50 км, до 8 Мбит/с). Они используются там, где не существует кабельных или оптоволоконных каналов или их создание по каким-то причинам невозможно или слишком дорого. Более низкие частоты (например, 300 МГц) мало привлекательны из-за ограничений пропускной способности, а большие частоты (>30 ГГц) работоспособны для расстояний не более или порядка 5км из-за поглощения радиоволн в атмосфере. При использовании диапазонов 4, 5 и 6 следует иметь в виду, что любые препятствия на пути волн приведут к их практически полному поглощению. Для этих диапазонов заметное влияние оказывает и поглощение в атмосфере. Зависимость поглощения от длины волны радиоволн показана на рис. 3.3.1а.
Рис. 3.3.1а. Зависимость поглощающей способности земной атмосферы от длины волны
Из рисунка видно, что заметную роль в поглощении радиоволн играет вода. По этой причине сильный дождь, град или снег могут привести к прерыванию связи. Поглощение в атмосфере ограничивает использование частот более 30 ГГц. Атмосферные шумы, связанные в основном с грозовыми разрядами, доминируют при низких частотах вплоть до 2 МГц. Галактический шум, приходящий из-за пределов солнечной системы дает существенный вклад вплоть до 200 ГГц. Зависимость поглощения радиоволн в тумане и дожде от частоты показана на рис. 3.3.2.
Рис. 3.3.2. Зависимость поглощения радиоволн в тумане и дожде от частоты
Мощность передатчика обычно лежит в диапазоне 50 мВт - 2 Вт. Модемы, как правило, используют шумоподобный метод передачи SST (spread spectrum transmission). Для устройств на частоты 2.4 ГГц и выше, как правило, используются направленные антенны и необходима прямая видимость между приемником и передатчиком. Такие каналы чаще работают по схеме точка-точка, но возможна реализация и многоточечного соединения. На аппаратном уровне здесь могут использоваться радиорелейное оборудование радиомодемы или радио-бриджи. Схема этих устройств имеет много общего. Отличаются они лишь сетевым интерфейсом (см. рис. 3.3.3). Антенна служит как для приема, так и для передачи. Трансивер (приемопередатчик) может соединяться с антенной через специальные усилители. Между трансивером и модемом может включаться преобразователь частот. Модемы подключаются к локальной сети через последовательные интерфейсы типа RS-232 или v.35 (RS-249), для многих из них такие интерфейсы являются встроенными. Отечественное радиорелейное оборудование имеет в качестве выходного интерфейс типа G.703 и по этой причине нуждается в адаптере. Радио-бриджи имеют встроенный Ethernet-интерфейс. Длина кабеля от модема до трансивера лежит в пределах 30-70м, а соединительный кабель между модемом и ЭВМ может иметь длину 100-150м. Трансивер располагается обычно рядом с антенной.
Рис. 3.3.3. Схема оборудования радиоканала передачи данных
Схемы соединения радиомодемов и традиционных модемов совершенно идентичны (см. рис. 3.3.4).
Рис. 3.3.4. Схема подключения радио-модемов
Кроме уже указанных примеров перспективным полем применения радиомодемов могут стать “подвижные ЭВМ”. Сюда следует отнести и ЭВМ бизнесменов, клиентов сотовых телефонных сетей, и все случаи, когда ЭВМ по характеру своего применения подвижна, например, медицинская диагностика на выезде, оперативная диагностика сложного электронного оборудования, когда необходима связь с базовым отделением фирмы, геологические или геофизические исследования и т.д. Радиомодемы позволяют сформировать сеть быстрее (если не считать времени на аттестацию оборудования, получение разрешения на выбранную частоту и лицензии на использование данного направления канала). В этом случае могут стать доступными точки, лишенные телефонной связи (что весьма привлекательно для условий России). Подключение объектов к центральному узлу осуществляется по звездообразной схеме. Заметное влияние на конфигурацию сети оказывает ожидаемое распределение потоков информации. Если все объекты, подключенные к узлу, примерно эквивалентны, а ожидаемые информационные потоки не велики, можно в центральном узле обойтись простым маршрутизатором, имеющим достаточное число последовательных интерфейсов.
Применение радио-бриджей особенно выигрышно для организаций, имеющих здания, отстоящие друг от друга на несколько километров. Возможно использование этих средств связи и для подключения к сервис-провайдеру, когда нужны информационные потоки до 2 Мбит/с (например, для проведения видео конференций). Если расстояния не велики (
Рис. 3.3.5. Схема подключения объектов через радио-бриджи с помощью всенаправленной антенны
Все соединяемые объекты (А, Б, В, и Г) должны быть оснащены радио-бриджами. Такая схема подключения эквивалентна с одной стороны кабельному сегменту ethernet, так как в любой момент времени возможен обмен лишь между двумя объектами; с другой стороны радио-бриджи А, Б, В и Г логически образуют много портовый бридж (или переключатель), что исключает загрузку локальных сетей объектов “чужими” пакетами. Модификации таких схем связи позволяют строить телекоммуникационные системы по схеме сотовых телефонных сетей.
При построении каналов на основе радиорелейных систем или радио-бриджей следует учитывать возможность их взаимного влияния (см. рис. 3.3.6). Проектируя такие каналы в городе и используя направленные параболические антенны, нужно учитывать возможные помехи от зданий и профиля местности. Направленная антенна с площадью А обеспечивает усиление сигнала:
длина волны несущей.
Угол излучения q такой антенны с радиусом R равен 0,61 l/R. Отсюда видно, что чем больше радиус, тем больше усиления и уже угол излучения и чувствительности.
Предельные расстояния для радио каналов приводятся поставщиками в предположении, что в пределах первой зоны Френеля каких-либо физических помех нет. При звездообразной схеме каналов (как на рис. 3.6.) нужно по возможности выполнить требования на минимальное расстояние между принимающими антеннами d (оно должно быть больше определенного значения, зависящего от апертуры антенны и расстояния между передатчиком и приемником).
Рис. 3.3.6.
Это расстояние определяется расходимостью (a) радиолуча и используемой длиной волны. Если это требование не выполнимо, следует в смежных каналах использовать разные длины волн. Диаграмма излучения направленной антенны показана на рис. 3.3.7 (стрелкой отмечено основное направление излучения). Эту диаграмму следует учитывать при выборе места установки антенны, особенно при использовании большой мощности излучения. Иначе один из лепестков излучения может прийтись на места постоянного пребывания людей (например, жилье). Учитывая эти обстоятельства, проектирование такого рода каналов целесообразно поручить профессионалам.
Рис. 3.3.7. Диаграмма излучения параболической антенны
Стоимость антенного комплекса обычно пропорциональна кубу диаметра антенны. Стандартная антенна intelsat имеет диаметр 30 м и угол излучения 0,010.
Спутниковые каналы используют диапазоны перечисленные в таблице 3.3.2.
Таблица 3.3.2. Частотные диапазоны, используемые для спутниковых телекоммуникаций
| Диапазон | Канал снижения (downlink)[ГГц] |
Канал подъема (uplink)[ГГц] | Источники помех |
| С | 3,7-4,2 | 5,925-6,425 | Наземные помехи |
| ku | 11,7-12,2 | 14,0-14,5 | Дождь |
| ka | 17,7-21,7 | 27,5-30,5 | Дождь |
/p> Из таблицы видно, что передача ведется на более высокой частоте, чем прием сигнала со спутника. Обычный спутник обладает 12-20 транспондерами (приемопередатчиками), каждый из которых имеет полосу 36-50МГц, что позволяет сформировать поток данных 50 Мбит/с. Такая пропускная способность достаточна для получения 1600 высококачественных телефонных каналов (32кбит/c). Современные спутники используют узкоапертурную технологию передачи vsat (very small aperure terminals). Такие терминалы используют антенны диаметром 1 метр и выходную мощность около 1 Вт. При этом канал к спутнику имеет пропускную способность 19,2 кбит/с, а со спутника более 512 кбит/c. Непосредственно такие терминалы не могут работать друг с другом, разумеется через телекоммуникационный спутник. Для решения этой проблемы используются промежуточные наземные антенны с большим усилением, что, правда увеличивает задержку. Схема связей в технологии VSAT.
Рис. 3.3.8. Схема спутниковой связи VSAT
Терминальные антены vsat имеют диаметр 1-1,5 м и излучаемую мощность 1-4 Вт, обеспечивая широкополосность до 64 кбит/с. Такие небольшие антенны не позволяют таким терминалам общаться непосредственно. На рис. 3.3.8. станции А и Б не могут непосредственно друг с другом. Для передачи данных используется промежуточная станция с большой антенной и мощностью (на рис. антенна В). Для создания постоянных каналов телекоммуникаций служат геостационарные спутники, висящие над экватором на высоте около 36000 км.
Теоретически три таких спутника могли бы обеспечить связью практически всю обитаемую поверхность земли (см. рис. 3.3.9.). Спутники, работающие на одной и той же частоте должны быть разнесены по углу на 2o. Это означет что число таких спутников не может быть больше 180. В противном случае они должны работать в разных частотных диапазонах. При работе в ku-диапазоне угловое расстояние между спутниками можно сократить до 1o. Влияние дождя можно минимизировать, используя далеко отстоящие наземные станции (размеры урагана конечны!).
Рис. 3.3.9.
Реально геостационарная орбита переполнена спутниками различного назначения и национальной принадлежности. Обычно спутники помечаются географической долготой мест, над которым они висят. На практике геостационарный спутник не стоит на месте, а выполняет движение по траектории, имеющей вид цифры 8. Угловой размер этой восьмерки должен укладываться в рабочую апертуру антенны, в противном случае антенна должна иметь сервопривод, обеспечивающий автоматическое слежение за спутником. Из-за энергетических проблем телекоммуникационный спутник не может обеспечить высокого уровня сигнала. По этой причине наземная антенна должна иметь большой диаметр, а приемное оборудование низкий уровень шума. Это особенно важно для северных областей, для которых угловое положение спутника над горизонтом невысоко (это особенно существенно для широт более 700), а сигнал проходит довольно толстый слой атмосферы и заметно ослабляется. Спутниковые каналы могут быть рентабельны для областей, отстоящих друг от друга более чем на 400-500 км (при условии что других средств не существует). Правильный выбор спутника (его долготы) может заметно снизить стоимость канала.
Число позиций для размещения геостационарных спутников ограничено. В последнее время для телекоммуникаций планируется применение так называемых низколетящих спутников ( S.Bhatti.
Типичный спутник имеет 12-20 транспондеров, каждый из которых имеет полосу 36-50 МГц. Один транспондер может обеспечить информационный поток в 50 Мбит/с или 800 64-килобитных каналов цифровой телефонии. Два транспондера могут использовать разную поляризацию сигнала и по этой причине работать на одной и той жк частоте. Каждый телекоммуникационный спутник снабжен несколькими антеннами. Низходящий луч может быть сфокусирован на достаточно ограниченную область на земле (с диаметром несколько сот км). Что также упрощает осуществление двунаправленного обмена.
Существует несколько способов работы совокупности наземных терминалов со спутником. При этом может использоваться мультиплексирование по частоте (FDM), по времени (TDM), CDMA (Code Division Multiple Access), ALOHA или метод запросов.
Схема запросов предполагает, что наземные станции образуют логическое кольцо, вдоль которого двигается маркер. Наземная станция может начать передачу на спутник, лишь получив этот маркер.
Простая система ALOHA (разработана группой Нормана Абрамсона из Гавайского университета в 70-х годах) позволяет каждой станции начинать передачу тогда, когда она этого захочет. Такая схема с неизбежностью приводит к столкновениям. Связано это отчасти с тем, что передающая сторона узнает о столкновении лишь спустя ~270 мсек. После столкновения станция ожидает некоторое псевдослучайное время и совершает повторную попытку передачи еще раз. Такой алгоритм доступа обеспечивает эффективность использования канала на уровне около 18%, что совершенно недопустимо для таких дорогостоящих каналов, как спутниковые. По этой причине чаще используется доменная версия системы ALOHA, которая удваивает эффективность. Одна наземная станция (эталонная) периодически посылает специальный сигнал, который используется всеми участниками для синхронизации. Если длина временного домена равна DT, тогда домен с номером k начинается в момент времени kDT по отношению к упомянутому выше сигналу. Так как часы разных станций работают немного по разному, необходима периодическая ресинхронизация. Другой проблемой является разброс времени распространения сигнала для разных станций.
Метод мультиплекcирования по частоте (FDM) является старейшим и наиболее часто используемым. Типичный транспондер с полосой 36 Мбит/с может использован для получения 500 64кбит/с ИКМ-каналов, каждый из которых работает со своей уникальной частотой, чтобы исключить интерференцию с другими. Соседние каналы должны отстоять на достаточном расстоянии друг от друга. Кроме того, должен контролироваться уровень передаваемого сигнала, так как при слишком большой выходной мощности могут возникнуть интерференционные помехо в соседнем канале. Если число станций невелико и постоянно, частотные каналы могут быть распределены стационарно. Но при переменном числе терминалов или при заметной флуктуации загрузки приходится переходить на динамическое распределение ресурсов. Одним из механизмов такого распределение имеет название SPADE, он использовался в первых версиях систем связи на базе INTELSAT. Каждый транспондер системы SPADE содержит 794 симплексных ИКМ-каналов по 64-кбит/c и один сигнальный канал с полосой 128 кбит/c. ИКМ-каналы используются попарно для обеспечения полнодуплексной связи. При этом восходящий и ниcходящий каналы имеют полосу по 50 Мбит/с. Сигнальный канал делится на 50 доменов по 1 мсек (128 бит). Каждый домен принадлежит одной из наземной станции, число которых не превышает 50. Когда станция готова к передаче, она произвольным образом выбирает неиспользуемый канал и записывает номер этого канала в очередной свой 128 битный домен. Если один и тот же канал попытаются занять две или более станции происходит столкновение и они вынуждены будут повторить попытку позднее.
Метод мультиплекирования по времени сходен с FDM и довольно широко применяется на практике. Здесь также необходима синхронизация для доменов. Это делается как и в доменной системе ALOHA c помощью эталонной станции. Присвоение доменов наземным станциям может выполняться централизовано или децентрализовано. Рассмотрим систему ACTS (Advanced Communication Technology Satellite). Система имеет 4 независимых канала (TDM) по 110 Мбит/c (два восходящих и два ниcходящих). Каждый из каналов структурированы в виде 1-милисекундных кадров, каждый из которых имеет по 1728 временных доменов. Каждый из временных доменов имеет 64-битовое поле данных, что позволяет реализовать голосовой канал с полосой в 64 кбит/c. Управление временными доменами с целью минимизации времени на перемещения вектора излучения спутника предполагает знание географического положения наземных станций. Управление временными доменами осуществляется одной из наземных станций (MCS - Master Control Station). Работа системы ACTS представляет собой трехшаговый процесс. Каждый из шагов занимает 1 мсек. На первом шаге спутник получает кадр и запоминает его в 1728-ячеечном буфере. На втором - бортовая ЭВМ копирует каждую входную запись в выходной буфер (возможно для другой антенны). И, наконец, выходная запись передается наземной станции.
В исходный момент каждой наземной станции ставится в соответствие один временной домен. Для получения дополнительного домена, например для организации еще одного телефонного канала, станция посылает запрос MCS. Для этих целей выделяется специальный управляющий канал емкостью 13 запросов в сек. Существуют и динамические методы распределения ресурсов в TDM (методы Кроузера [Crowther], Биндера [Binder] и Робертса [Roberts]).
Метод CDMA (Code Division Multiple Access) не требует синхронизации и является полностью децентрализованным. Как и другие методы он не лишен недостатков. Во-первых, емкость канала CDMA в присутствии шума и отсутствии координации между станциями обычно ниже, чем в случае TDM. Во-вторых, система требует быстродействующего и более дорогого оборудования.
Безопасная почта PGP
6.4.4 Безопасная почта PGP
Семенов Ю.А. (ГНЦ ИТЭФ)
В связи с массовым внедрением электронной почты и, в перспективе, полным вытеснением традиционной, проблема конфиденциальности доставки электронных сообщений становится крайне актуальной. В последние годы разработано несколько почтовых систем, предоставляющих эту конфиденциальность. Примером такой системы может служить PEM - почта с улучшенной защитой от несанкционированного доступа (PEM - Privacy Enhanced Mail, RFC-1421, 1422, 1423 и 1424). Первая разработка в области электронной криптографии относится к 1976 году, когда была создана система Диффи-Хелмана (Diffie-Hellman) с общедоступным шифровальным ключом. Позднее, в 1977 году Ривестом, Шамиром и Адлеманом была предложена двух ключевая система RSA (Rivest-Shamir-Adleman). Эта разработка была выполнена под патронажем Национального научного фонда США (NSF) и в 1983 году запатентована в США.
PEM является стандартом Интернет для улучшения защищенности электронной почты. PEM использует криптографическую технику для обеспечения контроля правильности передачи сообщения, защищенности и идентификации. Стандарт позволяет вам знать, что полученное сообщение не было изменено, быть уверенным, что ваше сообщение будет получено именно тем и только тем, кому было адресовано.
Предусмотрена интеграция MIME (Multipurpose Internet Mail Extensions) и PEM. Существует подписной лист (LISTSERV) для пользователей, интересующихся вопросами развития и использования PEM. Для подписки необходимо послать соответствующее сообщение по адресу pem-dev-request@tis.com.
Для пользователей PEM имеется еще один подписной лист: tispem-users@tis.com. Для подписки следует направлять заявки по адресу: tispem-users-request@tis.com. С вопросами по использованию TIS/PEM следует обращаться в tispem-support@tis.com.
Имеется версия программного обеспечения PEM в свободном доступе, например, TIS/PEM V7.0 (UNIX, только для США и Канады). Эта версия содержит в себе:
поддержку однопользовательского режима с возможностью совместного использования некоторых процедурных модулей;
легко читаемую базу данных для каждого пользователя;
поддержку для большего числа баз данных;
гибкую систему управления доступом;
гибкую систему поверки;
системы верификации, кодирования, декодирования и электронной подписи, совместимые с другими почтовыми серверами;
поддержку интеграции MIME-PEM.
Система TIS/PEM доступна через анонимное FTP в США и Канаде по адресу: ftp.tis.com pub/PEM/README; pub/PEM/LICENSE; pub/PEM/BUGS. Файл README содержит дополнительные инструкции по применению PEM.
Несравненно большей популярностью пользуется конфиденциальная почтовая система PGP (Pretty Good Privacy – замечательная конфиденциальность). История создания PGP довольно драматична (см. http://www.dcs.ex.ac.uk/~aba/timeline/. Создателем PGP является Фил Циммерман (США, 1991 год). PGP базируется на двух ключевой системе шифрования RSA и алгоритме IDEA (International Data Encryption Algorithm, предложен Ксейа Лайем и Джеймсом Массейем, Швейцария). Творение Циммермана было встречено без энтузиазма Агентством Национальной Безопасности США и против него было возбуждено уголовное дело. Хотя АНБ и могущественно, здравый смысл и закон в данном случае восторжествовали. Что же касается патента на RSA, он не является международным и вся ответственность за использование программ, базирующихся на данном алгоритме, лежит на пользователе (юридически ситуация весьма запутана). В России применение любой системы шифрования (формально даже архивирование!) требует лицензирования. Все правительства любят все держать в тайне, но не любят, когда кто-то пытается хранить в тайне что-то от правительства (даже если это любовные письма; если вы интересуетесь юридической стороной проблемы использования PGP, смотрите в http://cwis.kub.nl/~frw/people/koops/lawsurvy.htm. Чему здесь удивляться, ведь история “черных кабинетов” (в том числе и в России) исчисляется столетиями.
PGP версия 2.5 (http://www.ifi.uio.no/~staalesc/PGP ) (и более поздние используют RSAREF 1.0 вместо MPILIB) представляет собой публично доступный (легальный!) пакет электронной почты со встроенной системой шифрования сообщений. Пакет обеспечивает конфиденциальность переписки и пересылки файлов. Конфиденциальность заключается в том, что только лица, кому адресовано послание или файл, смогут его прочесть. PGP поддерживает технологию электронной подписи, гарантирующей получателю, что сообщение пришло именно от вас. Предусмотрен контроль неизменности сообщения в процессе доставки (принцип сходен с идеей CRC). При этом не требуется каких-либо секретных каналов для пересылки ключей кодирования. Именно эта схема являлась до недавнего времени основной. Главный ее недостаток - необходимость транспортировки секретного ключа. PGP использует технику шифрования с общедоступными ключами, совмещая удобства системы кодирования RSA с быстродействием традиционных методов. Существуют коммерческие версии PGP, встроенные в известные текстовые редакторы WORD и другие. В PGP предусмотрена схема, резко ускоряющая дешифровку. Возможно применение большого набора пар общедоступных и секретных ключей. Имеется система авторизации, контролирующая доступ к ключам и препятствующая использованию краденных секретных ключей. Предусмотрены и другие методы повышения секретности пересылки любых сообщений.
Пакет работает под MS-DOS, UNIX, Windows. Данная версия позволяет посылать сообщение сразу нескольким адресатам. Пакет имеет встроенную справочную систему (Help на английском, французском и испанском языках. Описания, инструкции по постановке и использованию можно найти по адресу: FTP ftp.uu.net/pub/security/pgp.
Безопасное ядро (SSH)
6.6 Безопасное ядро (SSH)
Семенов Ю.А. (ГНЦ ИТЭФ)
Администрирование сетей обычно производится с консоли. Это удобный и наиболее безопасный метод. Но время от времени возникают ситуации, когда администратор вынужден выполнять те или иные системные операции с удаленного терминала. Если терминальный обмен не зашифрован, он может быть перехвачен с помощью любой машины (например, используя программу tcpdump), подключенной к тому же логическому сегменту или, в более общем случае, к тому же каналу. Именно по этой причине целесообразно выделять почтовый сервер, DNS, сервер новостей и маршрутизаторы в отдельный сетевой сегмент, к которому не подключены “посторонние” машины. Для того чтобы предотвратить перехват сессии авторизации и последующей работы оператора, в Финляндии разработана специальная программа “безопасное ядро” SSH (Secure Shell). Эта общедоступная программа пригодна для любых удаленных сессий, включая те, которые используют протокол HTTP. SSH использует для шифрования как открытого ключа так и симметричной схемы. При этом производится аутентификация ЭВМ и формирование коммуникационного канала с шифрованием передаваемых данных. В отличие от SSL здесь не требуется приобретать сертификат сервера или клиента для обеспечения высокой степени безопасности. Благодаря тому, что программа разработана в Европе, пользователь даже за пределами США получает высокий уровень защиты (нет экспортных лицензионных ограничений). SSH заменяет для приложений, где требуется безопасность, такие программы как telnet, rlogin, rsh и rcp. Эта программа для ЭВМ, на которых установлена, шифрует также и сессии X Windows. Привлекательность программы заключается в том, что помимо перечисленных возможностей она применима для шифрования практически любой TCP/IP сессии, например, FTP или HTTP. Это реализуется путем запуска специальной прокси-программы на вашей локальной ЭВМ. Прокси-программа шифрует запрос и организует туннель до нужного сервера. Это позволяет использовать редактор HTML, графический WEB-броузер и другие программные продукты, которые сами по себе не поддерживают криптографической защиты. Шифрованная связь поддерживается с WEB-сервером, который не имеет соответствующего сертификата.
Для формирования SSH-прокси на удаленном WEB- сервере сначала нужно зарезервировать не используемый порт на локальной машине, например, 5678. После этого следует использовать программу SSH для того, чтобы установить связь, например, с каким-то WEB-сервером. При этом для создания прокси следует применить опцию –L:
SSH –L5678:www.pod.potol.com:80 www.pod.potol.com
Аргумент, следующий после флага опции -L имеет формат:
<локальный порт>:<удаленная ЭВМ>:<удаленный порт>.
Таким образом, мы требуем, чтобы прокси прослушивала локальный порт 5678 и переадресовывала весь обмен в зашифрованном виде в порт 80 узла www.pod.potol.com. После выполнения данной команды следует, например, запустить WEB-броузер на вашей ЭВМ и потребовать установления связи с http://localhost:5678/. Практически будет установлена связь с http://www.pod.potol.com, но весь диалог в этом варианте уже будет зашифрован. По завершении работы с броузером следует выполнить команду logout на удаленной ЭВМ. Общедоступную версию SSH можно найти по адресу: www.cs.hut.fi/ssh. Информацию о коммерческих версиях для Windows и Macintosh можно найти на сервере: www.datafellows.com/f-secure.
Безопасность WEB-серверов
6.7 Безопасность WEB-серверов
Семенов Ю.А. (ГНЦ ИТЭФ)
WEB-сервер достаточно сложная и потому уязвимая для атак программа. Причем угрозы могут исходить из самых неожиданных мест. Так в конце июня 1997 года было обнаружено, что Windows-95 (и NT) “повисает” (полный перечень причин повисания этой системы может занять целый том) при приходе на ее вход ICMP-пакета с длиной, которая не соответствует значению, указанному в его поле заголовка Длина.
WEB-сервер, также как любая сеть должен иметь свою, желательно записанную на бумаге политику безопасности. Это должен быть достаточно простой документ типа приведенного ниже.
Доступ к WEB-серверу имеет пять уровней:
Общедоступный с возможностью только чтения всех URL за исключением тех, что помещены в каталогах /private. Доступ сотрудников фирмы или организации, которой принадлежит сервер. Здесь также допустимо только чтение, но доступны и секции каталога /private. Разработчики WEB-сервера. Имеют возможность модифицировать содержимое сервера, инсталлировать CGI-скрипты, прерывать работу сервера. Администраторы узла (сервера). Имеют те же привилегии, что и разработчики, но могут также реконфигурировать сервер и определять категорию доступа. Системные администраторы. Имеют идентичные привилегии с администраторами сервера.
Для получения доступа на уровне 3-5 необходимо письменное разрешение директора организации или его заместителя по информационным системам. Доступ уровня 2 автоматически получают все сотрудники организации или фирмы при авторизации. Администраторы могут аннулировать авторизацию по решению заместителя директора по информационным системам, а при чрезвычайных обстоятельствах самостоятельно, но с последующим уведомлением руководства. Работа с локальной консоли WEB-сервера разрешается только администраторам. Удаленная работа администраторам запрещена, они должны работать только с локального терминала. CGI-скрипты устанавливаются на сервер после их проверки и одобрения как минимум двумя членами группы администраторов. Скрипты, исходные тексты которых недоступны, устанавливаются только по решению заместителя директора по информационным системам.
Информация из каталогов /private, которая считается конфиденциальной, доступна только с терминала самой ЭВМ.
При работе с WEB-сервером не допускается доступ к базам данных или файлам, если для этого не имеется соответствующего разрешения.
Описание политики безопасности должно включать указание периода формирования резервных копий содержимого сервера, описания допустимых сетевых услуг и время профилактических остановок. Включается сюда перечень видов обязательного мониторинга сервера и просмотра дневника посещений.
Приведенный текст описания политики безопасности может варьироваться в широких пределах, он зависит от используемой ОС и набора сетевых утилит.
Наиболее безопасной сетевой средой считается Macintosh OS. Это связано с тем, что она не включает в себя интерпретатора команд, не поддерживает скрипты и не предоставляет каких-либо дополнительных сетевых услуг, неавторизованный просмотр WEB-страниц на Макинтоше практически не возможен.
Системы Windows NT и UNIX обладают сопоставимыми и достаточно высокими уровнями безопасности. Большое число сообщений о дефектах безопасности UNIX свидетельствует о его массовом использовании.
Теперь рассмотрим, что нужно сделать, чтобы обеспечить максимально возможную безопасность WEB-cервера.
Выбрать наиболее безопасную ОС и сконфигурировать ее с учетом требования безопасности. Использовать все известные корректирующие программы, выпущенные разработчиком ОС. Организовать мониторирование любой подозрительной активности на сервере (активность в ночное время, многократные попытки авторизации и т.д.). Контролировать доступ к конфиденциальным документам. Доступ к таким документом должен быть разрешен только ограниченному числу пользователей. Доступ к таким частям сервера должен быть организован с использованием протокола SSL. Тщательно разрабатывать и проверять используемые CGI-скрипты и аплеты. Установить жесткие требования к доступу для выполнения различных операций, особенно для модификации содержимого и конфигурации сервера. Защитить локальную сеть от WEB-сервера. Исключить возможность проникновения к жизненно важным ресурсам сети через WEB-сервер, например, с помощью Firewall. Отслеживать вновь обнаруженные слабости используемой ОС и программного обеспечения сервера. Делайте это чаще, если вам не безразлична безопасность вашего сервера, не надейтесь, что все хакеры ленивее вас. Ссылки на различные серверы, где публикуется такая информация, можно найти в конце раздела 6.
При работе с ОС Windows NT следует отключить доступ TCP/IP от услуг NETBIOS. Это может быть сделано с помощью Firewall, блокировкой доступа к портам 137 и 138 для UDP и TCP. Можно решить эту проблему отключения NETBIOS от TCP/IP драйвера переконфигурировав Windows NT.
Если WEB-сервер нуждается в контроле доступа, то в настоящее время (в HTTP/1.1) имеется две возможности. Первая (basic) - предполагает традиционный ввод и передачу по сети имени клиента и пароля. Эта схема проста, но допускает перехват параметров доступа (а между клиентом и сервером может быть достаточно много промежуточных узлов). Вторая схема (digest) для пользователя выглядит аналогично, но вводимое имя и пароль не передаются по сети непосредственно. На их базе формируется дайджест MD5, который пересылается по сети и используется для идентификации клиента.
T1 имеют пропускную способность, соответствующую
2.3 Цифровые каналы T1 и Е1
Семенов Ю.А. (ГНЦ ИТЭФ)
Системы (каналы) T1 имеют пропускную способность, соответствующую 24 аналоговым каналам с полосой 0-3.3 кГц (американская версия стандарта). Частота стробирования равна 8 кГц, что соответствует передаче 8000 кадров в сек. После каждых 6000 футов коаксиального кабеля ставятся системы регенерации сигналов. Все 24 канала мультиплексируются на общий коаксиальный кабель, предварительно производится PCM-преобразование сигналов. 24 канала по 8 бит (при 8-битном АЦП) дает 192 бита на кадр. Один дополнительный (193-ий) бит используется для целей синхронизации (F). Таким образом частота бит в канале Т1 составляет 193*8000=1,554 Мбит/с (это стандарт США, его европейский аналог - Е1 имеет 30 каналов и пропускную способность 2048 кбит/c). Это соответствует частоте кадров 667/с. Каждый восьмой бит (младший) байта (временного домена на рис. 2.3.1) используется для целей управления, что несколько снижает пропускную способность. В ISDN каналы 1,544 и 2,048 Мбит/с, форматы которых здесь описаны, называются первичными.
8-битовые pcm-блоки генерируются каждые 125мксек (8000/с). Структура данных при передаче со скоростью 1,544 Мбит/с представлена ниже (isdn 2*B+D):
Рис. 2.3.1. Структура кадров для американского (вверху) и европейского (внизу) стандартов передачи данных
Скорости передачи 1,544 (кодирование B8ZS) и 2,048 Мбит/с (HDB3) называются первичными скоростями. Кадры структурированы так, что временные домены (таймдомен на рис. 2.3.1) для передачи данных по каналам B1 и B2 чередуются. В Европе используется 2048Мбит/с интерфейс. Каждый 6-ой кадр используется для сигнальных целей. Количество временных доменов в кадре определяет число телефонных разговоров, которые могут осуществляться одновременно. Для американского стандарта это число равно 24, а для европейского 30 (в последнем случае учтено то, что часть доменов используется в служебных целях).
Все современные коммутаторы управляются центральным процессором. Такие коммутаторы обычно называются коммутаторами, управляемыми встроенной памятью (SPC - Stored Program Controlled exchanges).
Дельта-модуляция
2.4.1 Дельта-модуляция
Семенов Ю.А. (ГНЦ ИТЭФ)
Дельта-модуляция представляет собой вариант дифференциальной импульсно-кодовой модуляции, где для кодирования разностного сигнала используется только один бит. Этот бит служит для того, чтобы увеличить или уменьшить оценочный уровень. Примером реализации дельта-модуляции может служить схема, показанная на рис. 2.4.1.1. Сигнал ЦАП отслеживает входной сигнал in(t). Здесь компаратор заменил дифференциальный усилитель, который используется в дифференциальном импульсно-кодовом модуляторе.
Рис. 2.4.1.1 Схема устройства линейной дельта-модуляции
Если скорость нарастания входного сигнала велика, то уровень на выходе ЦАП будет отставать и сможет нагнать In(t) только, когда входной сигнал начнет уменьшаться. Данный метод не является разумной альтернативой PCM. Для улучшения характеристик дельта-преобразователя реверсивный счетчик можно заменить цифровым процессором, при этом шаг S становится переменным, но кратным некоторому базовому значению.
Существуют много других способов кодирования человеческого голоса, среди них наиболее эффективный реализован в приборах, носящих название - вокодер (VOCODER).
