IPv6 для домашних сетей

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

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

Из наиболее частых вопросов можно выделить: «А ваш биллинг поддерживает IPv6 адреса?». При этом ответ: «А всё ваше оборудование готово к его внедрению?» вызывает удивление: «А что там готовить надо?».

Не хочется заниматься переписыванием основ IPv6 из RFC 2460 или Википедии, поэтому на этот фундаментальный вопрос ответим двумя предложениями. IPv4 и IPv6 — это два разных протокола, совсем разных. Как, например, AppleTalk или IPX — совсем разные. Поэтому IPv6 — это не просто «другие адреса», это совершенно другой протокол.

Вышесказанное необходимо осознавать в первую очередь украинским провайдерам: никакого UA-IX в IPv6 сетях нет, протоколом заложены элементы маршрутизации уже в заголовке IPv6 пакета (http://tools.ietf.org/html/rfc3587), сети аггрегируются по умолчанию, IPv6 full-view не может превышать 8К префиксов. Соответственно, провайдерам прийдётся отвечать на волну вопросов абонентов: «А почему у меня нет 100М на UA-IX?».

Также, в настоящее время ни одна биллинговая система не поддерживает полноценное управление IPv6. Некоторые системы заявили о поддержке IPv6, но на практике эта «поддержка» представляет собой лишь модифицированное поле IP адреса. А по стандарту, конечному пользователю адрес не выделяется, конечному пользователю должна выделяться сеть, по старым рекомендациям — /48 сеть (http://tools.ietf.org/html/rfc6177), по новым рекомендациям RIPE — уже /56 сеть, т.е. 256 сетей по 18446744073709551616 адресов. Повторим — каждому абоненту. Ни один из известных биллингов в настоящее время не поддерживает данные стандарты.

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

Мы рассмотрим два варианта внедрения IPv6: в Dual-Stack, и «чистого» IPv6.

Использование IPv6 в Dual-Stack

Dual-Stack — это параллельное использование IPv6 и IPv4. Пользователь получает оба варианта адресов. Очевидно, что выдавать реальный IPv4 адрес при этом никто не собирается, т.к. тогда смысла в IPv6 для провайдера нет, задача стоит экономить IPv4 адреса.

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

Начнём с коммутаторов доступа. Прекрасно показавшая себя связка DHCP Snooping + DHCP Option 82 имеется «из коробки» в IPv6 протоколе, только называется она opt37 (http://tools.ietf.org/html/rfc4649), но при этом сам коммутатор должен поддерживать IPv6 протокол, как минимум, уметь блокировать «чужие» RA, фильтровать ND, пр. Иначе ситуация будет подобна сети с DHCP на «тупых» свичах, где адреса раздаёт любой клиентский роутерчик.

На сегодняшний день подобная поддержка IPv6 известна только у последних D-Link, начиная с DES-3200, и более экстремальных вариантах типа коммутаторов SNR от уважаемого nag.ru, приобретая которые провайдер за собственные деньги подписывается в вечные бета-тестеры глюков прошивок. Но, надо отдать должное DCN (http://www.dcnglobal.com): а это и SNR, и Edge-Core, и многие другие торговые марки, — покупая коммутаторы D-Link, тоже немало времени будет потрачено администраторами на бета-тестирование и отлов багов.

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

Использование же VPN (PPTP, PPPoE) для выдачи адресов, несомненно, уменьшает запросы к коммутаторам доступа, однако увеличивает объём негатива среди абонентов.

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

Не лучше обстоят дела в центре сети. Мы не будем тщательно рассматривать вариант, где центром сети является сервер под FreeBSD/Linux, подобные сети обычно невелики, и имеющихся у них /22 или даже /23 IPv4 адресов с головой и надолго хватит на всех пользователей. Напомним только, что для FreeBSD dummynet пока ещё не научился использовать несколько ядер.

У «среднего» же провайдера в центре стоит какая-либо Cisco/Juniper/Extreme из среднего же диапазона оборудования. У нас для тестирования имелась Cisco 3750G, что является достаточно распространённым решением среди подобного размера провайдеров. Включаем поддержку IPv6, и видим, что ресурсы урезало даже не пополам:

Напомним цифры для IPv4:

Полторы тысячи абонентов — это уже мало кому подходит, но максимум в 1200 роутов — это совсем катастрофа, в настоящее время даже небольшие русские точки обмена трафиком присылают по 2000 префиксов, не говоря уже о точках типа DTEL-IX, UA-IX, или, тем более, MSK-IX.

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

Получается, что при объёме трафика в несколько гигабит возвращаться к «софтовым» шейперам на базе FreeBSD/Linux/Mikrotik уже невозможно, а приобретать оборудование уровня Cisco ASR1000 — нереально дорого.

Да и что делать с самим IPv6 трафиком, тоже вопрос. Отдавать аплинку? Почти все аплинки отдельно тарифицируют транзит IPv6 трафика. Заворачивать у себя IPv6 to IPv4? Тогда использование IPv6 вообще не имеет смысла. Поднять туннельный пиринг с кем-либо типа Hurricane Electric (http://www.tunnelbroker.net/new_tunnel.php?type=bgp)? Во-первых, трафик пойдёт через «мир» (у кого есть подобное разделение), во-вторых, при достижении определённых лимитов, Hurricane Electric тоже начнёт брать деньги за транзит. Получается, что кроме увеличения накладных расходов, внедрение IPv6 ничего положительного не даст. Если уж всё равно использовать NAT, то можно просто NAT-ить серые IPv4 адреса, и всё. Пользователи не заметят разницы.

Итого: типичное для «среднего» провайдера оборудование либо совсем невозможно использовать для работы пользователей в Dual-Stack, либо же оно будет нагружено сильнее в несколько раз (отдельная маршрутизация плюс NAT).

Использование «чистого» IPv6

С учётом нецелесообразности развёртывания Dual-Stack в домашних сетях, у провайдеров возникает вполне логичный вопрос: «А что, если мы только один сегмент сети переведём на «чистый» IPv6, а остальные пусть работают, как раньше?». В теории подобная схема выглядит неплохо: поставить отдельную железку под IPv6, раздать пользователям IPv6 адреса, докупить у аплинков IPv6 транзит — и пусть себе работают. Рассмотрим подробнее, как обстоят дела с поддержкой «чистого» IPv6 в настоящее время.

В этот раз опустим анализ коммутаторов доступа — всё аналогично описанному в разделе про Dual-Stack, разве что необходимо отметить, что коммутаторы D-Link при получении IPv6 по автоконфигурации не видят предлагаемых роутов, так что надо быть готовым к тому, что default gateway необходимо будет прописывать вручную.

В качестве примера «центра» сети мы опять использовали оборудование Cisco, IOS версии 15.1. К «настоящей» Cisco претензий нет никаких:

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

Перейдём к клиентскому оборудованию. Об этом писалось много раз, например, самим IETF (http://tools.ietf.org/html/rfc6586)? однако надежда на то, что поддержка IPv6 активно развивается производителями, заставила пробежаться по основным вариантам пользовательских подключений. А именно, мы проверили работоспособность «чистого» IPv6 подключения для Wi-Fi роутера Cisco (Linksys), а также компьютеров под управлением Debian/Ubuntu, Mac OS X, Windows7. Всё вышеперечисленное имело последние версии ПО/обновлений/патчей/прошивок.

Wi-Fi роутер

Для тестирования мы использовали достаточно новый роутер Cisco SB RV110W. Это роутер уже не имеет маркировки Linksys, он выпущен Cisco Small Business подразделением. Заявлена полная поддержка IPv6, как на WAN, так и на LAN порту. Действительно, в меню имеется выбор различных комбинаций IPv4 и IPv6 для этих портов. Мы выбрали «чистый» IPv6 для обоих, роутер перезагрузился, попытались подключиться. К wi-fi сети компьютер подключился, получил «серый» IPv6 адрес из диапазона fc00:: (http://tools.ietf.org/html/rfc4193)? и мы смогли зайти в админку роутера, но не далее — доступа в интернет на компьютере не было. На роутере мы увидели следующую картину:

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

Debian/Ubuntu

Тестирование производилось с последними версиями ПО: Debian Wheezy и Ubuntu 12.10. С учётом одинакового поведения, в дальнейшем мы их объединим под определением Debian. Здесь ситуация получше:

Итого: с одной стороны, полноценной безглючной поддержки «чистого» IPv6 в Debian пока нет, с другой стороны, уже сам выбор Debian как ОС подразумевает умение пользователя без особых проблем прописать вручную маршрут на шлюз.

Mac OS X

Несмотря на то, что мы ожидали полную поддержку IPv6, по факту мы получили следующее:

Итого: полноценной безглючной поддержки «чистого» IPv6 в Mac OS X пока нет, а с учётом полного отсутствия знания данной ОС типичной поддержкой провайдера, можно ожидать негатив и снижение лояльности со стороны пользователей продукции Apple.

Windows 7

К нашему удивлению, данная ОС, которая «из коробки» организует поддержку IPv6 через Teredo (http://technet.microsoft.com/en-us/network/cc917486.aspx), показала следующие особенности использования IPv6 протокола:

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


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

Даже microsoft.com не имеет АААА записи. Да и остальные сервисы Microsoft лишены поддержки IPv6, поэтому, например, ОС установить и запустить возможно, а вот обновить её — уже нет. Кроме того перестанет работать Microsoft Security Essentials, который не сможет обновить сигнатуры.

Да и заявленная работоспособность, например, youtube, тоже относительна: сам ресурс полностью поддерживает IPv6, однако для его использования нужен Adobe Flash Player, который скачать и установить невозможно, т.к. все ресурсы Adobe недоступны по IPv6.

Выходом остаётся всё тот же NAT, только уже в другом направлении, а единственным известным софтверным решением является TAYGA, NAT64 for Linux (http://www.litech.org/tayga), последние изменения в котором датированы 10.06.2011, и который не входит в состав ни одного распространённого дистрибутива. Да и очевидно, что более 90% клиентского трафика будет уходить в IPv4 сеть, а вопросы необходимых мощностей для Dual-Stack рассматривались выше.

Итоги

Подводя итоги, можно сделать следующие выводы:


Статьи - -