IPv6 (Internet Protocol version 6)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 18:51, 16 ноября 2016.
IPv6
Уровень (по модели OSI): Сетевой
Семейство: стек протоколов TCP/IP
Порт/ID: 67, 68/UDP
Назначение протокола: Получение сетевой конфигурации
Спецификация: RFC 2460
Основные реализации (клиенты): реализация стека TCP/IP в Windows, Linux, BSD
Основные реализации (серверы): реализация стека TCP/IP в Windows, Linux, BSD
Вступил в силу с: 1996
Сфера использования: Netscape

IPv6 (англ. Internet Protocol version 6) — новая версия протокола IP, призванная решить проблемы, с которыми столкнулась предыдущая версия (IPv4) при её использовании в Интернете, за счёт использования длины адреса 128бит вместо 32. Протокол был разработан IETF.

В настоящее время протокол IPv6 уже используется в нескольких тысячах сетей по всему миру (более 14000 сетей на осень 2013), но пока ещё не получил столь широкого распространения в Интернете, как IPv4. На конец 2012 года доля IPv6 в сетевом трафике составляла около 1 %. К концу 2013 года ожидался рост до 3 %. В России коммерческое использование операторами связи невелико (не более 1 % трафика). DNS-серверы многих российских регистраторов доменов и провайдеров хостинга используют IPv6.

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

Предпосылки к IPv6

Основной протокол, по которому в Интернете передадаются данные, называется IP (Internet Protocol). Всякие HTTP, ICQ и сервисы работают поверх него (с TCP или UDP в промежутке). IP умеет упаковывать данные в пакеты и передавать их между компьютерами. Понятно, желающим обменяться данными нужно как-то друг друга идентифицировать. Для этой цели используются IP-адреса.

А вот с адресами и начинаются проблемы. IP был придуман в 80-х годах XX века, когда никто и не предполагал, что доступ в Интернет через какие-то пятнадцать лет будет не то, что у каждой уважающей себя фирмы, а вовсе у каждого школьника. Поэтому адреса сделали длиной в четыре байта (от 0.0.0.0 до 255.255.255.255). Их 2^32 = 4294967296, казалось, что хватит всем. Прямо как 640 килобайт.

Но это еще не самый большой просчет. На ранних этапах развития сети адреса можно было получать не сколько тебе реально надо, а только блоками по 16777216, 65536 или 256 адресов. Если тебе надо 500 адресов, бери сразу 65536. Если надо 66000, бери 16 миллионов. Явно не самый эффективный расход адресного пространства.

Есть и еще один прикол: сеть 224.0.0.0/4 (268435456 адресов) выделили для многоадресной рассылки (через нее, в частности, работает IPTV), а адреса после нее зарезервировали для использования в будущем. Многие разработчики сетевого оборудования поставили аппаратный фильтр на эти зарезервированные адреса, и теперь если разрешить их использование, часть исторической инфраструктуры не сможет с ними работать.

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

Когда число пользователей сети начало стремительно возрастать, стало ясно, что адресов не так уж и много. В первую очередь отказались от дурацкой классовой адресации (той самой выдачи блоками фиксированного размера) и сделали возможным выдавать адреса в минимально нужном количестве. Потом и это перестало помогать, тогда подумали, что во имя спасения сети можно отказаться от уникальности адреса каждой машины и выдавать по одному уникальному адресу на сеть, чтобы все машины сети ходили в Интернет через него. Так появился NAT (Network Address Translation), который подменяет адрес источника у соединений вовне сети на адрес маршрутизатора. Для сетей за такими маршрутизаторами выделили всем теперь известные сети 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16.

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

Чем же плох NAT?

Есть мнение, что новый протокол не нужен, а можно жить с NAT и дальше.

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

А вот с соединениями из Интернета в нашу сеть проблем куда больше. Многие протоколы, в том числе SIP (для голоса поверх IP), FTP, да те же p2p-сети через NAT в его чистом виде работать не могут. Приходится строить костыли, либо встроенные в протокол (как у Skype и BitTorrent), либо на стороне маршрутизатора. Кроме этого, в больших сетях NAT становится очень ресурсоемкой операцией. На десятимегабитном канале какой-нибудь DIR-300 вполне справляется, чтобы NAT'ить 100 мегабит, уже нужно достаточно мощное железо.

Что NAT повышает безопасность — это тоже миф. Закрыть лишние входящие соединения с тем же успехом можно и межсетевым экраном.

История создания протокола

К 1996 году были выпущены спецификации протокола IPv6. Он предоставляет нам:

  • Огромное адресное пространство. Адреса стали длиной 128 бит, то есть всего их 2^128 = 340282366920938463463374607431768211456. Внушительно, правда?
  • Обязательная поддержка многоадресной рассылки (в IPv4 была опциальной).
  • Обязательная поддержка IPsec (шифрования трафика).
  • Автоматическая настройка адресов на машинах и поиск ими маршрутизатора.

