Подключение к интернету

Мы обещали рассказать про доступ в интернет через IPv6 — давайте это обсудим.

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

Что касается доступа в интернет в реальном мире через IPv6 — вы на самом деле уже активно им пользуетесь. Если у вас есть какая-то железка, например мобильный телефон, который работает через 4G, у вас обязательно IPv6 на нем есть — он не может не быть. Все современные технологии использования мобильных сетей основаны на IPv6. Даже если вы видите там IPv4, на самом деле это IPv4 уже в legacy-режиме — он реализован через переходные технологии. Но для вас как для клиента это все выглядит достаточно прозрачно: у вас есть железка, на ней есть IPv4-адрес и IPv6-адрес, и вы можете с этими адресами работать.

Сценарий с одним провайдером

IPv4: как было раньше

С IPv4 все понятно: у вас есть IPv4-адрес — может быть один, может быть целая пачка. Может быть, вы получаете доступ к канальной среде вашего провайдера, и он держит DHCP-сервер, от которого любые ваши железки могут получить адреса. Может быть, ваша CPE (Customer Premises Equipment) — то, что у вас находится на границе сети (если это мобильный телефон — то сам мобильник, если проводная сеть — роутер на границе с провайдером) — получит единственный адрес и дальше будет раздавать какую-то внутреннюю частную сетку, условно 192.168.0.0, и NATить во внешний публичный интернет. С IPv4 все в общем понятно и предсказуемо.

IPv6: получение адресов от провайдера

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

Например, если вы предприятие, у вас на границе с провайдером ставится ваша CPE — она же будет называться CE (Customer Edge). Провайдерский роутер в этом случае будет называться PE (Provider Edge).

Провайдерский роутер пересылает вам указание, какую сетку использовать. На канале между вами и провайдером настоящие адреса в общем-то и не нужны — вы себе адреса генерите самостоятельно либо с помощью SLAAC, либо просто link-local адреса.

Пачку адресов вы получаете по DHCPv6 Prefix Delegation. Провайдерский роутер может выдать вам, например, /48 или сразу /64 — неважно какую пачку выдаст, главное, что она должна быть крупнее, чем /64.

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

Как это работает

Провайдерский роутер выдает вам пачку адресов (например, /48). Ваша CPE, получив такую пачку, нарезает из нее сети /64 и назначает адреса конечным канальным средам. В сторону конечных клиентов направляется Router Advertisement. Клиенты, получив RA, берут левые 64 бита (префикс) и придумывают себе правые 64 бита с помощью Modified EUI-64. Результат — полноценный глобальный юникастовый адрес.

Провайдер ту сетку, которую он анонсирует своим клиентам, будет также отсылать всему остальному миру. Здесь будет использоваться BGP — ваш провайдер через провайдерскую сеть по BGP анонсирует всему остальному миру, что такие адреса используются именно этим провайдером.

Если какой-то сервер в интернете пытается достучаться до вашего адреса, сгенерированного по EUI-64, он будет видеть маршрут, который смотрит в сторону нашего провайдера. Все роутеры по пути будут знать, что сетка 2001:db8:b1:6b::/48 доступна именно в направлении нашего провайдера.

Маршрутизация и шлюзы

Вы анонсируете адреса, которые нужно использовать вашим клиентам. Со стороны вашего роутера анонсируете Router Advertisement, что вы будете шлюзом по умолчанию. Роутер провайдера тоже анонсирует, что он будет шлюзом по умолчанию. Поскольку все адреса генерятся после SLAAC, вы назначаете сами себе адреса, назначаете роутер соседа в качестве шлюза по умолчанию — и все прекрасно работает.

Это простейший сценарий подключения по IPv6 без каких-либо дополнительных технологий. Со стороны клиента нужно только на CPE сказать: получаем пачку адресов по DHCPv6 с помощью Prefix Delegation и анонсируем их своим клиентам.

Сценарий с двумя провайдерами

Если у вас два провайдера, ситуация немножко усложняется. Нужно:

1. Получить от каждого провайдера по пачке адресов
2. Выбрать, как отправлять трафик в интернет
3. В некоторых случаях — контролировать, как подключения из интернета к вашей сети будут осуществляться

Вариант с BGP и PI-адресами

Если вам нужно прозрачно переключаться между провайдерами (один провайдер умер — без потери соединения переключаетесь на другого), потребуется использовать:

• PI-адреса (Provider Independent) — провайдеро-независимые адреса
• BGP — для анонсирования этих адресов обоим провайдерам

Вы запускаете на вашей CPE BGP, подружаетесь с двумя провайдерами, анонсируете им свои PI-адреса. Все это надо заранее купить, согласовать, заплатить за использование BGP провайдерам. В общем, это дорого, долго и нудно.

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

Вариант с PA-адресами (без BGP)

Если у вас нет задачи прозрачно перескакивать между провайдерами или вы готовы в случае падения одного провайдера немножко пожить с недоступным сервисом снаружи, можно обойтись без BGP. Используются PA-адреса (Provider Assigned) — провайдер говорит: вот, используй такую-то пачку адресов (через Prefix Delegation или как-то еще). От каждого провайдера приходит отдельная пачка.

Как раздавать два префикса клиентам

Ничего страшного в том, чтобы в Router Advertisement указать два Prefix Information:

• Prefix Information 1 от провайдера 1
• Prefix Information 2 от провайдера 2

Ваши клиенты придумывают себе по два глобальных адреса — по одному из каждого полученного префикса. В IPv4 иметь два адреса было как бы некрасиво, а в IPv6 это норма. У вас может быть два адреса на клиентах — никаких проблем.

Политика выбора адресов

