 |
IPv6-адреса с вложенными IPv4-адресами
|
|
|
|
Для содействия успешному переходу от IPv4 к IPv6 были разработаны два механизма туннелирования IPv6-пакетов поверх инфраструктуры IPv4. В одном из методов узлам IPv6 присваиваются специальные IPv6 адреса одноадресной рассылки, которые в младших 32 битах содержат адрес IPv4. Такой тип адреса, называемый IPv4-совместимый адресом IPv6, в котором нули составляют все поля, за исключением младших 32 битов соответствующих IPv4-адресу, изображен на Рисунке 9-4. Во втором методе внутри IPv6-адреса содержится IPv4-адрес. Этот тип адреса используется для представления адресов-IPv6 узлам IPv4 (которые не поддерживают IPv6). Этот тип адреса называется "IPv4-отбражаемым адресом IPv6". В отличие от первого метода, 16-битное значение FFFF предшествующее 32-битному адресу IPv4 указывает на данный тип адреса.
Рисунок 9-4 - IPv6-адрес с вложенным IPv4-адресом
Адреса рассылки до первого получателя
Адреса рассылки до первого получателя структурно идентичны другим адресам одноадресной рассылки и выдаются из пула доступных адресов одноадресной рассылки в данной организации. Однако, в некоторых случаях предпочтительно применять адреса рассылки до первого получателя вместо того, чтобы использовать адрес одноадресной рассылки, назначенный конкретному узлу. Адреса рассылки до первого получателя назначаются группе узлов, которые обычно являются маршрутизаторами в сайте. Каждому из маршрутизаторов назначается одинаковый адрес, который определяется в качестве адреса рассылки до первого получателя.
Когда узлу-источнику необходимо отправить пакет на этот адрес, будет использоваться механизм поиска ближайшего узла, которому назначен данный адрес. Таким образом, узлу-источнику не нужно знать, какой адрес является адресом рассылки до первого получателя, и последовательное взаимодействие произойдет только между узлом-источником и ближайшим маршрутизатором, настроенным на использование адреса рассылки до первого получателя.
|
|
|
В соответствии с документами RFC 2373 и 2526, адреса рассылки до первого получателя на данный момент имеют ряд ограничений и являются предметом дальнейших исследований.
Групповые адреса
Как определено в RFC 2373 и 2375, групповые адреса используются в IPv6 для группового потока данных и заменяют широковещательные адреса в IPv6. Групповой адрес назначается группе узлов, но в отличие от адреса рассылки до первого получателя, все узлы, с назначенным групповым адресом, получат пакеты, отправленные на этот адрес. Узел может входить более чем в одну группу, кроме того, узлы не могут использовать групповой адрес в качестве адреса источника пакета, а также групповые адреса не могут быть использованы в заголовках маршрутизации. На Рисунке 9-5 изображен формат группового адреса IPv6.
Дополнительная информация. О групповых адресах и IPv6-трафике читайте в RFC 2373 и 2375
Рисунок 9-5 - Формат группового адреса IPv6
В Таблице 9-2 описаны поля группового адреса.
Таблица 9-2
| Сокращение | Поле | Длина | Характеристика |
| FP | Префикс формата | 8 бит | Значение «11111111» (или FF в шестнадцатеричной системе исчисления) указывает, что это групповой адрес |
| Flgs | Флаги | 4 бита | Первые 3 бита этого поля зарезервированы и должны иметь значение «0». Если четвертый бит имеет значение «0», это указывает на постоянно назначенный групповой адрес; если имеет значение «1», то этот групповой адрес временный, или не назначен Агентством по выделению имен и уникальных параметров Интернет (Internet Assigned Numbers Authority, IANA). |
| Scop | Область | 4 бита | Значение области ограничивает область действия группы. Значения «0» и «F» зарезервированы; могут быть использованы следующие значения: «1» - область локального узла; «2» - область локальной связи; «5» - область локального сайта; «8» - область локальной организации; «Е» - глобальная область; другие значения в настоящее время не используются. |
| Group ID | Группа | 112 бит | Это уникальный идентификатор для данной многоадресной группы, которая будет принимать пакеты, отправленные на этот адрес. |
Например, следующие групповые адреса используются для адресации пакетов для групп маршрутизаторов:
|
|
|
FF01:0:0:0:0:0:0:2 область локального узла; все маршрутизаторы. Этот адрес идентифицирует все маршрутизируемые интерфейсы в одном узле.
FF02:0:0:0:0:0:0:2 область локальной связи; все маршрутизаторы. Этот адрес идентифицирует все маршрутизаторы в одной связи.
FF05:0:0:0:0:0:0:2 область локального сайта; все маршрутизаторы. Этот адрес идентифицирует все маршрутизаторы в сайте.
Обнаружение соседа (neighbor discovery)
Термин «обнаружение» может ввести в заблуждение, так как узлы используют механизмы как для информирования других узлов о своем присутствии в сети, так и для определения параметров, таких как расположение узла, доступность маршрутизаторов, MTU канала и конфигурация адреса. Хотя основные механизмы обнаружения изложены в RFC 2461, некоторые методы обнаружения являются специфичными для конкретных типов связей. Механизмы обнаружения часто реализованы аналогично групповой рассылке и заменяют такие функции IPv4 как ARP (протокол преобразования адресов), IRDP (протокол анализа ICMP-маршрутизаторов), IGMP (межсетевой протокол управления группами) и перенаправление ICMP.
Методы обнаружения маршрутизаторов
Механизм обнаружения используется маршрутизаторами для различных целей. Маршрутизаторы применяют групповую рассылку сообщений Объявление маршрутизатора (Router Advertisement), через регулярные промежутки времени и при ответе на запросы Ходатайство маршрутизатора (Router Solicitation). Сообщения объявление маршрутизатора включают в себя следующую информацию, необходимую для конфигурирования узлов: адреса маршрутизаторов уровня связи; префиксы связи (соответствующие маски подсети в IPv4); MTU связи; рекомендуемое ограничение переходов.
Каждый маршрутизатор, объявляя свой физический адрес, тем самым позволяет другим узлам в сети определить наличие маршрутизатора. Объявляя префикс связи маршрутизатор, позволяет узлам определить, к какой подсети они подключены, и таким образом построить внутреннюю таблицу маршрутизации. В IPv6-пакете с каждым переходом уменьшается значение количества переходов, хранящееся в поле Предел переходов (Hop Limits), а не время жизни пакета (TTL). Отправляя рекомендуемое ограничение переходов в поле Предел переходов (Hop Limits), маршрутизатор помогает узлам определить, доступен ли пункт назначения по данному маршруту. К тому же, для правильного функционирования многоадресной рассылки все узлы, использующие одну связь, должны использовать одинаковое значение MTU.
|
|
|
Используя сообщения Объявление маршрутизатора, маршрутизаторы также могут быть сконфигурированы для распределения входящей нагрузки. Маршрутизаторы могут иметь несколько интерфейсов, подключенных к одной связи. Конечно, эти интерфейсы могут быть представлены в виде одного интерфейса с несколькими адресами, а маршрутизатор может не включать исходящие адреса в сообщение Объявление маршрутизатора. В таком случае хосты ожидающие отправки пакетов на маршрутизатор будут использовать запрос Ходатайство соседа (Neighbor Solicitation) для получения адреса интерфейса маршрутизатора. Маршрутизатор может отправлять различные адреса в ответах на запросы, отправленные различными хостами. Все хосты будут предполагать, что они отправляют пакеты на единственный интерфейс с несколькими адресами, в действительности же маршрутизатор может таким образом разделять входящий трафик между всеми подключенными интерфейсами.
Обнаружение хоста
Хосты используют механизмы обнаружения в основном, как исследовательский инструмент, хотя они будут также отвечать на запросы, информируя о своей собственной конфигурации. При инициализации хост может отправить запрос маршрутизатору для определения способа конфигурирования собственного адреса: либо с возможностью изменить собственный адрес во время работы, либо без возможности изменения. Автоконфигурирование с возможностью динамического назначения адреса используется при выдаче адреса хосту посредством службы DHCP.
|
|
|
Как описано в RFC 2462, автоконфигурирование без возможности изменения адреса разрешено хостам при самостоятельном назначении адреса, с помощью рассылки пакетов для выяснения того, используется ли данный адрес другими узлами в связи, и конфигурировании остальных параметров связи или сайта на основе информации, полученной хостом в сообщение Объявление маршрутизатора.
Дополнительная информация. Автоконфигурирование без возможности изменения адреса описано в RFC 2462.
Если узлу необходимо взаимодействовать с другим узлом, он отправляет сообщение Neighbor Solicitation (ходатайство соседа) на специальный адрес, называемый Целевым адресом ходатайствующего узла для многоадресной рассылки (solicited node multicast address) с целью анализа соседа на уровне связи. Узел-отправитель включает в это сообщение Ходатайства соседа (Neighbor Solicitation) свой собственный адрес уровня связи, чтобы узел-получатель мог кэшировать результаты, что исключает необходимость отправки встречного запроса узлом-получателем аналогичного ходатайства. В ответ на запрос узел-получатель отправит сообщение Объявление соседа (Neighbor Advertisement), включающее свой собственный адрес уровня связи.
Когда между двумя узлами установлено взаимодействие, каждый узел полагается на протоколы верхнего уровня для подтверждения того, что пакеты были успешно отправлены или получены. Если такое подтверждение отсутствует, для определения функционирования соседнего узла данный узел решает задачу, называемую Обнаружение недостижимости соседа (Neighbor Unreachability Detection), отправляя одноадресный запрос Ходатайства соседа непосредственно на этот узел. Если двухстороннее соединение не будет подтверждено, узел перестанет отправлять пакеты на недоступный адрес.
Дополнительная информация. В документе RFC 2463 описан механизм обработки ошибок протоколом ICMP, используемый в IPv6.
В случае изменения адреса уровня связи узла, будет разослано многоадресное сообщение Объявление соседа для извещения о своих изменениях другим узлам в сети. Другие узлы, получив данное сообщение, смогут обновить в кэше информацию об адресах уровня связи узла, и, следовательно, уменьшить вероятность неудачных попыток установки связи с недостижимым узлом.
Формат заголовка IPv6 и механизмы маршрутизации
Информация об адресах в IPv6 составляет только часть заголовка каждого пакета. Оставшаяся часть заголовка пакета IPv6 содержит информацию, необходимую узлам для эффективной оценки и обработки каждого пакета. На Рисунке 9-6 изображен общий формат заголовка пакета IPv6.
|
|
|
Рисунок 9-6 - Общий формат заголовка пакета IPv6
В Таблице 9-3 описаны поля заголовка пакета IPv
Таблица 9-3
| Поле | Длина | Характеристика |
| Версия (Version) | 4 бита | Значение «0110» указывает на версию 6. |
| Класс трафика (Traffic Class) | 8 бит | Используется при идентификации класса или приоритета трафика, для того чтобы пакеты могли быть перенаправлены с другими приоритетами для обеспечения QoS |
| Метка потока (Flow Label) | 20 битов | Пакеты, которые соответствуют определенному классу потока, помечаются для определения принадлежности этому потоку. |
| Длина полезной нагрузки (Payload Length) | 16 битов | Длина в октетах оставшейся части пакета, включающей в себя дополнительные заголовки. |
| Следующий заголовок (Next Header) | 8 битов | Определяет тип заголовка, следующего сразу после заголовка IPv6 используются те же значение, что и в поле протокола IPv4 (RFC 1700). |
| Предел переходов (Hop Limit) | 8 битов | Число связей, через которое пакет может быть передан пока не будет отброшен. Каждая пересылка уменьшает значение этого поля на 1. |
| Адрес отправителя (Source Address) | 128 битов | Адрес узла отправителя. |
| Адрес назначения (Destination Address) | 128 битов | Адрес узла назначения, который может быть либо окончательным получателем или промежуточным узлом. |
Помимо основного заголовка пакет IPv6 может содержать один или несколько дополнительных заголовков, которые используются для предоставления дополнительной информации о пакете, например информации о маршрутизации, информации о фрагментации пакета, и информации о следующем переходе в маршруте, определенной отправителем. При наличии дополнительного заголовка, называемого дополнительным заголовком Hop-by-Hop, узлы, участвующие в передаче пакета, не обрабатывают эти заголовки, и только узел назначения, определенный в пакете (либо узел окончательного назначения, либо узел промежуточного назначения) должен проанализировать и обработать все дополнительные заголовки. Каждый дополнительный заголовок имеет длину, кратную 8 октетам, что позволяет выровнять пакет и избавить от необходимости обработки дополнительных заголовков узлами при передаче пакета.
На Рисунке 9-7 изображена структура пакета IPv6, содержащего дополнительные заголовки.
Рисунок 9-7 - Дополнительные заголовки IPv6
Количество дополнительных заголовков в пакете может быть различным: могут присутствовать либо все заголовки, либо только некоторые, либо вообще отсутствовать. Дополнительные заголовки должны располагаться в порядке, изображенном на Рисунке 9-7.
Каждый дополнительный заголовок может встречаться в пакете только один раз, за исключением заголовка Параметры назначения (Destination Options), который может быть использован дважды: первый раз он используется перед заголовком Маршрутизации (Routing) и применяется к каждому из переходов, указанных в заголовке Маршрутизации, второй раз он присутствует как последний заголовок и применяется только в точке назначения.
Дополнительные заголовки всех типов используют поле Следующий заголовок, которое имеет длину 8 битов и определяет тип следующего заголовка. Значение «59» в этом поле, указывает на завершение последовательности заголовков.
Дополнительный заголовок Hop-by-Hop
Каждый узел, принимающий участие в передаче пакета, должен проанализировать заголовок Hop-by-Hop, формат которого изображен на Рисунке 9-8. Значение «0 «в поле Следующий заголовок предыдущего заголовка указывает на тип заголовка Hop-by-Hop. Несколько опций, указанных в заголовке и определяющих действия, выполняемые на промежуточных переходах по маршруту следования, должны быть обработаны по порядку. Поле Следующий заголовок определяет следующий далее заголовок, как описано выше. Поле Длина дополнительного заголовка (Header Extension Length) определяет длину этого дополнительного заголовка в октетах. Поле Тип действия (Option Type) длиной 8 битов указывает, какое действие должно быть выполнено узлом. В соответствии с этим полем узел может отбросить пакет, пропустить действие и продолжить обработку оставшейся части заголовка или отправить ICMP сообщение Нераспознанный тип действия (Unrecognized Option Type) на адрес отправителя.
Рисунок 9-8 - Формат заголовка Hop-by-Hop.
Заголовок Destination Options
Заголовок Опции узла назначения (Destination Options) практически идентичен заголовку Hop-by-Hop, за исключением того, что он не будет проанализирован промежуточными узлами по маршруту следования пакета, а будет проанализирован только узлом назначения. Значение «60» в поле Следующий заголовок предыдущего заголовка указывает на тип заголовок Опции узла назначения.
Рисунок 9-9 - Формат заголовка Destination Options
Заголовок Маршрутизации (Routing)
В протоколе IPv6 узел-отправитель может определить одну или несколько остановок пакета по пути его следования. Значение «43» в поле Следующий заголовок предыдущего заголовка указывает на тип заголовка Маршрутизации *. Формат заголовка Маршрутизации изображен на Рисунке 9-10. Этот дополнительный заголовок не будет проанализирован и обработан, пока пакет не достигнет узла назначения, указанного в основном заголовке IPv6. По достижении узла назначения заголовок маршрутизации будет проанализирован и обработан в соответствии с алгоритмом, определяемым полем Тип маршрутизации (Routing Type). Используя результаты обработки, пакет будет отправлен на следующий узел назначения, указанный в пакете. Поле Оставшиеся сегменты (Segment Left) длиной 8 битов определяет оставшееся количество адресов маршрута. Поле Резервное (Reserved) длиной 32 бита должно быть установлено в ноль и игнорируется при передаче. Поскольку пакет отправляется каждым из указанных в заголовке узлов, изменяется адрес пройденного узла в маршруте и уменьшается счетчик ретрансляций, пока в конечном итоге в пакете не будет достигнут адрес окончательного узла назначения.
Рисунок 9-10 - Формат заголовка маршрутизации
Заголовок Фрагмента (Fragment)
На Рисунке 9-11 изображена структура заголовка Фрагмента (Fragment) IPv6. Значение «44» в поле Следующий заголовок предыдущего заголовка указывает на тип заголовка Фрагмента. Протоколу IPv6 требуется минимальное значение MTU связи равное 1280 октетам; все связи, которые не поддерживают данное условие, должны предоставить собственные механизмы специфичные для такой связи, обеспечивающие фрагментацию и последующую сборку пакетов ниже уровня IPv6. Если MTU связи составляет как минимум 1280 октетов, а размер подлежащего отправке пакета больше этого значения, протокол IPv6 обеспечивает собственный механизм фрагментации. В IPv6 узлы отправители выполняют фрагментацию гораздо чаще, чем маршрутизаторы.
Наличие заголовка Маршрутизации, тем не менее, может потребовать от промежуточных узлов выполнения фрагментации пакета вследствие его прохождения по участку маршрута с различными MTU. Поскольку при каждом из таких переходов маршрутизатор выступает в качестве узла отправителя при отправке пакета до следующего узла, то узлу необходимо сравнить MTU связи с размером пакета, что является гораздо предпочтительнее, чем знать значения MTU для всех сетевых связей, по которым будет осуществлена передача пакета. Поле Смещение фрагмента (Fragment Offset) определяет порядок сборки пакета на узле получателе, поэтому каждому фрагментированному пакету для облегчения повторной передачи потерянных пакетов назначается уникальное значение, хранящееся в поле Идентификации (Identification). Флаг M, имеющий значение «0», указывает на то, что это последний из фрагментов. Значение «1» указывает на то, что имеются последующие фрагменты.
Рисунок 9-11 - Формат заголовка фрагмента
Заголовок Проверка подлинности (Authentication)
Заголовок Проверка подлинности (Authentication), обеспечивающий проверку источника данных и целостность данных, может быть использован как самостоятельно, так и совместно с заголовком Инкапсуляции с обеспечением безопасности полезной нагрузки (Encapsulating Security Payload, ESP). Однако заголовок Проверка подлинности не обеспечивает шифрование данных, в IPv6 за это отвечает заголовок ESP. Форматы заголовков Проверка подлинности и ESP описаны в RFC 2402 и 2406. Значения «51» и «50» в поле Next Header предыдущего заголовка указывают соответственно на типы заголовков Проверка подлинности и Инкапсуляция с обеспечением безопасности полезной нагрузки *.
Поле Длины нагрузки (Payload Length) длиной 8 битов в заголовке Проверка подлинности определяет размер этого заголовка в 32-битных словах. Поле Резерв (Reserved) длиной 16 битов не используется и должно иметь значение «0». Поле Индекс Параметра Безопасности (Security Parameters Index, SPI) содержит произвольное 32-битное значение. Совместно с адресом узла назначения и протоколом безопасности, при согласовании узлов, это значение однозначно определяет сопоставление безопасности пакета. Поле Номер последовательности (Sequence Number) длинной 32 бита увеличивается на единицу для каждого пакета, значение этого счетчика не может быть уменьшено без отправления и получения узлами нового сопоставления безопасности пакета. Длина данных проверки подлинности может варьироваться, но должна быть кратной 64 битам и, хотя и может содержать любые значения, но по требованиям безопасности эти данные формируются на основе значений Длины полезной нагрузки (Payload Length) и Значение проверки целостности (Integrity Check Value).
Рисунок 9-12 - Формат заголовка Проверка подлинности
Механизмы перехода
Механизмы для перехода с IPv4 на IPv6 хотя и определены в RFC 1933, но продолжают разрабатываться в настоящее время. Основная цель процесса перехода состоит в успешном сосуществовании протоколов двух версий, пока IPv4 будет использоваться, если вообще, когда-либо он будет исключен из употребления. Планы перехода разделены на две основные группы: поддержка двух стеков протоколов и использование IPv6 с помощью IPv4 туннелирования.
Дополнительная информация. Механизмы перехода от IPv4 к IPv6 определены в RFC 1933
Поддержка двух стеков протоколов
Простейший метод обеспечения функциональности IPv6 состоит в разрешении поддержки двух стеков протоколов каждым узлом. Узлы, использующие два стека протоколов, могут взаимодействовать через любой из стеков. При этом такие узлы могут использовать адреса IPv4 и IPv6, соответствующие каждому протоколу. Это даже не является требованием реализации, поскольку два адреса совершенно независимы. Такие узлы также могут выполнять туннелирование IPv6 через IPv4. Поскольку каждый стек полностью функционален, узлы могут конфигурировать свои IPv6-адреса как посредством автоконфигурирования без возможности изменения адреса, так и с помощью DHCP, при этом для IPv4-адресов использовать любой из современных методов конфигурирования.
Туннелирование IPv6 через IPv4
Второй метод реализации IPv6 в окружении IPv4 заключается в туннелировании пакетов IPv6 внутри пакетов IPv4. Эти узлы могут включать свои IPv4 адреса в IPv6-адреса, совместимые с IPv4-адресами, используя предшествующий IPv4 адресу 96-битный префикс «0:0:0:0:0:0». В случае применения этого метода не требуется немедленная замена маршрутизаторов в сети на совместимые с IPv6, но серверы DNS в такой смешанной сети должны поддерживать протоколы обеих версий. Для помощи в достижении этой цели, адресам IPv6 определен новый тип записи DNS «АААА».
Безусловно, поддержка протокола IPv4 будет продолжаться еще несколько лет. Тем не менее, ему недоступна функциональность IP, которую предоставляет IPv6 за счет расширяемости и богатых конфигурационных возможностей. Протокол быстро достигает завершенного состояния. Когда протокол IPv6 будет окончательно развернут, он сможет предоставить примерно 1500 IP-адресов для каждого квадратного ангстрема (10-10м) на планете, отлично обеспечивая любые сетевые потребности, что ранее считалось научной фантастикой.
|
|
|
