Введение в Интернет

1.1. Протокол IP

В Интернет используется много различных типов пакетов, но один из основных — IP-пакет (RFC-791), именно он вкладывается в кадр Ethernet и именно в него вкладываются пакеты UDP, TCP и ICMP. IP-протокол предлагает ненадежную транспортную среду: ненадежную в том смысле, что не существует гарантии благополучной доставки IP-дейтаграммы. Алгоритм доставки в рамках данного протокола предельно прост: при ошибке дейтаграмма выбрасывается, а отправителю посылается соответствующее ICMP-сообщение (или не посылается ничего). Обеспечение же надежности возлагается на более высокий уровень (UDP или TCP). Формат IP-пакетов показан на рисунке 1.5.

Поле версия характеризует версию IP-протокола (например, 4 для v4 или 6 – для v6). Формат пакета определяется программой и, вообще говоря, может быть разным для разных значений поля версия. Только размер и положение этого поля незыблемы. Поэтому в случае изменений длины IP-адреса или других вариаций заголовка слишком тяжелых последствий не произойдет. Понятно также, что значение поля версия во избежание непредсказуемых последствий должно контролироваться программой. Поле версия определяет то, что следует далее делать с заголовком дейтаграммы и полем данных. Ниже на рис. 1.5а для сравнения приведен формат заголовка дейтаграммы IPv6 (RFC-2460). Заголовок для IPv6 имеет размер в два раза больше, чем для IPv4.

Общим полем для заголовков является только версия. Поле длина заголовка Hlen (v4) нужно из-за возможности присутствия полей опций. Hlen — длина заголовка, измеряемая в 32-разрядных словах, обычно заголовок содержит 20 октетов (Hlen=5, без опций и заполнителя). В версии 6 заголовок имеет фиксированную длину, и необходимость в поле длины заголовка отпадает. Функция тип сервиса (ToS IPv4) реализуется в IPv6 в несравненно большем объеме с помощью полей класс трафика и метка потока. Функции полей идентификатор, флаги и указатель фрагмента, управляющие фрагментацией, реализуются, если требуется, с помощью полей метка потока или следующий заголовок (IPv6).

Поля идентификатор, флаги (3 бита) и указатель фрагмента (fragment offset; IPv4) управляют процессом фрагментации и последующей "сборки" дейтаграммы. Идентификатор представляет собой уникальный код дейтаграммы, позволяющий идентифицировать принадлежность фрагментов и исключить ошибки при "сборке" дейтаграмм. Бит 0 поля флаги является резервным, бит 1 служит для управления фрагментацией пакетов (0 — фрагментация разрешена; 1 — запрещена), бит 2 определяет, является ли данный фрагмент последним (0 — последний фрагмент; 1 — следует ожидать продолжения). Поле полная длина (IPv4) функционально эквивалентно полю размер поля данных (IPv6). Поле полная длина определяет полную длину IP-дейтаграммы (до 65535 октетов), включая заголовок и данные. В случае Ethernet длина дейтаграммы не может быть больше 1500 байт.

В IPv6 фрагментация может производиться только отправителем и можно считать, что флаг DF (не фрагментировать) по умолчанию подразумевается равным 1 (хотя поля флаги здесь по понятным причинам нет).

Протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов, должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.

Поле протокол (IPv4) заменено в IPv6 полем следующий заголовок. При этом функциональность существенно обогатилась, так как в IPv4 можно реализовать лишь один уровень вложения (UDP, TCP, ICMP). В IPv6 этого ограничения нет, и можно обеспечить любое число уровней вложения. В определенном смысле можно утверждать, что поля протокол (IPv4) и следующий заголовок выполняют ту же функцию, что и поле версия, — определяет программу обработки вложенного заголовка.

Поле контрольная сумма заголовка (IPv4) в версии 6 удалено, так как вероятность искажения заголовка по мере развития технологии стала пренебрежимо малой. Поля TTL (IPv4) и предельное число шагов (IPv6) в настоящее время совершенно тождественны.

Поле TTL относится к числу переменных полей заголовка. При прохождении через маршрутизатор над содержимым этого поля производится операция TTL=TTL-1, при этом должна быть пересчитана контрольная сумма. И, если TTL=0, дейтаграммы отбрасываются.

Потенциально переменными полями заголовка в IPv4 являются также флаги и указатель фрагмента.

IPv6 поля опций не нужны, так как их функцию может выполнить поле следующий заголовок.

Однооктетное поле тип сервиса (TOS — type of service; IPv4) характеризует то, как должна обрабатываться дейтаграмма, как производится буферизация. Это поле делится на 6 субполей (рис. 1.5б.).

Субполе приоритет предоставляет возможность присвоить код приоритета каждой дейтаграмме. Значения приоритетов приведены в таблице (в настоящее время это поле не используется).

