Пользователь
0,0
рейтинг
22 ноября 2012 в 16:03

Администрирование → IPv6 для домашних сетей из песочницы

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



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

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

Не хочется заниматься переписыванием основ IPv6 из rfc (http://tools.ietf.org/html/rfc2460) или википедии (http://ru.wikipedia.org/wiki/Ipv6), поэтому на этот фундаментальный вопрос ответим двумя предложениями. 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 + opt82 имеется «из коробки» в 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, и видим, что ресурсы урезало даже не пополам:
  • number of unicast mac addresses: 1.5K
  • number of IPv4 unicast routes: 2.75K
  • number of directly-connected IPv4 hosts: 1.5K
  • number of indirect IPv4 routes: 1.25K
  • number of directly-connected IPv6 addresses: 1.5K
  • number of indirect IPv6 unicast routes: 1.25K

Напомним цифры для IPv4:
  • number of unicast mac addresses: 3K
  • number of IPv4 unicast routes: 11K
  • number of directly-connected IPv4 hosts: 3K
  • number of indirect IPv4 routes: 8K

Полторы тысячи абонентов — это уже мало кому подходит, но максимум в 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 адреса и маршруты как по автоконфигурации, так и по DHCPv6 получает корректно; сама в роли роутера выступает корректно; вариантов работы с RA, ND и пр. множество, всё функционирует согласно документации; адреса раздаёт как по автоконфигурации, так и по DHCPv6 тоже корректно. Тут провайдеры домашних сетей могут только позавидовать магистралам, у которых проблем с запуском IPv6 особо и нет.

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

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), и мы смогли зайти в админку роутера, но не далее — доступа в интернет на компьютере не было. На роутере мы увидели следующую картину:
  • На WAN порту роутер корректно получил IPv6 адрес и маршруты, однако не подхватил DNS. Вручную прописанный DNS корректно заработал.
  • Даже при отключенной поддержке IPv4 роутер пытается его использовать, так, например, ping на 2a00:1450:400d:804::1009 работает, а вот ping на google.com говорит, что не может найти А запись. Тоже относится к NTP: в поле ввода сервера прописать IPv6 адрес можно, но роутер пытается отрезолвить его А запись, и засыпает лог соответствующими ошибками.
  • Роутер не умеет делать IPv6 NAT. Никак не удалось настроить выход в интернет из локалки с использованием «серых» адресов. Единственное решение — это в настройках DHCPv6 на роутере прописать реальную IPv6 сеть для LAN и прописать соответствующие маршруты в разделе IPv6 роутинга.

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

Debian/Ubuntu. Тестирование производилось с последними версиями ПО: Debian Wheezy и Ubuntu 12.10. С учётом одинакового поведения, в дальнейшем мы их объединим под определением Debian. Здесь ситуация получше:
  • При инсталяции Debian корректно получает IPv6 адрес по автоконфигурации, маршруты и DNS работают корректно, однако при переполучении адреса теряются все маршруты, включая default gateway. Соответственно, доступ в интернет пропадает, что может привести к остановке инсталляции при коротком таймауте DHCP lease.
  • При запуске установленной системы IPv6 адрес и DNS Debian получает корректно как по автоконфигурации, так и по DHCPv6, однако default gateway упорно отсутсвует, его необходимо прописывать вручную. Радует только то, что в дальнейшем он не затирается при переполучении адреса.

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

Mac OS X. Несмотря на то, что мы ожидали полную поддержку IPv6, по факту мы получили следующее:
  • IPv6 адрес и маршруты получает корректно как по автоконфигурации, так и по DHCPv6, однако DNS не подхватывается. При прописывании DNS вручную всё работает корректно.
  • Несмотря на то, что сеть полностью функционирует, для сетевых подключений выводится значок ошибки с восклицательным знаком. Чтобы его убрать, необходимо зайти в настройки сети, выбрать получение адреса вручную, и прописать любой IPv4 адрес.

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

