Механизмы перехода на IPv6

Не вызывает сомнений, что переход от IPv4 к IPv6 не может быть мгновенным. Долгое время две версии IP будут сосуществовать. Более того, поначалу узлы, реализующие IPv6, не будут предоставлять всех необходимых сервисов, а их расположение окажется напоминающим острова в океане IPv4. Следовательно, от узлов с IPv6 требуется выполнение двух свойств:

• возможность взаимодействовать с IPv4-узлами;
• возможность передавать пакеты IPv6 через существующую инфраструктуру IPv4.

Чтобы выполнить эти требования, рабочая группа по переходу на IP нового поколения (Ngtrans) предлагает два основных метода (см. [36], [37]:

• одновременная поддержка в узлах (и в хостах, и в маршрутизаторах) IPv6 двух стеков протоколов (IPv6/IPv4);
• туннелирования пакетов IPv6 для их передачи через инфраструктуру IPv4.

При одновременной поддержке двух стеков у узла должно быть по крайней мере два адреса — IPv4 и IPv6, которые, вообще говоря, могут быть никак не связаны друг с другом (хотя бы потому, что при переходе на IPv6 желательно избавиться от исторически сложившегося беспорядка в адресации IPv4). От адресов IPv4 требуется одно свойство — уникальность. Это значит, что к моменту исчерпания адресного пространства IPv4 процесс перехода на IPv6 должен зайти достаточно далеко, чтобы новые узлы могли получить все необходимые услуги исключительно средствами IPv6. (Другим решением является динамическая трансляция адресов IPv6<->IPv4.)

Очевидно, для одновременной поддержки двух стеков нужна соответствующая реализация инфраструктурных сервисов. Например, служба DNS должна выдавать как записи типа "A" с 32-битным IP-адресом, так и записи "AAAA" со 128-битным адресом (см. [38]). В зависимости от результата DNS-запроса может приниматься решение о том, каким стеком воспользоваться.

Отметим, что одновременная поддержка нескольких стеков не является серьезной проблемой для маршрутизаторов, которые всегда были многопротокольными. В принципе, то же верно и для хостов, поскольку практически все операционные системы поддерживают, наряду с IP, какие-либо унаследованные протоколы.

Механизм туннелирования давно используется в IPv4 для транспортировки не-IP-пакетов. Применительно к IPv6 выполняется инкапсуляция, показанная на Рис. 34. Соответственно, на другом конце туннеля выполняется обратное преобразование, а в промежутке имеет место обычная доставка пакета IPv4. С точки зрения IPv6, IPv4 играет здесь роль протокола канального уровня, поэтому, например, поле Hop Limit пакета IPv6 будет уменьшено лишь на 1 (если потребуется дальнейшее перенаправление пакета).

Можно выделить четыре вида туннелей (см. Рис. 35-Рис. 38):

• хост-хост. Два хоста с двойным стеком протоколов, имеющие доступ только к инфраструктуре IPv4, строят туннель "из конца в конец";
• маршрутизатор-хост. Здесь имеет место туннель "из середины в конец";
• хост-маршрутизатор, туннель "из начала в середину";
• маршрутизатор-маршрутизатор. Здесь туннель соединяет две промежуточные точки на маршруте.

В двух первых случаях конечная точка туннеля совпадает с конечной точкой маршрута пакета IPv6. Следовательно, адрес конца туннеля должен автоматически вычисляться как функция адреса целевого хоста. Говорят, что при этом производится автоматическое туннелирование. Чтобы автоматическое туннелирование было возможным, IPv6-адреса концов туннеля должны быть IPv4-совместимыми (см. Разд. Структура адресов в IPv6 ) и синтаксически, и по сути, то есть они должны получаться из адресов IPv4 приписыванием слева 96 нулевых бит.

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

Разумеется, оба конца любого туннеля (и автоматического, и сконфигурированного) должны обладать IPv4-совместимыми адресами.

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

Во взаимодействии систем IPv6/IPv4 есть ряд тонкостей, связанных с фрагментацией пакетов и функционированием протоколов маршрутизации (см. [37]), но мы не будем на этом останавливаться. Отметим лишь, что со временем может возникнуть ситуация, когда уже узлы IPv4 будут составлять островки в море IPv6. В таком случае применимо туннелирование, обратное по сравнению с рассмотренным: пакеты IPv4 инкапсулируются средствами IPv6 (см. [39]). Но до этого, как говорится, надо еще дожить.

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