0 — обычный уровень

1 — приоритетный

2 — немедленный

3 — срочный

4 — экстренный

5 — ceitic/ecp

6 — межсетевое управление

7 — сетевое управление

Формат поля TOS определен в документе RFC-1349. Биты C, D, T и R характеризуют пожелание относительно способа доставки дейтаграммы. Так, D=1 требует минимальной задержки, T=1 — высокую пропускную способность, R=1 — высокую надежность, а C=1 — низкую стоимость. В таблице 1.1 приведены рекомендуемые значения TOS.

Только один бит из четырех в TOS может принимать значение 1. Значения по умолчанию равны нулю. Большинство из рекомендаций самоочевидны. Так, при telnet наибольшую важность имеет время отклика, а для SNMP (управление сетью) — надежность.

До середины 90-х годов поле TOS в большинстве реализаций игнорировалось. Но после начала разработок средств обеспечения качества обслуживания (QoS) внимание к этому возросло. Появилось предложение замены поля TOS на поле DSCP (Differentiated Services Code Point), которое также имеет 8 бит (см. RFC-2474). (Смотри рис. 1.6.). Биты CU пока не определены. Иногда это поле называется байтом DS (Differentiated Services).

Биты DS0-DS5 определяют селектор класса. Значения этого кода представлены в таблице ниже. Стандартным значением DSCP по умолчанию является 000000 (Таблица . 1.1.1.).

На базе DSCP разработана технология "пошагового поведения" PHB (Per Hop Behavior). В рамках этой политики определяются коды DSCP внутри классов. Например, для политики немедленной переадресации EF рекомендуемое значение DSCP=101110. Эта политика соответствует наиболее высокому уровню обслуживания.

Маршрут транспортировки IP-дейтаграммы нельзя знать заранее, это связано с поэтапным (пошаговом) принятием решения о пути каждого пакета. Это свойство маршрутизации обусловлено тем, что IP является протоколом передачи данных без установления соединения.

Поле время жизни (TTL — time to live) раньше задавало время жизни дейтаграммы в секундах, т.е. предельно допустимое время пребывания дейтаграммы в пути. В настоящее время TTL определяет предельное число маршрутизаторов, через которые может пройти дейтаграмма. При каждой обработке дейтаграммы, например в маршрутизаторе, это время уменьшается в соответствии со временем пребывания в данном устройстве или согласно протоколу обработки. Если TTL=0, дейтаграмма из системы удаляется. Во многих реализациях TTL измеряется в числе шагов, в этом случае каждый маршрутизатор выполняет операцию TTL=TTL-1. TTL помогает предотвратить зацикливание пакетов. Поле протокол аналогично полю тип в Ethernet-кадре и определяет алгоритм обработки поля данные (см. табл. 1.1.1).

Поле контрольная сумма заголовка вычисляется с использованием операций сложения 16-разрядных слов заголовка по модулю 1. Сама контрольная сумма является дополнением по модулю один полученного результата сложения. Обратите внимание, здесь осуществляется контрольное суммирование заголовка, а не всей дейтаграммы. Поле опции не обязательно присутствует в каждой дейтаграмме. Размер поля опции зависит от того, какие опции применены. Если используется несколько опций, они записываются подряд без каких-либо разделителей. Каждая опция содержит один октет кода опции, за которым может следовать октет длины и серия октетов данных. Если место, занятое опциями, не кратно 4 октетам, то используется заполнитель. Структура октета кода опции отражена на рис. 1.7.

Флаг копия, равный 1, говорит о том, что опция должна быть скопирована во все фрагменты дейтаграммы. При равенстве этого флага 0 опция копируется только в первый фрагмент. Ниже приведены значения разрядов 2-битового поля класс опции (таблица 1.2.1.).

В таблице, которую вы найдете ниже, приведены значения классов и номеров опций (таблица 1.2.2.).

Наибольший интерес представляют собой опции временные метки и маршрутизация. Опция записать маршрут (RR) создает дейтаграмму, где зарезервировано место, куда каждый маршрутизатор по дороге должен записать свой IP-адрес (например, в случае утилиты traceroute). Формат опции записать маршрут в дейтаграмме представлен ниже на рис. 1.8 (предусмотрено место для записи 9 IP-адресов; к сожалению, реализация RR не является обязательной, да и девяти шагов часто недостаточно):

Поле код содержит номер опции (7 в данном случае). Поле длина определяет размер записи для опций, включая первые 3 октета. Указатель отмечает первую свободную позицию в списке IP-адресов (куда можно произвести запись очередного адреса). Интересную возможность предоставляет опция маршрут отправителя — посылать дейтаграммы по заданному отправителем маршруту. Это позволяет исследовать различные маршруты, в том числе те, которые недоступны через узловые маршрутизаторы. Существует две формы такой маршрутизации: Свободная маршрутизация и Жесткая маршрутизация (маршрутизация отправителя). Форматы для этих опций показаны ниже:

Жесткая маршрутизация означает, что адреса определяют точный маршрут дейтаграммы. Проход от одного адреса к другому может включать только одну сеть. Свободная маршрутизация отличается от предшествующей возможностью прохода между двумя адресами списка более чем через одну сеть. Поле длина задает размер списка адресов, а указатель отмечает адрес очередного маршрутизатора на пути дейтаграммы.

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

Чтобы посмотреть, как выглядит простая маршрутная таблица, воспользуемся командой netstat -rn (ЭВМ Sun. Флаг -r выводит на экран маршрутную таблицу, а -n отображает IP-адреса в цифровой форме. С целью экономии места таблица в несколько раз сокращена) (таблица 1.2.3.).

Колонка destination — место назначения, Default — отмечает маршрут по умолчанию; Gateway — IP-адреса портов подключения (маршрутизаторов); REFCNT (reference count) — число активных пользователей маршрута; USE — число пакетов, посланных по этому маршруту; interface — условные имена сетевых интерфейсов. Расшифровка поля FLAGS приведена ниже (таблица 1.2.4.).

Опция временные метки работает так же, как и опция запись маршрута. Каждый маршрутизатор на пути дейтаграммы делает запись в одном из полей дейтаграммы (два слова по 32 разряда). Формат этой опции отображен на рисунке 1.9.

Смысл полей длина и указатель идентичен тому, что сказано о предыдущих опциях. 4-битовое поле переполнение содержит число маршрутизаторов, которые не смогли записать временные метки из-за ограничений выделенного места в дейтаграмме. Значения поля флаги задают порядок записи временных меток маршрутизаторами (таблица 1.3.).

Временные метки должны содержать время в миллисекундах, отсчитанное от начала суток. Если маршрутизатору некуда положить свою временную метку (число меток превысило 9), он инкрементирует счетчик переполнение.

Взаимодействие других протоколов с IP можно представить из схемы на рис. 1.10. В основании лежат протоколы, обеспечивающие обмен информацией на физическом уровне, далее следуют протоколы IP, ICMP, ARP, RARP, UDP, TCP, IGMP и протоколы маршрутизаторов. Чем выше расположен протокол, тем более высокому уровню он соответствует. Протоколы, имена которых записаны в одной и той же строке, соответствуют одному и тому же уровню. Но все разложить аккуратно по слоям невозможно: некоторые протоколы занимают промежуточное положение, что и отражено на схеме, (области таких протоколов захватывают два уровня). Здесь протоколы IP, ICMP и IGMP помещены на один уровень, для чего имеется немало причин. Но иногда последние два протокола помещают над IP, так как их пакеты вкладываются в IP-дейтаграммы. Так что деление протоколов по уровням довольно условно. На самом верху пирамиды находятся прикладные программы, хотя пользователю доступны и более низкие уровни (например, ICMP), что также отражено на приведенном рисунке 1.10.

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

1.2. Протокол IPv6

В конце 1992 года сообщество Интернет для решения проблем адресного пространства и ряда смежных задач разработало три проекта протоколов: "TCP and UDP with Bigger Addresses (TUBA)"; "Common Architecture for the Internet (CatnIP)" и "Simple Internet Protocol Plus (SIPP) с длинами адресов 40-64 бит. После анализа всех этих предложений был принят новый протокол IPv6 с IP-адресами в 128 бит вместо 32 для IPv4. Внедрение этого нового протокола представляет отдельную серьезную проблему, так как этот процесс не предполагает замены всего программного обеспечения во всем мире одновременно (более подробное описание см. http://book.itep.ru/4/44/ip6_4411.htm).

Одной из причин появления новой версии протокола называется ограниченность множества адресов. В действительности 232 > 4 миллиардов, не так уж много, если принимать во внимание, что уже сегодня в Интернет около 1 миллиарда сетевых объектов. Если учитывать широко используемую технику классов IP-адресов, то свободного адресного пространства уже почти не осталось. Можно задаться вопросом, почему 32 разряда адреса заменили в новом стандарте на 128?

В действительности, для того, чтобы обеспечить все человечество Земли (да и всех прочих живых существ на планете), хватило бы с большим запасом 64-битного адреса. Кто-то посчитал, что 2128 больше числа молекул в нашей галактике. Есть повод подумать, что это слишком большое число. На самом деле принятое решение вполне обосновано.

