О журнале

IPV6 — новый этап развития Интернета
Мендкович А.С., Сидельников Д.И.

IPV6 — новый этап развития Интернета

А.С. Мендкович, Д.И. Сидельников

1. Введение

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

Несмотря на глобальный характер предстоящих изменений, которые, несомненно, будут иметь не только технические, но и экономические последствия, а также сложность сопряженных с внедрением новой версии протокола организационно-технических задач, данная проблема – в отличие от «проблемы 2000», все еще недостаточно освещается не только в средствах массовой информации, но и в профессиональных научно-технических изданиях. Общее число публикаций по данной тематике относительно невелико, большинство из них носит фрагментарный характер, затрагивая лишь отдельные аспекты проблемы.

Целью данной работы является комплексное рассмотрение особенностей протокола IPv6, факторов, определяющих актуальность его внедрения, технологических и методических аспектов перехода от IPv4 к IPv6.

2. История вопроса

2.1. История возникновения и развития протокола IPv6 и мотивация его разработки

Возникновение и первоначальное развитие протокола IP (Internet Protocol) осуществлялось в рамках первых исследовательских сетей начала 70-х годов [1], однако за последнее десятилетие IP превратился в основной протокол сетевого уровня. Это означает, что поверх IP осуществляется огромное количество разнообразных телекоммуникационных взаимодействий, каждое из которых, к тому же, может предъявлять весьма специфические требования к IP-сети. Современный масштаб глобальной IP-сети таков, что проявились те фундаментальные ограничения, которые были заложены при разработке основ IP-протокола 2–3 десятилетия назад, когда общее количество узлов составляло всего несколько десятков. В 70-е годы рост Сети был приблизительно линейным (рис. 1). Если бы такие темпы сохранились, то сейчас Сеть насчитывала бы не более 1000 узлов. Однако в первой половине 80-х линейный характер роста постепенно сменяется экспоненциальным, и на рубеже 80-х и 90-х рост Сети определенно приобрел характер взрыва. Действительно, в 1981 году в Сети насчитывалось всего около 200 узлов [2], а по состоянию на март 2000 года – более 75 млн.!!!

Рис. 1. Рост числа устройств, подлюченных к Интернету в 1969-1999 гг.

Одновременно с развитием и усложнением сервисов сети видоизменялась и несущая технология – Интернет-протокол (IP). Со временем IP претерпевал множество модификаций, которые существенно улучшили многие его параметры. Однако быстрота и перспективы дальнейшего роста сети поставили перед IP-протоколом, который используется в настоящее время, ряд неразрешимых проблем:

истощение адресного пространства;
неограниченный рост маршрутных таблиц;
отсутствие встроенных механизмов обеспечения «качества обслуживания»;
отсутствие встроенных механизмов автоконфигурации хостов;
отсутствие встроенных средств безопасности;
неэффективность механизмов поддержки мобильных устройств.

Для устранения обозначившихся недостатков IP-протокола Проблемная группа проектирования Интернет (IETF – Internet Engineering Task Force) разработала спецификации IP-протокола следующего поколения, известного как IPng, или IPv6. Внедрение протокола IPv6 является одновременно и насущной задачей, и долгосрочной перспективой для сетевых администраторов и операторов сетей общего пользования. С одной стороны, продукты, поддерживающие IPv6, уже появились на рынке, с другой стороны, доработка и усовершенствование IPv6, вероятно, будут продолжаться и в начавшемся десятилетии. Несмотря на то, что в основе IPv6 лежат необходимые доработки прежней версии протокола IP (IPv4), IPv6 следует воспринимать как новый протокол, который станет прочным фундаментом современных сетей.

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

Активными сторонниками протокола IPv6 являются такие страны, как Япония и Китай, которые не получили достаточного адресного пространства IPv4. За IPv6 ратуют также поставщики новых видов телекоммуникационных услуг. Например, операторы мобильной цифровой телефонной связи – им потребуются миллионы IP-адресов для различных устройств, используемых при организации передачи данных в сети. Существенным преимуществом IPv6 является большая длина IP-адреса, позволяющая поддерживать адресацию практически каждого электронного устройства в мире.

В тоже время главный управляющий компании Lucent Technologies Ричард Макгин считает основным фактором, стимулирующим отказ от IPv4, недостатки механизмов обеспечения качества обслуживания (QoS) в этом протоколе. «Сегодняшний вариант IP вряд ли будет использоваться через пять лет, – он превратится в то, что мы называем версией 37 протокола IP, – говорит Макгин, – IP будет развиваться, включая в себя многое из того, что сегодня имеется в технологии АТМ… Иначе он просто не сможет стать основой мультисервисных сетей.» [3] Следует отметить, что в принципе путем модификации IPv4 можно наделить этот протокол некоторыми из вышеупомянутых свойств. Однако, по мнению Совета по архитектуре сети Интернет (IAB – Internet Architecture Board), результаты, которых можно достичь таким способом, окажутся значительно скромнее тех, которые сулит широкомасштабное внедрение IPv6. Кроме того, разработка IPv6 ведется таким образом, чтобы максимально защитить ранее сделанные инвестиции в сети, основанные на IPv4.

