Pull to refresh

IPv6 не нужен?

Reading time 7 min
Views 103K
Недавно прочитал заметку, смысл которой сводится к тому, что не мешало бы проверить, вдруг вы уже используете IPv6 и ничего не замечаете. Следствием этого, на мой взгляд, является другой смысл, что для подавляющего большинства IPv6 ничего нового не принесёт: сайты будут так же открываться, а телефоны так же звонить.

Последнее время IPv6 перестал быть новым, возможно это относится только к моей среде общения, но говорить об IPv6 как о новом протоколе — перестали. Читать о том как здорово поднимать туннели ради доступа к заветному и недоступному уже совсем неинтересно. IPv6 стал одним из… Казалось бы, наконец-то, можно кричать «Ура!», но став одним из, он потерял драйвер роста, превратившись в заурядный. Доказать потребителю что ему надо именно это стало сложнее, потребитель не готов платить за один из…

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

Примерно чуть больше года назад было решено отдать IPv6 нашим абонентам. После первых экспериментов прошло достаточно времени, мы смотрели на график Google и хотели не опоздать. Абоненты для нас это пользователи услуг регионального провайдера интернет, классический tirple play: доступ к интернет (без PPPoE и VPN), телевидение (мультикаст) и телефония. Предпосылки, если ссылаться на приведённый график очевидны — туннельные протоколы почти ушли, родного контента стало больше, все большие сайты и хостинги включили IPv6 по умолчанию, магистральные операторы не берут дополнительную плату за dualstack адрес на стыках. Фактически пользоваться интернет в IPv6 стало можно, а быть первым в регионе и перетащить к себе под крыло ещё чуть-чуть абонентов — заманчивая идея.

Начало


Сначала получили адреса с префиксом /32, совершенно свободно обычным для провайдера способом через RIPE или LIR. Предполагалось, что на время тестов хватит и /48, но потом во время проектирования стало понятно, что /32 самый раз.

С аплинками было чуть посложнее (сейчас, наверное, уже нет), но такой магистральный провайдер нашёлся, подняли BGP в IPv6 обменялись префиксами. На текущий момент BGP fullview в IPv6 порядка 22000 префиксов, что очень мало если сравнивать с IPv4 где их больше 500000. Нашёлся даже пиринг партнёр, который был не против поднять с нами IPv6 сессию.

Если вы строите сети хотя бы пять лет, у вас должно было смениться пару поколений устройств, если вы строите сети больше 10 лет, даже используя одного вендора, в сети должен был образоваться некоторый сумбур из устройств, которые исправно работают, но которые совершенно не подходят под новые реалии. Определённо было известно, что если на маршрутизаторе не заявлена поддержка IPv6, то IPv6 там не будет, никакого подвоха от коммутаторов мы не ожидали. Предполагаемая зона охвата на чистом IPv6 составляла примерно 30%, без замены оборудования.

Абонентские оконечные устройства. Здесь как оказалось совершенно неизведанная территория. Если с операционными системами всё более или менее ясно, то с домашними маршрутизаторами кто во что горазд. Решено было разбираться по ходу дела, главным казалось, настроить магистральную сеть.

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

Проект


Если на секунду покажется что /32 это много, следует отогнать от себя эти мысли — /32 это впритык. С таким количеством адресов появляется соблазн сделать всё правильно и структурно и на всю жизнь:
  • /60 — абоненту. Можно и /64, конечно, но /60 это же навсегда, и не надо будет что-то отдельно придумывать для тех кому надо будет побольше;
  • /52 — на узел, из расчёта 256 абонентов;
  • /40 — на район, из расчёта 4096 узлов, по количеству виланов на устройство;
  • остальное это районы, максимум 256 минус служебные сети.

Итого 256*4096*256 = 2^28 ~ около 268 миллионов абонентов у каждого из которых, ну очень много адресов. С этим всё в порядке.

Так как изначально было очевидно, что всем не получится отдать родной IPv6, то тем, кому не повезло, IPv6 решено было отдавать в туннелях. Хотелось чтобы всё происходило автоматически без дополнительной настройки. Идеальным вариантом мог бы стать teredo, но у него не было поддержки наших IPv6 адресов, только зарезервированный диапазон. Это касается и 6to4, реализация которого подразумевает наличие публичного IPv4 на интерфейсе. Поэтому основным туннельным протоколом был выбран чистый туннель, как в туннельных брокерах. Пусть это и требовало некоторой настройки, но однократной, и поддержка на устройствах была гораздо шире.

Реализация


Магистральные маршрутизаторы. Тут почти всё хорошо. Всё, что новее 5-ти лет и заявлено как маршрутизатор, или если это L3 коммутатор не самый младший в линейке, имеет поддержку IPv6. В разной степени проработанности, но базовые функции OSPFv3, ACL, ND, DHCPv6 включая snooping, диагностические утилиты, обычно присутствуют.

Конечно, некоторые устройства подвержены детским болезням:
  • Повышенная нагрузка на CPU (особенно это касается OSPFv3), хотя IPv6 как раз и должен был решить проблему недостатка вычислительной мощности;
  • Некоторые производители придумывают совершенно жуткие синтаксические конструкции, чтобы вписать настройку IPv6 в существующий интерфейс;
  • Базовые команды диагностики не всегда корректно работают. Даже попытка проверить что-то ping может завершиться печально.

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

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

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