Во-первых, это облегчило совместное существование традиционных 32- и новых 128-битных адресов, во-вторых, открыло возможность упрощенной схемы установление соответствия между IP- и Ethernet-адресами, и, пожалуй, самое важное, – дало шанс введения географической системы адресации. Идея географической адресации достаточно проста. Сначала выделяются равные диапазоны адресов для каждого из континентов (в Антарктиде используется всего несколько сотен адресов, а в Северной Америке — несколько сот миллионов). Далее каждый из диапазонов делится по числу стран, по числу областей, городов, кварталов… Такое деление позволит строить маршрутизаторы, где просмотр таблицы маршрутизации будет предполагать всего десяток-полтора сравнений, что на порядки меньше, чем сейчас.

При глобальном внедрении адресации IPv6 можно ожидать существенного снижения стоимости маршрутизаторов и сокращения значений RTT.

Теперь посмотрим, чем отличается IPv6 от IPv4, не считая длины адресов.

Важным преимуществом IPv6 является идея "следующего заголовка". Так как в IPv4 в IP-дейтаграмму можно вложить UDP, TCP или ICMP, возникает проблема идентификации и обработки заголовков, вложенных, например, в сегмент TCP.

Формат и семантика адресов IPv6 описаны в документе RFC-1884. Версия ICMP IPv6 рассмотрена в RFC-1885.

В документе RFC-2460, который появился спустя три года после RFC-1883, поле приоритет заменено на поле класс трафика. Это поле имеет 8 бит (против 4 в поле приоритет). При этом размер поля метка потока сократился до 20 бит. Это было продиктовано требованиями документа RFC-2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", ориентированного на решение задач управления QoS.

В протоколе IPv6 существует три типа адресов (таблица 1.3.1.):

В IPv6 не существует широковещательных адресов, их функции переданы мультикастинг-адресам.

Существует три стандартные формы для представления IPv6 адресов в виде текстовых строк.

fedc:ba98:7654:3210:FEDC:BA98:7654:3210 или
1080:0:0:0:8:800:200C:417A

может быть представлено в виде (таблица 1.3.3.).

Альтернативной формой записи, которая более удобна при работе с IPv4 и IPv6, является x:x:x:x:x:x:d.d.d.d, где 'x' — шестнадцатеричные 16-битовые коды адреса, а 'd' — десятичные 8-битовые, составляющие младшую часть адреса (стандартное IPv4 представление). Например:

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

Специфический тип IPv6 адресов идентифицируется лидирующими битами адреса. Поле переменной длины, содержащее эти лидирующие биты, называется префиксом формата (Format Prefix — FP). Исходное назначение этих префиксов представлено в табл. 1.4.

Замечание: Не специфицированные адреса, адреса обратной связи и IPv6 адреса со встроенными IPv4 адресами определены вне "0000 0000" префиксного пространства.

Данное распределение адресов поддерживает прямое выделение адресов провайдера, адресов локального применения и мультикастинг-адресов. Зарезервировано место для адресов NSAP, IPX и географических адресов. Оставшаяся часть адресного пространства зарезервирована для будущего использования. Эти адреса могут использоваться для расширения имеющихся возможностей (например, дополнительных адресов провайдеров и т.д.) или новых приложений (например, отдельные локаторы и идентификаторы).

Уникастные адреса отличаются от мультикастных значением старшего октета: значение FF (11111111) идентифицирует мультикастинг-адрес; любые другие значения говорят о том, что адрес уникастный. Эникастные (anycast) адреса берутся из уникастного адресного пространства и синтаксически неотличимы от них.

1.2.1. Уникастные адреса

IPv6 уникастные адреса сходны с традиционными IPv4 адресами при бесклассовой междоменной маршрутизации (Classless InterDomain Routing — CIDR).

Существует несколько форм присвоения уникастных адресов в IPv6, включая глобальный уникастный адрес провайдера (global provider based unicast address), географический уникастный адрес, NSAP адрес, IPX иерархический адрес, Sitelocaluse адрес, Linklocaluse адрес и совместимый с IPv4-адрес ЭВМ. В будущем могут быть определены дополнительные типы адресов.

Узлы IPv6 могут иметь существенную или малую информацию о внутренней структуре IPv6 адресов, в зависимости от выполняемой узлом роли, (например, ЭВМ или маршрутизатор). Как минимум, узел может считать, что уникастный адрес (включая его собственный адрес) не имеет никакой внутренней структуры, то есть представляет собой 128 битовый неструктурированный образ.

ЭВМ может дополнительно знать о префиксе субсети для каналов, c которыми она соединена, где различные адреса могут иметь разные значения n:

Машины могут использовать и другие иерархические границы в уникастном адресе. Хотя простейшие маршрутизаторы могут не знать о внутренней структуре IPv6 уникастных адресов, маршрутизаторы должны знать об одной или более иерархических границах для обеспечения работы протоколов маршрутизации. Известные границы для разных маршрутизаторов могут отличаться и зависят от того, какое положение занимает данный прибор в иерархии маршрутизации.