Длинные адреса поначалу могут выглядеть страшно. И правда, 2001:db8:0000:0000:0000:0000:0000:0001 выглядит куда сложнее для запоминания, чем 192.0.2.1. Но две или более группы нулей можно заменить символом «::», а незначащие нули не писать. Выходит 2001:db8::1, совсем просто.

Кстати, несмотря на непонимание некоторых провайдеров, в IPv6 вообще не полагается выдавать пользователю единственный адрес. Только подсеть /64 на сегмент, /56 (или /48) на сеть из нескольких сегментов. Размер /64 выбран для того, чтобы можно было автоматически сгенерировать уникальный адрес каждого хоста из MAC-адреса.[2]

Автономным системам (провайдерам, например), выдаются сети /32 вида 2001:db8::/32. А те самые /64 имеют вид 2001:db8:aa:bb::/64. Как видно, их куда проще запомнить, чем мелкие сети IPv4 типа /27, имеющие не такую красивую границу.

При использовании нового протокола автоматической настройки администратору достаточно включить ее на маршрутизаторе и прописать используемую подсеть, клиенты получат себе адреса и найдут маршрут наружу без его участия. Разве что адреса DNS-серверов сейчас так раздать нельзя, нужен DHCPv6. Но расширения для этой цели уже предложены.

Современное положение

Большинство провайдеров очень не спешили с внедрением IPv6. Главная тому причина: на замену старого железа, которое его не поддерживает, нужно очень много денег. Один коммутатор третьего уровня стоит несколько сотен тысяч долларов. А еще нужно менять абонентские концентраторы, биллинг и еще много чего. Поэтому возможностей получить IPv6 домой на данный момент (2011 год) практически нет. Только у некоторых в тестовом режиме (Comcast в США, например). А вот на точках обмена трафиком и в дата-центрах он обычно есть.

Сайтов и сервисов с поддержкой IPv6 тоже пока немного, но ситуация исправляется. Но пользователей p2p там уже достаточно много. И все же переход на IPv6 неизбежен. К концу 2000-х ситуация с адресами стала критической, а в феврале 2011 года последние пять блоков /8 были выданы региональным регистраторам для раздачи пользователям. Когда их все раздадут, адресов IPv4 больше не останется.

Внедрение протокола

Перевод на IPv6 начал осуществляться внутри Google с 2008 года. Тестирование IPv6 признано успешным. 6 июня 2012 года состоялся Всемирный запуск IPv6. Интернет-провайдеры включат IPv6 как минимум для 1 % своих пользователей (уже подписались AT&T, Comcast, Free Telecom, Internode, KDDI, Time Warner Cable, XS4ALL). Производители сетевого оборудования активируют IPv6 в качестве настроек по умолчанию в маршрутизаторах (Cisco, D-Link). Веб-компании включат IPv6 на своих основных сайтах (Google, Facebook, Microsoft Bing, Yahoo), а некоторые переводят на IPv6 также корпоративные сети. В спецификации стандарта мобильных сетей LTE указана обязательная поддержка протокола IPv6.

Технология IPv6

Рис. 1. Трансляция протоколов

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

Трансляция протоколов. Трансляция протоколов реализуется шлюзами, которые устанавливаются на границах сетей, использующих разные версии протокола IP. Согласование двух версий протокола IP происходит путем преобразования пакетов IPv4 в IPv6, и наоборот. Процесс преобразования включает, в частности, отображение адресов сетей и узлов, различным образом трактуемых в этих протоколах. Для упрощения преобразования адресов между версиями разработчики IPv6 предлагают использовать специальный подтип IРv6-адреса — IРv6-совместимый IРv6-адрес, который в младших 4-х байтах переносит IРv6-адрес, а в старших 12 байтах содержит нули . Это позволяет получать IPv4-адрес из IPv6-адреса простым отбрасыванием старших байтов.

Для решения обратной задачи — передачи пакетов IPv4 через части Интернета, работающие по протоколу IРv6, — предназначен IРv6-отображенный IРv6-адрес. Этот тип адреса также содержит в 4-х младших байтах IРv6-адрес, в старших 10-ти байтах — нули, а в 5-м и 6-м байтах IРv6-адреса — единицы, которые показывают, что узел поддерживает только версию 4 протокола IP.

Рис. 2. Обратная транасляция

