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

Бывает, что хостеры назначают разным клиентам IPv6-адреса внутри одной сети /64. При этом крупные сервисы, вроде Google, воспринимают все адреса внутри диапазона /64 как одного клиента. В результате клиенты могут страдать из-за действий соседа по диапазону.

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

В статье мы разберем основные ошибки использования IPv6 провайдерами.

Завязка сюжета: RFC 3177

В 2001 году в рекомендациях по распределению адресов было рекомендовано (простите за тавтологию, это важно) выделять:

• /48 в общем случае
• /64 если за ним одна и только одна подсеть
• /128 если одно и только одно устройство

Одиозный документ RFC 2119, в котором регламентируется применение различных уровней обязательности для выполнения указаний определяет «рекомендуется» следующим образом:
Слова «Должны» или «Рекомендуется» означают, что могут существовать обоснованные причины в определенных обстоятельствах не поступать указанным образом, однако выбор другой линии поведения должен быть взвешенным решением, принятым с полным пониманием последствий.
Возможно, полного понимания последствий на тот момент ни у кого не было, возможно «определённые обстоятельства» так и не были определены, но, так или иначе, рекомендациям все следовали.

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

Осознание проблемы: RFC 6177

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

Основная логика при рекомендации размера выдачи блока /48 конечному потребителю преследовала три цели.

Во-первых, назначенное пространство адресов должно быть достаточным для целей потребителя и легко расширяемым, без приседаний со штангой. Да, именно так и написано, только в английском варианте — jump through hoops. Одна из важных причин перехода на IPv6 — это изменение существующего размера назначения от «один адрес» до «множество подсетей».

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

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

Хотя все эти условия выполнялись, стало очевидным что рекомендация /48, мягко говоря, избыточна.

Закрепление /64 как единицы выдачи

Помимо порядка распределения были и другие моменты. Оказалось, что многие особенности IPv6 не работают, если префикс сети не /64. А именно не работают:

• Neighbor Discovery (ND)
• Secure Neighborship Discovery (SEND)
• некоторые части Mobile IPv6
• Site Multihoming by IPv6 Intermediation
• много разных мелочей

Дополнительным фактором стало то, что многие проектируемые технологии опирались именно на такой префикс сети.

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

Второе — переход на новый стандарт всегда является болью для техподдержки и системных администраторов. Единый префикс/64 должен был уменьшить эту боль до приемлемого значения.

Положение дел на фронтах

Как уже происходило ранее в далёком 2001, рекомендацию /64 многие крупные игроки интернета воспринимают как стандарт. С одной стороны это хорошо, с другой не очень.

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

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

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

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

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

Помимо этого, возможны и другие неприятные неожиданности. Например вы получили в своё пользование блок /64, но это динамический блок, как динамический адрес — сегодня 2001:DA8:1D01:FA13::/64, завтра 2001:DA8:1D01:FС15::/64. Новые приключения каждый день!
Есть немалый шанс встретить разнообразные комбинации этих проблем и другие причудливо изогнутые грабли в довесок.

Выдаем IPv6 со своего сервера

Если у нас есть квинтиллионы IP-адресов, то почему бы не выдавать реальные IP-адреса, например, VPN-клиентам так, чтобы они ходили в интернет без NAT и могли принимать входящие подключения из мира. Звучит прекрасно, но на практике сделать это не так просто. Для этого потребуется отдельная IPv6 сеть, маршрутизируемая через IP-адрес, назначенный на интерфейс сервера.

Допустим, на сервер назначен адрес 2a01:baba::c0fee:dead/64, тогда для VPN-клиентов потребуется отдельная сеть вроде 2a01:baba:fafa:0f0f::/64, маршрутизируемая через адрес 2a01:baba::c0fee:dead/64.

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

Заключение

Читать рекомендации IETF не самое интересное занятие, однако крайне полезное. Заполнять им долгие зимние вечера явно не стоит, но и пренебрегать чтением важных для вас разделов также нежелательно.

Выбирая себе провайдера, убедитесь, что он разделяет эту точку зрения.

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

Подписывайтесь на нашего разработчика в Instagram