С интересом прочитала статью @maybe_elf «Проекту IPv6 исполнилось 30 лет». Но очень удивилась некоторым комментариям к ней. К сожалению, у многих российских ИТ инженеров до сих пор нет понимания неизбежности перехода на IPv6. Поддерживаю позицию Сергей Федотов @FSA. И полностью согласна с мнением Сергея @kovserg, что «на самом деле проблема не в ipv6, а в том что людям лень разбираться в дебрях спецификаций».
Решила поделиться опытом проектирования и внедрения IPv6 соблюдая отраслевые спецификации. Накопился внушительный объем материала (разработка, внедрение, безопасность), но начинать надо сначала и сверху. Так что цель этой статьи – предоставить информацию и рекомендации, касающиеся аспектов планирования адресации при развертывании IPv6.
Но прежде, чем начать я бы хотела добавить еще один аргумент за IPv6. Ну, согласитесь – это красиво!
Это красиво, когда сделано не «кривыми ручками» (как на картинке в одном из комментариев), а по хорошо разработанному плану, согласно всем стандартам, и с понимание накопленного отраслью практического опыта.
Важно заметить, что чаще всего регистратор (для России регистратором является RIPE NCC) выдает минимальное адресное пространство размером в /48. Даже для компании среднего размера, у которой есть филиалы, это очень мало. Всегда нужно стараться зарезервировать как можно большее пространство, потому что мы должны помнить про принцип постоянного расширения сетей. Когда я начала работу над внедрением IPv6 в одном агентстве проект был в полном тупике, и прежде всего из-за нехватки подсетей. При наличии нескольких десятков филиалов ARIN выделило им всего /48. Из этого пространства они линейно нарезали массу маленьких кусочков. В результате мало что работало, и это была каша и ад. Инженеры постоянно ругались на «гадский IPv6». Не IPv6 был гадский, а дизайн и методы его внедрения. Мы добились, от ARIN чтобы они выделили агентству /40 (кстати, /48 тоже оставили за ними) и переделали дизайн. Это было возможно, потому что есть отраслевые правила, по которым определяются размеры адресного пространства:
Количество сайтов | Размер блока |
1 | /48 |
2-12 | /44 |
13-192 | /40 |
193-3,072 | /36 |
3,073+ | /32 |
Итак, одним из фундаментальных аспектов любой инфраструктуры IP-коммуникаций является план адресации. Внедрение IPv6 в сеть с его новой архитектурой адресации означает, что проектировщикам сетей необходимо пересмотреть существующие подходы к адресации сетей. Непонимание этого аспекта существенно замедляет развертывание и интеграцию IPv6.
Правильно составленный план даёт возможность линейно наращивать ресурсы. В IPv6 масштабируемость означает, что ты можешь добавить тысячи новых сегментов сети, не меняя общую логику адресации. Такой подход поможет обеспечить операционные преимущества:
Наглядность структуры (подчеркивает, что логику деления сети видно сразу).
Интуитивность адресации (когда администратору не нужно гадать, к какому сегменту относится префикс).
Прозрачность иерархии (акцент на том, что уровни сети легко различимы).
Когнитивная доступность, более легкая узнаваемость (префиксы легко запомнить или отличить друг от друга).
Семантическая ясность (когда в префикс заложен понятный смысл, например, код региона или отдела).
Визуальная чистота (минимум «каши» из цифр и букв) и понятная навигация (внутри адресного пространства).
Оптимизация агрегации маршрутов.
Более эффективное администрирование списков контроля адресов (ACL) и других политик безопасности.
Масштабируемость (система не становится «хаосом» при росте).
Мой список отраслевых стандартов, которые необходимо учитывать при планировании адресного пространства:
1) Унификация размеров подсетей [ RFC 7381 ]
Разделение выделенного адресного пространства на подсети одинакового размера (сайта, подсети, функции) помогает упростить общую схему адресации. Такую иерархию проще спроектировать, администрировать, вносить и отслеживать изменения. Кроме того, их проще суммировать, что потенциально позволяет создавать более компактные таблицы маршрутизации и более аккуратные списки контроля доступа (ACL), уменьшая риск ошибок.
Если план IPv6 составлен правильно, то даже при десятикратном увеличении сети администратор по-прежнему понимает структуру адресов с первого взгляда, потому что она разработана по единому плану.
2) Соблюдение границ полубайта (nibble boundaries) [RFC 4864; RFC 6177]
Граница полубайта — это сетевая маска, которая соответствует границе в 4 бита. В префиксе IPv6 каждый шестнадцатеричный символ представляет собой один полубайт, что составляет 4 бита.
Соблюдение границ полубайта обеспечивают более удобочитаемую адресацию, делая префиксы более узнаваемыми и простыми для понимания. Это заметно повысит эффективность работы сетевых администраторов, уменьшит количество ошибок в конфигурациях.
Также надо помнить, что длина делегированного префикса DNSv6 всегда должна быть кратна 4 (/64, /60, /56, /52, /48 и т. д.), чтобы обеспечить согласованность записей обратного дерева (DNS PTR) в ip6.arpa. Поэтому если мы хотим, чтобы обратное разрешение DNS имен работало в IPv6 сетях, длина префикса должна заканчиваться на границе полубайтов.
3) Выделение 64-битного префикса как минимального размера сегмента сети [RFC 3956; RFC 3971; RFC 4864; RFC 4866; RFC 5375; RFC 6461; RFC 7371; RFC 8981]
Отраслевой стандарт рекомендует использовать 64-битный префикс на каждом сегменте сети, независимо от его размера в IPv4 сети. Важно отметить, что исключением являются только соединения типа «point-to-point» на каналах связи между маршрутизаторами (в IPv4 это обычно сети с префиксом /30). Рабочая группа по проектированию интернета (IETF) представила предлагаемый стандарт [RFC 6164], который рекомендует использовать 127-битные префиксы для соединений типа «point-to-point» между маршрутизаторами.
В остальных случаях использование длины префикса подсети, отличной от /64, нарушит работу многих функций IPv6, включая обнаружение соседей (ND), безопасное обнаружение соседей (SEND), нарушение работы авто-конфигурации адресов SLAAC (Stateless Address Autoconfiguration), ограничит использование расширения конфиденциальности в IPv6 (privacy extensions), ошибки соединений мобильного IPv6, работу протокола независимой многоадресной рассылки в разреженном режиме (PIM-SM) со встроенным RP. Многие другие приложения, сервисы и серверы ожидают, что клиенту выделена полноценная /64 сеть. Получение префикса другого размера может привести к тому, что они просто не подключатся. Ряд других функций, находящихся в настоящее время в разработке, также базируются на использовании префиксов подсети /64.
Итак, использование /64 как минимального размера подсети для клиентов, позволяет гарантировать работоспособность всех функций IPv6. Также снижает эксплуатационные и накладные расходы на конфигурацию, упрощает управление сетевой инфраструктурой.
4) Иерархическая организация адресного пространства [RFC 5375]
Иерархическая схема адресации для проектирования крупных сетей потенциально может оптимизировать её работу, универсальность в предоставлении услуг, повысит адаптивность к изменениям, также упростит управление сетью.
Важнейшим плюсом иерархической схемы является возможность агрегации адресного пространство на всех уровнях:
· Географические границы — путем присвоения общего префикса всем подсетям в пределах географической области.
· Организационные границы — путем присвоения общего префикса административным группам в рамках корпоративной инфраструктуры.
· Тип сервиса — путем резервирования префиксов для определенных услуг, таких как: VoIP, WiFi, доступ в Интернет, системы безопасности, мониторинг и т. д.
Например, рассмотрим дизайн иерархической IPv6 структуры крупной компании, филиалы которой находятся в разных регионах страны. Компания закупила адресное пространство размером /40.
Диапазон /40 можно разделить на 4 региона каждый размером /42. Да, размер /42 не проходит по границе полубайта. В данном случае это приемлемо, поскольку это просто дополнительный логический уровень группы-«папки» для регионов, созданный для удобства (размер по границе полубайта /44 позволил бы создать16 регионов, что для обычных коммерческих организаций слишком много).
Каждый регион будет содержать до 64 сайтов размером /48. Каждый сайт может содержать до 16 групп типов сервисов, каждая группа сервиса может содержать до 4096 сетей размером /64. Дополнительный логический уровень сервисов в иерархии позволяет группировать подсети в отдельные категории (безопасность, сетевые устройства, базы данных, устройства мониторинга, сети для пользователей и т. д.). Это будет полезно для агрегации маршрутов и создания меньших списков контроля доступа (ACL) и политик безопасности внутри сайта, так как, очевидно, что трафик для подсетей, где находятся пользователи, будет сильно отличаться от трафика подсетей с контролерами доменов, серверами баз данных или сетевого мониторинга.
Возможны варианты, когда имеет смысл разделить каждую сеть /52 с третьего уровня на 16 подгрупп /56 размера, в каждой из которых будет 256 сеток по /64.
Ниже приведен пример визуализации возможных вариантов разбивки IPv6 сети размером /48
Варианты дизайна могут быть различными, в зависимости от организационной структуры и функционала. Самое главное провести качественный анализ действующих сетей и хорошо представлять вектор стратегического развития организации, влияющий на динамику расширения сети.
5) Методы распределения IPv6 префиксов [RFC 5375; RFC 6177]
Для крупных организаций и сайтов рекомендуется разреженное распределение (sparse allocation). Разреженное распределение IPv6 предполагает назначение префиксов с большим количеством дополнительных неиспользуемых префиксов между ними. Адресное пространство представляется в виде круга, который делится на равные сектора начиная с верхнего уровня иерархии. Каждая секция в свою очередь рассекается на нужное количество секторов нижнего уровня. Основное преимущество этого метода заключается в оставлении резервного пространства. Разреженное распределение иногда называют бисекцией, которая выделяет блоки на границе каждой новой половины. Этот метод обеспечивает резервное адресное пространство, которое с большей вероятностью будет непрерывным.
На рисунке ниже представлена визуализация метода разреженного распределения данных размером /42 на уровне регионов (1-4) в размер /48 на уровне сайтов:
Преимуществом режима разреженного распределения является гарантированное наличие непрерывного пространства, зарезервированного для всех выделенных ресурсов. Он хорошо подходит для суммирования маршрутов, уменьшает размер таблиц маршрутизации и упрощает настройку межсетевых экранов и других сетевых устройств. Хотя этот метод не определен как стандарт, он рассматривается как рекомендуемый подход к планированию адресации для поддержания чистоты и эффективности таблиц маршрутизации IPv6.
Однако для небольших сайтов лучшей практикой является компактная, а не разреженная нумерация подсетей и использование младших битов при нумерации подсетей по возможности в сочетании с "N+1" распределением. В IPv6 распределение "N+1" обычно относится к стратегии, при которой сетевой оператор запрашивает префикс для своих текущих потребностей (N) плюс дополнительное выделение (+1) для обеспечения будущего роста, часто для резервирования или для сохранения смежных блоков для расширения организации.
Окончательный выбор схемы адресации должен быть сделан по результатам анализа специфики и требований каждого сегмента, подробного обследования топологии, определение векторов расширения сети.
6) Резервируйте первую и последнюю подсеть
Резервирование первой (::0) и последней (::ffff:ffff:ffff:ffff) подсетей в IPv6 /64 не требуется RFC. В IPv6 каждый адрес в пределах подсети /64, включая первые и последние, является валидным адресом хоста, а использование подсети с одними нулями или единицами не создает конфликтов.
Тем не менее, оставлять в резерве первую и последнюю подсети считается хорошей практикой. Любая подсеть, однозначно обозначенная нулем, может вызвать путаницу. Разумно обозначать первую подсеть в любой группе числом 1 (в отличие от 0). Кроме того, эти подсети будут храниться в резерве для будущего использования, чтобы иметь как минимум две «резервные» подсети на этом уровне иерархии.
Используйте первую подсеть (00) для специальных служб или оставьте пустой, чтобы избежать путаницы с адресом самой сети.
Резервирование последней подсети (ff) часто используется для Subnet Router Anycast, который требует наличия адреса со всеми единицами в поле идентификатора подсети, поэтому её лучше не назначать хостам.
Не забывайте четко документировать все зарезервированные диапазоны.
7) Использование непредсказуемых механизмов присвоения статических IPv6 адресов для шлюзов и других критических важных сетевых устройств [RFC 7721]
Диапазоны IPv6 и адреса для устройств в таких сегментах, которые служат буфером между внутренней и внешней сетью (DMZ), должны быть стандартизированы, но использовать непредсказуемый механизм присвоения идентификаторов узлов инфраструктуры.
Мы знаем, что IPv4 сети легко могут быть просканированы, поскольку адресное пространство даже в несколько тысяч адресов не является проблемой для любого сетевого сканера. Совсем другая картина с IPv6 пространством. Номинальная сеть размером /64 содержит приблизительно 18,4 квинтиллионов адресов. Сканера, который может взять такой объем, не существует. Это значит, что адреса важных узлов можно надежно спрятать. Очень печально, когда сетевые инженеры продолжают использовать диапазоны низких значений (::1, ::2, ::3, т.д.) для шлюзов. В таком случае злоумышленникам просто нужно просканировать 100 адресов из низкого диапазона, чтобы идентифицировать шлюзы и межсетевые экраны.
С точки зрения безопасности, маршрутизатор или шлюз не следует рассматривать как первый хост в подсети. Аналогично, хосты не следует рассматривать последовательно, начиная с нижнего и верхнего пределов диапазона адресов узлов. Создание вручную настраиваемых случайных идентификаторов узлов — хорошее решение, но оно сопряжено с более высокими эксплуатационными затратами, что может сделать его непрактичным для администрирования всей сети. Однако дополнительная административная нагрузка может быть оправдана при применении к подсетям с высокой целевой ценностью. Мы должны помнить, что мере роста сеть становится более защищенной от случайных сбоев, но крайне уязвимой при атаке на главные хабы. Любой непредсказуемый механизм присвоения идентификаторов узлов важным сетевым устройствам предпочтительнее, если он обеспечивает правильный баланс между безопасностью и удобством обслуживания.
Больше информации про безопасное развертывание IPv6 систем будет в отдельной статье по безопасности. Здесь я упоминаю этот принцип так как он непосредственно связан с планированием адресного пространства и унификации принципов присвоения статических адресов.
8) Использование строчных букв в адресах IPv6 [RFC 5952]
Хотя регистр символов в IPv6-адресах не имеет значения, RFC 5952 рекомендует использовать нижний регистр. «Символы "a", "b", "c", "d", "e" и "f" в IPv6-адресе ДОЛЖНЫ быть представлены в нижнем регистре».
*********
Проектирование IPv6-сетей требует системного подхода. Грамотное планирование адресного пространства IPv6 опирается на отраслевые стандарты и глубокое понимание накопленного отраслью практического опыта.
В этой статье я рассмотрела только принципы планирования адресного пространства IPv6-сетей. В следующих статьях я постараюсь обобщить накопленный практический опыт по безопасности IPv6-сетей и правильного внедрения. Например, избирательная фильтрация сообщений ICMPv6 на периметре сети, обеспечивающая сохранение основных функций IPv6 при одновременной блокировке вредоносного или зондирующего трафика (RFC 4890), о правильном порядке и механизмах внедрения (Happy Eyeball RFC 8305, RFC 7381) и другие важные аспекты.