Примером уникастного адресного формата, который является стандартным для локальных сетей и других случаев, где применимы MAC адреса, может служить:

Здесь 48-битовый идентификатор интерфейса представляет собой IEEE-802 MAC адрес. Использование IEEE 802 MAC адресов в качестве идентификаторов интерфейсов будет стандартным в среде, где узлы имеют IEEE 802 MAC адреса. В других средах, где IEEE 802 MAC адреса недоступны, могут использоваться другие типы адресов связного уровня, такие, как E.164 адреса, в качестве идентификаторов интерфейсов.

Включение уникального глобального идентификатора интерфейса, например, IEEE MAC адреса, делает возможным очень простую форму авто-конфигурации адресов. Узел может узнать идентификатор субсети, получая информацию от маршрутизатора в виде сообщений оповещения, которые маршрутизатор посылает связанным с ним партнерам, и затем сформировать IPv6 адрес для себя, используя IEEE MAC адрес в качестве идентификатора интерфейса для данной субсети.

Другой формат уникастного адреса относится к случаю, когда локальная сеть или организация нуждаются в дополнительных уровнях иерархии. В этом примере идентификатор субсети делится на идентификатор области и идентификатор субсети. Формат такого адреса имеет вид (рис. 1.13):

Эта схема может быть развита с тем, чтобы позволить локальной сети или организации добавлять новые уровни внутренней иерархии. Может быть, желательно использовать идентификатор интерфейса, меньший, чем 48-разрядный IEEE 802 MAC адрес, с тем, чтобы оставить больше места для полей, характеризующих уровни иерархии. Это могут быть идентификаторы интерфейсов, сформированные администрацией локальной сети или организации.

Адрес 0:0:0:0:0:0:0:0 называется не специфицированным адресом. Он не должен присваиваться какому-либо узлу, поскольку лишь указывает на отсутствие адреса. Примером использования такого адреса может служить поле адреса отправителя любой IPv6 дейтаграммы, посланной инициализируемой ЭВМ до того, как она узнала свой адрес.

Не специфицированный адрес не должен использоваться в качестве указателя места назначения IPv6 дейтаграмм или в IPv6 заголовках маршрутизации.

Уникастный адрес 0:0:0:0:0:0:0:1 называется адресом обратной связи. Он может использоваться компьютером для посылки IPv6 дейтаграмм самому себе. Этот адрес нельзя использовать в качестве идентификатора интерфейса.

Адрес обратной связи не должен применяться в качестве адреса отправителя в IPv6 дейтаграммах, которые посылаются за пределы узла.

1.2.2. IPv6 адреса с вложенными IPv4 адресами

Алгоритмы IPv6 включают в себя механизм (для ЭВМ и маршрутизаторов) организации туннелей для IPv6 пакетов через маршрутную инфраструктуру IPv4. Узлам IPv6, которые используют этот метод, присваиваются специальные IPv6 уникастные адреса, которые в младших 32 битах содержат адрес IPv4. Этот тип адреса называется "IPv4-compatible IPv6 address" и имеет формат, изображенный на рис. 1.14:

Определен и второй тип IPv6 адреса, который содержит внутри IPv4 адрес. Этот адрес используется для представления IPv6 адресов узлам IPv4 (тем, что не поддерживают IPv6). Этот тип адреса называется "IPv4-mapped IPv6 address" и имеет формат, показанный на рис. 1.15:

1.2.3. Провайдерские глобальные уникаст-адреса

Глобальный уникаст-адрес провайдера имеет назначение, описанное в [ALLOC]. Исходное назначение этих уникаст-адресов аналогично функции IPv4 адресов в схеме CIDR [см. CIDR]. Глобальный IPv6 уникаст-адрес провайдера имеет формат, отображенный ниже на рис. 1.16:

Старшая часть адреса предназначена для указания, кто определяет часть адреса провайдера, подписчика и т.д.

Идентификатор регистрации определяет регистратора, который задает провайдерскую часть адреса. Термин "префикс регистрации" относится к старшей части адреса, включая поле ID регистрации.

Идентификатор провайдера задает специфического провайдера, который определяет часть адреса подписчика. Термин "префикс провайдера" относится к старшей части адреса включая ID провайдера.

Идентификатор подписчика позволяет разделить подписчиков, подключенных к одному и тому же провайдеру. Термин "префикс подписчика" относится к старшей части адреса, включая ID подписчика.

Часть адреса интра-подписчик определяется подписчиком и организована согласно местной топологии Интернет-подписчика. Возможно, что несколько подписчиков пожелают использовать область адреса интра-подписчик для одной и той же субсети и интерфейса. В этом случае идентификатор субсети определяет специфический физический канал, а идентификатор интерфейса — определенный интерфейс субсети.

1.2.4. Локальные уникаст-адреса IPv6