Мультиплексирование стеков протоколов. Мультиплексирование стеков протоколов означает установку на взаимодействующих хостах сети обеих версий протокола IP. Обе версии стека протоколов должны быть развернуты также на разделяющих эти хосты маршрутизаторах. В том случае, когда IPv6-xoct отправляет сообщение IРv6-хосту, он использует стек IPv6 если тот же хост взаимодействует с IPv4-xoctom — стек IPv4. Маршрутизатор с установленными на нем двумя стеками называется маршрутизатором IPv4/IPv6, он способен обрабатывать трафики разных версий независимо друг от друга.

Инкапсуляция, или туннелирование. Инкапсуляция — это еще один метод решения задачи согласования сетей, использующих разные версии протокола IP. Инкапсуляция может быть применена, когда две сети одной версии протокола, например IPv4, необходимо соединить через транзитную сеть, работающие по другой версии, например IPv6 (рис 3) При этом пакеты IPv4 помещаются в пограничных устройствах (на рисунке роль согласующих устройств исполняют маршрутизаторы) в пакеты IPv6 и переносятся через «туннель», проложенный в IPv6-ceть. Такой способ имеет недостаток заключающийся в том, что узлы IPv4-ceTeft не имеют возможности взаимодействовать с узлами транзитной IPv6-cera. Аналогичным образом метод туннелирования может использоваться для переноса пакетов IPv6 через сеть маршрутизаторов IPv4.[3]

Рис. 3. Инкапсуляция

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

Конфигурирование адресов IPv6

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

Второй способ проверки состояния не предусматривает, поэтому здесь конфигурировать клиент не нужно. Конфигурируется только маршрутизатор, где установлен демон конфигурации без проверки состояния, например RADVD или Quagga. Работа первого из них будет рассмотрена и проиллюстрирована ниже, а вот Quagga, который также может посылать сообщения Router Advertisement и принимать Router Solicitations, рассматриваться в данной статье не будет из-за близкого сходства с RADVD.

Автоконфигурирование

При инициализации сетевого интерфейса ему назначается локальный IPv6-адрес, состоящий из префикса fe80::/10 идентификатора интерфейса, размещённого в младшей части адреса. В качестве идентификатора интерфейса часто используется 64-битный расширенный уникальный идентификаторEUI-64, часто ассоциируемый с MAC-адресом. Локальный адрес действителен только в пределах сетевого сегмента канального уровня и используется для обмена информационными ICMPv6 пакетами.

Для настройки других адресов узел может запросить информацию о настройках сети у маршрутизаторов, отправив ICMPv6 сообщение «Router Solicitation» на групповой адрес маршрутизаторов. Маршрутизаторы, получившие это сообщение, отвечают ICMPv6 сообщением «Router Advertisement», в котором может содержаться информация о сетевом префиксе, адресе шлюза, адресах рекурсивных DNS серверов, MTU и множестве других параметров. Объединяя сетевой префикс и идентификатор интерфейса, узел получает новый адрес. Для защиты персональных данных идентификатор интерфейса может быть заменён на псевдослучайное число.

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

NAT64/DNS64

NAT64/DNS64 работают совместно, чтобы преобразовать трафик входящих подключений от узла IPv6 в трафик IPv4. DNS64 разрешает имя узла, работающего только по IPv4, в преобразованный адрес IPv6. NAT64 преобразует входящий трафик IPv6 в трафик IPv4 и выполняет обратное преобразование ответного трафика. К чему приводит это изменение.

Подключаясь к серверу Direct Access, клиенты DirectAccess отправляют только трафик IPv6. С поддержкой NAT64/DNS64 на сервере DirectAccess на базе Windows Server 2012 клиенты DirectAccess отныне могут устанавливать связь с узлами интрасети, работающими только по IPv4.

Основные преимущества протокола

Статические "белые" IP-адреса для всех ваших компьютеров (даже за провайдерским NAT)