Приложение, которое хочет подключаться к наружным узлам, должно выбрать, из-под какого адреса подключаться. Для этого используются политики выбора адресов — Address Selection Policy. Эти политики передаются клиентам по DHCPv6 в виде соответствующей опции.

Клиент:

1. Придумал себе адрес 1 (из префикса провайдера 1)
2. Придумал себе адрес 2 (из префикса провайдера 2)
3. Получил по DHCPv6 опцию Address Selection Policy
4. Для конкретного приложения выбирает подходящий адрес

Обработка отказа провайдера

Если провайдер умирает, адреса должны быстро пропасть с клиентов. Для этого в Router Advertisement вы выставляете минимальные сроки жизни:

• Preferred Lifetime — например, 2 секунды. Если два RA подряд пропустили, адреса уже не стоит использовать
• Valid Lifetime — например, 5 секунд. Если в течение 5 секунд префикс не приходит, выкидываем его из таблицы маршрутизации и из таблицы адресов

Таймеры должны быть не меньше, чем интервал отправки Router Advertisement.

После отказа провайдера 2 приложения, использовавшие адреса этого провайдера, обнаруживают, что подключение отвалилось, и переподключаются из-под адресов провайдера 1. Адреса умершего провайдера протухают самостоятельно без какой-либо помощи со стороны провайдера — CPE просто перестает присылать соответствующий префикс.

Сравнение с IPv4

В IPv4-схеме все было бы по-другому. У вас был бы NAT на роутере и что-то типа Policy Based Routing для выбора, в какого провайдера отправлять трафик. Вы бы NATили пакеты в одну сторону в адреса PA1, в другую — в адреса PA2.

В IPv6 NAT не нужен — вы используете сразу оба адреса, и перебивать их не требуется.

NAT в IPv6 (если очень хочется)

NPTv6 — Network Prefix Translation

Если вам очень сильно хочется NAT в IPv6, есть механизм NPTv6 (Network Prefix Translation). Это описано в RFC 6296 как экспериментальный стандарт. Важно: экспериментальный — это не равно стандарту. RFC (Request for Comments) описывает, как рабочая группа по вопросам интернета рекомендует делать. RFC 6296 не говорит, что это норма — это скорее "можно попытаться так сделать, если очень хочется, но делайте стандартным образом".

NPTv6 работает следующим образом. У вас есть роутер, обслуживающий клиентов за Unique Local адресами (например, fd00::/64). Пакет идет из-под адреса fd00::2:1, и вы хотите выпустить его наружу. У вас есть глобальный маршрутизируемый префикс, например 2001:db8:2::/64.

Network Prefix Translation берет "плохой" префикс (Unique Local) и подставляет вместо него "хороший" (глобальный), но правая часть адреса (Interface ID) сохраняется — обычно по /64 маске:

fd00::2:1          -->  2001:db8:2::2:1
[ULA prefix][ID]   -->  [GUA prefix][ID]

Главное преимущество NPTv6 — она работает без сохранения состояния (stateless). Алгоритмическая трансляция: получили пакет, посмотрели на левые 64 бита, заменили на правильные, отправили дальше. Не нужно запоминать, кого во что перебили, как в NAT для IPv4. Это работает очень быстро.

Все проблемы NAT при этом сохраняются: портятся адреса внутри пакетов, портятся контрольные суммы, портятся цифровые подписи. Но если очень надо — можно делать.

NAT66 — полноценный NAT

Другая штука называется NAT66. Она не стандартная в том смысле, что по ней даже RFC нет — это вендорские реализации. Например, у Juniper есть NAT66.

Это полноценный NAT в том смысле, в котором он был в IPv4. У вас есть таблица трансляции:

Частный адрес	Публичный адрес
fd00::2:1	2001:db8:2::1
fd00::2:2	2001:db8:2::3

Обратите внимание: хвост адреса не обязательно сохраняется — он может быть любым.

NAT66 также позволяет работать не только с адресами, но и с сокетами (пара адрес + порт). Если два клиента используют один и тот же публичный адрес, различение идет по TCP/UDP-портам — точно так же, как это было в NAPT (Network Address and Port Translation) в IPv4.

Почему NAT в IPv6 — это зло

Использовать NAT в IPv6 — абсолютное зло. Это гарантированно приведет к проблемам:

• Не будет работать IPsec
• Не будут работать механизмы передачи протоколов, которые внутри себя кодируют адреса (как FTP в IPv4, где нужен ALG для расковыривания командной сессии и замены частных адресов на публичные)
• Проблемы с SIP — протоколом инициации сессий в телефонии, который указывает, какие адреса должны использоваться для передачи голосовых данных. За NAT (особенно за двойным NAT) телефония работает с огромными сложностями

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

• В каждой канальной среде — 2^64 адресов (это примерно 10^20 хостов)
• Каждый клиент получает сразу целую пачку адресов
• Юрлицо может получить 65 536 отдельных /64 сетей

Все это для того, чтобы хватило адресов и NAT был не нужен.

Тем не менее, для тех, кому очень хочется, есть два механизма:

• NPTv6 — stateless-трансляция (только префикс)
• NAT66 — stateful-трансляция (полноценный NAT с таблицей)

Итоги

• Один провайдер: все просто — подключаетесь, получаете пачку адресов по DHCPv6 Prefix Delegation, раздаете клиентам через RA, начинаете работать. Никакого NAT не надо
• Два провайдера: раздаете оба префикса клиентам, настраиваете Address Selection Policy по DHCPv6. При отказе провайдера адреса протухают автоматически благодаря коротким Preferred/Valid Lifetime в RA
• BGP + PI-адреса: нужны только если требуется прозрачное переключение между провайдерами без разрыва соединений
• NAT в IPv6: крайне не рекомендуется, но технически возможен через NPTv6 (stateless) или NAT66 (stateful)

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