Существует два типа уникастных адресов локального использования. Имеется локальные адреса сети и канала. Локальный адрес канала предназначен для работы с одним каналом, а локальный адрес сети — с одной локальной сетью (site). Локальный IPv6 уникаст-адрес канала имеет формат, отображенный ниже на рис. 1.17:

Локальные адреса канала предназначены для обращения через определенный канал, например, для целей автоконфигурации адресов, поиска соседей или в случае отсутствия маршрутизатора. Маршрутизаторы не должны переадресовывать пакеты с локальными адресами отправителя. Локальный адрес сети имеет формат, показанный на рис. 1.18:

Локальные адреса сети могут использоваться для локальных сетей или организаций, которые (пока еще) не подключены к глобальному Интернет. Им не нужно запрашивать или "красть" префикс адреса из глобального адресного пространства Интернет. Вместо этого можно использовать локальный адрес сети IPv6. Когда организация соединяется с глобальным Интернет, она может сформировать глобальные адреса путем замещения локального префикса сети префиксом подписчика.

Маршрутизаторы не должны переадресовывать пакеты с локальными адресами сети отправителя.

1.2.5. Эникаст-адреса

Эникаст-адрес IPv6 является адресом, который приписан нескольким интерфейсам (обычно принадлежащим разным узлам); при этом пакет, посланный по эникастному адресу, будет доставлен ближайшему интерфейсу в соответствии с метрикой протокола маршрутизации.

Эникастные адреса выделяются из уникастного адресного пространства и используют один из известных уникастных форматов. Таким образом, эникастные адреса синтаксически неотличимы от уникастных адресов. Когда уникастный адрес приписан более чем одному интерфейсу, он превращается в эникастный адрес, и узлы, которым он приписан, должны быть сконфигурированы так, чтобы распознавать этот адрес.

Для любого эникастного адреса существует адресный префикс P, который определяет топологическую область, где находятся все соответствующие ему интерфейсы. В пределах области, заданной P, каждый член эникастной (anycast) группы должен быть объявлен как отдельный вход в маршрутной системе; вне области, заданной P, эникастный адрес может быть занесен в маршрутную запись для префикса p.

Заметим, что в худшем случае префикс P эникастной группы (anycast set) может быть нулевым, т.e., члены группы могут не иметь никакой топологической локальности. В этом случае эникастный адрес должен объявляться как отдельная маршрутная запись (separate routing entry) по всему Интернет, что представляет собой серьезное ограничение, так как число таких глобальных эникастных адресов не может быть большим.

Одним ожидаемым приложением эникастных адресов является идентификация набора маршрутизаторов, принадлежащих Интернет сервис провайдеру. Такие адреса в маршрутном заголовке IPv6 могут использоваться в качестве промежуточных, чтобы обеспечить доставку пакета через определенного провайдера или последовательность провайдеров. Другим возможным приложением может стать идентификация набора маршрутизаторов, связанных с определенной субсетью, или набора маршрутизаторов, обеспечивающих доступ в определенный домен.

Существует ограниченный опыт широкого применения эникастных Интернет адресов, некоторые возможные осложнения и трудности рассмотрены в [anycst]. Имеются следующие ограничения при использовании эникастных IPv6 адресов:

Необходимые эникаст-адреса

Эникаст-адрес маршрутизатора субсети предопределен и имеет формат, отображенный на рис. 1.19:

Префикс субсети в эникастном адресе является префиксом, который идентифицирует определенный канал. Этот эникастный адрес является синтаксически идентичным уникастному адресу для интерфейса канала с идентификатором интерфейса, равным нулю.

Пакеты, посланные группе маршрутизаторов с эникастным адресом, будут доставлены всем маршрутизатам субсети. При этом все маршрутизаторы субсети должны поддерживать работу с эникастными адресами. Реальный обмен будет осуществлен лишь с тем маршрутизатором, который ответит первым.

Эникастный адрес маршрутизатора субсети предполагается использовать в приложениях, где необходимо взаимодействовать с одним из совокупности маршрутизаторов удаленной субсети — например, когда мобильный хост хочет взаимодействовать с одним мобильным агентом в его "домашней" субсети.

1.2.6. Мульткаст-адреса

Мультикастинг-адрес IPv6 является идентификатором для группы узлов. Узел может принадлежать к любому числу мультикастинг-групп. Мультикастинг-адреса имеют следующий формат (рис. 1.20рис. ):

11111111 в начале адреса идентифицирует адрес как мультикатинг-адрес.

Старшие 3 флага зарезервированы и должны быть обнулены.

T = 0 указывает на то, что адрес является стандартным (wellknown) мультикастным, официально выделенным для глобального использования в Интернет.

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 дейтаграммах или встречаться в любых заголовках маршрутизации.