Windows 7. К нашему удивлению, данная ОС, которая «из коробки» организует поддержку IPv6 через Teredo (http://technet.microsoft.com/en-us/network/cc917486.aspx), показала следующие особенности использования IPv6 протокола:
  • IPv6 адрес получает как по автоконфигурации, так и по DHCPv6, однако маска устанавливается /48, вне зависимости от того, какую выдаёт сервер. Вспомним рекомендации RIPE о выдаче /56 сетей, получается, что в случае Windows автоматическая раздача адресов невозможна.
  • DNS не подхватывается. При прописывании DNS вручную его параметры сохраняются.
  • Предложенные маршруты в таблицу маршрутизации заносятся, но с приоритетом меньшим, чем туннели Teredo. Для того, чтобы заработало IPv6 подключение, необходимо остановить и отключить связанные с туннелями службы и настройки, из которых бОльшая часть требует прав администратора. Более того, часть операций возможно осуществить только (!) через командную строку, используя утилиту netsh.
  • Даже после упомянутых выше операций «чистая» IPv6 в данной ОС не функционирует, выводится значок ошибки «Подключение ограничено или отсутствует». Необходимо прописать любой IPv4 адрес, без шлюза и DNS, после чего IPv6 сеть начинает полноценно функционировать.

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




Однако, даже если преодолеть технические трудности в получении и настройке IPv6 пользователем, то что ожидает его сегодня в этой «сети будущего»? К сожалению, его там не ожидает почти ничего. Пробежавшись по популярным сайтам, видим, что:
  • по IPv6 работают: google, youtube, facebook, vkontakte
  • по IPv6 не работают: skype, icq, yandex, odnoklassniki, steam, ex.ua и почти все остальные, включая новостные, развлекательные и игровые ресурсы.

Даже 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 рассматривались выше.

Итоги


Подводя итоги, можно сделать следующие выводы:
  • В настоящее время провайдерам домашних сетей протокол IPv6 можно рассматривать как вспомогательный, ожидать скорого перехода на IPv6 в мире не имеет смысла по причине не очень широкого наполнения IPv6 сети пользовательскими ресурсами.
  • Не представляется практически возможным развернуть «чистую» IPv6 сеть: ни оборудование доступа, ни абонентское оборудование не поддерживает полноценную сеть без IPv4 протокола.
  • Использование Dual-Stack не имеет смысла, т.к. представляет из себя всё тот же NAT, но отягощённый необходимостью обновить всё оборудование доступа и центра на поддерживающее IPv6, а также отдельно приобретать полосу для транзита IPv6 трафика.
  • Фактически в настоящее время использовать IPv6 сеть будут только сервисы google и торренты, остальной трафик будет уходить в IPv4. Вопрос: менять ли всё оборудование доступа ради улучшенной поддержки торрентов? — надо полагать, для провайдеров имеет только один ответ.


UPD: Приношу извинения andrewsh, что не заметили собранного им пакета tayga для Debian Wheezy.
Pavel Kotelva @tipa_pasha
карма
25,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (120)

  • +1
    Шикарнейшая статья, спасибо!
  • +9
    > Роутер не умеет делать IPv6 NAT

    Что-что?! o_O
    • +1
      Преобразование из «серых» адресов диапазона fc00:: в routable.
      • +9
        И каким документом это описано? Нет, спасибо, NAT нам в IPv6 не нужен.

        • +2
          По приведенной ссылке, пункт 4.1. Routing. Эта сеть только для локального использования, аналог серых сетей из RFC1918, она не маршрутизируется за пределы сети.
      • +1
        в IPv6 такого не предусмотрено.
        • +2
          По приведенной ссылке, пункт 4.1. Routing. Эта сеть только для локального использования, аналог серых сетей из RFC1918, она не маршрутизируется за пределы сети.
          • +8
            Совершенно верно. И никакого NAT.
  • +4
    Благодарю. Прочитал взахлёб. Думал, что переход на IPv6 лишь дело времени, а оказалось всё значительно хуже.
    • +2
      Спасибо. Да, мы тоже думали, что IPv6 сети доступных ресурсов будет больше, а можно пробовать разворачивать «чистую» IPv6. Ну, и производители софта и железа тоже удивили. По факту, сейчас хорошо с IPv6 работает только магистральное оборудование, конечному пользователю в v6 сети особо нечего делать пока что.
      • –2
        На самом деле это объясняет отсутствие массового перехода на IPv6. Полагаю, что «пока петух не клюнет» этого не произойдёт.

        Ещё я полагаю, что проблемы поддержки связанны с тем, что IPv4 обкатаны много-много лет. И все ошибки отлавливались ещё на этапе становления протокола. В данном случае мы видим становление и его неопробованность.
        • +2
          понимаешь в чём штука… петух не клюнет. во всяком случае в не в ближайшие 10-15 лет.

          1. можно юзать NAT. и будут. и со всё бОльшим использованием NAT будут появлятся всё более мощные железки — т.к. будет спрос.
          2. ресурсы на ipv6 не будут появлятся потому что нет пользователей, а пользователей не будет потому что нет поддержки провайдеров.

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

          вспомните — раньше SMTP-сервера релеили почту от всех подряд. пока просто некоторое количество важных серверов не перестало принимать от таких других серверов почту. почта не работала где-то с неделю, если не больше, но всё устаканилось. потому что сеть была маленькая. сейчас такое невозможно, т.к. курс на глобализацию был остановлен общемировым кризисом и сепаратистские настроения преобладают.
          • +2
            NAT тоже ограничен количеством портов (65535) на IP. 10-15 лет? Вряд ли.

            Ну хотя, если создать симметричный NAT, максимально упаковывающий юзеров, в том числе повторно использующий исходящие порты для разных юзеров и разных серверов, можно ещё продлить жизнь ненадолго. Уверен, пользовалели Teredo, TeamViewer, игроки, использовавшие ранее Hamachi, да просто p2p'шники, по достоинству оценят симметричный NAT, уходя к конкурентам.

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

            Модуль для InnoSetup и других инсталляторов оценит IPv4 и IPv6 connectivity, попробует разные варианты, в том числе 6to4 и Teredo, и оставит включенными те, которые работают.
          • 0
            Ещё вызывает некоторое сомнение размах, с которым раздаются IPv6 адреса. Да, адресов очень много, но каждому пользователю выдавать /64+/48 — не факт, что надолго хватит. Плюс, зарезервированные, и служебные блоки. Поэтому, последние рекомендации RIPE выдавать /56 вместо /48 навевают вопрос: «А не окажется ли, что лет через три-пять-десять IPv6 будет объявлен неудачным и маленьким, и начнётся внедрение какого-нибудь IPv8?».

            А так — да, вы совершенно правильно заметили, что присутствует замкнутый круг ресурсы <-> пользователи. Но IETF не пойдёт на резкие шаги по ограничению IPv4, так что перспективы IPv6, как мне кажется — это оставаться одним из удобных для магистралов протоколов.
            • 0
              Наоборот. Магистралы (P-роутеры) еще весьма длительное время будут сидеть на IPv4. Ибо те же протоколы на v6 (включая LDP) обладают куда меньшим функционалом.
            • 0
              Там все продумано. Если у них с первой попытки правильно раздать не получится, останется еще адресов на вторую попытку.
          • 0
            1. Использование NAT решает проблему провайдеров.
            Провайдеры-то да — они могут преспокойно упаковывать абонентов за NAT всё плотнее и плотнее ещё десятки лет.

            А вот для датацентров, нехватка IPv4-адресов — это полный абзац.
            Сервер или виртуалочку абонента за NAT не засунешь, они должны быть высунуты в интернет.
            Датацентры уже начали взвинчивать цены на IPv4-адреса, надеясь «отжать» их у тех, кто берёт более чем один адрес на сервер. Допустим, они преуспеют, и практически у всех серверов будет не более чем один адрес.
            Потом они вычерпают весь «чёрный рынок» IPv4.
            А дальше — всё, приехали.
            • 0
              Вот, что странно. Пару лет назад провайдеры домосеток начали активно раздавать реальные IP почти принудительно. Когда все кричали о том, что заканчиваются IPv4 те е домосетки начали раздавать их вообще бесплатно. И сейчас очень легко получить IPv4. В общем как раз все наоборот — никто никого не пихает за НАТ.

              Я про Украину, в частности Киев, Харьков.
              • –1
                Подозреваю, что тут дело в другом — когда все абоненты сидят за одним огромным NAT, затруднительно определить по заявке из органов, кто выходил с конкретного IPv4 адреса «в ночь с пятницы на понедельник» ©.
                Но вся эта лафа быстро закончится, когда закончатся IPv4 адреса.

                Повторюсь — это гипотеза. Я не знаком с реалиями украинского телекома. Просто провожу параллели с нашими российскими реалиями.

                Данный вопрос я решил просто: каждому абоненту-физлицу даётся блок IPv4 адресов, который NATится в некий реальный.
                В силу нехватки IPv4 адресов, физлица группируются на этих NAT.
                В данный момент они у меня группируются по двое. Далее будут по трое, четверо и т.д.
                Органы это устраивает — найти конкретного из 2-3-4 человек всё равно весьма несложно.
                • +1
                  Дак вот насколько я знаю в Украине так не буйствуют, как в России. У нас здесь даже намека на ваш СОРМ нет вроде как.
                  • 0
                    Как раз СОРМ решает эту проблему, поскольку позволяет органам прослушивать «серый» трафик.
                    В условиях отсутствия СОРМ единственный способ понять, кто набедокурил — «вычислять по айпи»…
                    • 0
                      А, не сообразил, спасибо. Но, все равно мне кажется причина не в этом…
                      • 0
                        Может, и в чём-то другом, не спорю.
                        Например, в перегрузке NAT — интернет быстро «жиреет».
                        Но по моему 12-летнему опыту работы в отрасли, наиболее вероятная причина — всё-таки названная мной ранее.
            • 0
              > для датацентров, нехватка IPv4-адресов — это полный абзац.

              в данной статье рассматривали только домашников. о них и говорим. ;)
  • 0
    Как же всё печально-то…
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Можете пожалуйста кратко срезюмировать это видео? А то на работе смотреть 40 минут видео не получается.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Благодарю!
      • 0
        Краткие тезисы есть в PDF в виде слайдов
  • +3
    Ну не знаю. У меня в дебиане через RA получает и адрес и шлюз и не теряет. dhcpv6 и rdnss не проверял.
    • +4
      проверил rdnss (прописал опцию в radvd.conf), NetworkManager его подхватил и прописал в resolv.conf

      то же самое на этапе инсталяции — не проверял.
      • +1
        Аналогично. В течение 2 лет в домашней сети у меня был IPv6. На сервере (debian) был поднят 6to4 через 192.168.99.1, раздача шла через RA radvd + DHCPv6 dibbler. Как linux, так и Windows 7 в сети работали хорошо, все маршруты и default gatewayи поднимались без проблем, ничего не конфликтовало с teredo.

        Я не знаю, как там в ряду серьезного сетевого оборудования, вроде Cisco и Juniper, но с решениями на базе linux все довольно неплохо, скажу я вам. Т.е. вот автор говорит, что ping google.com пытается пинговать IPv4-адрес и не находит его, это правильное поведение, т.к. для пинга ipv6-адресов есть ping6. Аналогично, traceroute6, tracepath6, ip6tables и т.д.

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

        Не используйте NAT64/DNS64. Это глупо, это костыль. Скайп через такое работать точно не будет, т.к. в него забиты IPv4-адреса. И не используйте IPv6-only. Можно и нужно использовать dual-stack.
        Для тех, кто не в курсе: NAT64 — возможность ходить на IPv4-адреса через IPv6, т.е. есть специальный шлюз, DNS64 резолвит ip этого шлюза и дописывает IPv4-адрес, и таким образом вы попадаете на IPv4-адрес через IPv6 через этот шлюз. Это гораздо хуже, чем предоставлять dual-stack с нормальным IPv4 и «кривым» (через 6rd или как-то еще) IPv6.

        Если объяснить пользователям, как настроить ОС так, чтобы IPv4-трафик был приоритетней (если у домена есть A и AAAA, чтобы по умолчанию использовался A), то проблем особо не будет, а пользователь сможет еще и игры хостить через свой IPv6.
        • 0
          Я не знаю, как там в ряду серьезного сетевого оборудования, вроде Cisco и Juniper

          Плохо. Очень.
          Пока нельзя организовать полноценную провайдерскую сеть на IPv6. Однако, вполне можно транспортировать IPv6 пакеты по провайдерской сети, в которой все сигнальные протоколы работают поверх IPv4. Собственно, так сейчас везде и делают. До полного отказа от IPv4 пройдут еще десятилетия.
  • +3
    по IPv6 не работают: skype, icq, yandex, odnoklassniki, steam, ex.ua и почти все остальные, включая новостные, развлекательные и игровые ресурсы

    Не совсем так, yandex.com работает по IPv6
    • 0
      Наверняка, но если в саппорт домашней сети позвонит 300 клиентов с вопросом: «А почему у меня ya.ru не открывается?», то рассказывать каждому о том, что нужно теперь yandex.com использовать — заметно ударит по репутации провайдера.
      • +1
        Как раз поэтому, только на yandex.com пока.
        Внутри все уже давности готово. Как только провайдеры подтянутся, так и остальное переключат.
    • +2
      А много обычных среднестатистических пользователей знают про yandex.com? не флейма ради вопрос, мне действительно интересно… За все годы, что он (Я) работает, про yandex.com я впервые услышал сейчас. Большая часть моих знакомых, кто пользуется яндексом не знает даже про ya.ru.
      И я предвижу очень много криков офисных сотрудников «аа… интернет не работает» и пинков от руководства, если такое провернуть почти в любом офисе, где я работал.
      • 0
        Именно по этому на IPv6 в начале перевели не очень критичную часть. Они подробно на YaC рассказывали. Они проводили несколько экспериментов и выяснили, что наличие IPv6 у многих провайдеров не означает, что он работает. А вот к примеру windows, когда видит, что IPv6 есть, отдает предпочтение ему, а если он нормально не работает… Ну, в общем, вы поняли :)
        Еще раз повторюсь. В Яндексе для IPv6 все готово, как только провайдеры будут готовы, Яндекс включит поддержку всех сервисов.
    • +1
      И ещё vk.com (такой мелкий сайтик для юзеров из СНГ).
      • +2
        Там IPv6 есть в DNS, но реально не на всех серверах это в актуальном состоянии. Там полный бардак.
        • 0
          Бардак этот особо не ощущается уже, то ли было раньше ;)
      • 0
        Ну, да, я его назвал в статье по-старинке: vkontakte.
  • +2
    Мы в Питере, например, не платим дополнительно за IPv6 аплинка.
    Менять оборудование на поддерживающее IPv6 не надо, поскольку магистральное довольно давно поддерживает. Пихать 3750G в центр маршрутизации и жаловаться на урезанное количество памяти под маршруты несколько странно.
    • 0
      1. Я специально обратил внимание, что вопрос касается «средние» домосетки. Это замечательно, что у вас стоит хотя бы 7600 циска в ядре, и вы можете в dual-stack раздать IPv6 адреса абонентам, и NAT-ить им серые IPv4. Вопросов только два: какой объём трафика вы сможете прогнать с учётом NAT-a? И, основной: а зачем это делать, если в IPv6 сети у конечного пользователя только торренты работают, а основной трафик всё равно уходит в IPv4 через NAT?
      2. IPv6 имеет смысл использовать магистралам, можно завернуть IPv4 в IPv6, и работать с одним протоколом в пределах своей сети.
      3. Среди наших клиентов — провайдеров домосеток, циски 3560-3750 в ядре весьма и весьма распространённое явление. Да и они себя показали очень хорошо на сетях до 2500 абонентов.
      • +4
        Торренты и есть основной трафик ;)
      • +1
        1. Мы и есть средняя домосетка. Не нужна 3750 в центре, не-нуж-на. Какое-то время держит D-Link, затем целесообразно переходить уже на Extreme (x650, x670) или Juniper(EX4200, например). 3750 совершенно вылетает из общего ряда. А, из Цисок 650x серия хорошо идёт. 3750 вообще никуда.
        Трафик с помощью NAT'a прекрасно прогоняется обьёмами (проверено на практике) до 10 Гбайт спокойно — его чрезвычайно удобно распараллеливать на относительно дешёвые PC-сервера.
        Делать это надо уже сейчас, потому что спрос на это УЖЕ есть.
        2. Не магистрал, но что-то ОЧЕНЬ сомневаюсь. Тем более что сами магистралы IPv6 вполне себе разворачивают.
        3. Бессмысленна она в домосетях, вообще. Это я говорю как бывший админ десятитысячной домашней сетки и нынешний пятитысячной.
  • +1
    Выходом остаётся всё тот же NAT, только уже в другом направлении, а единственным известным софтверным решением является TAYGA, NAT64 for Linux (http://www.litech.org/tayga), последние изменения в котором датированы 10.06.2011, и который не входит в состав ни одного распространённого дистрибутива.


    Простите, но «ЩИТО»‽ Для кого, спрашивается, я пакеты делал?
    • 0
      1. Да, прошу прощения, есть пакет для wheezy, сейчас поправлю.
      2. Но, тем не менее, это та же самая 0.9.2 версия от 10.06.2011, насколько я понимаю?
      • +1
        Да, это она. Но почему нужна именно она, а не какая-либо другая?
  • +6
    И да, даже и не думайте о NAT в IPv6. Не начинайте этот кошмар заново.
    • 0
      Да, именно это и неприятно удивило, что вместо того, чтобы использовать философию IPv6 протокола, разработчики пытаются скопировать принципы организации работы роутрера из IPv4.
      • +2
        Не понял. Вы сами написали, что минусом является отсутствие NAT. Или это были не Вы? :)
        • 0
          Минусом является следующее. Если провайдер развернул чистую IPv6 сеть, то невозможно пойти в магазин, купить wi-fi роутер с поддержкой IPv6, включить его в розетку, и попасть в интернет.

          Даже если абонент в wizard-е первого запуска выберет IPv6, что уже выходит за пределы способностей среднего пользователя, то он получит адрес из сети fc00::/7, с которым он может только зайти на роутер, но не дальше. И звонок в поддержку домосетки абоненту не поможет, потому что пройтись по десятку менюшек, и корректно прописать выданные провайдером IPv6 сети для раздачи в LAN, а уж тем более маршруты — 99,99% пользователей гарантированно не сумеют.
          • +2
            Простите, это где Вы видели такие роутеры, которые выдают fc00::/7? Я не то что таких роутеров, а вообще с такими адресами в дикой природе не сталкивался, как-то так.
          • +2
            Да и даже у вас написано:
            Единственное решение — это в настройках DHCPv6 на роутере прописать реальную IPv6 сеть для LAN и прописать соответствующие маршруты в разделе IPv6 роутинга.

            Это не «единственное решение». Просто именно так делать и надо. По-другому не бывает, да.
          • +3
            Роутер должен через PPPoE, RA или DHCPv6 получить от провайдера настройки для себя, сделать на их основе настройки для LAN и начать анонсить их в LAN по DHCPv6 и RA.
            • +3
              И, по–хорошему, те же действия роутер должен делать для Teredo и 6to4 (если полученный IPv4 не серый). Предположительно, доступ к другим Teredo узлам будет быстрее через Teredo, чем через нативный IPv6, и аналогично с 6to4.

              Далее, у роутеров могут быть какие–то свои базы автонастройки 6rd для провайдеров типа ТТК–ЗС. Получили IPv4, взглянули на него, узнали, что у этого провайдера есть 6rd, настроили 6rd.
              • 0
                Teredo не маршрутизируется, т.к. выдает только 1 адрес.
          • +4
            1. хватит считать пользователей идиотами
            2. хватит пускать идиотов в сеть.

            я кончел ©
          • +2
            Вы видимо не совсем изучили IPv6.
            SLAAC и/или DHCPv6 должны раздавать сверху поданную /64 далее (в идеале и /56 и /48, но пока нет единого решения как это делать, ведь это LAN сегменты, а не один LAN сегмент). Он получит fe80 адрес локальный автоматом из своего мака, с помощью него он сможет отловить ICMP6 для установки соединения с рутером и соответственно установки реального внешнего IP с рутингом по SLAAC или DHCPv6.
            • 0
              А как корректно раздать IPv6, если провайдер выдает только одну /64? Делить на меньшие подсети — неправильно и не рекомендуется, а иначе только бриджем. Пусть хотя бы /60 дают.
  • +3
    приобретать оборудование уровня Cisco ASR1000 — нереально дорого.

    Серьезно?
    Одна коробка, способная вытянуть почти 40гбит/с, стоит навскидку что-то около ста долларов по GPL. Со всеми лицензиями. Это я под 1002-X посчитал. И эта пара коробок наверняка способна стоять в самом ядре сети средних масштабов провайдера (но я не работал в операторе, потому могу ошибаться с оценкой трафика как в большую, так и в меньшую сторону). И умеет она до черта и больше.
    Прямо сегодня рассказывали, что топовая модификация на тестах успешно роут-рефлектила в сумме 28 миллионов маршрутов при около 60к BGP соседств, даже не собираясь от этого умирать.

    Ну и по поводу странных претензий к 3750-м. Вы уверены, что на них стоит поднимать BGP в условиях IX? Я вот нет. Они вообще не для этого предназначаются. Но я не вижу проблем для мелкого оператора (который слов вроде MPLS не знает и довольствуется QinQ в качестве доминирующего средства туннелирования, причем через весь город) тотально суммаризировать префиксы на каждом хопе, в итоге умещаясь в сотню-другую маршрутов на ядре. Включая, само собой, 0/0 в сторону устройств, пирящихся с IX.
    • –2
      1. Ну, в сотню тысяч у.е., пожалуй, не получится уложиться.
      2. То, что вы описываете, относится к магистралам, нагрузка на ядро домашних сетей иная, и выше.
      3. Мы работаем с большим количеством провайдеров домашних сетей, вас бы очень неприятно удивили реальные схемы построения и организации сетей. Особенно по сравнению с «рекомендациями» от Cisco.
      4. Да, понятно, что 3750-3560 не предназначены для подобных задач, но на сетях до 2500 абонентов они обычное явление. В качестве ядра, с BGP, несколькими пирами, UA-IX (8-9К префиксов), и PIM-ом. Да, и загрузка по процу при этом у них в районе 30%. Их апгрейдят обычно, только когда в TCAM упираются.
      • +1
        1. Плюс-минус. Если забить на резервирование, то можно вообще обойтись одной железкой. Ну и о выкладках, сделанных более полугода назад, забудьте — 1002-Х только что появился. Очень вкусная железка. Более емкие устройства тоже непрерывно обновляются.
        2. Вы говорите, что 3560-3750 обычно стоят в ядре. Через них точно проходит поболее чем 40G? Просто такого непросто добиться, учитывая, что там в основном гигабитные интерфейсы :) А ASR имеет смысл ставить только на периметр (которому технически ничто не мешает быть ядром), и вот там carrier-grade NAT пригодится.
        3. Да знаю я. Мне уже доводилось анализировать топологию L2 кольца одного местного провайдера и давать рекомендации по выравниванию костов STP, чтобы увести абонентов с постоянно падающего линка. Мне эта топология потом неделю в кошмарах снилась. Тут проблема ведь даже не в топологии, а в квалификации тех, кто поддерживает сеть.
        4. Кошмар.
        • 0
          Вы часто видели в свободном доступе графики загрузки каналов провайдера домашней сети? А знаете, почему? :) 40G канала среднему провайдеру не нужно вообще, даже 10G не всегда востребованы.
          • +2
            Тогда как понимать фразу «нагрузка на ядро домашних сетей иная, и выше.»? Так нагрузка выше, или ниже?
            Шасси 1002-X (суп, два БП, 6 SFP дырок) стоит 33к. Плюс, вероятно, лицензия на 5к. Все GPL, то есть по факту будет намного дешевле. Это даст 5гб/с со всеми сервисами.
            1002-X — такая замечательная маленькая железка, которая может роутить от 5гб/с до 36гб/с с промежуточными шагами в 10G и 20G (и насколько я понимаю архитектуру ASR, наличие/отсутствие NAT, netflow и прочих сервисов никак не сказывается на производительности). Одним и тем же железом. Скорости разблокируются лицензией, железо остается тем же самым.
            • +1
              К сожалению, рекламный поток, выливаемый на посетителей семинаров/встреч, проводимых Cisco, очень сильно отличается от реалий провайдерского телекома. Да и, как минимум, нужно 48 sfp модуль куда-то вставить, а то, что вы предлагаете — не подходит для этого.
              • 0
                Ага, тот рекламный поток неслабо, так сказать, вдохновляет :) Ничего, по опыту — к выходным оклемаюсь. Однако, мы уже давно подумываем купить себе ASRов — есть задачи, где софтовый 7206-й справляется плохо.

                Да, портовые адаптеры под ASR стоят неадекватных денег. Но если нужно принять много гигабитных физик, по которым ходит мало гигабитов — что конкретно мешает затерминировать их на тот же каталист или любой другой коммутатор с SPFшками, а на ASR выдать выдать их уже транком?

                Ну и под «реалиями провайдерского телекома» понимается «кольца-кольца-кольца дэлинков»?
                • +1
                  1. В настоящее время считаю оптимальным вариантом для среднего провайдера 7600/6500 серию. Оптимальное соотношение цена/качество. Можно закрыть все текущие задачи, и всё равно остаётся ресурс на будущее развитие.
                  2. Кольца, звёзды — какая разница? Только лишь в настройке STP. Один раз настроить. А вот то, что на доступе:  dlink/edge-core/zyxel/tp-link и прочие китайские поделки, они могут разукрасить каждый ваш день неповторимыми глюками. Да и то, что стоит в центре — отдельная тема, фантазии некоторых «IT-специалистов», особенно в небольших городах, иногда выплёскиваются в чудовщные реализации, где местный админ не уходит в отпуск годами, «потому что иначе всё ляжет».
                  • 0
                    А вы думаете, 6-тонник в роли роутера будет дешевле ASRа? 720-й суп уже EOL, sup32 тоже, остались 720-10G и 2T. Один 720-й 10G суп (без шасси, без всего) стоит дороже одного ASRа в полном сборе. При этом уступает тому по части связанного с роутингом функционала (и NAT/PAT, и человеческий иерархический QoS, и многое другое).
                    Про 7600 не слежу, но наверняка там не лучше с ценами.

                    Ну а STP сам по себе является огромной проблемой. Не должно быть территориально разнесенных L2 сегментов окромя EoMPLS, не должно быть неравномерного распределения трафика (или тем более блокирования линков). Но вот только постройка правильной MPLS сети с TE и прочими наворотами — задача для мелкого хомячкового провайдера куда более сложная, чем покупка пары ASRов. И с точки зрения денег, и с точки зрения мозгов.
                    • +1
                      1. К сожалению, реальная практика показывает, что очень редкий провайдер покупает новые железки. Это сегмент для корпораций, в основном, не связанных с IT. Если вас так часто Cisco таскает по семинарам/конференциям, значит вы либо реселлер, либо интегратор, либо представитель подобной корпорации, чей основной бизнес никак не основан на IT, однако бюджетирование позволяет CIO строить корпоративную инфраструктуру по всем «рекомендациям» Cisco.
                      2. Зато вторичный рынок активно бурлит, поэтому sup720 будет на нём присутствовать в достаточном количестве ещё лет пять, не меньше. Как и 67хх модули. Поэтому, для провайдера, который чаще всего либо находится на самоокупаемости, либо потратил уже все инвестиции, и должен начинать возвращать инвестору вложения, оптимальным решением является собрать на вторичке 7600/6500 за $25-35K, которая закроет все задачи сегодняшнего и завтрашнего дней. Опять-таки, именно 7600/6500, т.к. это «настоящий» хардварный роутер, а не 7200/7300.
                      3. Предлагаемые Cisco лабораторные схемы типа «правильной MPLS сети с TE и прочими наворотами» упираются в простой вопрос: «А зачем?». С точки зрения провайдера домашней сети основной позицией является, и будет являться: «Необходимо с минимальными накладными расходами организовать схему более-менее стабильно работающей сети». И вопрос даже не в мозгах, тем более, что для Cisco/Juniper на офф.сайте имеется полная документация по всем вопросам и технологиям, а вопрос именно в целесообразности использования той, или иной технологии.
                      • 0
                        1. Ни реселлер, ни интегратор, а конечный пользователь, чей бизнес действительно не связан с IT, однако качественная инфраструктура нужна.
                        2. По связанным с роутингом возможностям обе эти железки сильно отстают от специализированного роутера :)
                        3. Это же очевидно — обеспечить более полную утилизацию имеющихся каналов связи, ибо STP неуправляем. А более полная утилизация — это возможность и сделать более вкусные тарифы, и подключить больше абонентов. А главное — стремительная сходимость при очередном перерубании оптики бульдозером.
  • +2
    Выглядит странно… Во всех четырех случаях, описанных в статье, были проблемы с DNS по IPv6. У автора точно с внешней инфраструктурой всё в порядке? Что использовалось с качестве эталонного ipv6 клиента, подтвреждающего, что инфраструктура IPv6 настроена правильно?
    • 0
      В качестве клиента использовались:
      1. Железки cisco с разными IOS.
      2. Те же самые системы в условиях dual-stack корректно забирают оба DNS: и IPv6, и IPv6.
      • +1
        Инфраструктура Сisco c клиентами от cisco? Честно признаться. такая конструкция от доминирующего производителя доверия не вызывает. Cisco уже на раз ловили на несовместимости с железом сторонних производителей. И памятуя 3Сom'овский ethernet… Да и цисковский smb wifi роутер тоже не заработал.

        Попробуйте в качестве эталонных железок выбрать что-нибудь от другого производителя. Например от Juniper…
        • +1
          1. Вспомнил, OpenWRT абсолютно корректно работал как в dual-stack, так и в чистом IPv6. И DNS тоже корректно забирал. Но в данной статье OpenWRT не рассматривалась, т.к. обзор ориентирован на провайдеров домашних сетей.
          2. К сожалению, как показывает практика, не получается считать Extreme/Juniper «эталонными» железками. Из ярких примеров — недавнее трёхдневное флопанье UA-IX.
        • 0
          Да стоило хотя бы тот же Mikrotik попробовать.
          Тот же дешевый 751й SOHO-роутер со свежей прошивкой стабильно умеет принимать RA, запрашивать посредством DHCPv6 routed-префикс, и использовать его в качестве ip-pool для клиентов во внутренней сети. Причем как и по Ethernet-у, так и по PPP.
          • 0
            Микротик — это несколько спорный вопрос. К нам приходит в среднем два-три потенциальных клиента в месяц со словами: «Нам так надоел микротик, жить с ним больше не можем, пожалуйста, сделайте, чтобы его не было». При этом сам по себе Микротик, имхо, очень неплохая вещь для соответствующих задач. Задачи эти описаны на его офф.сайте, это: подключение branch office (сети филиалов) в корпоративную сеть, и wi-fi hotspot.

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

            Но, опять-таки, повторюсь: есть задачи, для которых микротик — хороший, а иногда, и лучший выбор.
            • 0
              Например, CPE у конечного пользователя.
  • +1
    Да и заявленная работоспособность, например, youtube, тоже относительна: сам ресурс полностью поддерживает IPv6, однако для его использования нужен Adobe Flash Player, который скачать и установить невозможно, т.к. все ресурсы Adobe недоступны по IPv6.

    При всём уважении, но это чушь… Android 4.2 на моём Nexus 7 официально не поддерживает Adobe Flash Player. Но не видел на YouTube ни одного ролика, который бы я не смог посмотреть из-за отсутствия AFP…
    • 0
      Вы можете очень просто убедиться в том, что вы заблуждаетесь: поставьте Windows 7, накатите на неё все обновления, пропишите чистый IPv6 адрес, и сходите на youtube.
      • 0
        Попробую как-нибудь… W7 со всеми апдейтами у меня стоит. Но я совсем не понимаю причем тут адоб…
      • +1
        Хм, у меня w7 и она получает маску /64, что я делаю не так?
        • 0
          Попробуйте получить /56 или /96
          • +1
            А зачем мне другая длина префикса при SLAAC?
            Насколько мне известно, максимальная длина префикса для его работы — /64.

            Мой коммент относился к
            IPv6 адрес получает как по автоконфигурации, так и по DHCPv6, однако маска устанавливается /48, вне зависимости от того, какую выдаёт сервер.
    • +2
      Вы смотрите его не через Flash, а в html 5 mode
      • +2
        Бинго!
      • +3
        А что мешает при использовании ipv6 смотреть в html5 mode?
        • 0
          Это замечательно, что вы знаете где и как это включить на youtube. Возможно, вы и Gentoo собираете с 2002 года. Однако для домашней сети, практически всегда существующей в условиях жёсткой конкуренции, лояльность пользователей является приоритетной задачей. А лояльность эта обратно пропорциональна количеству звонков абонентов в саппорт. Даже с вопросом: «А как мне включить html5 mode для youtube?».
          • 0
            Я был убежден, что html5 на youtube по умолчанию, если у вас правильный веб-броузер, поддерживающий html5.

            Нв выходных гляну в чем там проблема…
            • 0
              Пытался я жить без флеша несколько месяцев назад, не вышло. Через html5 они рекламу, кажется, показывать не умеют, от того и половина роликов недоступна оказывается. На том же андроиде клиент показывает и рекламу, и ролик, естественно, без всякого флеша (имею в виду клиент. Рекламы в роликах на сайтах как-то не встречал) Может, что-то и изменилось нынче.
          • 0
            А мне, пожалуйста, QuickTime mode или VLC mode :)
  • 0
    еще в ipv4 существовалс такая опция dhcp как prefix deligation. вот в ipv6 этот параметр и должен показать себя во всей красе.

    алгоритм такой: абонент получает RA, в котором есть префикс global unicast и шлюз. также опционально может быть dns и обязательно managment flag, который указывает, проводить дальнейшую настройку по dhcpv6 или нет. если да, то отправляется multicast пакет, в который коммутатор доступа добавляет opt37 и шлюз релеит его на центральный сервер. в ответе будут все обычные параметры плюс опция PD, заглянув в которую шлюз должен нарисовать этот маршрут в сторону абонента, а абонетский роутер должен начать выдавать эту сеть на внутренних интерфейсах. все работает и все счастливы!..
    • 0
      Мы тоже надеялись, что так и будет, однако по факту обнаружилось, что разработчики просто переписали схему IPv4 на IPv6, не используя вообще ничего, специфичного для IPv6 протокола.
  • +1
    У ТТК–ЗС IPv6 сделан как 6rd, то есть, периферия и биллинг видят IPv4, потом пакеты где–то разворачиваются в полноценный IPv6.
  • +6
    Я посмотрел профиль автора и у меня возникло странное предположение, что технарь из украинского пионертелекома (или около того), не осиливающего IPv6, говорит людям, что оно им на самом деле не нужно и работать не будет. Скажите, автор, насколько я прав в своём предположении? Доводы в статье надуманные на 146%
    • 0
      1. Мы осуществляем поддержку ядра сети многих домосеток, из которых, несомненно, несколько десятков можно отнести к «пионертелекому». География наших клиентов — СНГ.
      2. Будьте любезны, приведите ваши доводы либо опровержения, с удовольствием их выслушаю.
    • +2
      Согласен.
      Возможно, по поводу домашних роутеров инфа и весьма достоверная, но заметно явное недопонимание технологий, с которыми должен быть знаком любой провайдер, особенно домашних сетей ;)
  • –1
    Хорошая статья. Одно «но» — Edge-Core — это не DCN, это Accton.
  • +2
    Вышесказанное необходимо осознавать в первую очередь украинским провайдерам: никакого UA-IX в IPv6 сетях нет,

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

      На UA-IX BGPv6 поднят и вполне работает.
      Префиксов на момент пол-года назад в fullview было 6k кажись. На тему агрегации серьезно ломаются копья, потому как народ по привычке начал дробить префиксы (и на то есть по правде говоря основания) и уже виден тот момент, когда 76е fullview v4 и v6 одновременно не потянут.
      Насчет 100М вообще не понятно — при чем к v6 полоса?

      Да и вообще в статье много спорных утверждений (например насчет отдельных полос под v6 у аплинков).
  • +2
    Вы еще припомните такие «мелочи», как «полная» поддержка IPv6 в SNMP у той же циски, или возможность зажимать скорость для клиентов согласно их тарифным планам на том ПО и железе, которое уже есть в сетях. Как биллингам работать, если по тарифу первый 10 Гб клиент получает на скорость 5 Мбит, а далее скорость падает вдвое, при этом скорость доступа к сети провайдера всегда должна быть, скажем, 30 Мбит? Вопросов больше, чем ответов.
    Особенно радуют отдельные крупные хостинги с вопросами «ой, а зачем вам вообще этот Ipv6?», и, порой, норовящие продавать каждый Ipv6 адрес поштучно :)
  • 0
    как так получилось что интернет лишился ipv5? как то быстро мы проскочили с ipv4 на ipv6…
    • 0
      IPv5 — это секретный военный проект. К сожалению по дурацкой оплошности вся информация о нем была утеряна, поэтому пришлось придумывать 6ю версию с нуля :-)
      • 0
        Вы еще про IPv9 спросите. А между тем tools.ietf.org/html/rfc1606 :)

        P.S. Очевидно, чтобы адресов хватило всех холодильникам каждой блохи каждой скотины у каждого китайца :)
  • +2
    У меня уже около года включен на сайтах IPv6, так вот подавляющее большинство запросов из Китая и USA.
  • +2
    Всё не так печально. Для оператора связи есть простая схема — называется vlan per customer.
    При этом на доступе можно использовать даже самые дряхлые управляемые коммутаторы, от которых не требуется вообще знать, что такое IPv6 — управлять ими можно и по IPv4.

    На агрегации нужна железка посвежее, умеющая «влан во влане», но и это не проблема — они сейчас дешёвые. Например, DGS-3120-24SC.

    Пока полоса не превышает 5-10 гигабит — в ядре вполне справятся обычные PC-роутеры, при нехватке одного роутера трафик можно разбросать по роутерам. При полосе более 10 гигабит становится оправданной покупка, например, младшего Juniper MX, который позволяет терминировать, если мне не изменяет память, до 32 тысяч вланов.

    В итоге абонент получает автоконфигурацию по DHCP+RA и у него всё работает.
    IPv6 — стандартная подсеть /64, IPv4 — например, серая подсеть /28.

    Теперь про абонентское железо — опять же, есть одно очень простое решение: абонентский вайфай можно перевести в режим моста. Либо отключить на нём DHCP и воткнуть провайдерский кабель в LAN. И с этого момента уже неважно, что старая абонентская железка ничего не знает про IPv6 — всё будет работать и так.

    Если абоненту не требуется вайфай — то роутер не нужен вообще, никакой, достаточно неуправляемого свича за 300руб.
    • 0
      Прошу пояснить при чем тут q-in-q и как его использовать.
      Ну и чем спасет vlan на пользователя…
      • +1
        Можно и без QinQ, но тогда будет лимит в четыре тысячи абонентов. В случае QinQ, теоретический предел порядка 16 миллионов.

        vlan на пользователя имеет массу преимуществ:

        — во-первых, как я написал выше, можно вводить IPv6 даже на самых старых свичах. Например, у меня в сети в нескольких местах трудятся D-Link DES-3226, которые датируются чуть ли не 2001 годом. Несмотря на столь почтенный возраст, они прекрасно работают по сей день. Им без разницы, что пропускать — IPv4 ли, IPv6 ли…
        Конечно, для них нет плат с поддержкой wdm sfp модулей, но «вторым» свичом на доступе, будучи присоединённым к «первому» свичу медным гигабитом, они работают прекрасно.

        — при предоставлении IPv6, можно выделять независимую /64 подсеть каждому абоненту, вместо «общеколхозной».
        Это резко упрощает идентификацию абонента по адресу, ведение базы и администрирование адресного пространства в целом.

        — практически исчезает необходимость в пользовательском роутере.
        Абонент может воткнуть неуправляемый свич и кучу устройств в него, все они автоматом получат адреса (что v6, что серые v4) по DHCP — благодаря тому, что отсутствует необходимость в идентификации адресов и защитной привязке адресов к порту, лимит на их количество практически исчезает.
        А это не только экономия денег, но ещё и экономия на поддержке — не нужно разбираться, проблема с сетью или с абонентским роутером, не нужно гонять сотрудника к абоненту, чтобы настраивать роутер, или полчаса пытаться объяснять абоненту, как его настроить самостоятельно (в итоге плюнув и выслав сотрудника).
        Да и абонент при проблемах с роутером склонен пенять на провайдера.

        — полная изоляция абонентов друг от друга.
        Абонент не имеет даже теоретической возможности «нагадить» соседу. Ни намеренно, ни сдуру.
        Абоненты не связаны между собой — по сути, они всё равно что подключены к разным провайдерам. Могут достучаться до друг друга только «через интернет».

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

        — нет нужды в разного рода «привязках», которыми страдают некоторые провайдеры. Просто воткнул и работает, никаких звонков «у меня сменился mac-адрес».

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

        В общем, по сути палочка-выручалочка. Одни плюсы.
        Минус только один — нужны управляемые свичи с вланами.
        • 0
          Я все равно не понял про q-in-q. Что с ним делать?
          Вот есть допустим коммутатор доступа и 32 абоненскими vlan'ами, прилетели эти vlan'ы на агрегацию, дальше что происходит?
          • +1
            Порт QinQ коммутатора может работать в двух режимах — NNI и UNI.
            NNI — это традиционный режим. Прилетели 32 влана и коммутатор их понимает как 32 разных влана.
            UNI — это режим свёртки в QinQ. В этом режиме коммутатор перестаёт обращать внимания на vlan-теги в пакетах, а вместо этого на абсолютно все приходящие пакеты, без разбору, вешает указанный vlan-тег «поверх».
            Соответственно, на порту агрегирующего коммутатора, который смотрит на наш коммутатор доступа, мы включаем UNI. 32 влана сворачиваются в один влан, который улетает в ядро.
            В итоге, в ядре мы имеем один влан на весь указанный доступ, пакеты в котором имеют двойной тег: снаружи тег, которым их обернул агрегирующий коммутатор, а внутри тег какого-то из 32 вланов.

            Всё это прилетает на роутер в ядре, в котором созданы интерфейсы — по интерфейсу на абонента.
            У всех интерфейсов указаны оба vlan-тега — внешний и внутренний.
            На Juniper это прямо так и пишется в явном виде в свойствах интерфейса — например,

            vlan-tags outer 3 inner 121;

            На PC-роутерах же, просто создаются вложенные vlan-интерфейсы — сначала «внешний», цепляемый к физическому интерфейсу, а потом 32 «внутренних», цепляемых к «внешнему» — например,

            ifconfig vlan3 create vlan 3 vlandev em0 up
            ifconfig vlan121 create vlan 121 vlandev vlan3 up
            • 0
              Спасибо, стало понятно )
            • 0
              Сделайте милость, расскажите еще один момент: схема отличная, но ведь (обычно) юзеры хотят и используют в т.ч. и IPv4. Так вот по сколько IPv4-адресов на юзера Вы выделяете? Ресурс-то дефицитный :), а многим дома девайса по 3-4 точно надо подключить… Плюс, получается, Вы выделяете на юзера по подсетке, т.е. тратите адреса не только на девайсы, но и по 3 адреса для служебных целей — не сильно расточительно, в случае IPv4?
              • 0
                Поскольку это «серые» адреса — абсолютно не расточительно.
                На юридических лиц — подсеть /24, 253 эффективных адреса.
                На физических лиц — подсеть /28, 13 эффективных адресов.
                Например, абонент получает по DHCP шлюз 10.1.0.1, а адреса выдаются в диапазоне 10.1.0.2 — 10.1.0.14 включительно.

                Если же абонент просит выделить внешний IPv4 адрес — то он выдаётся уже штучно по запросу, по rfc3069.
                В моём случае конфигурирования по DHCP при этом уже не происходит, т.к. будет неопределённой ситуация, какой адрес выдавать устройству, запросившему его по DHCP — единственный назначенный абоненту внешний, либо какой-либо из серых.
                К примеру, провайдер располагает подсетью 4.0.0.0/16 и хочет ею распорядиться предельно экономно.
                У всех абонентов, использующих внешние IPv4 адреса, прописывается один и тот же шлюз 4.0.0.1 и одна и та же маска 255.255.0.0, а адреса указываются уже индивидуально из диапазона 4.0.0.2 — 4.0.255.254 включительно. Таким образом, если выдавать по одному адресу, то этими 65536 адресами можно обеспечить 65533 абонента.
                Разумеется, можно выдать и два, три и так далее IPv4 адресов одному и тому же абоненту, что иногда востребовано юридическими лицами.
                В отличие от работы с подсетями, помимо отсутствия затрат адресов для служебных целей, эта технология хороша тем, что адреса можно выдавать и изымать штучно, обеспечивая абонента ровно таким количеством адресов, в котором он нуждается, без «захомячивания» адресов впрок.

                Также бывают иные подходы по той же технологии.
                Например, московский провайдер Онлайм вместо использования «серых» адресов выдаёт реальные по DHCP, обеспечивая абонента от 1 до 5 внешними адресами. Шестой адрес уже не будет выдан, ответа на DHCP запрос не будет, пока не освободятся какие-то из занятых пяти. Когда длительное время не возобновляется DHCP аренда, адрес у абонента изымается, и в следующий раз будет выдан уже другой.
                За отдельную плату один из адресов становится фиксированным и выдаётся всегда один и тот же.
                Однако, это слишком расточительный подход, и вполне вероятно, что суровые реалии дефицита IPv4 заставят их пересмотреть подход в ближайшие годы.
  • 0
    В gentoo есть tayga:

    $ eix tayga
    * net-proxy/tayga
         Available versions:  0.9.2
         Homepage:            http://www.litech.org/tayga/
         Description:         out-of-kernel stateless NAT64 implementation based on TUN
    
    


    Согласен с автором, что «работа не для обычного пользователя»

    Спасибо за интересный обзор.
    • 0
      Помнится, этим летом на конференции Cisco для операторов связи в презентации было сказано, что уже 29% контента лежит в ipv6. Они врали?
      • 0
        скорее всего 29% контента — это google :)
  • 0
    Убрал тоннель с роутера, Гугол задолбал перекидывать на голландскую версию.
    • 0
      Прошу прощения, промахнулся топиком.

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