Теоретические основы и архитектура
Абонент сегодня получает IPv6 так же обязательно, как IPv4, и BNG должен выдать ему адрес для самого CPE, префикс для домашней сети и сведения о DNS, при этом не сломав учёт, привязку к VRF и маршрутизацию. В PPPoE и IPoE это делают по-разному: PPP согласовывает только идентификатор интерфейса (IPv6CP), а префиксы приходят из Router Advertisement и DHCPv6 (IA_NA для адреса WAN, IA_PD для делегированного префикса). Урок разбирает флаги M/O и параметры RA, различие SLAAC и DHCPv6, делегирование префикса и его маршрутизацию на BNG, атрибуты RADIUS для IPv6. Затем рассматриваются переходные механизмы: DS-Lite (RFC 6333) с AFTR, NAT64/DNS64, 464XLAT и 6rd. Вторая часть - L2TPv2 (RFC 2661) для оптового доступа: LAC принимает PPP-сессию, LNS другого оператора её завершает, а RADIUS передаёт атрибуты туннеля (RFC 2868). Предполагаются знания PPPoE/IPoE, RADIUS и CGNAT из предыдущих уроков модуля.
Как IPv6 получает абонент: роли RA и DHCPv6
В IPv4 DHCP выдаёт адрес, маску, шлюз и DNS одним обменом. В IPv6 функции разделены: шлюз по умолчанию CPE узнаёт только из Router Advertisement (RFC 4861), DHCPv6 (RFC 8415) шлюз не передаёт. RA отправляется по Router Solicitation и периодически; в нём стоят флаги M (managed: адрес через DHCPv6) и O (other: прочие параметры, например DNS, через DHCPv6), время жизни маршрутизатора (по умолчанию 1800 с, 0 означает "не шлюз"), интервал RA (по RFC 4861 максимум по умолчанию 600 с, у многих платформ - 200 с) и Prefix Information Option (PIO) с префиксом, сроками valid/preferred (по умолчанию 2592000 и 604800 с) и флагами L (on-link) и A (autonomous: можно строить адрес SLAAC). Для SLAAC префикс должен быть /64. Практика оператора: на WAN-канале ставят M=1 или SLAAC с O=1, а префикс LAN выдают DHCPv6 IA_PD. Длинные интервалы RA замедляют обнаружение отказа шлюза и пересмотра префикса: на широкополосном доступе их держат в сотни секунд, а не в минуты.
PPPoE и IPoE: чем отличается старт
В PPPoE после LCP и аутентификации NCP IPv6CP (RFC 5072) согласует только 64-битный идентификатор интерфейса; адрес WAN строится SLAAC по RA либо выдаётся DHCPv6 IA_NA, а PD запрашивается отдельным DHCPv6. Профиль RADIUS управляет префиксами: Framed-IPv6-Prefix (97) для адреса WAN, Delegated-IPv6-Prefix (123, RFC 4818) для PD, Framed-IPv6-Pool (100), Framed-IPv6-Route (99), Framed-Interface-Id (96), DNS-Server-IPv6-Address (169, RFC 6911). В IPoE нет PPP-сессии: жизненный цикл определяют RA, DHCPv6 и аренда, абонента опознают по link-local, DUID и данным ретрансляции (option 18 Interface-ID и 37 Remote-ID, RFC 3315/4649) от access-узла, который работает как Lightweight DHCPv6 Relay Agent (RFC 6221). Без LDRA на access-узле BNG не знает, на каком порту сидит абонент.
Делегирование префикса и его маршрутизация
IA_PD (RFC 3633, затем RFC 8415) выдаёт CPE префикс для LAN: чаще всего /56 или /60 (редко /48), иногда /64 для простых устройств. Размер пула считается по разности длин: пул /40 с /56 вмещает 2^16 = 65536 абонентов, пул /48 с /64 на WAN - тоже 65536. Главная задача BNG: на каждый делегированный префикс установить маршрут с next-hop link-local адресом CPE на интерфейсе абонента, иначе обратный трафик из ядра не попадёт в домашнюю сеть. Эти маршруты не раздаются в IGP по одному: BNG суммирует пул (для /40 - один маршрут) и объявляет его в IGP/BGP, а при сбросе сессии маршрут исчезает. Для PPPoE маршрут исчезает вместе с интерфейсом. Для IPoE он зависит от аренды: при нестабильной аренде ставят короткие T1/T2 и контроль доступности, чтобы не держать маршруты "мёртвых" CPE. При отказе BNG и замене в резерве делегированный префикс должен остаться прежним (привязка в RADIUS или синхронизация), иначе абонент сменит префикс и сломает свою домашнюю сеть.
DS-Lite, NAT64/DNS64, 464XLAT, 6rd
DS-Lite (RFC 6333): сеть доступа только IPv6, CPE (B4, Basic Bridging BroadBand element) инкапсулирует IPv4-пакеты в IPv6 к AFTR (Address Family Transition Router) оператора, где выполняется NAT44. Адрес AFTR CPE узнаёт из DHCPv6 option 64 (AFTR-Name, RFC 6334) и разрешает его через DNS. Приватные IPv4-адреса абонентов не нужны в сети оператора, адреса RFC 6598 для NAT444 не тратятся; в ключ трансляции входит IPv6-адрес B4, поэтому разные абоненты могут иметь одинаковые частные IPv4. Минусы: туннель добавляет 40 байт заголовка (на MTU 1500 выходит 1460 для внутреннего IPv4), нужен учёт по IPv6 абонента, порты и логирование аналогичны CGNAT. NAT64 (RFC 6146) с DNS64 (RFC 6147) даёт клиентам только с IPv6 доступ к IPv4-серверам: DNS64 синтезирует AAAA из A с префиксом 64:ff9b::/96 (RFC 6052) или своим, а NAT64 транслирует пакеты. Приложения с IPv4-литералами не работают, их закрывает 464XLAT (RFC 6877): CLAT на устройстве транслирует IPv4 в IPv6, а PLAT (NAT64) у оператора возвращает его в IPv4; схема распространена в мобильных сетях. 6rd (RFC 5969) - противоположный вариант: IPv6 поверх IPv4-доступа без состояния, префикс абонента строится из его IPv4-адреса и 6rd-префикса оператора, на границе стоит Border Relay. Сегодня это временная мера, когда доступ нельзя перевести на IPv6.
L2TPv2: LAC, LNS и опт
L2TPv2 (RFC 2661) переносит PPP-кадры через IP. LAC (L2TP Access Concentrator) принимает PPP-сессию, LNS (L2TP Network Server) её завершает. Транспорт - UDP, порт 1701. Сначала строится управляющее соединение (tunnel): SCCRQ - SCCRP - SCCCN, затем для каждого абонента сессия: ICRQ - ICRP - ICCN. Управляющие сообщения надёжны (номера Ns/Nr, ZLB как подтверждение), keepalive - сообщение Hello (по умолчанию 60 с). Туннель можно аутентифицировать общим секретом (challenge/response, MD5); шифрования у L2TP нет, при необходимости его даёт IPsec (RFC 3193). Идентификаторы Tunnel ID и Session ID локальны для каждой стороны. Накладные расходы - IP 20 + UDP 8 + L2TP 6-12 + PPP 2-4 байта, поэтому MSS подбирают (обычно 1400-1412) и учитывают, что PPPoE на LAC уже даёт MTU 1492.
