Cайт Кéмчука

У корня DNS

kemchuk — Fri, 29 Aug 2014 21:09:01 GMT

У корня DNS

Нормальная работа сети Интернет немыслима без правильно функционирующей системы доменных имен, или DNS (Domain Name System). Всякий раз, когда мы набираем имя веб-сайта или посылаем электронную почту, эта система берет на себя задачу трансляции имени в цифровой адрес протокола IP, необходимый для осуществления связи между компьютерами в сети.

Принципы работы системы разрешения имен

Система DNS является иерархической и распределенной. Не существует единой базы данных, хранящей информацию о всех именах и соответствующих им IP-адресах и других записях. Напротив, DNS - это миллионы баз данных, каждая из которых содержит информацию о конкретном домене. Иерархию DNS можно увидеть в доменном имени, например, в имени веб сайта. Возьмем, например, сайт RIPE NCC - www.ripe.net. Это имя состоит из трех частей, разделенных точками. Точнее четырех, поскольку, формально говоря, полное доменное имя всегда заканчивается точкой, обозначающей так называемый корневой домен, или корневую зону DNS. Итак:

.	Корневая зона, содержащая информацию о всех поддоменах: net, com, org, ru, su , и т.д. Точнее, информацию о серверах, обслуживающих эти домены.
net	Домен net, содержащий информацию о всех поддоменах, зарегистрированных в ней. Например, ripe. Опять же, этот домен содержит адреса серверов, у которых можно получить дополнительную информацию о содержимом поддоменов.
ripe	Домен ripe, содержащий информацию о всех поддоменах, а также имена серверов, зарегистрированных непосредственно в этом домене, например www.ripe.net.
www	Имя вэб-сервера RIPE NCC и соответствующие ему IP адреса.


	Рис 1 Процесс трансляции имен в DNS

Соответственно, трансляция имени www.ripe.net в соответствующие ему один или более IP-адресов будет происходить в несколько этапов. Сначала будут запрошены серверы, обслуживающие корневую зону. Эти серверы ничего не знают о существовании домена ripe и тем более адрес www.ripe.net. Но они сообщат, как можно связаться с серверами, обслуживающими домен следующего уровня - net. От них мы узнаем адреса серверов домена ripe, которые, в свою очередь, и ответят на запрос о IP-адресе сервера www.ripe.net.

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

Эта иерархически распределенная архитектура DNS обеспечила долгожитие системы и ее эволюционное развитие уже на протяжении более четверти века.

Но есть в системе DNS одна особенность, отличающая ее от многих других систем Интернета, имеющих децентрализованный характер. Это та самая точка, корень дерева DNS, откуда начинаются все свежие запросы. О нем мы и поговорим подробнее.

Корневой уровень DNS

Корневые серверы (КС) DNS являются критическим компонентом системы, поскольку обеспечивают доступ к корневой зоне DNS. Корневая зона содержит информацию обо всех доменах самого верхнего уровня: национальные домены (например .ru), домены общего назначения (например .com) и спонсированные домены (например .museum). Эта информация указывает клиенту на какие серверы DNS отправить последующий запрос для продолжения разрешения полного доменного имени. Другими словами, любой "свежий" (т.е. не сохраненный в кэше клиента) запрос начинается с обращения к корневому серверу.

Особенностью корневых серверов является также то, что первичный запрос (priming), т.е. самый первый запрос, осуществляемый клиентом, производится по IP адресу сервера, а не по его имени. Это объясняется тем, что для трансляции имени в IP адрес необходима система DNS, для начала работы с которой необходим доступ к корневому серверу. Очевидно, что изначальная информация о корневых серверах (их IP адреса) не может быть получены из системы DNS. Эта информация содержится в специальном файле hints, хранящемся у клиента и обычно получаемом вместе с программным обеспечением (операционная система, ПО DNS, и т.п.)

Сегодняшняя система корневых серверов и координация ее работы

Со времени создания системы DNS в середине 80-х годов до 2000 года, система корневых серверов (СКС) состояла из первичного (primary) сервера (ns.internic.net, позднее переименованный в a.root-servers.net) и растущего числа реплик (secondary), в конечном итоге достигшее 12, с именами b.root-servers.net, c.root-servers.net и т.д. до m.root-servers.net. Каждый сервер управляется и сопровождается отдельной организацией-оператором, различными по роду деятельности, организации и географии. Полный список приведен ниже, его также можно найти на сайте http://www.root-servers.org.

В 2000-2002 г.г. архитектура системы была изменена. Был создан "скрытый" мастер-сервер и 13 равноправных КС, получающих идентичные копии корневой зоны от мастера.

Начиная с 2003 года получила распространение технология anycast, позволяющая "клонировать" серверы с одним и тем же именем и адресом. Эта технология стала активно использоваться рядом операторов и позволила существенно расширить географию СКС, до этого охватывающую преимущественно США.

Рассмотрим подробнее участников СКС. Для этого обратимся к процессу внесения изменений в содержимое корневой зоны, представленному на рисунке 2.


	Рис 2 Процесс внесения изменений в корневую зону

Запрос на изменение поступает от администратора домена верхнего уровня (ccTLD, gTLD, и т.д.) и обслуживается IANA. Типичным примером такого запроса является изменение состава серверов, обслуживающих домен.

После проведения необходимых административных и технических процедур (например проверка правильности и законности запроса, проверка возможных негативных последствий на корневую зону), запрос на изменение подписывается цифровым образом и направляется для авторизации аудитору, роль которого в настоящее время выполняет Министерство Торговли США.

Затем изменения направляются организации, ответственной за фактическое редактирование и публикацию зоны в DNS. Эту роль в настоящее время выполняет компания VeriSign. Кстати, эта же компания является оператором 2 корневых серверов - a.root-servers.net и j.root-servers.net.

Зона изначально публикуется на скрытом мастер-сервере и затем распространяется на все реплики с использованием протокола TSIG, защищающий данные от модификации при передаче.

Операторы КС

Операторами КС являются различные организации, получившие право управления серверами в относительно отдаленном прошлом, когда подобные вопросы решались менее формально. Среди операторов находятся университеты, организации Министерства Обороны США, некоммерческие ассоциации. Операторы являются финансово и юридически независимыми от корпорации ICANN, в рамках которого действует IANA. При принятии операционных решений операторы руководствуются технической целесообразностью и существующими стандартами (например, RFC2870), в основном поддерживая статус-кво. Крупнейшим решением такого рода, принятого независимо оператором сервера f.root-servers.net компанией ISC, было решение о применении технологии anycast. Хотя это решение прошло тщательную экспертную проверку специалистов, оно не было регламентировано ICANN или каким-либо из его Советов. Впоследствии к ISC присоединился ряд других операторов.

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

Операторы КС образуют неформальную группу, целью которой является координация совместных действий и обмен операционной информацией и опытом. Группа проводит регулярные встречи 3 раза в год, приуроченные к совещанию IETF. Одним из результатов таких совещаний является генерация секретного ключа для протокола TSIG.

Члены группы являются также членами Консультационного Совета КСК ICANN (Root Server System Advisory Committee, RSSAC), в задачу которого входит выработка рекомендаций по управлению КСК и внесению различных изменений в систему.

До недавнего времени отсутствовали какие-либо формальные отношения между операторами и ICANN/IANA. Эта ситуация изменилась с подписанием первого соглашения между ICANN и оператором сервера f.root-servers.net компанией ISC. Данное соглашение не предусматривает никаких финансовых расчетов и лишь определяет взаимные обязанности сторон в отношении управления КС. Известно, что ряд операторов также обсуждают подобные соглашения с ICANN.

Ниже приведен список и краткая характеристика текущих операторов СКС.

СКС	Организация-оператор	Характер деятельности
A	VeriSign, Inc.	Коммерческая корпорация, крупнейший поставщик цифровых сертификатов и средств защиты электронных коммуникаций, США
B	Information Sciences Institute	Институт Университета Южной Калифорнии (USC), США
C	Cogent Communications	Один из крупнейших коммерческих Интернет сервис провайдеров, США
D	University of Maryland	Университет, США
E	NASA Ames Research Center	Государственное агентство, США
F	Internet Systems Consortium, Inc.	Некоммерческая корпорация, США
G	U.S. DOD Network Information Center	Государственное агентство, США
H	U.S. Army Research Lab	Государственное учреждение, США
I	Autonomica	Коммерческая организация, подразделение Netnod AB, Швеция
J	VeriSign, Inc.	Коммерческая корпорация, крупнейший поставщик цифровых сертификатов и средств защиты электронных коммуникаций, США
K	RIPE NCC	Некоммерческая ассоциация, Нидерланды
L	ICANN	Некоммерческая корпорация, США
M	WIDE Project	Некоммерческий проект, секретариат Университет Кейо, Япония

Альтернативные СКС

Хотя возможность умышленного нарушения работы КС или модификация содержимого корневой зоны каким-либо из операторов или ICANN/IANA маловероятна, строго говоря, в настоящее время не существует формальных процессов или международных законодательных актов, которые могли бы этому воспрепятствовать. Можно сказать, что нормальное функционирование СКС отчасти зависит от "доброй воли" участников.

Необходимо заметить, что подобные "неформальные" зависимости, основанные на доверии, характерны для работы системы DNS (и во многом сети Интернет) в целом. В конечном итоге, выбор, какие КС использовать, остается за клиентом. Эта информация содержится в конфигурационном файле hints и может быть изменена.

Эта особенность вкупе с неудовлетворенностью существующей системой управления СКС во главе с ICANN при участии правительства одной страны - США, привела к созданию так называемых альтернативных СКС. Примерами таких систем служат Public-Root, Open Root Server Network (ORSN) и UnifiedRoot. Хотя эти системы копируют текущее состояние корневой зоны, сама архитектура предусматривает, что в определенных условиях альтернативные СКС могут предоставить альтернативное пространство имен. Администратор клиента DNS (обычно сервера DNS, обслуживающего корпоративных пользователей или клиентов кабельной сети) может выбрать альтернативную СКС изменив соответствующим образом файл hints.