На сегодня, если не считать прямого IPv6 (которого российские провайдеры пока не дают), наиболее привлекательным способом подключения к IPv6 является регистрация у так называемого туннельного брокера, т.е. компании, которая предоставляет (бесплатно) услугу «перебрасывания» трафика из IPv4 в IPv6 и обратно. При использовании такого способа, каждый пользователь не только получает прямой доступ к IPv6-интернету (даже находясь за провайдерским IPv4 NAT'ом!), но и имеет собственную подсеть IPv6, которая привязывается не к его текущему IPv4-адресу, а к его эккаунту (имени и паролю) у брокера. Таким образом имеется возможность не только получить диапазон IPv6-адресов, но и сохранить его за собой даже при смене своего непосредственного провайдера IPv4.

Кроме того, пользователям в полное распоряжение выдаётся как минимум подсеть /64, которой достаточно, чтобы можно было подключить к сети 264устройств, и дать им всем настоящие («белые»), статические Интернетовские адреса.

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

Может возникнуть вопрос – а как быть с безопасностью? Отсутствие в IPv6-мире NAT, неверно воспринимаемого некоторыми как средство защиты сети от вторжений, на возможность обезопаситься от взломщиков никоим образом не влияет. Достаточно настроить файрвол таким образом, чтобы он не пропускал из Интернета в локальную сеть входящих соединений, кроме тех, которые вы специально хотите разрешить. В GNU/Linux для этих целей имеется инструмент ip6tables, являющийся аналогом используемого для настройки IPv4-файрвола iptables.

Более высокая скорость скачивания торрентов

Протокол BitTorrent построен таким образом, что находящиеся за провайдерским NAT и не имеющие возможности принимать входящие соединения пользователи могут «торрентить» файлы только с тех, кто за таким NAT'ом не находится (т.е имеет возможность принять входящее соединение). Это очень существенное ограничение даже сегодня, но вдвойне – в ближайшие годы, т.к. по мере исчерпания IPv4-адресов, всё больше провайдеров будут забирать у пользователей реальные IPv4 и «садить» их за NAT. Таким образом, количество торрентовских peer'ов и seed'ов, имеющих связность между собой, будет падать, вплоть до полной невозможности выкачать некоторые малопопулярные торренты.

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

Чтобы задействовать новый протокол при скачивании/раздаче торрентов, необходима его поддержка со стороны трекера. IPv6 на сегодня поддерживают два из трёх крупнейших российских трекеров. Стоит отметить, что после включения IPv6, торренты могут работать быстрее не только у тех, кто находится за злобными провайдерскими NAT, а у всех, сделавших это. Всё дело в том, что имея настроенный доступ в IPv6-интернет, вы получаете возможность качать и с компьютеров тех пользователей Сети, у которых по разным причинам нет возможности раздавать файлы по IPv4. И в конечном итоге, видя больше seed'ов и больше peer'ов – получаете более высокую скорость.[4]

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

Более высокая скорость скачивания чего угодно

Если ваш провайдер внедрил IPv4 NAT и параллельно с ним нативный IPv6, вы вполне можете обнаружить, что доступ к интернет-ресурсам по IPv6 у вас работает гораздо быстрее, надёжнее и беспроблемней, чем по IPv4 через NAT.

Объяснение этому простое: Carrier-grade NAT, т.е. трансляция адресов для десятков тысяч абонентов (и хранение в памяти информации о сотнях тысяч установленных ими соединений) – задача крайне ресурсоёмкая даже для очень дорогих специализированных провайдерских роутеров. Неудивительно, что в часы пиковой нагрузки оборудование, отвечающее у вашего провайдера за NAT, может оказаться перегруженным.

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

Общие положение IPv6

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

  • расширенное адресное пространство, которое избавляет:
  • от грозящей IPv4 нехватки адресов и необходимости NAT;
  • простоту конфигурации IP-адресов без проверки состояния, благодаря которой не требуется настраивать отдельные хосты;
  • простой способ перенумерования;
  • упрощенный (по сравнению с IPv4) заголовок IP-пакетов;
  • отсутствие фрагментации на маршрутизаторах (свойственной IPv4) — она производится только на хостах, использующих обнаружение PMTU.

Имеются, конечно, у IPv6 на Linux и некоторые недостатки, не упомянутые в настоящей статье. До сих пор, скажем, здесь не реализован LVS (Linux Virtual Server — виртуальный сервер Linux). Зато перевести приложения на IPv6 сравнительно просто. В целом же переход на IPv6 выглядит неизбежным, так как новый протокол дает по сравнению с IPv4 много серьезных преимуществ. Вот только этот процесс потребует времени, так что нам еще предстоит сталкиваться с сетями, где одни машины поддерживают исключительно IPv4, другие — только IPv6, третьи — оба эти протокола. Сегодня, к счастью, уже имеется масса технологий туннелирования, помогающая справляться с такими сетями. Так что даже несмотря на некоторые сложности переходного периода, протокол нового поколения IPv6 обязательно выйдет в сеть и в конце концов значительно улучшит ее.

Примечания

  1. IPv6 [Электронный ресурс] : Материал из Википедии — свободной энциклопедии: — Режим доступа:https://en.wikipedia.org/wiki/IPv6
  2. IPv6 [Электронный ресурс] : Материал из https://urbanculture.in: — Режим доступа: https://urbanculture.in/IPv6/%D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F
  3. IPv6 [Электронный ресурс] : Материал из http://iptcp.net/: — Режим доступа: http://iptcp.net/perekhod-na-versiyu-ipv6.html
  4. IPv6 [Электронный ресурс] : Материал из https://xakep.ru: — Режим доступа: https://xakep.ru/2012/01/09/58121/