Предопределенные мультикаст-адреса

Приведенные ниже мультикаст-адреса являются зарезервированными (предопределенными):

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/relayagent: FF02:0:0:0:0:0:0:C

Приведенные выше мультикастинг-адреса идентифицируют группу всех IPv6 DHCP серверов и транзитных агентов в пределах области 2 (локальный канал).

Адрес активного узла (solicitednode): FF02:0:0:0:0:1:xxxx:xxxx

Приведенный выше мультикаст-адрес вычислен как функция уникастного и эникастного адресов узла. Мультикаст-адрес активного узла (solicitednode) сформирован из младших 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 адреса, которые отличаются только старшими разрядами, например, из-за множественных старших префиксов, соответствующих разным провайдерам, будут совпадать с адресом активного узла, что сокращает число мультикаст-групп, к которым узел должен присоединиться.

1.2.7. Заголовки расширения IPv6

В IPv6, опционная информация уровня Интернет записывается в отдельных заголовках, которые могут быть помещены между IPv6 заголовком и заголовком верхнего уровня пакета. Существует небольшое число таких заголовков, каждый задается определенным значением кода поля следующий заголовок. В настоящее время определены заголовки: маршрутизации, фрагментации, аутентификации, инкапсуляции, опций hop-by-hop, места назначения и отсутствия следующего заголовка. Как показано в примерах ниже, IPv6 пакет может нести нуль, один или более заголовков расширения, каждый задается предыдущим полем следующий заголовок (рис. 1.22):

Заголовки расширения не рассматриваются и не обрабатываются узлами по пути доставки. Содержимое и семантика каждого заголовка расширения определяет, следует или нет обрабатывать следующий заголовок. Следовательно, заголовки расширения должны обрабатываться строго в порядке их выкладки в пакете. Получатель, например, не должен просматривать пакет, искать определенный тип заголовка расширения и обрабатывать его до обработки предыдущих заголовков.

Единственное исключение из этого правила касается заголовка опций hop-by-hop, несущего в себе информацию, которая должна быть рассмотрена и обработана каждым узлом по пути следования, включая отправителя и получателя. Заголовок опций hop-by-hop, если он присутствует, должен следовать непосредственно сразу после IPv6-заголовка. Его присутствие отмечается записью нуля в поле следующий заголовок.

Если в результате обработки заголовка узлу нужно перейти к следующему заголовку, а код поля следующий заголовок не распознается, необходимо игнорировать данный пакет и послать соответствующее сообщение ICMP (parameter problem message) отправителю пакета. Это сообщение должно содержать код ICMP = 2 ("unrecognized next header type encountered" — встретился нераспознаваемый тип следующего заголовка ) и поле — указатель на неузнанное поле в пакете. Аналогичные действия следует предпринять, если узел встретил код следующего заголовка, равный нулю в заголовке, отличном от IPv6-заголовка.

Каждый заголовок расширения имеет длину, кратную 8 октетам. Многооктетные поля в заголовке расширения выравниваются в соответствии с их естественными границами, т.е. поля с шириной в n октетов помещаются в n октетов, начиная с начала заголовка, для n = 1, 2, 4 или 8.

1.2.8. Отсутствие следующего заголовка

В заголовке, за которым следует поле данных, в поле следующий заголовок IPv6 записывается код 59. Если поле длина данных заголовка IPv6 указывает на присутствие октетов после конца заголовка, содержащего код 59 в поле следующий заголовок, эти октеты должны быть проигнорированы и переданы без изменений при переадресации пакета.

1.2.9. О размере пакетов

Как уже было замечено выше, протокол IPv6 требует, чтобы каждый канал в Интернет имел MTU = 576 октетов или более. Для каждого канала, который не способен обеспечить длину пакетов в 576 октетов, должна быть обеспечена фрагментация/дефрагментация на уровне ниже IPv6.

Для каждого канала, с которым связан узел непосредственно, он должен быть способен принимать пакеты с размером MTU данного канала. В каналах, которые можно конфигурировать, например, PPP [RFC-1661], должно быть установлено MTU не менее 576 октетов; рекомендуется устанавливать максимально возможное MTU, чтобы позволить инкапсуляцию (туннелирование) без привлечения фрагментации.

Настоятельно рекомендуется, чтобы узлы IPv6 использовали механизм определения MTU пути [RFC-1191] для реализации преимущества большого значения MTU. Однако в минимальной конфигурации IPv6 (например, в BOOT ROM) может ограничивать себя в пределах 576 октетов и не применять процедуру выявления MTU пути.

Для того чтобы послать пакет длиннее, чем 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, которое следует использовать.

1.2.10. Метки потоков