Альтернативные СКС получили критическую оценку со стороны IETF как открывающие потенциальную возможность раскола единого Интернета (см. RFC2826).

Техническое развитие корневого уровня DNS

Система корневого уровня DNS весьма консервативна. Это и понятно - любые изменения на этом уровне затрагивают функционирование всей глобальной системы доменных имен. Тем не менее, несколько важных изменений были внедрены в СКС и корневую зону в течение последних лет.

Anycast

Вы наверное заметили, что количество КС, а точнее имен КС, является "счастливым" числом 13. Это не вызов суеверию, число 13 связано с ограничением на размер сообщения в 512 байт, установленным стандартом DNS [RFC1035 4.2.1]. Хотя исторически это ограничение было вызвано ограничением на пакеты UDP не допускающим фрагментации, оно продолжает существовать в протоколе DNS, несмотря на появление новых сетевых протоколов, например IPv6. Расширенный стандарт DNS (EDNS0, RFC2671 2.3, 4.5) предусматривает предварительное соглашение о размере сообщения между клиентом и сервером, однако степень распространения этого протокола в сегодняшних системах DNS недостаточна для снятия ограничения в 512 байт в ближайшем будущем.

Все 13 имен КС (a.root-servers.net - m.root-servers.net) умещаются в отведенные 512 байт, а в случае четырнадцати имен для значительной части запросов ответ не сможет полностью поместиться в отведенные 512 байт. Результатом может стать существенное снижение производительности системы, так как часть клиентов вынуждена будет повторить запрос, но теперь с использованием гораздо более "медленного" протокола TCP.

До 2003 года максимальное количество КС совпадало с числом имен и не могло превышать 13. Но даже при таком количестве, для многих клиентов, особенно находящихся вне США и Западной Европы, КС располагались неоптимально.

Другой проблемой, требующей решения являлось то, что 13 серверов оказалось достаточно просто атаковать посредством распределенной атаки DoS. Так случилось в октябре 2002 года, когда большинство КС были недоступны в течение нескольких часов.

Решению этих проблем помогла т.н. технология anycast, известная с 1993 года, но не применявшаяся в глобальном масштабе и на таком уровне. Суть ее заключается в анонсировании оператором одной и той же сети (префикса IP и автономной системы) в различных частях Интернета. Благодаря архитектуре системы маршрутизации для любого клиента существует единственный и самый "короткий" путь к любой другой сети Интернета. Таким образом, anycast позволяет клиенту установить связь с наиболее близкой в топологическом смысле сети anycast без дополнительных изменений в ПО и протоколах!

Технология anycast наиболее подходит для приложений, использующих протокол UDP, работающий без установления продолжительной связи. В противном случае, при каких-либо изменениях в топологии Интернет (которые происходят постоянно), кратчайший путь может привести клиента к другой сети anycast, и связь будет разорвана.

