От IPv4 к IPv6: на перепутье

Стандарт IPv6 является прямым преемником четвертой версии Internet-протокола, доминирующей с 1983 г.; разрыв в последовательности номеров объясняется тем, что согласно рекомендациям RFC 1819 версия 5 была зарезервирована для экспериментального потокового протокола (streaming protocol). С начала 1990-х гг., когда стало ясно, что из-за расширения Internet в обозримом будущем появятся различные проблемы, комитет Internet Engineering Task Force (IETF) трудится над протоколом-преемником (RFC 2460). Наряду с ликвидацией ограничений по объему адресного пространства, которые непременно бы возникли рано или поздно, были предусмотрены дальнейшие усовершенствования и оптимизация ІР-протокола. Процедуры разработки основных протоколов IPv6 затянулись до весны 1999 г., но заявки на официальное получение адресов IPv6 (на-пример, в RIPE NCC для Европы) стали приниматься уже летом 1999 г.

Подобно IPv4, протокол IPv6 находится в постоянном развитии. Сегодня особенно интересной считается проблематика, связанная с переходом с IPv4 на IPv6. Разработчики IPv6 стремились прежде всего избежать назначения определенного «времени Ч», до которого всем надлежало перейти на новый протокол (RFC 1550), — в отличие от предыдущего раза, когда предписывалось, что «новая эра» наступит 1 января 1983 г. В частности, рабочая группа NGTrans в составе IETF разрабатывает механизмы плавного перехода. Под переходом (transition) IETF понимает любые методы перевода оконечных устройств, маршрутизаторов и сетей существующей инфраструктуры, базирующейся на IPv4, на новую версию IPv6. При этом первоочередная цель — обеспечить дальнейшее взаимодействие ІР?б-совместимых устройств с традиционным ІР?4-оборудованием. В настоящее время рабочая группа NGTrans обеспокоена не недостатком подходящих вариантов перехода, а, наоборот, их многообразием:

методы на основе двойного набора протоколов (dual stack): сетевые компоненты снабжены двумя стеками протоколов, т. е. поддерживают как IP v4, так и IPv6;
методы туннелирования, предусматривающие упаковку данных IPv6 в заголовки IPv4 (и наоборот): становится возможной передача трафика по сетям, которые сами по себе тот или иной «туннелируемый» протокол не поддерживают;
трансляция IPv4 в IPv6 и обратно, обеспечивающая взаимодействие оборудования IPv6 с системами на основе IPv4.

Двойной набор

Оснащение устройств, совместимых с IPv4, вторым стеком, рассчитанным на IPv6, представляется простейшим и наиболее очевидным способом перехода на новый протокол. Как предписывает RFC 19ЗЗ, сетевой компонент с двумя стеками к устройству, которому система разрешения доменных имен DNS присвоила адрес IPv4, обращается по протоколу IPv4, а к устройству с адресом IPv6 — соответственно по IPv6.

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

Чтобы сгладить остроту этой проблемы, был разработан механизм Dual Stack Transition Mechanism (DSTM). В отличие от «чистокровных» систем с двойным стеком оконечным устройствам DSTM сначала присваивается лишь ІРvб-адрес. Если этому устройству нужно установить связь с системой, рассчитанной на IPv4, оно получает адрес IPv4 с сервера DHCP vб, который параллельно временно записывает адрес IPv4 в DNS. Временное выделение адреса IPv4 называется Assignment of IPv4 Global Addresses to IPv6 Hosts (AIIH). DSTM определяет способ пересылки пакетов IPv4 в динамическом туннеле напрямую через ІР?б-инфраструктуру на конечный пункт туннелирования (tunneling endpoint, ТЕР) граничного маршрутизатора IPv4/ IPv6 и фактически заменяет собой функции администрирования схемы маршрутизации IPv4. DSTM устраняет такой недостаток, как необходимость выделения постоянного ІРv4-адреса для каждой оконечной системы. Правда, для DSTM нужен сервер DHCFV6 и характерна значительная ресурсоемкость, обусловленная использованием механизмов автоматического конфигурирования IPv6. Кроме того, DSTM все еще имеет статус проекта Internet-норматива и поэтому еще окончательно не стандартизирован. Спецификация DHCPv6 пока также еще не утверждена.