Дополнительно подняли teredo relay на miredo. Teredo сам по себе очень интересный протокол, даже если у вас только IPv6 сеть, но вы не забываете об обделённых вынужденных пользоваться teredo, поднятие teredo relay в вашей сети очень сильно улучшит им жизнь. Раз в 10, если судить по пингам. Конечно, это касается только ваших серверов, никакого транзитного трафика бежать через ваш релей не будет.

Устройства абонентов повели себя по-разному. Фактически Windows и Linux не принесли сюрпризов. В разных системах и версиях имеются разные приоритеты для IPv6, где-то на первом плане DHCPv6, где-то, даже если все адреса IPv6 получены, всё равно работаем через IPv4. Так как IPv4 выключать не собирались, то здесь решено было действовать по факту, если не работает чиним. Многие роутеры в свою очередь порадовали наличием возможности включения механизмов туннелирования и также достаточно умным поведением, даже без запроса DHCPv6-PD они смогли распределить выделенный им префикс /64 на свою локальную сеть.

А вот железный полисер нас подвёл. При всём своём авторитете марки и расписанном функционале, не смог переварить наши требования, просто отказался применять новые адреса. Но не всегда, а через раз, как бы я могу как и обещал, но не буду. Поэтому временно была пересмотрена стратегия выделения адреса, только /64 на абонента.

Заработало


Когда были готовы настройки магистральных узлов и серверы туннелей, мы разрешили абонентам пользоваться IPv6. Разрешили пользоваться, но самим абонентам не сказали. Таким образом у кого устройства были настроены на автоматическое получение IPv6 (все современные ОС), те должны были получить адреса и начать использовать новый протокол по назначению. Для всех тех, кто каким-то образом узнал об IPv6, но не смог настроить нативно, тем предлагалось перейти на сервер туннелей для настройки.

Так работало 3 месяца, за которые:
  • Нативный трафик IPv6 линейно рос и добрался примерно до отметки 1-2% от общего трафика;
  • Структурно: в основном web и видео через web, никакого торрента;
  • Количество абонентов тоже линейно росло до примерно такой же величины;
  • На сервере туннелей зарегистрировалось порядка 1000 абонентов, которые генерировали трафик сравнимый с нативным;
  • Даже трафик через teredo relay составил 50 Кбит/c.

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

  • Много адресов. В среднем активных устройств на абонента, которым требуется доступ в интернет 2-3, может, побольше — гаджетомания побеждает. Но даже сейчас это покрывается с лихвой частным адресным пространством без IPv6. Хоть каждому абоненту до 2^24, хотя на всех абонентов 2^24 — сейчас этого более чем достаточно;
  • Каждый адрес публичный. Сейчас у нас все адреса при доступе к интернет получают уникальный публичный адрес через NAT. Да через NAT, но с точки зрения конечного абонента NAT как первичный фильтр очень хорош. IPv6 подставляет под удар каждое подключенное устройство;
  • IPv4 кончаются. Если перейти от NAT к PAT(NAPT) при мультиплексировании 1 к 2, экономия 2 раза — в два раза больше подключенных абонентов. Такое мультиплексирование незаметно вообще, никому, 1 к 10 более реальные значения. А для тех кому действительно нужны публичные адреса после такого перехода они легко найдутся. Это не отменяет того факта что IPv4 кончаются, но провайдеры с полностью понятной технологией NAT это заметят самые последние. Многие наверняка уже использую NAPT или уже cgNAT, но IPv4 ещё можно купить или арендовать, причём достаточно свободно. Цены выросли, список предложений сократился, но до ситуации «нету ничего» ещё минимум пару лет;
  • Автоматические настройки. Для провайдера stateless технологии ужасны, тотальный контроль залог успеха. Гигантское количество IPv6 адресов разных типов на одном интерфейсе, гигантские возможности потенциальной ошибки. Если не следить за адресами, большая часть сети превратится в ботнет и уже будет поздно что-то менять;
  • Multicast против Broadcast. Коммутаторам всё равно, даже иногда плохо, логика начинает сбоить при использовании различных фильтров. На сетевом уровне, вместо 192.168.0.255/24 такой же FF02::1, т.е. тоже всё равно.


Итого


Оставили работать только сервер туннелей, последняя регистрация на котором была 9 марта, через 7 месяцев как убрали новость об IPv6. Остальное выключили через пару дней после объявления, поняв что единственным результатом это больше звонков от тех кто хочет что-то сделать, но не знает зачем, и почти полную неготовность даже в ближайшей перспективе софтверной обвязки. Те, кто знал зачем, сделал это сам. Сейчас доделываем биллинг, обновляем прошивки и оборудование и приходим к понимаю что IPv6 такой же протокол как и IPv4, интернет к этому стал готов и поэтому сам по себе «новый» протокол стал неинтересен. Спешить никуда не надо. Ни один конкурент за это время не предложил ничего, хотя почти все зарезервировали себе IPv6 префиксы.

Для всех тех, кто думает что у его провайдера нет IPv6, попробуйте поискать — может быть, уже есть, просто вам это не нужно?
Tags:
Hubs:
+44
Comments 128
Comments Comments 128

Articles