Я живу в небольшом городе в так называемом «ближнем» Подмосковье, это примерно в 10 км от МКАД. В городе есть несколько Интернет-провайдеров, все они предоставляют доступ в Интернет через локальные городские сети. К одному из них подключен и я.
Время от времени я захожу на сайт своего провайдера с целью узнать, не изменилось ли чего в тарифах. Обычно примерно раз в год повышается гарантированная полоса пропускания на безлимитных тарифах при сохранении величины абонентской платы, и подобные новости всегда меня радуют. В этот раз изменений в тарифах не было, но появилась информация, что в тестовом режиме заработал доступ по протоколу IPv6.
Условия просто отличные: прямой пиринг с вышестоящими провайдерами (то есть никаких дурацких туннелей) и — тадам! — бесплатный нелимитированный трафик. Понятное дело, я сразу взялся поднять у себя это дело.
И тут возник вопрос. Основным преимуществом IPv6 перед IPv4 является не просто большое, а гигантское адресное пространство, адреса в IPv6 могут закончиться только если земной Интернет распространится и в другие галактики. При такой прорве адресов логично, если все мои машины в квартире получат по «белому» IPv6 адресу. Однако у провайдера IPv6 настроен очень просто и без затей: в локальную сеть раздаются адреса из /64 префикса через stateless автоконфигурацию. Таким образом мой маршрутизатор может получить один адрес на своем внешнем интерфейсе, а все внутренние сети придется по прежнему пропускать через NAT.
Чтобы избавиться от NAT нужно получить не просто адрес, а сеть. Я написал письмо в техподдержку с вопросом о возможности такой процедуры, но ответа не получил. Я написал еще раз, добавив в копию адрес noc@. Оказалось, что такого адреса нет, и снова письмо осталось без ответа. И тогда я решил действовать самостоятельно.
Из префикса /64 можно абсолютно безболезненно вырезать себе необходимый кусок. Дело в том, что при автоконфигурации IPv6 адреса в этом префиксе генерируются на базе MAC-адресов клиентов. Таким образом, подобрав заведомо несуществующий блок MAC-адресов, можно выделить себе нужный подпрефикс.
Остается одна проблема. Маршрутизатор провайдера не знает, что мы забрали себе кусок его префикса, и не сможет направлять трафик на внешний интерфейс нашего маршрутизатора. Еще одна проблема — внешний интерфейс маршрутизатора не должен находиться в той же сети, что и внутренние интерфейсы. То есть нужна еще некая пиринговая сеть.
Первая проблема решается так же, как и в мире IPv4 — через ARP-прокси. Только вместо ARP в IPv6 используется NDP — Neighbor Discovery Protocol. Для управления этим протоколом в OpenBSD существует утилита ndp(8). Вторую проблему можно решить довольно неожиданным способом. В IPv6 каждый сетевой интерфейс имеет так называемый link-local адрес. Этот адрес имеет смысл только внутри локального сегмента сети и не маршрутизируется. Понятно, что и внешний интерфейс моего маршрутизатора, и внутренний интерфейс маршрутизатора провайдера имеют по такому адресу, и эти адреса находятся в одной сети.
Таким образом все теоретические аспекты будущей конфигурации были проработаны, и я уже был готов приняться за реализацию, как вдруг мне пришло в голову попытать счастья с техподдержкой провайдера еще раз. Я вспомнил, что на сайте провайдера есть форум, на котором довольно часто появляются специалисты технической поддержки. Я повторил свой вопрос там в ветке обсуждения протокола IPv6 и в тот же день получил положительный ответ, а вместе с ним собственный префикс /64 и статический маршрут на свой маршрутизатор!
Итак, городить огород не пришлось, чему я очень рад. Дальше все было просто. В силу того, что выдали мне префикс /64, раздавать на внутренних интерфейсах я мог только более узкие сети, например /80. Для таких сетей простая stateless автоконфигурация не работает, нужно поднимать DHCPv6. Для этого был поставлен из портов и настроен WIDE-DHCPv6. Кроме того был поднят rtadvd(8), который выдавал маршрут по умолчанию и флаг «Other statefull configuration», сообщающий клиентам, что адреса необходимо получать по DHCP.
После этого все отлично заработало как на лаптопе с OpenBSD, так и на десктопе с Windows 7. Замеры скорости приятно удивили: 12-13 Мбит/сек. Еще один приятный сюрприз: сервисы Google, в том числе YouTube, оказались доступны по IPv6. Дело в том, что Google не дает IPv6 адреса своих сервисов всем подряд. Чтобы получить доступ, провайдер должен связаться с Google, доказать, что предоставляет IPv6 связность хорошего качества, и тогда Google вносит рекурсивные DNS серверы провайдера в «белый» список, разрешая им резолвить имена своих сервисов в IPv6 адреса. Видимо, мой провайдер всю эту процедуру прошел.