Поставщики сетевого оборудования уже сейчас предусматривают поддержку протокола IPv6 в своих продуктах (см. 3.1) аналогично тому, как они поддерживают протокол IPv4. Стоимость модернизации сети с целью реализации поддержки IPv6, согласно мнению некоторых экспертов, будет сравнима со стоимостью установки новой версии операционной системы, однако, в конечном итоге, поддержка протокола IPv6 должна дать экономию. Эллисон Мэнкин (Allison Mankin), компьютерный разработчик Института информатики Южно-Калифорнийского университета (USC/ISI), предполагает, что для провайдеров услуг переход на IPv6 «не так дорог, как переход на использование многочисленных трансляторов NAT» [4]. Кроме того, эксплуатация IPv6-сети дешевле эксплуатации аналогичной IPv4-сети, потому что протокол IPv6 оказывается «умнее» протокола IPv4 при решении различных проблем. Например, IPv6-узлы могут автоматически конфигурировать сами себя не только с помощью протокола динамической конфигурации хоста (DHCPv6), что требует постоянного отслеживания состояния этого процесса, но и с помощью механизма автоконфигурации IPv6 без фиксации состояния [10]. Используя метод «обнаружения соседа» [9], IPv6-узел может подключиться к любой сети, найти сервер автоконфигурации без фиксации состояния и сконфигурировать себя для последующей работы в сети, – и все это без вмешательства человека. Данные функции способствуют получению реального доступа к сети с высокой степенью готовности (plug-and-play network access) и существенно снижают расходы на эксплуатацию сети.

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

3. Текущее состояние дел в области внедрения протокола IPv6

3.1. Основные этапы перехода от IPv4 к IPv6 и их временные рамки

IP-протокол следующего поколения (IPng), позже получивший название IPv6, сложился в результате непростой эволюции нескольких инициатив IETF. Этот процесс продолжался более трех лет и представлял собой параллельное развитие, взаимодействие и объединение нескольких инициативных предложений (рис. 2), пока в июле 1994 года на XXX совещании IETF в Торонто не были согласованы общие рекомендации по архитектуре IPng. Новой версии IP-протокола был присвоен номер 6 [5]. Таким образом, 1994 год формально можно считать годом рождения IPv6, хотя процесс разработки стандартов этого протокола еще продолжается и поныне.

Рис. 2. Диаграмма эвелюции протокола IPv6.

К настоящему моменту протокол IPv6 является рабочим стандартом (Draft Standart) — остался всего один шаг до его принятия в качестве официального стандарта Интернет. Это означает, что основные спецификации [6, 7, 8, 9, 10, 11] протокола IPv6 уже вряд ли изменятся в процессе стандартизации. Другие спецификации пока еще находятся либо на начальном этапе процедуры стандартизации (Proposed Standard) [12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32], либо в стадии разработки [33, 34, 35, 36, 37, 38, 39, 40, 41].

Стабильность спецификаций создает все необходимые условия для появления IPv6 продуктов на рынке [42]:

Sun, Compaq (Digital), IBM, SCO включили поддержку IPv6 в новых версиях своих операционных систем (ОС).
Microsoft: стандартный пакет Windows 2000 не будет поддерживать IPv6, но на рынке существует несколько пакетов, которые позволяют осуществить поддержку IPv6 под Win9x/NT/Win2000.
Проект KAME50, посвященный внедрению стека IPv6 в BSD-подобные ОС, продлен до марта 2002 года. В рамках этого проекта уже разработаны модификации BSD-подобных ОС, позволяющие поддерживать стек протокола IPv6.
Ядро ОС Linux теперь также предусматривает поддержку IPv6.
Маршрутизаторы: Telebit (Ericsson), BayRS (Nortel), GR2000 и NR60 (Hitachi) – уже сейчас поддерживают протокол IPv6.
Крупнейший производитель маршрутизаторов – Cisco Systems – планирует включить поддержку IPv6, только начиная с версии 12.1(5)T своей сетевой операционной системы (IOS), которая должна выйти к октябрю 2000 г. Имеющиеся сейчас экспериментальные версии IOS содержат слишком много ошибок, чтобы их можно было использовать в штатном режиме на сети оператора.

Ускорению развертывания сервисов IPv6 способствовало также принятое в июле 1999 года решение начать распределение адресного пространства IPv6. По состоянию на конец февраля 2000 года по всему миру было выделено всего не более двух десятков блоков адресов IPv6 (из них 11 – в Европе, в том числе один – для российской сети FREEnet).

Конечно, нельзя ожидать, что после принятия стандарта для протокола IPv6 протокол IPv4 мгновенно исчезнет. В сети, насчитывающей миллионы устройств и сотни миллионов пользователей, невозможно назначить «час X», когда вся сеть мгновенно перейдет с одного протокола на другой. Этот процесс не будет быстрым. «Переход займет, как минимум, 15 лет, если началом его считать 1994 год», – считает Брайан Карпентер (Brian Carpenter), председатель IAB и директор программы по стандартам и технологиям для сети Интернет в компании IBM.