24-битовое поле метки потока в заголовке IPv6 может использоваться отправителем для выделения пакетов, для которых требуется специальная обработка в маршрутизаторе, такая, например, как нестандартная QoS или realtime сервис. Этот аспект 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 секундам. Метки потока, которые применяются для потоков, существующих более продолжительное время, не должны использоваться дольше.

Когда узел останавливает или перезапускает процесс (например, в случае сбоя), он должен позаботиться о том, чтобы метка потока была уникальной и не совпадала с другой, еще действующей меткой. Это может быть сделано путем записи используемых меток в стабильную память, так, чтобы ею можно было воспользоваться даже после серьезного сбоя в системе. Если известно минимальное время перезагрузки системы (время перезагрузки обычно больше 6 секунд), это время можно использовать для задания времени жизни меток потоков.

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

1.2.11. Приоритет

4-битовое поле приоритета в IPv6 заголовке позволяет отправителю идентифицировать относительный приоритет доставки пакетов. Значения приоритетов делятся на два диапазона. Коды от 0 до 7 используются для задания приоритета трафика, для которого отправитель осуществляет контроль перегрузки (например, снижает поток TCP в ответ на сигнал перегрузки). Значения с 8 до 15 используются для определения приоритета трафика, для которого не производится снижения потока в ответ на сигнал перегрузки, например, в случае пакетов реального времени, посылаемых с постоянной частотой.

Для трафика, управляемого сигналами перегрузки, рекомендуются следующие значения приоритета для конкретных категорий приложений (см. таблицу 1.5).

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

Для трафика, не контролируемого на перегрузки, нижнее значение приоритета (8) должно использоваться для тех пакетов, которые отправитель разрешает выбросить в случае перегрузки (например, видеотрафик высокого качества), а высшее значение (15) следует использовать для пакетов, которые отправитель не хотел бы потерять (например, аудиотрафик с низкой надежностью). Не существует связи между относительными приоритетами обменов с и без контроля перегрузки.

1.3. IP-туннели

IP-туннелем называется прием, когда IP-дейтаграмма, адресованная по адресу IP1, вкладывается в IP-пакет, адресованный IP2. Устройство адресат (IP2) должно иметь программу, которая извлекает из поля данных дейтаграмму и направляет ее по адресу IP1. Техника IP-туннелей может оказаться иногда полезной при администрировании маршрутизации, так как метрика внешних протоколов маршрутизации может не учитывать пропускную способность каналов и некоторые другие факторы, например, QoS. В этом случае IP-дейтаграммы вкладываются в IP-дейтаграммы отправителем (начало туннеля) и извлекаются оттуда в конце туннеля. Конец туннеля не обязательно совпадает с конечным местом назначения пакетов. Такая простая схема туннелирования может порождать некоторые проблемы (см. рис. 1.23).

Из рисунка видно, что простой туннель может породить асимметричный маршрут, при котором пути туда и обратно не совпадают. Чтобы такого не произошло, применяется техника "маскарада" (masquerading). Для этого "маршрутизатор конца туннеля" должен извлечь вложенный пакет (как это он делает и на рис. 1.23) и вложить его в пакет с адресом места назначения IP3, указав при этом в качестве отправителя себя (IP3/IP2[IP3/IP1]). Тогда конечный адресат IP3 будет посылать отклики по адресу IP2, а не IP1. А уже маршрутизатор конца туннеля будет пересылать их первоисточнику запроса IP1.

В последнее время техника туннелей нашла применение при построении так называемых прокси-серверов, популярность которых связана с возможностью заметно сократить внешний (часто зарубежный) трафик за счет запоминания в дисковом буфере файлов, наиболее часто запрашиваемых клиентами. Заметно упрощает решение данной задачи многие современные маршрутизаторы, которые могут отфильтровывать запросы по определенным портам и переадресовывать их прокси-серверу (см. рис. 1.24).

Схема с "невидимым" прокси-сервером работает следующим образом. Сначала запрос поступает в маршрутизатор, там он анализируется и, если выясняется, что это HTTP или FTP-запросы, переадресуется прокси-серверу. Если запрашиваемый файл находится в буфере сервера, заказ клиента удовлетворяется локально. В противном случае запрос снова посылается маршрутизатору. Запросы прокси-сервера маршрутизатор переправляет во внешнюю сеть. В случае использования персональной ЭВМ в качестве прокси-сервера можно ее снабдить двумя сетевыми интерфейсами для приема и посылки запросов, что сделает работу более эффективной. Если маршрутизатор не поддерживает описанный режим, то при конфигурации сетевого программного обеспечения клиента можно явно прописать адрес прокси-сервера, и все соответствующие запросы пойдут непосредственно туда.

Туннели широко применяются и при передаче мультимедийных данных. Идеи прокси широко используются в межсетевых экранах (Firewall).

Технология IP-туннелей находит применение и при построении корпоративных сетей, которые иногда называют Интранет.