Туннели

Кроме методов перехода с двойным набором протоколов, которые пересылают «родные» IFV6-пакеты и поэтому требуют наличия 1Ру6-совместимых маршрутизаторов, существуют способы на основе так называемых туннелей. Туннелирование часто применяется для передачи трафика между двумя конечными пунктами сети, которая, например, не поддерживает определенных свойств, путем инкапсуляции одного протокола в другом. Уже несколько лет [Руб-туннели используются для непосредственного соединения 1Ру6-сетей, не связанных между собой через традиционный Internet: в одном конечном пункте туннеля 1Ру6-пакеты упаковываются в 1Ру4-пакеты, пересылаются с помощью IPv4, а в другом снова распаковываются (RFC 1933).Так, значительные участки бВоnе, первой в мире экспериментальной ІР?б-сети, построены на «туннельных» каналах. Туннели, соединяющие сети друг с другом, зачастую имеют статическую конфигурацию, поскольку они, как правило, сохраняются в течение длительного времени. Однако туннели со статической конфигурацией малопригодны для подключения отдельных оконечных устройств, т. к. трудоемкость администрирования довольно велика. Поэтому IETF работает над заменой статических туннелей динамическими.

Туннели на основе многоадресной передачи

Первые идеи построения динамических туннелей зародились у Брайана Карпентера. Так называемый механизм 6over4 (RFC 2529) описывает способ передачи оконечными устройствами пакетов IPv6 по динамическим туннелям в сетях на основе IPv4. Главная идея заключается в использовании сети широковещательной передачи в качестве «виртуальной сети Ethernet*. В ней могут функционировать обычные механизмы IPv6 для автоматического конфигурирования и обнаружения соседнего устройства (neighbour discovery). Метод 6over4 стандартизован, однако используется редко: во многих сетях отсутствует необходимая для 6over4 инфраструктура многоадресной передачи 1Ру4-пакетов.

Сознавая ограниченность 6over4, Брайан Карпентер разработал собственный вариант метода динамического тунеллирования — 6to4 (RFC 3056). Его основная идея также относительно проста. Любая оконечная ІРv4-система или граничный маршрутизатор может самостоятельно сформировать ІРvб-адрес путем присоединения к своему ІР?4-адресу, который выступает в роли 32-разрядного агрегатора (Next Level Aggregator, NLA) ІР?vб-адреса, 16-битный префикс (специально зарезервированное значение 0x2002::). Таким образом определяются самые важные для данного метода первые 48 разрядов. Оконечные устройства или маршрутизаторы 6to4 инкапсулируют ІРvб-пакеты в IPv4 и отправляют с указанием типа протокола 41, как и в других механизмах туннелирования. Правила маршрутизации пакетов аналогичны обычным правилам туннелирования (с той лишь разницей, что в роли следующего пункта передачи пакета от маршрутизатора или оконечного устройства 6to4 выступает другой маршрутизатор 6to4, который должен быть известен). Место нахождения маршрутизатора 6to4 определяется по соответствующему ІР?4-адресу, извлеченному из пакета IPv6 (пакет попадает на этот маршрутизатор по сети IPv4). Маршрутизатор 6to4 разбирает пакет, отделяя инкапсулированные элементы, и направляет его по целевому адресу уже через сеть IPv6.

В свою очередь оконечное устройство IPv6 распаковывает пакет, распознает свой собственный адрес 6to4 и передает пакет на более высокие уровни протоколов (например, TCP или UDP). Чтобы оконечное устройство IPv6 смогло переслать пакет маршрутизатору, с которым установлена связь посредством 6to4, в его маршрутных таблицах должен присутствовать соответствующий маршрут для префикса 2002::. При наличии нескольких маршрутизаторов 6to4 протокол маршрутизации выбирает наиболее удобный маршрут.Маршрутизатор 6to4 принимает пакет с адресом 2002-/48, предназначенный оконечной системе, извлекает из него 1Ру4-адрес и отправляет пакет по этому IPv4-адресу.Механизм 6te»4 весьма удобен для подключения отдельных оконечных систем к большим сетям IPv6, а также для соединения крупных доменов IPv6. Единственное условие: должен быть известен маршрутизатор 6to4, способный принимать отосланные по его адресу IP-пакеты с типом протокола 41. Метод 6to4 не работает с ІР?4-адресами частных сетей, не помогает экономить адресное пространство и предназначен лишь для начальной фазы перехода.

Брокер туннелей

Существует и другой вариант метода туннелирования — с применением туннельного брокера (tunnel broker). Строго говоря, он не является самостоятельным методом, а служит для полуавтоматического конфигурирования статических туннелей между изолированными оконечными системами с двойным набором протоколов и так называемыми туннельными серверами. Брокер туннеля позволяет клиентскому устройству задать конфигурацию туннеля, например, через Web-сайт. Брокеру туннеля, как правило, нужны сведения об ІР?4-адресе, требуемом имени DNS и типе клиентской системы (словно речь идет об оконечном устройстве или маршрутизаторе). Затем на основании этих сведений он задает на специальном туннельном сервере конфигурацию конечного пункта туннеля и сообщает клиентской системе все данные об этом конечном пункте, которые ей необходимы.Брокеры туннеля удобны тем, что позволяют загружать полный конфигурационный сценарий, подогнанный под конкретную операционную систему и автоматизирующий процедуры настройки конфигурации клиента. Этот способ хорошо пригоден для создания ІРvб-туннеля для отдельных систем, не имеющих прямого доступа к сети IPv6.

Механизмы трансляции

К третьей категории способов перехода относятся так называемые методы трансляции. На первый взгляд они предлагают именно то, что нужно для перехода с IPv4 на IPv6: преобразование IPv4 в IPv6 и наоборот. К сожалению, они обладают серьезными недостатками, поэтому следует тщательно взвесить все «за» и «против».

Для перевода IPv4 в IPv6 простой трансляции сетевых адресов (Network Address Translation, NAT), известной по IPv4, недостаточно. Все поля в заголовке протокола IPv4 необходимо преобразовать в поля IPv6, поэтому NAT в данном случае называется Protocol Translation, сокращенно NAT/PT (RFC 2766). Сама процедура NAT/PT основывается на алгоритме Stateless IP and ICMP Translation (SIIT), описанном в Internet-стандарте RFC 2765.

Ограниченность NAT/PT. На третьем уровне модели ISO OSI преобразование вариантов протоколов сравнительно легко осуществимо — трудности начинаются на более высоких уровнях. В случае с протоколами транспортного и прикладного уровня, которые не используют символьные обозначения (что было бы желательно на прикладном уровне), а напрямую переносят ІР?4-адреса, простой трансляции IP-заголовка становится недостаточно. Применение ІРv4-адресов в заголовках особенно характерно для FTP. Следовательно, здесь должно производиться преобразование транспортных и прикладных протоколов. При наличии соответствующей спецификации трансляцию может осуществлять шлюз прикладного уровня (Application Layer Gateway, ALG), «сидящий» на шлюзе NAT/PT. Однако для всех остальных протоколов, «фирменных» или предназначенных для конкретных приложений, шлюз NAT/PT такую трансляцию выполнять не способен. Следовательно, алгоритм NAT/PT пригоден лишь для ограниченного набора протоколов. Хотя благодаря ALG их количество несколько увеличивается, многие протоколы вообще не функционируют с NAT/PT.

При передаче пакетов из ІР?4-сетей в сети IPv6 и наоборот транслятор NAT/TP заменяет исходный адрес своим собственным, чтобы приложение смогло найти «обратную дорогу» через шлюз NAT/PT в соответствующем домене IPv4 или IPv6. Однако таким образом NAT/PT разрушает механизмы IP Security (IPSec), т. к. приложение, как правило, не обнаруживает никаких «защитных» связей с NAT/PT. Для IPv6, который предписывает обязательную поддержку IPSec, это серьезное ограничение.

И это лишь основные осложнения при применении NAT/PT. Итак, метод NAT/PT полезен в некоторых случаях, однако его нельзя считать принципиальным решением всех проблем перехода.

Bump in the Stack

Если NAT/PT осуществляет преобразование протоколов с помощью шлюза, то метод Bump in the Stack (BIS, также называемый иногда BITS) передоверяет трансляцию протокола самому оконечному устройству; при этом она должна выполняться незаметно для приложения. Bump in the Stack (RFC 2767) позволяет применять ІР?4-приложения и в сетях IPv6. В операционной системе (обычно в драйвере устройства) кроме стека протоколов IPv4 применяется и набор протоколов IPv6; ІРv4-пакеты транслируются в ІРvб-пакеты. Механизм BIS временно присваивает ІРvб-адресам ІРv4-адреса для локального использования, которые служат лишь для взаимодействия с приложением, и преобразует соответствующие функции.

Тем самым BIS сильно напоминает NAT/TP, правда, без NAT-шлюза. Кроме того, BIS дает возможность применять в сетях IPv6 традиционные ІРv4-приложения, не адаптированные под IPv6. Однако у BIS имеются те же недостатки, что и у NAT/PT. Транслятор в операционной системе может нарушить функции защиты, выстроенные от приложения к приложению, а привязанная к специфике конкретных приложений трансляция ІРv4-адресов также создает осложнения, для устранения которых необходим ALG-шлюз.

Другие механизмы трансляции

Стоит также упомянуть о механизме SOCKS. Сегодня SOCKS применяется в виртуальных частных сетях (VPN), а клиенты, снабженные средствами поддержки SOCKS, могут через шлюз SOCKS в защищенном режиме связываться с Internet. Для шлюза SOCKS также был разработан транслятор, позволяющий преобразовывать IPv4 в IPv6.Кроме того, известно, что в IETF уже обсуждался вопрос о трансляторе TCP Relay, способном передавать сообщения из сетей IPv4 в сети IPv6 на уровне портов TCP. Однако эксперты признают, что этот способ еще не отработан и нуждается в дальнейших исследованиях. На заседаниях IETF рассматривались и «свежие» идеи, например Bump in the API с преобразованием интерфейсов Socket API в библиотеках и предложения о соединении доменов IPv6 с BGP4.

Залючение

Ни один из механизмов перехода не является решением «на все случаи жизни», что, в общем, отвечает стратегии IETF, предусматривающей разработку для каждой проблемы отдельного протокола, который, подобно специальной отвертке из большого набора инструментов, может затем использоваться для решения более масштабных проблем. Однако ввиду многочисленности алгоритмов перехода многим сетевым администраторам будет весьма трудно выбрать подходящий способ перехода (тем более что пока не ясно, насколько хорошо разные механизмы перехода совместимы друг с другом).

К сожалению, «палочки-выручалочки» типа сводного каталога, в котором давались бы рекомендации по выбору оптимальных механизмов для конкретных случаев применения или описывались бы успешные примеры из практики, пока не существует. Возможно, он будет составлен, но сейчас сетевые администраторы, которые начинают серьезно заниматься IPv6 и проблемами перехода, обречены на муки выбора. Тем не менее положение не безнадежно: группа IETF весьма заинтересована в массированной поддержке распространения IPv6, поэтому предпримет соответствующие меры, чтобы помочь специалистам-практикам с предприятий, которые планируют перевести свои сети на IPv6.