С другой стороны, важнейшим мотивом, побудившим начать разработку нового протокола, был и остается недостаток адресного пространства IPv4. Так когда же адресное пространство IPv4 полностью иссякнет? По этому вопросу нет полного единодушия среди экспертов. В 1996 году Американская регистрационная служба Интернет (ARIN – American Registry for Internet Number) объявила, что распределено все адресное пространство сетей класса A, 62% адресов сетей класса B и 37% адресов сетей класса C. Принимая во внимание современные тенденции в области распределения адресного пространства, два ведущих эксперта рабочей группы IETF по оценке времени, оставшегося до окончательного истощения адресного пространства (Address Lifetime Expectations working group), делают следующие прогнозы [43]: один считает, что адресное пространство IPv4 будет полностью исчерпано в 2008, а другой – в 2018 году. Сопоставляя эти цифры с оценками длительности переходного периода, мы приходим к выводу, что откладывать начало перехода к IPv6 недопустимо, иначе есть риск столкнуться с нехваткой адресов раньше, чем завершится переход на IPv6.

3.2. Опыт практического использования протокола IPv6

Важнейшую роль в разработке и внедрении протокола IPv6, помимо рабочих групп IETF, сыграли и продолжают играть несколько международных организаций:

6BONE [44]. С 1996 года сеть 6bone используется для обкатки протокола IPv6. Появившись как экспериментальная площадка рабочей группы IETF, 6bone превратилась в добровольное объединение сетей Северной Америки, Европы и Японии, которое накапливает опыт работы с IPv6 и координирует свою активность с соответствующими комитетами IETF. По состоянию на 22 февраля 2000 года 6bone охватывает 525 сетей в 42 странах. Российскую часть 6bone представляют: Институт ядерных исследований РАН (Москва), Институт системного программирования РАН (Москва), Ярославский государственный университет (Ярославль), Уральская государственная академия железнодорожного транспорта (Екатеринбург), Научно-технический центр «Атлас» (Рязань).
6REN [45]. Координационная инициатива исследовательских и академических сетей, которые предоставляют высококачественный транзитный сервис IPv6 в штатном режиме. Все участники 6REN имеют право бесплатно подключиться по IPv6 к узлу обмена данными 6TAP [46] в Чикаго (США). В отличие от сети 6bone, которая широко использует туннелирование IPv6 поверх IPv4, в 6TAP туннели не используются: подключения к 6TAP осуществляются по технологии IPv6 поверх АТМ.
IPv6 Форум [47]. Мировой консорциум ведущих поставщиков сетевого оборудования, академических и исследовательских сетей. Цель форума состоит в том, чтобы осуществлять продвижение протокола IPv6 путем создания и информирования рынка, доведения IPv6 до конечного пользователя и, в конечном итоге, создания высококачественного и безопасного Интернета нового поколения. IPv6 форум предоставляет всем заинтересованным людям и организациям доступ к знаниям и технологии глобальных сетей нового поколения. По состоянию на 17.02.2000 IPv6 Форум объединял 78 организаций: 29 – из Северной Америки, 36 – из Европы и 13 – из Азиатско-Тихоокеанского региона. 02.08.1999 в России создан национальный IPv6 Форум [48], являющийся официальным российским представительством международного IPv6 Форума. Российский IPv6 форум поддерживается специалистами Центра Интернет Ярославского государственного Университета им. П. Г. Демидова и центром управления Российской академической сети FREEnet. В дополнение к общим задачам, решаемым международным IPv6 форумом, Российский IPv6 форум решает задачу создания русскоязычного сообщества пользователей и поставщиков решений и сервиса IPv6. На сервере форума можно найти большое количество информации по IPv6, а также множество полезных ссылок на ресурсы по данной тематике.

В Японии протокол IPv6 исследуется в рамках проекта WIDE [49]. Цель исследований, проводимых в рамках этого проекта, его инициаторы формулируют предельно кратко: «создание широкомасштабной среды для распределенных вычислений». Само название проекта расшифровывается как «Широко интегрированная распределенная среда» (Widely Integrated Distributed En-vi-ron-ment).

Другой японский проект – KAME [50] – внес и продолжает вносить большой вклад в разработку программного обеспечения (ПО) для протокола нового поколения. Это совместный проект семи японских компаний. Его цель – разработка свободно распространяемого ПО для протоколов IPv6 и IPsec под BSD-подобные операционные системы (FreeBSD, NetBSD, OpenBSD, BSDI).

Помимо исследовательских проектов, некоторые компании уже приступили к реализации коммерческих проектов, связанных с внедрением IPv6. К примеру, некоторые крупные операторы объявили о предоставлении коммерческого сервиса по протоколу IPv6:

NTT (Япония);
IIJ (Япония);
MCI WorldCom (США);
Trumpet (Австралия).

Хотя таких операторов пока немного, но их количество продолжает расти. Nokia и Cernet (китайская сеть для научных исследований и образования, объединяющая 600 университетов и имеющая 2,1 млн. пользователей) начали сотрудничество по разработке в Китае интернет-технологий с использованием протокола IPv6 [51]. В рамках этого сотрудничества создана совместная лаборатория в Пекине. Партнеры намерены создать по всей стране сеть, соединяющую университеты, с использованием IP-маршрутизаторов и программного обеспечения Nokia.