В 2003 году, после тщательной экспертной проверки и тестирования, оператор сервера f.root-servers.net разместил реплику своего сервера с использованием anycast. Примеру ISC последовал и ряд других операторов и география системы КС существенно расширилась, как можно видеть из рис. 3. На сегодняшний день общее число серверов, по-прежнему управляемых 12 операторами, достигло 166. Два таких сервера (f.root-servers.net и k.root-servers.net) расположены в России.


	Рис 3 География системы КС ( см. http://www.root-servers.org/)

IPv6

Внедрение поддержки IPv6 в корневой зоне в начале 2008 года обеспечило полную поддержку протокола IPv6 в глобальной системой доменных имен.

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

На первый взгляд несложная задача, включение этой информации в корневую зону было связано с основной проблемой - превышение размера ответа, и в частности ответа на первичный (priming) запрос, все те же 512 байт!

Напомню, что ответ на первичный запрос содержит имена и адреса всех 13 КС. Оказывается, в 512 байт умещаются все имена, все 13 IPv4 адресов и только 2 адреса IPv6. В принципе, этой информации достаточно, чтобы клиент мог продолжить поиск в DNS. Но было неясно, как отреагируют различные клиенты на отсутствие информации, которую они, возможно, предполагали получить. Не приведет ли это к обвальному использованию протокола TCP, позволяющему избежать ограничения на размер пакета, но и гораздо более "дорогостоящего"? Эти вопросы требовали тщательного тестирования.

Другой проблемой являлось наличие адресов IPv6 в файле hints - так сказать стартера клиента. Если клиент не сможет прочитать этот файл, например, потому что он не предполагает наличия адресов IPv6 в файле hints, глобальная система DNS окажется для него недоступной.

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

Исследование этих вопросов показало, что особых причин для беспокойства нет: большинство современных клиентов поддерживают расширение EDNS0, позволяющее передачу DNS-пакетов большего размера. Даже в противном случае, ответ на первичный запрос, не превышающий 512 байт, содержит достаточно информации для начала поиска. Тестирование также не выявило проблем с новыми записями в файле hints.

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

Адреса IPv6 первых шести КС были включены в корневую зону и файл hints 4 февраля 2008 года. Никаких значимых сбоев в работе глобальной системы DNS отмечено не было.

IDN

IDN расшифровывается как Internationalised Domain Names, или международные доменные имена, и означает возможность использования национальных алфавитов при задании имени домена или сервера. Технология весьма привлекательная, как с технической, так и с политической точки зрения, поскольку для пользователей с нелатинскими алфавитами она позволяет практически полностью исключить необходимость использования латиницы при работе в Интернете.

Однако базовый стандарт DNS допускает использование только 7-битной кодировки для символов, так называемую таблицу ASCII, да и то с некоторыми ограничениями для имен хостов. В то же время стандартной формой кодирования символов национальных письменных языков является Юникод (Unicode).

Для трансляции символов Юникода в набор допустимых символов DNS используется так называемый Пюникод (Punycode). Имена в Пюникоде выглядят немного странно, например, слово "испытание" будет представлено как xn--80akhbyknj4f, но зато они полностью соответствуют стандарту DNS.

Соответственно, любое приложение, поддерживающее национальные языки, должно транслировать доменное имя, введенное пользователем, в строку Пюникода. Далее все работает как обычно "клиент" DNS производит поиск для разрешения имени в адрес IP. Например, если пользователь набирает в окошке вэб-браузера "пример.испытание", поиск DNS будет произведен для имени xn--e1afmkfd.xn--80akhbyknj4f и в результате будет получен IP-адрес вэб-сервера - 199.7.85.17.

Тестирование IDN некоторые доменные операторы начали еще в 2001 году, а, начиная с 2003 года, ряд операторов доменов верхнего уровня открыли регистрацию поддоменов, содержащих IDN. В 2006 году ICANN начал тестирование IDN в корневой зоне, сначала в лаборатории, а затем и в реальном режиме. На сегодняшний день домен example.test представлен в корневой зоне на 11 языках, включая русский. Достаточно набрать http://пример.испытание, чтобы попасть на заглавную страницу этого проекта ICANN.

В настоящее время ведется обсуждение так называемого процесса "Fast Track", который позволит операторам существующих национальных доменов верхнего уровня зарегистрировать эти домена на национальных языках.

С использованием IDN связан и ряд проблем. Например, IDN открывает более широкие возможности для спуфинга (spoofing) имен, когда имя сервера внешне очень похоже на другое имя, но на самом деле использует другие символы, так называемые гомографы. Действительно, как отличишь www.paypal.com от www.pаypal.com в котором вторая буква "а" набрана кириллицей. По сравнению с обычными именами, где 1 похоже на l, а 0 на O, IDN содержит гораздо больше гомографов. Решение этой проблемы требует строгого контроля со стороны регистраторов доменов, ограничения числа поддерживаемых языков в рамках домена и запрета смешивания различных языков в доменном имени.

DNSSEC

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

В настоящее время поддержка DNSSEC весьма разбросана по дереву DNS, что в большинстве случаев не позволяет построить так называемые цепочки доверия. Отсутствует поддержка DNSSEC и в корневой зоне. Все это, по существу, сводит на нет преимущества DNSSEC.

Начиная с 2007 года подразделение ICANN IANA начало тестирование поддержку DNSSEC в корневой зоне в лабораторном режиме. С технической точки зрения тесты не выявили никаких проблем, однако отсутствие прогресса в этой области в первую очередь связано с вопросами контроля за содержимым корневой зоны и управления цифровыми ключами, преимущественно политического характера.

Укрепим Интернет против тотального прослушивания!

kemchuk — Fri, 29 Aug 2014 21:02:24 GMT

Укрепим Интернет против тотального прослушивания!

На прошлой встрече IETF88 в Ванкувере широко обсуждалась проблема всеобщего прослушивания, масштаб которой открылся благодаря разоблачениям Эдварда Сноудена. Я писал об этом в статье «Что мы знаем о защите информации в Интернете?» (http://www.ripn.net/articles/Anti-surveillance/).

С тех пор общественность и журналисты немного охладели к этой теме, политики выступили с нужными заявлениями, но проблема по своей сути и масштабу по-существу не изменилась. IETF же определил проблему в технических терминах и начал дискуссию об уязвимых местах протоколов и способах их устранения. За день до начала заседания IETF89 в Лондоне, IAB (www.iab.org) и W3C (www.w3c.org) совместно организовали рабочее совещание STRINT (https://www.w3.org/2014/strint/) в ходе которого попытались всесторонне рассмотреть угрозы, пути противодействия и имеющийся и желаемый инструментарий.

Анатомия тотального прослушивания

Анализ угроз

Прежде чем говорить о решениях проблемы, необходимо эту проблему определить. От того насколько верно определены параметры проблемы зависит и качество и полнота предлагаемых решений. В области безопасности для этого принято использовать т.н. модель угроз, которая помимо уязвимостей системы учитывает присутствие и мотивацию атакующего. Поскольку даже при наличии уязвимости, отсутствие у атакующего желания ее использовать, предполагает отсутствие атаки как таковой. Документ «Атака тотального прослушивания: модель угроз и определение проблемы» («Pervasive Attack: A Threat Model and Problem Statement», http://datatracker.ietf.org/doc/draft-barnes-pervasive-problem/?include_text=1) описывает следующие категории атак:

Широкомасштабный сбор Интернет-трафика
Атаки типа MITM (Man-in-the-middle, человек посередине, http://ru.wikipedia.org/wiki/Человек_посередине)
Использование имплантатов - модифицированного программного обеспечения или вредоносных программ.

Рассмотрим эти категории подробнее.

Широкомасштабный сбор Интернет-трафика

Как следует из документов, раскрытых Эдвардом Сноуденом, одним из способов получения больших объемов трафика оказался традиционный способ прослушивания опорных телекоммуникационных каналов. Газета The Guiardian в качестве примера приводит программу агентства GCHQ (http://www.gchq.gov.uk) под кодовым названием Tempora. В рамках этой программы проводится прослушивание 1500 основных каналов, обеспечивающих Интернет-связность Великобритании (http://www.theguardian.com/uk/2013/jun/21/how-does-gchq-internet-surveillance-work), обеспечивающее доступ к данным объемом 21.6 петабайт в день.

Другим вариантом является предоставление данных по требованию правоохранительных органов. Например, программа PRISM обеспечила агентству NSA (http://www.nsa.gov/) доступ к данным Google, Facebook, Microsoft, Skype, Apple, Yahoo. Точная информация о степени кооперации этих компаний отсутствует, но очевидно, что речь шла не о целевых запросах, а о сплошном сборе данных с последующим анализом.

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

Атаки типа MITM (человек посередине)

Прослушивание может также быть реализовано с использованием более активных атак, например, т.н. атак "человек посередине". В этих случаях атакуемый становится невидимым посредником в обмене информацией между отправителем и получателем. При этом данные могут быть как просто скопированы, так и модифицированы. Вариантов реализации такого рода атак несколько. Например известно, что программа NSA под кодовым именем QUANTUM использует несколько способов перехвата трафика HTTP, таких как изменение ответов DNS или использование HTTP перенаправления (код 302).

Другие варианты перехвата трафика могут использовать уязвимости глобальной системы маршрутизации и протокола BGP, перенаправляя потоки данных через сеть атакующего. Примером такого перенаправления является т.н. утечка маршрутов (route leaks), когда маршрут, полученный сетью-клиентом от одного провайдера транзита переанонсируется другому транзитному оператору. Атаки такого типа отнюдь не теоретические, нарушение политики клиент-провайдер было неоднократно замечено в Интернете. (См., например, статью «Why Google Went Offline Today and a Bit about How the Internet Works», http://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about).

Другим способом является захват префикса (prefix hijack) с возвратом трафика в прежнее русло - атака Пилосова-Капеллы (от этой атаке я писал в статье «Безопасность системы маршрутизации Интернета», http://www.ripn.net/articles/secure_routing/) . Атаки такого рода также случаются регулярно, см. статью Renesys «The New Threat: Targeted Internet Traffic Misdirection» (http://www.renesys.com/2013/11/mitm-internet-hijacking/).

Использование имплантатов - модифицированного программного обеспечения или вредоносных программ.

Известно также, что NSA использовало различные методы для ослабления систем шифрования и анонимности, используемых в Интернете - например, шифрования трафика с помощью технологий TLS (http://ru.wikipedia.org/wiki/TLS) или системы аномизации Tor (https://www.torproject.org/).

В пассивных и активных (MITM) атаках перехвата NSA активно применяло системы дешифровки с помощью цифровых ключей, собранных в рамках программы BULLRUN. Похоже, что в рамках этой и ряда других программ производилось систематическое внедрение "задних дверей" в криптографические технологии, коммерческие устройства и системы защиты. Некоторые примеры этой деятельности приведены в статье, опубликованной в Нью-Йорк Таймс «Secret Documents Reveal N.S.A. Campaign Against Encryption» (http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html?_r=0).

Архитектурная концентрация

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

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

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

На инфраструктурном уровне мы наблюдаем значительную концентрацию объема передаваемого трафика через трансатлантические каналы, инфраструктуры крупных дата-центров и точек обмена трафиком. Доступ к этим объектам означает доступ к колоссальному объему информации.

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

Наконец, на уровне приложений и услуг происходит колоссальное сосредоточение данных и метаданных в руках нескольких организаций. Количество пользователей Google, Facebook, Twitter, Skype идет на сотни миллионов, а обмен данными с этими концентраторами составляет значительный процент всего трафика Интернета. Например Google составляет четверть всего трафика североамериканских Интернет сервис-провайдеров, во много благодаря YouTube, конечно. Открытый DNS-резолвер Google Public DNS обслуживает 7% всех запросов! Хотя данные DNS не конфиденциальны, характер запросов может многое рассказать о пользователе.

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

Анализ трафика, данные и метаданные

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

Новый проект лаборатории Media Lab Массачусетского технологического института immersion (https://immersion.media.mit.edu/) позволяет получить предоставление, как много могут рассказать метаданные. Проект строит социальную сеть пользователя лишь анализируя «метаданные» его электронной почты – поля «From», «To», «Cc» и временные штампы. На рис.1 представлена сеть одного из моих почтовых аккаунтов.

Рис 1. Социальная сеть пользователя электронной почты, построенная проектом immersion в результате анализа метаданных. Размер круга обозначает интенсивность обмена, а цвета – принадлежность людей к той или иной группе.

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

Например, метод IdleScan (http://nmap.org/book/idlescan.html) позволяет определить наличие потоков данных между компьютерами в сети. Метод использует идентификационный номер фрагмента IP-пакета, т.н. IP ID. Многие операционные системы просто увеличивают этот индекс при отправлении каждого пакета.

В статье «Spying in the Dark: TCP and Tor Traffic Analysis» (http://freehaven.net/anonbib/papers/pets2012/paper_57.pdf) показано, что единственным требованием успешного наблюдения является то, что прослушиваемый пользователь также обменивается данными с сайтом атакующего. Отслеживая изменение индекса IP-ID в ответ на пробные пакеты, атакующий может достаточно достоверно установить факт обмена данными между определенными компьютерами. Этот метод может также достаточно успешно использоваться даже если пользователи используют анонимные сети Tor.

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

Проблема заключается в том, что метаданные гораздо труднее скрыть от посторонних глаз, чем сами данные. Основу метаданных составляют данные протоколов более низкого уровня, например, IP или транспортного – TCP. Другой проблемой является то, что многие метаданные широко используются в управлении сетями, например для мониторинга производительности, планирования и классификации трафика. Функционирование многих устройств сетевой защиты базируется на метаданных.

Но и для новых протоколов уменьшение "необходимых" сети метаданных может привести к блокированию трафика. Примером может служить высокая степень блокирования фрагментированного трафика. Дело в том, что фрагментированные IP пакеты не содержат достаточной информации о потоке данных и многие сетевые экраны такие пакеты попросту отбрасывают.

Арсенал

Оппортунистическое шифрование

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

Преимущества и необходимость шифрования канала очевидны, когда речь идет о приложениях электронной торговли или обмен конфиденциальной информацией. Но действительно, стоит ли шифровать канал доступа пользователя скажем к статьям Википедии или новостным сайтам? Имеет ли смысл шифрование обмена данных DNS, которые по определению являются общедоступными?

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

Чтобы лучше понять проблемы, связанные с шифрованием потоков на транспортном уровне, вкратце рассмотрим технологию TLS.

TLS, или Transport Layer Security (Безопасность транспортного уровня), представляет собой криптографический протокол, обеспечивающий как безопасность, так и целостность данных для потоков транспортного уровня на основе протокола TCP. TLS позволяет осуществлять обмен данными в Интернете, например между браузером и веб-сервером, не допуская подслушивания и фальсификации данных, тем самым обеспечивая аутентичность и конфиденциальность в публичных сетях. TLS является новейшей версией протокола SSL, хотя имя SSL по прежнему используется при разговоре о защищенных соединениях.

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

Процесс обмена ключами и создание защищенного канала TLS схематически представлен на рис.2.

Рис. 2. Фаза «рукопожатия» и создания защищённого канала в протоколе TLS при использовании системы кодирования RSA.

Для проверки подлинности отправителя, например веб-сервера, обычно используется инфраструктура публичных ключей (Public Key Infrastructure, PKI). Так, с помощью PKI вэб-браузер сможет проверить подлинность серверного сертификата, соответствие имени субъекта сертификата имени сервера и, в идеальном случае, не был ли сертификат отозван (revoked).

Оппортунистическое шифрование обычно означает, что при установлении соединения с сервером клиент изначально пытается использовать шифрование и выбирает открытый канал только, если попытка использования шифрования не удалась.

Наиболее известным примером оппортунистического шифрования является расширение STARTTLS (http://ru.wikipedia.org/wiki/STARTTLS), которое позволяет создать зашифрованное соединение прямо поверх открытого канала.

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

Perfect forward secrecy

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

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

Избежать такой ситуации позволяет криптографическая система при которой компрометация долговременного серверного ключа в будущем не позволит расшифровать прошлый обмен данными. Такая особенность системы получила название «идеальной прямой секретности» (perfect forward secrecy, или PFS).

В протоколе TLS PFS реализуется путем использования RSA только для аутентикации сервера, а для генерирования и обмена ключами – протокол Диффи-Хеллмана (Diffie-Hellman, http://ru.wikipedia.org/wiki/Протокол_Диффи_—_Хеллмана), позволяющий создать разделяемый секрет (симметричный ключ) между сторонами, обменивающимися данными по открытому каналу. В этом случае ключ для шифрования данных действует только на протяжении сессии, а затем уничтожается. Такие ключи получили название эфемерных, а алгоритм – DHE (Diffie-Hellman Ephemeral). Поскольку эти ключи независимы от долгосрочного серверного ключа, компрометация последнего не позволяет расшифровать прошлые обмены данными. Злоумышленнику в этом случае придется взламывать ключи для каждой сессии, что делает задачу доступа к данным почти невыполнимой.

Работа TLS в режиме DHE показана на рис. 3.

Рис.3. Обмен ключами в TLS по протоколу Диффи-Хеллмана с реализацией PFS.

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

Проблемы Web PKI

Под термином Web PKI обычно понимают систему аутентикации и шифрования веб-транзакций, основанную на технологии X.509 PKI, используемую сегодня производителями браузеров и операторами веб-сайтов. Суть системы проста – веб-сайт получает сертификат X.509 от удостоверяющего центра, именем субъекта сертификата является доменное имя сайта, а ключом сертификата является публичный ключ сайта. Сертификат используется протоколом TLS, и с его помощью клиент-браузер может шифровать и дешифровывать данные, которыми он обменивается в этим сайтом.

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

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

«Аккредитацию» и создание этого списка каждый производитель клиентского ПО – браузеров осуществляет самостоятельно на основании рекомендаций организации CAB (CA/Browser) Forum (https://cabforum.org). Например, с подробными требованиями, предъявляемыми к УЦ со стороны компании Mozilla, разработчика браузера Firefox, можно познакомиться на их сайте: http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/.

Другой особенностью является то, что компрометация «аккредитованного» удостоверяющего центра позволяет злоумышленнику создать необходимые сертификаты. Случай взлома УЦ DigiNotar в 2011 году – яркий тому пример (см., например, http://www.xakep.ru/post/59572/default.asp?utm_source=dlvr.it&utm_medium=twitter). Наконец, секретные агентства государств, в юрисдикции которых находится УЦ, имеют дополнительный рычаг воздействия на этот УЦ.

О некоторых из этих проблем я писал в статье «Путевые заметки: IETF-84» (http://www.ripn.net/articles/IETF84/). Там же я привел возможное решение многих проблем Web PKI - DANE (DNS-based Authentication of Named Entities). DANE позволяет владельцу доменного имени опубликовать сертификат TLS или указатель на доверенную систему PKI, в которой такой сертификат находится. Преимуществом этого подхода является то, что для проверки подлинности DANE использует систему, хотя и напоминающую PKI, но базирующуюся на DNS и полностью конгруэнтной с DNS - это DNSSEC. Таким образом обеспечивается такая же криптографическая защита, как и в традиционных PKI, но цепочка доверия полностью соответствует доменной иерархии. Другими словами, DANE позволяет получить достоверный сертификат от самого владельца имени без посредников.

Существующие протоколы

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

Для работы в этом направлении в IETF был начат процесс анализа существующих спецификаций. Желающие внести свой вклад могут зарегистрировать его на вики: https://trac.tools.ietf.org/group/ppm-legacy-review/.

Вопросы внедрения

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

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

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

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

Будем надеяться, что ответом на это станет качественно новый уровень защиты данных в Интернете.

IPv6: вчера, сегодня, завтра (Часть III; заключительная)

kemchuk — Fri, 29 Aug 2014 20:56:19 GMT

IPv6: вчера, сегодня, завтра (Часть III)

Стратегия развития: сосуществование IPv4 и IPv6

Начав читать эту заключительную часть «трилогии» вы, возможно, с недоумением обнаружите, что в ней протоколу IPv4 уделено, пожалуй, больше места, чем его последователю – IPv6. Почему же в статье о завтрашнем дне протокола IPv6 и, как следствие, Интернета в целом, мы уделяем столько внимания его предшественнику? Не является ли внедрение IPv6 в инфраструктуре сервис-провайдера решением проблемы отсутствия свободного пула адресов IPv4?

Сложность в том, что эффективность этого внедрения зависит от степени глобального проникновения и использования IPv6. На сегодняшний день, степень эта весьма невелика, как мы увидели в предыдущей статье. Соответственно невысока и эффективность инвестиций в IPv6 поскольку, внедрение IPv6 не решит проблем недостатка IPv4, ибо большая часть Интернета по-прежнему доступна только через протокол IPv4. Размер этой части Интернета определяет значимость протокола IPv4 и, в обратной пропорции, протокола IPv6 для сервис-провайдеров. Действительно, как только все ресурсы Интернета будут доступны с помощью обоих протоколов, необходимость в протоколе IPv4 отпадет. На этом положении, кстати, и была основана изначальная схема перехода к IPv6, так называемая схема “двойного стека”.

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

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

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

Рис.1. Динамика сосуществования IPv4 и IPv6

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

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

Однако многим сервис-провайдерам придется столкнуться с проблемой нехватки IPv4 и задуматься над ее решением.

Существует два способа решения этой проблемы. Первый - это получение дополнительных адресов IPv4. Однако в недалеком будущем обращение к RIPE NCC или другой Региональной Регистратуре не даст желаемого результата ввиду отсутствия свободно распределяемого адресного пространства, и адреса будут перераспределяться между игроками путем купли-продажи, дарения, объединения и поглощения компаний и т.п. Трудно сказать, как будет развиваться этот сценарий и насколько объемным и ликвидным окажется рынок адресного пространства. В любом случае, второй способ - повышение эффективности использования адресного пространства с помощью технологии NAT (Network Address Translation), - является более реальной альтернативой или дополнительным решением. Этот сценарий показан на графике кривой розового цвета.

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

Техническое отступление: как происходит передача данных в Интернете

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

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

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

Эта особенность, а именно, что отправитель и получатель данных в действительности адресуются парой {IP-адрес, порт}, используется в технологии NAT (Network Address Translation), или более точно - NAPT (Network Address & Port Translation). Другими словами, с помощью одного IP-адреса можно теоретически адресовать 65535 "соединений" - число, значительно превышающее потребности единичного пользователя. В этом случае устройство NAT для внешней сети будет выглядеть как компьютер с очень большим числом одновременно работающих приложений, в то время как на самом деле устройство NAT при передаче пакетов подставляет вместо порта и собственного IP-адреса (как адреса получателя с точки зрения внешних приложений) порт и локальный IP-адрес реального получателя. Обычно для адресации конечных устройств локальной сети, расположенной за устройством NAT используется специальное зарезервированное адресное пространство. Схема работы NAT показана на рисунке 2.

Рис.2. Схема работы NAT

Насколько эффективен NAT? Это зависит от характера приложений, работающих на конечных устройствах и интенсивности их взаимодействия с глобальным Интернетом. На сегодня, компьютер обычного пользователя создает от 60 до 100 соединений с различными ресурсами глобального интернета. Дело в том, что многие приложения открывают более одного соединения. Это в большей степени относится к вэб-приложениям. Например, Google Maps одновременно использует несколько десятков соединений. Но даже если эта цифра на порядок больше технология NAT позволяет более 60 пользователям совместно использовать один и тот же IP-адрес.

Звучит очень привлекательно. К сожалению, не все так радужно. Технология NAT содержит ряд серьезных недостатков, о которых мы поговорим позже. Здесь же отмечу, что NAT нарушает принцип "прозрачности" Интернета, о котором я говорил в предыдущих статьях. Помимо усложнения архитектуры сети, для полноценной работы некоторых приложений требуются дополнительные средства, такие как STUN (RFC5389, http://datatracker.ietf.org/doc/rfc5389/), ICE (RFC5245, http://datatracker.ietf.org/doc/rfc5245/), TURN (http://ru.wikipedia.org/wiki/Traversal_Using_Relay_NAT, RFC5766, http://datatracker.ietf.org/doc/rfc5766/). Использование каскадов NAT, когда в сети за устройством NAT расположены также NAT с "вложенными" сетями, только усугубляет эти проблемы.

Переходные технологии сосуществования

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

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

Давайте посмотрим, что же имеется в арсенале сервис-провайдеров.

Технологии туннелирования

Технологии тунелирования приходят на помощь, когда инфраструктура сервис-провайдера не поддерживает один из протоколов.

6to4

Технология 6to4 была стандартизована еще в 2001 году (RFC3056, http://datatracker.ietf.org/doc/rfc3056/) и с тех пор является наиболее распространенным методом для соединения изолированных островков IPv6 с другими такими же островами, а также глобальным Интернетом IPv6 через океан IPv4. Для этого используются автоматически создаваемые туннели.

Шлюз, или маршрутизатор 6to4, обеспечивает создание динамических туннелей путем инкапсуляции пакетов IPv6 в IPv4 для передачи через Интернет IPv4 к другому острову и декапсуляции входящего трафика. Для определения принимающего конца туннеля, шлюз извлекает адрес IPv4, который является адресом принимающего шлюза 6to4, из IPv6-адреса получателя.

Особенностью этого метода заключается в том, что все островки 6to4 совместно используют адресное пространство, определяемое префиксом 2002::/16. При этом адресное пространство каждого островка определяется путем "присоединения" к 16 битам префикса 2002 32 бит IPv4-адреса шлюза 6to4. Например, если IPv4-адрес шлюза 193.0.7.5, то адресное пространство сети 6to4 определено префиксом 2002:c100:705::/48.

Для обеспечения связности с глобальным Интернетом IPv6 используются так называемые релеи 6to4. Это также шлюзы 6to4, однако, они являются интерфейсом между сетями 6to4 и остальным Интернетом IP6. Для избежания необходимости задания адресов релеев вручную, все они имеют один и тот же адрес - 192.88.99.1, который анонсируется с использованием технологии аникаст (anycast, http://ru.wikipedia.org/wiki/Anycast).

Схема работы системы 6to4 представлена на рисунке 3.

Рис. 3. Схема работы технологии 6to4

Хотя эта технология является наиболее популярной, намного опережающей подобные туннельные технологии как ISATAP и Teredo, ее применимость в основном ограничена пользователями-энтузиастами и небольшими корпоративными сетями. Для серьезных игроков больший интерес представляют технологии 6rd и DS-lite.

6rd

Одним из недостатков 6to4 является отсутствие контроля над релеем, обеспечивающим выход в глобальный IPv6. Поэтому невозможно гарантировать какие-либо параметры качества и связность, не говоря о том, что и выбор конкретного релея происходит автоматически, используя технологию аникаст.

На помощь здесь приходит метод 6rd (RFC5969, http://datatracker.ietf.org/doc/rfc5969/), о нем я немного писал в предыдущей статье. Эта технология решает проблему предоставления доступа к IPv6 пользователям провайдера широкополосного доступа без необходимости поддержки IPv6 в сети самого провайдера.

Во-первых, сеть 6rd использует собственное адресное пространство IPv6, полученное от Региональной Интернет Регистратуры. Это позволяет сервис-провайдеру анонсировать реальные IPv6-префиксы и, таким образом, более точно определять собственную политику маршрутизации.

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

Эти отличия показаны на рисунке 4.

Рис. 4. Схема работы технологии 6rd

DS-lite

DS-lite (http://datatracker.ietf.org/doc/draft-ietf-softwire-dual-stack-lite/) в некотором смысле является зеркальной технологией по отношению к 6rd. DS-lite предполагает, что сеть провайдера полностью поддерживает IPv6, а туннели используются для передачи трафика IPv4 от сети пользователя к устройствам NAT сервис-провайдера. Также предполагается, что устройства сети пользователя поддерживают "двойной стек", а именно протокол IPv4 и IPv6.

Суть этого метода заключается в совместном использовании технологий туннелирования (инкапсуляция трафика IPv4 в пакеты IPv6) и централизованного NAT, или LSN (Large Scale NAT, также называемого CGN, Carrier Grade NAT), с целью обеспечения совместного использования ограниченного пула адресов IPv4 всеми пользователями сервис-провайдера. При этом обмен трафиком с ресурсами Интернет, доступными по протоколу IPv4, происходит с использованием этого протокола, а с ресурсами IPv6 - с использованием IPv6. Эта схема не предусматривает трансляции протоколов.

Рис. 5. Схема работы DS-lite

Как можно заметить из рисунка 5, на котором представлена схема работы DS-lite, обмен трафиком с ресурсами IPv6 происходит непосредственно, без использования каких-либо промежуточных технологий, например, туннелей.

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

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

Задачей DS-lite является исключение каскадирования устройств NAT, когда все устройства пользователей непосредственно взаимодействуют с центральным устройством NAT сервис-провайдера. В этом случае оконечное устройство пользователя не выполняет никаких функций NAT, а вместо этого обеспечивает создание туннелей к центральному NAT для каждого нового соединения между приложениями пользователя и сервисами Интернета.

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

Говоря о прозрачности, одной из основных сложностей, связанных с применением NAT, является проблема контроля приложений за значениями порта и IP-адреса соединений, поскольку устройство NAT заменяет их на динамически присваиваемые. От этого зависит нормальное функционирование некоторых приложений, например, большинства мультимедийных интерактивных приложений. На сегодняшний день разработаны несколько механизмов решения этой проблемы, такие как STUN, ICE и TURN. Очевидно, что каскадирование устройств NAT усложняет ситуацию.

Отмечу, что технология DS-lite не предусматривает поддержку устройств, работающих только по протоколу IPv6. Для этого используются технологии трансляции.

Технология трансляции: NAT64 + DNS64

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

Для взаимодействия таких сетей с Интернетом IPv4 необходимо применение трансляции адресов IPv6 в адреса IPv4 и обратно. Ввиду недостатка ресурсов IPv4, здесь, как и в случаях, рассмотренных выше, необходимо применение мультиплексирования потоков. По существу, в этой ситуации используются технологии централизованного NAT с внедрением дополнительной функции трансляции протоколов. Этот компонент еще называют NAT64 (http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful/). Взаимодействие с другими сетями IPv6 происходит прозрачно. Эта архитектура показана на рисунке 6.

Рис.6. Архитектура системы трансляции протоколов NAT64

Однако в данной схеме есть одна особенность, а именно необходимость дополнительной поддержки одного из наиболее критических приложений Интернета - системы доменных имен DNS.

Дело в том, что для большей части ресурсов Интернет запрос DNS вернет адрес IPv4. Поскольку сети, о которых идет речь, поддерживают только IPv6, такой ответ DNS вряд ли окажется полезным. Для решения этой проблемы используется дополнительный компонент - шлюз приложений (Application Layer Gateway, ALG). Суть его заключается в замещении адреса IPv4 в ответе DNS на синтезированный адрес IPv6, понятный клиенту, а также транслятору протоколов NAT64. Более подробно работу DNS ALG я рассмотрел в статье "Из жизни IP адресов. Перспективы протокола IPv4 и перехода к адресации IPv6".

Игроки и их потребности

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

Провайдеры транзита

Под провайдерами транзита я имею в виду сети, клиенты которых как правило самостоятельные сети со своим собственным адресным пространством. Услуги транзита, которые предоставляют такие операторы, обеспечивают этим клиентам глобальную связность.

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

Можно с уверенностью сказать, что проблемы переходного периода для операторов транзита не являются существенными.

Корпоративные сети

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

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

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

Провайдеры широкополосного доступа

Эти провайдеры обеспечивают широкополосный доступ к Интернету для "домашних" пользователей, с использованием кабельной или телефонной инфраструктуры доступа с помощью технологий DOCSIS и ADSL.

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

Для преодоления проблем переходного периода этим провайдерам скорее всего, придется прибегнуть к уже обсуждавшимся технологиям централизованного NAT-мультиплексирования совместно с технологиями туннелирования DS-lite или 6rd. Это может потребовать достаточно значительного изменения инфраструктуры, включая системы обслуживания, мониторинга и билинга. В большинстве случаев желательна также поддержка IPv6 пользовательскими оконечными устройствами (Customer Premise Equipment, CPE), например кабельными- или ADSL-модемами.

Все это говорит о том, что здесь требуется существенная подготовка и инвестиции. Несвоевременная модернизация инфраструктуры может существенно снизить эффективность инвестиций (например, замена оконечного оборудования вне нормального цикла модернизации), ограничить возможность роста и снизить конкурентоспособность провайдера.

Дополнительным осложнением может явиться требование доступности отдельных услуг, предоставляемых в сети пользователя (т.н. домашний офис – SOHO), например вэб-сайтов, из глобального Интернета. Сегодня такая возможность обычно реализуется конфигурацией фиксированной трансляции определенных адресов и портов (т.н. port forwarding) на оконечном устройстве, которое находится под контролем самого пользователя. Новая архитектура потребует кооперации со стороны самого сервис-провайдера, обслуживающего LSN. Для автоматизации этого процесса в IETF в настоящее время разрабатывается протокол контроля распределения портов (Pinhole Control Protocol, PCP, http://datatracker.ietf.org/doc/draft-ietf-pcp-base/).

Мобильные операторы

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

К тому же, по сравнению с широкополосным пользовательским доступом, услуга передачи данных менее насыщенна. Например, в развивающихся регионах, несмотря на значительное проникновении сотовой связи, мобильный Интернет только набирает обороты. Даже в развитых Европейских странах только 60% абонентов пользуются услугами передачи данных. Учитывая, что распространение услуги происходит по так называемой S-кривой, можно предположить, что скорость проникновения мобильного Интернета в сотовые сети будет только расти.

Во многих случаях технология двойного стека (например, используемая в DS-lite) является экономически нецелесообразной, поэтому наиболее перспективным является применение механизмов трансляции, когда мобильная сеть поддерживает исключительно IPv6, а для доступа к ресурсам, доступным только по IPv4, используется схема NAT64+DNS64.

Провайдеры распределенного контента и просто контент-провайдеры

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

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

Наиболее целесообразным подходом для контент провайдеров является использование стандартной модели "двойного стека", когда ресурс доступен непосредственно как по протоколу IPv4, так и по протоколу IPv6.

Для провайдеров распределенного контента проблема переходного периода является более сложной.

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

Другая причина связана с доступом к контенту по протоколу IPv6, а именно пока что более низкая средняя производительность и параметры качества Интернета IPv6. Об этой проблеме я рассказывал в предыдущей статье на примере Google и Akamai.

Серьезность проблемы

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

Итак, давайте посмотрим на состояние дел в различных регионах земного шара. Для этого я обратился к статистическим данным на сайте http://www.internetworldstats.com и к статистическим источникам общего назначения.

Например, в Германии с их 82 миллионами населения и 35 миллионами домашних хозяйств, уровень проникновения составляет 79%. Учитывая среднюю скорость роста за последние 10 лет (150%), потребность в дополнительном адресном пространстве IPv4 в год составит порядка /12^¹ для провайдеров широкополосного доступа и /12 для мобильных операторов. Другими словами - /11 на всю страну. А с учетом мультиплексирования потоков с применением технологии NAT (принимая повышение эффективности в 64 раза) эта цифра окажется равной /17.

В то же время для России цифры еще менее радужны. Если верить статистике, в стране с населением в почти 140 миллионов насчитывается примерно 60 миллионов пользователей Интернета. При этом количество распределенных адресов IPv4 в этом регионе (http://www.bgpexpert.com/addrspace2010.php) составляет всего 35 миллионов. Это означает, что утилизация адресного пространства уже превышает 100% и использование технологий NAT носит масштабный характер. Это также означает, что получение дополнительных адресов, потребность в которых в год предположительно составляет порядка /10 для широкополосных операторов и /13 - для мобильных (с учетом текущего уровня использования передачи данных абонентами сотовой связи), практически невозможно путем реструктуризации внутренних или неиспользуемых ресурсов.

Еще более серьезной является ситуация в Китае и Индии, где потребность в адресном пространстве выражается цифрами /6 - /7! Даже с применением NAT-мультиплексирования цифра остается гигантской и выражается миллионами адресов IPv4.

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

Проблемы технологий сосуществования

Как мы увидели, все технологии сосуществования предусматривают применение NAT-мультиплексирования для IPv4, необходимое для того, чтобы "перешагнуть порог" дополнительного, но отсутствующего адресного пространства IPv4 (см. Рис. 1).

Однако масштабное использование NAT-мультиплексирования несет в себе существенное усложнение архитектуры и ряд серьезных проблем. О некоторых из них я уже писал в моей статье "Из жизни IP адресов. Перспективы протокола IPv4 и перехода к адресации IPv6", но здесь также остановлюсь на важных аспектах.

Приложения

Некоторые приложения не смогут нормально функционировать и потребуют дополнительных решений и поддержки (я уже упомянул это при обсуждении каскадирования NAT). К таким приложениям относятся протоколы предусматривающие инициацию входящих соединений, использующих предопределенные порты (well known ports), фиксирующие значение адреса получателя или отправителя в передаваемых данных, а также предполагающие уникальность IP-адреса.

Идентификация

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

Безопасность

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

Качество связи

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

Эти и другие проблемы тщательно анализируются в документе IETF «Issues with IP Address Sharing» http://tools.ietf.org/html/draft-ietf-intarea-shared-addressing-issues. Многие из этих проблем не новы, но масштабность их проявления в будущем потребует более сложных и дорогостоящих решений, чем сегодня.

Альтернативные сценарии развития

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

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

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

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

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

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

Вероятность развития второго сценария зависит от того, насколько быстро будет происходить проникновение услуги передачи данных в сотовых сетях. Напомню, что в отличие от широкополосного доступа, размер клиентской базы пропорционален населению в регионах, где степень проникновения сотовой связи на сегодняшний день во многих случаях близка или даже превышает 100% (несколько сотовых номеров на человека). И хотя в тех же регионах, и Россия находится среди них, процент использования услуги передачи данных по различным оценкам находится в диапазоне от 5 до 30%, эта цифра в короткий срок может подскочить до 60% (цифра, характерная для стран северной Европы) и выше. Инфраструктура в большинстве случаев готова, мобильные устройства поддерживают и все больше требуют (возьмите, например, современные смартфоны iPhone, Samsung, Blackberry) наличие мобильного Интернета.

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

Но у мобильных операторов есть альтернатива. А именно, предоставлять только услуги, основанные на IPv6. Да, не все ресурсы будут доступны, но и затраты на предоставление мобильного Интернета изменятся незначительно. К тому же, для многих пользователей окажется приемлемой неполная функциональность Интернета, например доступность только Google и ресурсов, хранимых в его кэше, Facebook и Twitter. А возможность предоставление этих ресурсов по протоколу IPv6 при наличии спроса несомненна.

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

Безусловно, такое развитие событий является наиболее предпочтительным. Данный сценарий позволит существенно сократить переходный период, упростить или, по крайней мере, не сильно усложнить архитектуру Сети.

Заключение

Какой из трех сценариев воплотится в будущем? Как изменится архитектура Интернета в результате этого перехода? На эти вопросы трудно дать однозначный ответ.

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

IPv6: вчера, сегодня, завтра (Часть II)

kemchuk — Fri, 29 Aug 2014 20:54:13 GMT

IPv6: вчера, сегодня, завтра (Часть II)

Взгляд на текущий уровень внедрения IPv6

Итак, спустя более декады степень проникновения IPv6 по-прежнему невелика. По различным оценкам эта цифра колеблется между 1.5 и 5.5 %. Гораздо меньше, чем должно было быть согласно изначальной схеме перехода от протокола IPv4 к протоколу IPv6. Согласно этому плану переход к IPv6 предполагал параллельное использование обоих протоколов всеми устройствами Сети задолго до опустошения пула свободных адресов IPv4, и как следствие, возможность простого "отключения" IPv4 по достижении этой точки. В свое время Geoff Huston схематически представил это следующей диаграммой, рис.1:

Рис. 1. Переход к протоколу IPv6 по схеме «двойного стека» (источник: Geoff Huston “Is the Transition to IPv6 a "Market Failure?", http://www.potaroo.net/ispcol/2009-09/v6trans.html)

Этого не произошло по различным причинам, о которых я говорил в предыдущей статье. Это означает, что изначальный план перехода "двойного стека" скорее всего, провалился и самое время задуматься над альтернативными сценариями. Благо в IETF уже не первый год ведется активная работа по стандартизации альтернативных механизмов перехода. Но это проблема завтрашнего дня и о ней мы поговорим в следующей статье. А сегодня мы оценим реальное состояние дел в области внедрения IPv6. Начнем с того, что попытаемся разобраться, насколько готова базовая инфраструктура Интернета к новому протоколу.

Готовность инфраструктуры

Рис. 2. Распределение адресного пространства IPv6 Региональными Интренет-Регистратурами (источник http://www.nro.net/statistics/index.html)

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

На рисунке 2 представлена диаграмма распределения адресного пространства IPv6 по годам Региональными Интернет-регистратурами (РИР). Видно, что в последние три года число запросов IPv6 значительно возросло, достигнув около 1300 выделенных блоков в этом году. Как правило, изначально полученного адресного блока сервис-провайдерам хватает надолго, поэтому количество распределенных блоков соответствует числу сетевых операторов, по крайней мере, планирующих заняться внедрением IPv6. Начиная с 1999 года, РИРы совместно распределили более 4700 адресных блоков IPv6.

Более реальную картину об использовании IPv6 можно получить, анализирую систему маршрутизации Интернета. Анонсирование префиксов IPv6 подразумевает, что хотя бы часть инфраструктуры сервис провайдера поддерживает этот протокол, хотя все же мало говорит об IPv6-пользователях и информационных ресурсах этого провайдера. Некоторые исследования (например, http://www.cs.princeton.edu/~jrex/papers/ipv6-pam09.pdf показывают, что более половины распределенных префиксов никогда не анонсируются в глобальном Интернете. Если мы посмотрим на график роста числа автономных систем, анонсирующих хотя бы один префикс IPv6 (рис. 3), можно заметить, что их число действительно значительно меньше, чем число распределенных блоков адресов IPv6. На сегодняшний день процент автономных систем, или другими словами, отдельных сетей, поддерживающих в той или иной степени IPv6, составляет 8%.

Рис. 3. Рост числа анонсируемых IPv6-префиксов и автономных систем их анонсирующих (источник http://www.ipv6actnow.org/info/statistics/)

Рис. 4 Поддержка IPv6 участниками точек обмена трафиком (источник: презентация Thorleif Wiik, BCIX на 17 форуме Euro-IX, сентябрь 2010г.)

Важным катализатором внедрения IPv6 является поддержка этого протокола точками обмена трафиком (Internet eXchange Points, IXP). Насколько же готовы точки обмена трафиком к IPv6? Из диаграммы на рисунке 4 можно увидеть, что степень готовности сервис-провайдеров – членов IXP - существенно варьируется. Так 75% участников точки обмена трафиком Telx в Нью-Йорке поддерживают IPv6, в то время как в Санкт-Петербурге эта цифра составляет 12%.

Оценка реального трафика IPv6 гораздо менее впечатляюща. Например, процент трафика IPv6 в точке обмена трафиком в Амстердаме, AMS-IX, достигает 2%, для большинства IXP эта цифра колеблется около 1%.

Информационные ресурсы

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

В этом смысле доступность информационных ресурсов по протоколу IPv6 является важным индикатором готовности Интернета к новому протоколу.

Полезным, в этом смысле, будет взглянуть на доступность наиболее популярных вэб-сайтов по протоколу IPv6, используя рейтинги популярности Alexa (www.alexa.com). На рисунке 5 показан процент вэб-сайтов в категориях наиболее популярных 10, 100, 1000 и 10000, обеспечивающих доступ к ресурсам по протоколу IPv6. Как видно из графика, только четыре из наиболее популярных 100 сайтов поддерживают IPv6. Средняя цифра по всем информационным ресурсам довольно неутешительна. Также вызывает озабоченность факт, что в этом году не проявилось какой-либо тенденции к изменению этого плачевного состояния дел. Ведь именно владельцы информационных ресурсов могут разрешить проблему курицы и яйца, когда наличие услуг IPv6 у интернет сервис-провайдера не дает никаких дополнительных преимуществ его клиентам, а поддержка вэб-сайтом IPv6 не имеет смысла, так как только мизерное число потенциальных пользователей могут воспользоваться этим протоколом.

Рис. 5. Процент вэб-сайтов в категориях Alexa (www.alexa.com) топ-10, топ-100, топ-1000, топ-10000, поддерживающих доступ по протоколу IPv6 (источник: http://ipv6monitor.comcast.net/)

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

Рис. 6. Сравнительная скорость доступа к информационным ресурсам с использованием протоколов IPv4 и IPv6 (источник: отчет ОЭСР http://www.oecd.org/dataoecd/48/51/44953210.pdf)

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

Фактическое использование IPv6

Итак, доступность контента разочаровывает, хотя готовность инфраструктуры вселяет некоторую надежду. Самое время взглянуть на использование протокола конечными пользователями.

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

Этот метод был использован, в частности, в исследованиях Google, RIPE NCC (www.ripe.net) и Sander Steffann (http://ipv6test.max.nl).

Анализ данных, сбор которых Google производит начиная с 2008 года, обнаруживает некоторые интересные особенности реального использования IPv6. Например, процент пользователей, использующих IPv6 при наличии такой возможности, по-прежнему невысок и колеблется около 0.25%. При этом отсутствует четкая тенденция роста, в то время как использование различного рода туннельных технологий устойчиво уменьшается в пользу непосредственной поддержки IPv6 (рис.7). В качестве технологий туннелирования наиболее популярной является 6to4. Вслед за ней следуют протоколы Teredo и ISATAP. Все эти протоколы позволяют компьютерам, подключенным к сети, поддерживающей только протокол IPv4, обмениваться данными с сетями IPv6 с использованием автоматически создаваемых туннелей. При этом все они предполагают наличие соответствующей глобальной инфраструктуры – конфигурационных серверов для преодоления устройств NAT в случае Teredo, рэлеев (Teredo и 6to4) или маршрутизаторов ISATAP, обеспечивающих декапсуляцию данных и передачу их из туннеля в нормальную сеть и обратно. Все эти технологии призваны объединить локальные островки IPv6 друг с другом и с «большой землей» - незначительной частью Интернета с глобальной IPv6-связностью.

Рис. 7. Степень использование IPv6 конечными пользователями (источник: Google, см. также http://www.google.com/intl/en/ipv6/statistics/)

Похожее исследование, проведенное RIPE NCC (http://labs.ripe.net/Members/emileaben/content-measuring-ipv6-web-clients-and-caching-resolvers-part-1), показывает более высокие числа - в среднем 1.2% пользователей сайта www.ripe.net используют IPv6. Скорее всего, это связано с большей технической ориентированностью этой аудитории.

Также интересно отметить степень распространения IPv6 в пользовательской среде в различных странах (рис. 8). По результатам исследования Google в этом отношении лидирует Франция, где более 1.2% пользователей имеют доступ к IPv6-ресурсам. Высокий процент обусловлен лидирующим положением в области внедрения IPv6 крупнейшего национального сервис-провайдера Free (о технологии "быстрого внедрения", используемой Free, мы поговорим чуть позже). Хотя Россия и Украина занимают почетные 2-е и 3-е места, по уровню внедрения реального IPv6 вслед за Францией стоит Китай. Использование туннельной технологии 6to4 в России и Украине хотя и говорит об интересе пользователей к IPv6, но не означает, что инфраструктура сервис-провайдеров поддерживает новый протокол.

Рис. 8. Степень распространения IPv6 в пользовательской среде в различных странах (источник: Lorenzo Colitti, Steinar H. Gunderson, Erik Kline, Tiziana Refice “Evaluating IPv6 Adoption in the Internet”, Google)

Ведущие игроки: успехи и проблемы

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

Google

Инженеры Google провели огромную работу по внедрению IPv6. Первым публичным шагом стало появление отдельного сайта, поддерживающего IPv6 - ipv6.google.com. Хотя практическая ценность такого нововведения невелика, это, в то же время, продемонстрировало на практике, что IPv6 может быть внедрен относительно небольшими усилиями. Это также явилось свидетельством серьезности намерений Google в этой области.

Следующим шагом явилось поддержка IPv6 основным сайтом Google. Тут Google столкнулся с проблемой – в результате ошибок конфигурации потенциальных клиентов IPv6 этот ресурс просто становился для них недоступным. Например, поддержка IPv6 в локальной сети организации в некоторых случаях приводит к разрешению DNS-имени в адрес IPv6 (т.н. запись AAAA), в то время как реальная сетевая связность сети с глобальным IPv6-Интернетом может отсутствовать. Также, во многих случаях, время доступа с помощью IPv6 проигрывает конкурирующему IPv4. В результате сайт получает меньшее число хитов, что ведет к уменьшению рейтинга и помещаемой рекламы и, в конечном итоге, прибыли и конкурентоспособности. То, что ни одна коммерческая компания терять не намерена.

Частичным решением этой проблемы стал так называемый метод "белых списков" (whitelisting). Суть его состоит в регистрации сетей (а точнее, сетевых резолверов DNS), обеспечивающих полноценный доступ IPv6 и техническую поддержку для своих пользователей. Пользователи таких сетей при разрешении имени www.google.com получат также IPv6-адрес этого сайта и смогут использовать этот протокол для доступа к Google. Пользователям незарегистрированных сетей www.google.com по-прежнему доступен только по протоколу IPv4. Если вы хотите подробнее познакомиться с этим методом - обратитесь на сайт Google http://www.google.com/intl/en/ipv6/, там же вы можете подать заявку на участие.

Хотя этот метод позволяет крупным контент-провайдерам постепенно внедрять IPv6 в глобальном масштабе, ограничения этого подхода очевидны. Основным является отсутствие масштабируемости. Этот подход также стал предметом критики между контент-провайдерами и сервис-провайдерами широкополосного пользовательского Интернета, таких как, например, Comcast. Последние опасаются, что данные соглашения передают чрезмерный контроль в руки контент-провайдеров и в дальнейшем могут приобрести коммерческий характер.

Akamai

Akamai является одним из ведущих провайдеров распределенного контента (Content Distribution Network, CDN), предоставляющий услуги таким компаниям как NBA, Clear Channel и Fox Interactive. Через сеть Akamai проходит от 15 до 30 % интернет трафика, общей производительностью, превышающей 4 терабит/с. Внедрение IPv6 в сети Akamai может существенно увеличить долю IPv6-Интернета, поскольку все клиенты Akamai получат возможность предоставлять свои информационные ресурсы также по протоколу IPv6.

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

Также, все системы регистрации, отчетности и финансового учета должны быть обновлены для поддержки нового протокола. Это, пожалуй, посложнее проблемы 2000 года!

T-mobile

Американское подразделение T-mobile в этом году объявило пользовательское тестирование мобильной сети с использованием протокола IPv6. Для участия в тестировании пользователи должны быть подписчиками T-mobile USA с неограниченным планом по передаче данных, и обладать телефонами Nokia 5230 Nuron, Nokia E73 или Nokia N900. Тестовая сеть основана на технологиях трансляции NAT64 (со шлюзом DNS - DNS64), о которой я писал в статье “Из жизни IP адресов. Перспективы протокола IPv4 и перехода к адресации IPv6.”

Интересно отметить, что вы не найдете объявления о тестировании на официальном сайте T-mobile, но в описании теста на Google Groups (http://groups.google.com/group/tmoipv6beta) пользователей предупреждают, что многие приложения как, например, Visual Voice Mail, MyAccount, MMS не будут работать, а поддержка тестирующих будет осуществляться только через форум Google Groups.

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

Сотрудники Ericsson Jari Arkko и Ari Keränen провели эксперимент по доступности различных сервисов и информационных ресурсов Интернета для сети, поддерживающей только протокол IPv6. Для этого они использовали собственное решение NAT64+DNS64 и мобильные телефоны, поддерживающие IPv6. Общее заключение - решение в целом работает, но многие приложения недоступны.

В частности, большая часть вэб-ресурсов доступна без проблем. Если обычно (с использованием протокола IPv4) процент ошибок доступа составляет около 1%, то при трансляции эта цифра в два раза больше. Причинами являются ошибки DNS, блокирование экранами безопасности, использование так называемых "литералов" IPv4 (адреса IPv4 явно заданные, либо как часть контента HTML или протокола, например http или xmpp) и тому подобное. Удивительно небольшая цифра!

К сожалению не все так радужно для других приложений. Например, Skype, Gtalk, MSN и ICQ заставить работать не удалось. Не работают и большинство игр, за исключением использующих вэб-интерфейс. Так что с "Lord of the Rings" или "Secondlife" на вашем мобильнике придется пока подождать.

Comcast

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

Общий план внедрения IPv6 Comcast состоит из трех фаз. В первой фазе, в которой проект находится в настоящее время, помимо внедрения IPv6 во внутренней сети управления и ограниченных пилотных проектов с непосредственной поддержкой IPv6, основной упор делается на предоставлении доступа к IPv6 всеми имеющимися средствами. Это и давно использующиеся технологии туннелирования 6to4 и относительно недавно разработанная ее вариация 6rd, хорошо зарекомендовавшая себя во французской сети Freenet.

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

Наконец, в заключительной фазе, к которой компания планирует перейти по мере полного опустошения пула свободных адресов IPv4, IPv6 станет основным протоколом, в то время как доступ к ресурсам, доступным только посредством IPv4, будет происходить с использованием туннельных технологий, например DS-lite (http://datatracker.ietf.org/doc/draft-ietf-softwire-dual-stack-lite/).

Free

В 2007 году Rémi Després, который в семидесятых был одним из создателей сети передачи данных Transpac, предложил второму по величине провайдеру широкополосного доступа во Франции - Free (www.free.fr) - решение, позволяющее быстро внедрить IPv6 без значительных капиталовложений. Решение это, которое Rémi назвал 6rd (от rapid deployment, а также от инициалов его создателя), настолько понравилось техническому директору Free, что спустя всего 5 недель эта технология была успешно внедрена, а пользователи сети получили возможность использования IPv6.

Технология 6rd особенно эффективна для сервис-провайдеров широкополосного Интернета, поскольку не требует внедрения IPv6 в сети доступа. Суть ее заключается в построении автоматического туннеля между «домашним шлюзом» пользователя и 6rd релэя, являющимся интерфейсом к IPv6-Интернету. В этом смысле идея очень похожа на давно используемую технологию 6to4. Основное различие заключается в том, что 6to4 использует открытые релэи, доступные по предопределенному адресу IPv4, при этом технология аникаст позволяет пользователю выбрать топологически ближайший релэй.

В случае 6rd релэй является частью инфраструктуры сервис-провайдера и, соответственно предоставляет туннельный доступ только для собственных пользователей, в отличие от анонимного доступа в случае 6to4. Также, в 6rd используются реальное адресное пространство IPv6, полученное через систему РИРов, что позволяет сервис-провайдеру анонсировать реальные IPv6-префиксы и, таким образом, более точно определять собственную политику маршрутизации.

Возвращаясь к сети Free, технология 6rd позволила Франции занять ведущее место по внедрению IPv6, а пользователям Free – получить доступ к ресурсам IPv6 без дополнительных затрат.

Заключение

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

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

Я не знаю ответов на эти трудные вопросы. Но в следующей статье мы попробуем взглянуть на различные сценарии развития событий и стратегии, которые могут выбрать участники экосистемы под названием Интернет.

IPv6: вчера, сегодня, завтра (Часть I)

kemchuk — Fri, 29 Aug 2014 20:52:18 GMT

IPv6: вчера, сегодня, завтра (Часть I)

Интернет - поистине удивительный феномен! Трудно переоценить его инновационный потенциал, и в то же время Интернет крайне консервативен и с большой неохотой реагирует на изменения. Работа Сети основана на взаимодействии и кооперации между сервис-провайдерами, и, тем не менее, Интернет демонстрирует яркий индивидуализм, когда дело доходит до усилий на благо всего сообщества.

Парадоксы этой уникальной экосистемы можно отчетливо увидеть в истории протокола, который должен стать протоколом будущего Интернета - IP версии 6. О нем и пойдет речь в этой статье.

На самом деле - это три статьи под общим названием "IPv6: вчера, сегодня, завтра", каждая из которых посвящена определенному периоду, связанному с IPv6. В первой статье, "вчера", мы обернемся назад, чтобы увидеть истоки IPv6, его возможности и связанные с ним надежды, а также проанализируем, почему спустя десятилетие уровень проникновения IPv6 очень мал.

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

Наконец, в статье "завтра" я попробую заглянуть в будущее, хотя хочу сразу предупредить, что даром ясновидения не обладаю. Несмотря на то, что внедрение протоколаIPv 6 является необходимым условием долгосрочного развития открытого Интернета, в непосредственном будущем основной проблемой многих сервис-провайдеров может стать продолжающаяся потребность в дополнительных адресахIPv4. Победит ли IPv6 в этих условиях или станет жертвой корпоративного эгоизма?

И.А.Бродский когда-то сказал: "Настоящему, чтобы обернуться будущим, требуется вчера". С этого вчера мы и начнем.

Истоки

Если вы думаете, что протокол IPv6 является "новым" - это не совсем так. Базовая спецификация этого протокола была опубликована 12 лет назад (RFC2460, http://datatracker.ietf.org/doc/rfc2460/), а работа над его созданием началась в начале девяностых годах прошлого столетия.

Работа эта, как это ни покажется странным, была вызвана проблемой нехватки адресного пространства. И это почти 20 лет назад! Тогда эта проблема была на время решена изменениями архитектуры маршрутизации - CIDR (Classless Inter-Domain Routing, RFC 1518, http://datatracker.ietf.org/doc/rfc1518/) и соответствующими изменениями в распределении адресного пространства (RFC1519, http://datatracker.ietf.org/doc/rfc1519/), обеспечившие значительно более эффективное его использование.

Также интересно отметить, что начало этой работы ознаменовалось конфликтом, который привел к ревизии процесса принятия решений вIETF, что в то время означало - в Интернете. То, что сегодня называется размытым термином Internet Governance.

Итак, в 1991-92 годах IETF и все техническое сообщество было серьезно озабочено проблемами нехватки адресного пространства с одной стороны и неудержимого роста таблиц маршрутизации - с другой. Для анализа этих проблем и выработки решений была специально сформирована группа ROAD (ROuting and ADressing, Маршрутизация и Адресация). Группа выработала конкретные краткосрочные рекомендации (такие как, например, CIDR), однако достичь консенсуса относительно долгосрочных решений, в частности в области увеличения адресного пространства, группе не удалось.

В июне 1992 года комитет IESG (IETF Engineering Steering Group) рассмотрел эти предложения и рекомендовал более глубокое обсуждение возможных решений с целью лучшего понимания последствий и модели переходного периода (RFC 1380, http://datatracker.ietf.org/doc/rfc1380/). В то же время, новые предложения как решить проблему большего адресного пространства, продолжали поступать.

Двумя неделями позже IAB провел рабочее совещание в рамках которого выработал собственные рекомендации (http://www.ripe.net/ripe/maillists/archives/ripe-list/1992/msg00001.html). В отличие от IESG, IAB считал, что опасность исчерпания адресных ресурсов слишком велика, чтобы позволить длительный эволюционный процесс выбора лучшего решения. По мнению IAB IETF должен был начать активно работать над одним из рассматривавшихся решений, а именно IPv7 (так IAB назвал новый протокол), основанный на протоколе CLNP - межсетевой протокол модели OSI, который использует 160-битную адресацию, описанный в стандарте ISO 8473 Международной Организации по Стандартизации (ISO, International Organization for Standardization).

Эти рекомендации вызвали бурю протеста. Критике подверглись как технические качества предложения, так и сам поступок, который был воспринят как волюнтаристское решение IAB и грубое нарушение процесса принятия решений в IETF. Отягощающим обстоятельством явился также факт, что предложение было основано на одном из протоколов конкурирующего семейства OSI, активно поддерживаемого в то время многими государствами и крупными традиционными телекоммуникационными компаниями. Предложение IAB рассматривалось как передача контроля над одним из фундаментальных протоколов Интернета - IP в руки ISO.

Одним из последствий этого инцидента явилось уменьшение роли IAB в процессе стандартизации и полный пересмотр процесса выбора членов IAB и IESG. Этот процесс, который существует и по сегодняшний день, предусматривает номинацию кандидатов из международного технического сообщества независимым Номинационным Комитетом, члены которого случайно выбираются из добровольцев - участников IETF.

Другим последствием стал выбор нового протокола, IP следующего поколения, или IPng, следуя традиционному процессу IETF "снизу-вверх". За основу было взято одно из многочисленных предложений - SIP (Simple Internet Protocol). Впоследствии ему был присвоен номер "6".

Архитектура

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

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

Суть принципа прозрачности состоит в том, что "интеллект" сосредоточен в оконечных устройствах, которые используют прозрачную сеть для обмена данными. Прозрачность сети заключается в отсутствии фильтрации или модификации данных, в том числе и контрольной информации, например заголовков пакетов. Такая архитектура, в корне отличавшаяся от традиционных телефонных сетей, в которых "интеллектуальная" сеть передает данные между простыми устройствами, в многом определила инновационный потенциал Интернета и его бурное развитие.

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

Однако некоторые решения, призванные отдалить проблему нехватки адресов IPv4, существенным образом искажали эту элегантную архитектурную концепцию. Наряду с долгосрочным планом решения проблемы - разработкой нового протокола на смену IPv4 и уже упоминавшимся изменением в системе маршрутизации CIDR, в 1993 году было предложено еще одно решение, призванное существенно увеличить эффективность использования глобальных адресов IP - трансляция адресов, или NAT (Network Address Translation).

Решение это, впервые описанное в RFC1631 (http://datatracker.ietf.org/doc/rfc1631/), являлось простым и одновременно эффективным. Оно было основано на наблюдении, что в пользовательской сети (например, в сети организации) интенсивность обмена трафиком между компьютерами внутри сети значительно превышает обмен трафиком с глобальными внешними ресурсами. Соответственно, в каждый момент времени только часть компьютеров сети обменивается данными с глобальным Интернетом и требует меньше глобальных IP адресов, чем общее число компьютеров в сети. В дальнейшем это решение было доработано и включило также трансляцию номеров портов (своего рода адресов приложений на конкретном компьютере), что позволило повысить эффективность использования глобальных адресов в десятки, а то и в сотни раз.

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

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

Это, однако, не вызывало особого энтузиазма в IETF, - "запятнанный" нарушением принципа прозрачности, NAT надолго остался "золушкой" в мире Интернет-технологий. Наряду с решением проблемы нехватки адресного пространства раз и навсегда, протокол IPv6 был призван восстановить чистоту и простоту архитектуры Сети и обеспечить ее дальнейшее развитие.

К светлому будущему

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

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

Протокол IPv6 полностью интегрирован с протоколом IPsec, обеспечивающим защищенность данных на уровне IP, то есть "сквозную" защищенность между оконечными устройствами.

Также в протокол были интегрированы такие функции как автоконфигурация, оптимизация контрольной информации и поддержка мобильной связи.

Государственная поддержка

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

Так, например, IPv6 стал частью национальной стратегии Японии в области информационных технологий и Интернета, так называемой стратегии e-Japan. В частности, стратегия предполагала полный переход на протокол IPv6 к 2005 году. Для достижения этой цели государство использовало различные средства - от значительного финансирования разработок и исследований в области IPv6, до специальный налоговых льгот и масштабных образовательных программ, стимулирующих переход на новую технологию.

Примерно в то же время, переход на IPv6 был обозначен как один из приоритетов в построении единого информационного пространства Европейского Союза. Основной упор делался на развитие мобильной связи на основе технологии 3G и IPv6 с его колоссальным объемом адресного пространства подходил как нельзя более кстати. В послании Еврокомиссии Совету Европы и Европарламенту в 2002 году, в частности говорилось, что внедрение 3G на основе IPv4 представляет серьезный риск ввиду ограниченности числа адресов, недостаток которых станет критичным уже к 2005 году (http://www.ec.ipv6tf.org/PublicDocuments/com2002_0096en01.pdf,).

Участие государства в процессе внедрения IPv6 в США было отчасти связано с объявленной США войной с терроризмом и кибер-терроризмом в частности. Дело в том, что одной из особенностейIPv6 считалась более высокая защищенность передачи данных. Хотя в реальности IPv6 не многим более защищен, чем IPv4, факт более интегрированной поддержки протокола IPsec, явился одним из ключевых в принятии Министерством Обороны США в 2003 году программы перехода к IPv6 к 2008 году (http://www.defense.gov/news/Jun2003/d20030609nii.pdf).

Утраченные иллюзии

На фоне пропагандистских усилий Региональных Интернет Регистратур и других "I*-организаций" (IETF, ISOC, ICANN и т.д), государственной поддержки и угрозы опустошения пула свободных адресов IPv4, пожалуй самой острой несбывшейся надеждой оказались темпы внедрения IPv6. Спустя десятилетие с момента создания протокола уровень его распространения не превышает нескольких процентов. (http://labs.ripe.net/Members/mirjam/content-ipv6-measurements-compilation-part-2/, http://www.potaroo.net/ispcol/2010-04/ipv6-measure.html).

Давайте попытаемся понять причины такой ситуации.

Начнем с того, что само нововведение не было таким уж революционным. Изменение ограничивалось протоколом IP, не затрагивая все остальные уровни протоколов - транспортные (TCP, UDP) и протоколы приложений. Электронная почта осталась электронной почтой, а вэб-страница отображается одинаково, независимо от того доступен ли сайт по протоколу IPv4 или IPv 6. По-существу, основным изменением было увеличение длины адреса в четыре раза и соответствующее колоссальное увеличение адресного пространства.

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

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

Отражение этих несбывшихся надежд относительно IPv6 видно в краткой сравнительной характеристике двух протоколов, сделанной как-то одним из сетевых инженеров - "на 92 битов больше и никаких чудес".

Но при этом три фактора оказались критическими для IPv6.

Во-первых, IPv6 несовместим с IPv4. Это означает, что устройство, поддерживающее только IPv4, не может непосредственно обмениваться данными с устройством IPv6. Это, скорее, недостаток IPv4, который не предусматривает расширяемости, но потерпевшим стал IPv6. Отсутствие совместимости означает невозможность постепенного внедрения, когда сети переходят на новый протокол, примерно так же, как мы обновляем программное обеспечение на нашем компьютере. Может показаться, что так и происходит и постепенно все больше сетей поддерживают IPv6, но это не так. Внедрение IPv 6 требует построение параллельной инфраструктуры и сети, даже если обе реализуются теми же устройствами. Эта параллельная сеть требует затрат, но, увы, пока что не дает никаких дополнительных преимуществ.

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

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

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