NATO объявило в 1999 году о своем принципиальном решении перевести свою сеть на протокол IPv6.

Военно-морской флот Германии уже использует для своих целей ПО с обеспечением гарантированного качества сервиса (QoS) на основе протокола IPv6.

Европейский филиал японской компании NTT Communications объявил [52] о начале коммерческих испытаний протокола IPv6, соединив свою европейскую сеть с японской, где аналогичные испытания уже начаты. Для приобретения необходимого опыта компания намерена заключить партнерские соглашения с провайдерами услуг и контента. В настоящее время компания ищет партнеров, которые будут иметь бесплатный доступ в сеть в ходе проведения испытаний. Японское отделение NTT начало проведение испытаний в ноябре 1999 года, а американское – в апреле 2000-го. Компания утверждает, что она создаст первую в мире сеть, использующую новую версию IP-протокола.

Практически ежедневно поступают сообщения, свидетельствующие о том, что освоение протокола IPv6 набирает темп.

4. Спецификации протокола IPv6

4.1. Архитектура адресации в IPv6

По сравнению с IPv4, в IPv6 длина IP-адреса увеличена сразу в четыре раза – до 16 октетов (128 битов). Это, помимо прочих положительных сторон, позволит устранить одну из главных причин использования неуникальных адресов в Интернете, а именно: их недостаточность. Количество уникальных IPv6-адресов составляет примерно 3.4?1038. Если бы каждому жителю Земли выделили количество адресов IPv6, соответствующее теоретической емкости всего IPv4 Интернета, то и тогда адресное пространство IPv6 осталось бы практически неиспользованным.

Стандартом [6] определено три типа адресов:

Индивидуальный (Unicast) – адрес отдельного интерфейса. Пакет, отправленный по индивидуальному адресу, доставляется на интерфейс, идентифицируемый этим адресом.
Произвольный (Anycast) – адрес набора интерфейсов, обычно относящихся к различным узлам. Пакет, направленный по «произвольному» адресу, доставляется на один из интерфейсов, идентифицированных этим адресом (на «ближайший», согласно метрике протокола маршрутизации).
Групповой (Multicast) – адрес набора интерфейсов, обычно относящихся к различным узлам. Пакет, посланный по групповому адресу, доставляется на все интерфейсы, идентифицированные этим адресом.

В IPv6 отсутствуют широковещательные адреса (broadcast). Вместо них используются групповые адреса.

Поля в адресах имеют наименования. Если это наименование используется вместе с термином «ID» после него (например, «interface ID»), оно указывает на содержимое поименованного поля. Если же оно используется с термином «prefix» (например, «subnet prefix»), то обозначает ту часть адреса, которая состоит из всех старших разрядов вплоть до поименованного поля включительно.

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

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

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

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

Как и в IPv4, в IPv6 префикс подсети связан с одним каналом. Однако одному каналу может быть присвоено несколько префиксов.

Приняты три формы представления адресов IPv6 в текстовом виде:

1. Предпочтительная форма x:x:x:x:x:x:x:x, где знаки «x» – шестнадцатеричные значения восьми 16-битовых частей адреса. Нет необходимости писать ведущие нули в каждом отдельном поле, однако в каждом поле должна быть, по меньшей мере, одна цифра.

Примеры:
3FFE:2403:0:0:280:C8FF:FE4B:F7A8
FF01:0:0:0:0:0:0:101
0:0:0:0:0:0:0:1
0:0:0:0:0:0:0:0

2. Для облегчения записи адресов, содержащих длинные последовательности нулевых битов, принят специальный синтаксис для сжатия нулей. Обозначение «::» указывает на наличие нескольких 16-битовых групп нулей. Это обозначение может присутствовать в адресе только один раз. Оно может использоваться также для сжатия ведущих и/или концевых нулей в адресе.

Примеры:
3FFE:2403::280:C8FF:FE4B:F7A8
FF01::101
::1
::

3. Альтернативной формой, которая иногда более удобна при работе в смешанной среде узлов IPv4 и IPv6, является x:x:x:x:x:x:d.d.d.d, где знаки «x»- шестнадцатеричные значения шести старших 16-битовых частей адреса, а «d» – десятичные значения четырех младших октетов адреса (стандартное представление 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 такое же, как и в IPv4, и записывается в нотации: ipv6-address/prefix-length,

где ipv6-address – адрес IPv6 в любой из перечисленных выше нотаций;
prefix-length – десятичное значение, определяющее число левых (старших) непрерывно следующих битов адреса, образующих префикс.

В IPv6 тип адреса и характер его использования определяются значением старших битов адреса. Поле переменной длины, состоящее из этих начальных битов, называется «префикс формата» (Format Prefix, сокращенно – FP). На настоящий момент стандартом определены следующие значения FP (таблица 1).

Таблица 1. Префиксы формата [6]

Значение FP задает структуру оставшейся части адреса: наличие определенных полей, их формат и назначение [6, 7, 26, 35]. К примеру, агрегируемый глобальный индивидуальный адрес имеет следующую структуру [53]:

Рис. 3. Структура агрегируемого глобального индивидуального адреса

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

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

4.2. Структура пакета IPv6

Пакет IPv6 (рис. 4) по сравнению с пакетом IPv4 имеет более простое строение:

Заголовок пакета имеет фиксированную длину – 40 байт. Дополнительные заголовки, которые могут содержаться в пакете IPv6, организованы (в отличие от опций заголовка IPv4) гораздо строже:

Заголовок пакета не содержит контрольной суммы (канальный уровень заботится о генерации и проверке контрольных сумм).
В IPv6 отсутствует возможность фрагментации «слишком больших» пакетов промежуточными узлами. Оконечные устройства должны использовать механизм определения максимального размера пакета (Path MTU discovery) при взаимодействии друг с другом и, при необходимости, выполнять фрагментацию пакетов.

Рис. 4. Формат пакета IPv6.

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

Пакет IPv6 содержит следующие поля:

Version (ver, 4 бита) – номер версии протокола IP. Это поле в случае протокола IPv6 имеет значение «6».
Traffic Class (pri, 8 битов) – класс обслуживания. Это поле может использоваться источником трафика и/или промежуточными маршрутизаторами для обеспечения дифференцированного качества обслуживания пакетов.
Flow Label (20 битов) – идентификатор потока. Это поле может использоваться источником трафика для выделения из общей массы определенной последовательности пакетов (потока). Для каждого из потоков источник может запросить определенный уровень качества обслуживания, отличный от уровня обслуживания, предоставляемого по умолчанию, а также отличный от уровня обслуживания других потоков.
Payload Lenght (payload len, 16 битов) – размер «полезной» части пакета. Это поле содержит беззнаковое целое число, равное количеству октетов, содержащихся в той части пакета IPv6, которая следует сразу за 40-байтовым заголовком.
Next Header (next hdr, 8 битов) – указатель следующего заголовка. Это поле определяет тип дополнительного заголовка, следующего сразу за заголовком IPv6.
Hop Limit (8 битов) – максимальное количество промежуточных узлов. Это поле содержит беззнаковое целое число, которое уменьшается на единицу каждым промежуточным узлом, через который проходит данный пакет. Как только поле становится равным нулю, пакет отбрасывается.
Source Address (128 битов) и Destination Address (128 битов) – адрес источника и адрес назначения, соответственно. Эти поля содержат адреса IPv6, структура которых рассматривается выше более подробно.
Payload (data) – «полезные» данные. Эта часть пакета IPv6 содержит те данные, которые, после доставки пакета по назначению, извлекаются и передаются для обработки соответствующему протоколу верхнего уровня.

В заключение отметим, что стандартом IPv6 предусмотрено, чтобы все типы каналов связи передавали, не требуя фрагментации на сетевом уровне, IPv6 пакеты размером вплоть до 1280 байт.

4.3. Особенности маршрутизации IPv6

Дробление адресного пространства на небольшие блоки ведет к тому, что узловые маршрутизаторы Интернета должны содержать в своей памяти слишком большие таблицы маршрутизации (рис. 5).

Рис. 5. Количество маршрутов IPv6 в 1998-2000 гг. [54]

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

Как уже отмечалось выше, сама структура агрегируемого глобального индивидуального адреса в IPv6 специально разработана так, чтобы обеспечить агрегирование маршрутов. В IPv6 поддерживаются два типа агрегирования [7]: «операторский» (provider based) и «узловой» (exchange-based). Это делает возможным эффективное агрегирование маршрутов как тех потребителей, что подключаются к узлу доступа определенного оператора, так и тех, сети которых подключены непосредственно к публичному узлу обмена данными. Потребитель свободен в выборе типа подключения своей сети.

Агрегируемые адреса образуют трехуровневую иерархическую структуру:

уровень сети общего пользования (Public Topology);
уровень сети потребителя (Site Topology);
уровень идентификатора интерфейса (Interface Identifier).

Уровень сети общего пользования охватывает набор операторов и узлов обмена данными, которые на общих основаниях предоставляют услугу транзита в Интернете (public Internet transit services). Уровень сети потребителя соответствует конкретному сайту или организации, которая не предоставляет услуги транзита для узлов, расположенных вне этого сайта. Уровень идентификатора интерфейса описывает отдельные интерфейсы, подключенные к определенному каналу связи.

Потребители, подключенные непосредственно к узлу доступа определенного оператора, получают адресное пространство из блока адресов этого оператора. Этот тип агрегирования – «операторский» – давно применяется в IPv4 CIDR.

Те же потребители, которые выбрали подключение к публичному узлу обмена данными, получают адресное пространство из блока адресов этого узла и используют новый тип агрегирования – «узловой». Такие потребители подписываются (прямо или косвенно, через договор с узлом обмена) на получение услуги транзита от одного или более операторов Интернета, присутствующих на данном узле. В этом случае потребитель не связан своими адресами с определенным оператором и может отказаться от услуг одного оператора в пользу другого, не меняя адресов в своей сети. Кроме того, как уже отмечалось, при таком подключении потребитель (multihomed site) может пользоваться услугами сразу нескольких операторов.

Прежде чем уточнить механизм агрегирования префиксов на каждом уровне иерархии (см. выше), дадим расшифровку сокращений, используемых для описания структуры агрегируемого адреса (рис. 3):

Идентификаторы (под)агрегата верхнего уровня занимают верхнюю ступень в иерархии маршрутов. Маршрутизаторы, не использующие «маршрут по умолчанию», обязаны содержать в своей таблице маршрутизации записи, отвечающие каждому TLA ID, и, возможно, еще записи, соответствующие более специфичным маршрутам внутри того TLA ID, к которому относится данный маршрутизатор. Таблица маршрутизации может содержать некоторое количество дополнительных записей в целях оптимизации маршрутизации для данной конкретной топологии [39], но при планировании сети следует стремиться к тому, чтобы свести количество таких записей к минимуму.

Идентификаторы агрегата следующего уровня используются операторами и организациями, которым был выделен TLA ID, для создания иерархии адресов внутри данного TLA ID.

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

Идентификаторы интерфейсов используются для адресации конкретных интерфейсов в масштабах данного конкретного канала связи (или ЛВС). Идентификатор интерфейса должен быть уникальным в пределах данного канала связи. Согласно требованиям стандарта, этот идентификатор должен иметь длину 64 бита и формат, соответствующий IEEE EUI-64 [55].

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

4.4. Механизмы автоконфигурации хостов IPv6

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

Автоконфигурация без фиксации состояния

Автоматически присваивает IPv6 адрес (Stateless Address Autoconfiguration)

Находит маршрутизатор
– Запросить маршрутизатор о префиксах, действующих на данном канале связи
– Сконфигурировать глобальный адрес на интерфейсе
Устанавливает маршруты

Автоконфигурация с фиксацией состояния

Использует протокол DHCPv6.

4.5. Механизмы обеспечения «качества обслуживания» (QoS)

В заголовке пакета IPv6 появилось новое (по сравнению с IPv4) поле – «идентификатор потока», – которое в совокупности с другим полем заголовка – «класс обслуживания» – дает возможность поддержки разных уровней качества обслуживания.

4.6. Механизмы защиты информации и обеспечения сетевой безопасности

В отличие от IPv4, стандарт протокола IPv6 требует обязательной поддержки протокола IPsec. Различают три основных компонента IPsec-протокола [56, 57, 58].

Аутентификационный заголовок (AH – Authentication Header) проверяет идентичность отправителя пакета и аутентичность содержимого (contents) пакета.
Инкапсулирующий защитный модуль (ESP – Encapsulating Security Payload) шифрует пакет перед его отправкой; модуль ESP может также инкапсулировать исходный IP-пакет.
Блок обмена ключами в сети Internet (IKE – Internet Key Exchange) управляет передачей ключей безопасности от отправителя к получателю. (IKE был ранее известен под названием протокол ISAKMP/Oakley – Internet security association and key management protocol/Oakley – протокол [разработанный университетом в Оукли] управления ключами для защиты соединений в сети Internet.)

Аутентификационный заголовок (AH) и модуль ESP могут применяться с различными схемами аутентификации и шифрования, некоторые из которых должны применяться в обязательном порядке. Например, стандарт IPsec определяет, что пакеты должны аутентифицироваться либо с помощью профиля сообщения MD5 (Message Digest 5), разработанного фирмой RSA Data Security Inc. (Сан-Матео, Калифорния), либо с помощью алгоритма защитного хеширования SHA-1 (Secure Hashing Algorithm-1), который разработан Агентством Национальной Безопасности США (NSA – National Security Agency).

Поставщики могут свободно применять дополнительные алгоритмы аутентификации и шифрования.

5. Основные способы сопряжения участков сетей IPv4 и IPv6 во время переходного периода

Как уже отмечалось выше, протоколу IPv6 придется длительное время взаимодействовать с IPv4 и на первом этапе даже существовать в его среде [59]. IPv6, к счастью, не создает ограничений, связанных с жестким порядком действий в переходный период: администраторы сетей могут модернизировать свои хост-машины, а затем маршрутизаторы, либо, наоборот, сначала – маршрутизаторы, а потом – хост-машины. Они даже могут модернизировать лишь часть хост-машин и часть маршрутизаторов, отложив остальное на будущее.

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

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

трансляторы протоколов,
двухпротокольные стеки (dual stacks) и
туннелирование (tunnels).

Метод трансляции протоколов состоит в преобразовании по определенным правилам пакетов IPv6 в пакеты IPv4, и обратно. В настоящее время применяются три механизма трансляции протоколов. Один из них – преобразование заголовков, в котором IP-заголовки транслируются из одной версии в другую протокол-шлюзом (protocol gateway device). Все шлюзы для трансляции протоколов размещены на границах между сетями IPv4 и IPv6.

Другой механизм трансляции протокола предполагает использование транспортного ретранслятора: протокол-шлюз принимает сегменты TCP и дейтаграммы UDP от исходного узла и воссоздает TCP- и UDP-трафик, передаваемый узлу назначения. Другими словами, такой шлюз не просто исследует и переводит IP-заголовки, но также обрабатывает заголовки протокола транспортного уровня, чтобы заставить их «работать» на соответствующей версии IP-протокола.

Третий механизм представляет собой proxy-приложение. В этом случае транслятор является шлюзом между сетями IPv4 и IPv6 на прикладном уровне.

Строение пакета IPv6, однако, слишком сильно отличается от устройства пакета IPv4, чтобы можно было сделать преобразование одного в другой, без утраты некоторых важных свойств протокола IPv6. Одна из проблем связана с преобразованием адресов IPv6 в адреса IPv4. Другая сложность состоит в том, что протокол IPv4 уничтожает или изменяет половину IPv6 заголовков (например, в IPv4 отсутствует аналог идентификатора потока – «flow label»). В результате, при трансляции утрачиваются многие из тех функций протокола IPv6, которые выгодно отличают его от IPv4. Кроме того, IPv6 снимает поддержку фрагментации IPv4-пакетов при их передаче.

Второй подход состоит в том, что IPv6-узлы должны поддерживать оба стека протокола IP – и IPv4, и IPv6 – в полном объеме. Узел сам выбирает, какой протокол использовать в каждом конкретном случае: IPv6 может использоваться только в том случае, если удаленный узел также поддерживает IPv6. Признаком того, что удаленный узел поддерживает новую версию протокола IP, служит наличие в DNS [12] специальной записи (AAAA), ассоциированной с данным узлом. Двухпротокольный подход может реализовываться и сам по себе, и в комбинации с третьим из перечисленных подходов – туннелированием.

Рис. 6. Схема туннеля "IPv6 поверх IPv4"

На первом этапе, пока большая часть Интернета работает по протоколу IPv4, реализация связности по протоколу IPv6 будет осуществляться методом туннелирования. Такое туннелирование достигается путем инкапсуляции IPv6-пакета внутри пакета IPv4. Передача информации при этом осуществляется следующим образом: IPv6-узел создает IPv6-пакеты, которые инкапсулируются в пакеты IPv4 и передаются через IPv4-сеть. Узел на другом конце туннеля разворачивает IPv4-пакет, извлекает IPv6-пакет и затем передает его в узел назначения.

Существуют туннели разных типов, причем тип используемого туннеля зависит от того, какое устройство производит инкапсуляцию и декапсуляцию пакетов. Туннели «маршрутизатор-маршрутизатор» могут использоваться для связывания двух «чистых» IPv6-сетей, разделенных IPv4-сетью. Туннели «хост-маршрутизатор» позволяют изолированным двухпротокольным хост-машинам преодолевать участки IPv4-сети, связываясь с IPv6-сетями через двухпротокольный IP-маршрутизатор. Туннели «маршрутизатор-хост» связывают изолированные двухпротокольные узлы c IPv6-сетями, тогда как туннели «хост-хост» позволяют изолированным двухпротокольным узлам взаимодействовать по протоколу IPv6 через IPv4-сети.

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

Многоадресная туннельная передача по протоколу IPv4 возможна только в пределах той инфраструктуры IPv4-сети, которая поддерживает многоадресную передачу. Узел, инкапсулирующий IPv6-пакет в IPv4-пакет, определяет конечную точку туннеля путем использования многоадресной передачи по протоколу IPv4 для «обнаружения соседа» (neighbor discovery). Этот механизм позволяет IPv6-узлу «обнаружить» другие узлы, относящиеся к тому же каналу связи, определить их адреса на уровне канала связи, найти маршрутизаторы, а также поддерживать информацию о маршрутах к активным соседним узлам. Данный вариант позволяет не конфигурировать туннель и не использовать IPv4-совместимые адреса – но, к сожалению, многие операторы Интернета еще не поддерживают маршрутизацию многоадресных пакетов.

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

Литература

1. S. King, R. Fax, D. Haskin, W. Ling, T. Meehan, R. Fink, C. E. Perkins. The Case for IPv6. Internet Draft, Internet Architecture Board, draft-ietf-iab-case-for-ipv6–06.txt, December 1999.
2. http://www.isc.org/ds/host-count-history.html.
3. Сети и системы связи. 2000, № 2 (52), С. 23.
4. Сетевой журнал Data Communications, 2000, № 1, С. 63.5. S. Bradner, A. Mankin. The Recommendations for the IP Next Generation Protocol // RFC 1752, Jan. 1995.
6. R. Hinden, S. Deering. IP Version 6 Addressing Architecture // RFC 2373, July 1998.
7. R. Hinden, M. O’Dell, S. Deering. An IPv6 Aggregatable Global Unicast Address Format // RFC 2374, July 1998.
8. S. Deering, R. Hinden. Internet Protocol, Version 6 (IPv6) Specification // RFC 2460, Dec. 1998.
9. T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6) // RFC 2461, Dec. 1998.
10. S. Thomson, T. Narten. IPv6 Stateless Address Autoconfiguration // RFC 2462, Dec. 1998.
11. A. Conta, S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification // RFC 2463, Dec. 1998.
12. S. Thomson, C. Huitema. DNS Extensions to support IP version 6 // RFC 1886, Dec. 1995.
13. Y. Rekhter, T. Li. An Architecture for IPv6 Unicast Address Allocation // RFC 1887, Dec. 1995.
14. J. McCann, S. Deering, J. Mogul. Path MTU Discovery for IP version 6 // RFC 1981, August 1996.
15. D. Haskin, E. Allen. IP Version 6 over PPP // RFC 2472, December 1998.
16. G. Malkin, R. Minnear. RIPng for IPv6 // RFC 2080, January 1997.
17. M. Daniele. IP Version 6 Management Information Base for the Transmission Control Protocol // RFC 2452, December 1998.
18. M. Daniele. IP Version 6 Management Information Base for the User Datagram Protocol // RFC 2454, December 1998.
19. M. Crawford. Transmission of IPv6 Packets over Ethernet Networks // RFC 2464, December 1998.
20. D. Haskin, S. Onishi. Management Information Base for IP Version 6: Textual Conventions and General Group // RFC 2465, December 1998.
21. D. Haskin, S. Onishi. Management Information Base for IP Version 6: ICMPv6 Group // RFC 2466, December 1998.
22. M. Crawford. Transmission of IPv6 Packets over FDDI Networks // RFC 2467, December 1998.
23. M. Crawford, T. Narten, S. Thomas. Transmission of IPv6 Packets over Token Ring Networks // RFC 2470, December 1998.
24. A. Conta, S. Deering. Generic Packet Tunneling in IPv6 Specification // RFC 2473, December 1998.
25. M. Degermark, B. Nordgren, S. Pink. IP Header Compression // RFC 2507, February 1999.
26. D. Johnson, S. Deering. Reserved IPv6 Subnet Anycast Addresses // RFC 2526, March 1999.
27. B. Carpenter, C. Jung. Transmission of IPv6 over IPv4 Domains without Explicit Tunnels // RFC 2529, March 1999.
28. P. Marques, F. Dupont. Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing // RFC 2545, March 1999.
29. A. Conta, A. Malis, M. Mueller. Transmission of IPv6 Packets over Frame Relay Networks Specification // RFC 2590, March 1999.
30. D. Borman, S. Deering, R. Hinden. IPv6 Jumbograms // RFC 2675, August 1999.
31. S. Deering, W. Fenner, B. Haberman. Multicast Listener Discovery (MLD) for IPv6 // RFC 2710, October 1999.
32. C. Partridge, A. Jackson. IPv6 Router Alert Option // RFC 2711, October 1999.
33. J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd. OSI NSAPs and IPv6 // RFC 1888, August 1996.
34. W. Stevens, M. Thomas. Advanced Sockets API for IPv6», RFC 2292, February 1998.
35. R. Hinden, S. Deering, «IPv6 Multicast Address Assignments», RFC 2375, July 1998
36. R. Hinden, «Proposed TLA and NLA Assignment Rules // RFC 2450, December 1998
37. R. Gilligan, S. Thomson, J. Bound, W. Stevens. Basic Socket Interface Extensions for IPv6 // RFC 2553, March 1999.
38. M. Crawford. Router Renumbering for IPv6 // Internet Draft, draft-ietf-ipngwg-router-renum-10.txt, March 2000.
39. J. Yu. IPv6 Multihoming with Route Aggregation // Internet Draft, draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt, November 1999.
40. D. Johnson, C. Perkins. Mobility Support in IPv6 // Internet Draft, draft-ietf-mobileip-ipv6–09.txt, October 1999.
41. R. Callon, D. Haskin. Routing Aspects of IPv6 Transition // RFC 2185, September 1997.
42. http://www.ipv6.ru/soft/
43. F. Solensky. «IPv4 Address Lifetime Expectations» in IPng: Internet Protocol Next Generation (S.Bradner, A. Mankin, ed), Adddison Wesley, 1996.
44. http://www.6bone.net/
45. http://www.6ren.net/
46. http://www.6tap.net/
47. http://www.ipv6forum.com/
48. http://www.ipv6.ru/
49. http://www.wide.ad.jp/
50. http://www.kame.net/
51. РБК, 14.03.2000, Москва 16:45:06.
52. РБК, 27.03.2000, Москва 17:59:02.
53. APNIC, ARIN, RIPE NCC, «IPv6 Assignment and Allocation Policy Document», RIPE-196, July 1999.
54. http://www.telstra.net/ops/bgptable.html
55. IEEE, «Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority», http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, January 2000
56. S. Kent, R. Atkinson. Security Architecture for the Internet Protocol // RFC 2401, November 1998.
57. S. Kent, R. Atkinson. IP Authentication Header // RFC 2402, November 1998.
58. S. Kent, R. Atkinson. IP Encapsulating Security Payload (ESP) // RFC 2406, November 1998.
59. R. Gilligan, E. Nordmark. Transition Mechanisms for IPv6 Hosts and Routers // RFC 1933, April 1996.

&copy Информационное общество, 2000, вып. 4, с. 11 - 22.

О журнале

Рекомендации

IPV6 — новый этап развития Интернета Мендкович А.С., Сидельников Д.И.

IPV6 — новый этап развития Интернета
Мендкович А.С., Сидельников Д.И.