Теоретические основы и архитектура
В сетях BNG применяются две основные модели подключения абонентов: PPPoE (Point-to-Point Protocol over Ethernet, RFC 2516) и IPoE (IP over Ethernet: сессия поверх DHCP без PPP; описывается спецификациями Broadband Forum, например TR-101 и TR-146, а не одним RFC). 1. PPPoE: классический протокол, устанавливающий PPP-сессию между CPE и BNG. Две фазы: Discovery (PADI — broadcast-поиск концентратора, PADO — предложение BNG, PADR — запрос сессии клиентом, PADS — подтверждение с Session ID, PADT — разрыв) и PPP Session (LCP — параметры канала и MRU 1492, PAP/CHAP — аутентификация, IPCP/IPv6CP — адресация). Плюсы: встроенная аутентификация, привычная модель сессии, простое отключение неплательщика. Минусы: оверхед 8 байт (нужен MSS clamping или RFC 4638), PPP-автомат и keepalive в control plane, неудобный multicast IPTV; пересылка данных у современных BNG при этом идёт в аппаратуре. 2. IPoE: безтуннельный доступ на базе DHCP (DHCPv4 Option 82 / DHCPv6 Option 18/37). Коммутатор доступа вставляет Circuit-ID (порт) и Remote-ID (узел доступа), BNG определяет линию по этим идентификаторам и запрашивает авторизацию в RADIUS: логин и пароль не вводятся. Option 82 лишь идентифицирует линию, а не аутентифицирует её: доверять ей можно, только если её вставляет и фильтрует собственный коммутатор доступа. MTU остаётся 1500.
PPPoE: две фазы и формат кадра
PPPoE (RFC 2516) переносит PPP внутри Ethernet. Кадры Discovery идут с EtherType 0x8863, кадры сессии - 0x8864. Заголовок PPPoE (6 байт): Version=1 (4 бита), Type=1 (4 бита), Code (1 байт), Session-ID (2 байта), Length (2 байта); за ним 2 байта PPP Protocol. Итого оверхед 8 байт: при Ethernet MTU 1500 максимум IP-пакета - 1492, поэтому MRU по умолчанию 1492. RFC 4638 (тег PPP-Max-Payload) позволяет договориться о 1500, если на всём пути MTU >= 1508 (baby-jumbo), но не все CPE это поддерживают.
Discovery - четыре пакета и теги в формате TLV:
- PADI (Code 0x09), broadcast ff:ff:ff:ff:ff:ff, Session-ID 0: клиент ищет концентратор; теги Service-Name (0x0101, пустой = "любой"), Host-Uniq (0x0103).
- PADO (0x07), unicast: BNG предлагает себя; теги AC-Name (0x0102) и Service-Name, при необходимости AC-Cookie (0x0104) против флуда PADR.
- PADR (0x19), unicast: клиент выбирает один из PADO и запрашивает сессию.
- PADS (0x65): BNG присваивает Session-ID (1-65535, уникален в паре MAC клиента + MAC BNG) и подтверждает.
- PADT (0xA7): разрыв сессии любой стороной. Клиент повторяет PADI с экспоненциальной паузой; пустой ответ означает, что service-name не совпал, VLAN неверный или лимит
sessions per-macисчерпан.
PPP: LCP, аутентификация, NCP
После PADS идёт PPP на 0xC021 (LCP): Configure-Request/Ack/Nak/Reject, опции MRU (1), Authentication-Protocol (3), Magic-Number (5). Magic-Number позволяет распознать петлю, Echo-Request/Reply - это keepalive (обычно интервал 10-30 с, 3-5 потерь = разрыв). Аутентификация: PAP (0xC023) передаёт пароль открытым текстом один раз, клиент инициирует; CHAP (0xC223, RFC 1994) - BNG шлёт случайный challenge, клиент отвечает MD5(id + secret + challenge), пароль по линку не идёт, BNG может повторять challenge во время сессии. Для RADIUS CHAP-вариант передаётся атрибутами CHAP-Password и CHAP-Challenge, сервер должен знать secret в открытом или обратимом виде. Далее NCP: IPCP (0x8021) согласует IP-Address (option 3), DNS-серверы (129/131, RFC 1877); IPv6CP (0x8057) согласует только 64-битный Interface-Identifier, а префикс выдаётся уже вне PPP: SLAAC (RA от BNG) для WAN-адреса и DHCPv6 IA_PD (RFC 8415) для делегированного префикса LAN (обычно /56 или /60). IPv4 по IPCP - /32 point-to-point: BNG добавляет в таблицу маршрут /32 на виртуальный интерфейс сессии.
IPoE: DHCP вместо PPP
IPoE не создаёт туннеля: клиент шлёт DHCPv4 Discover (RFC 2131) прямо в Ethernet, а BNG выступает DHCP-сервером или relay (giaddr = адрес BNG). Сессией считается связка MAC + (S-VLAN, C-VLAN) + option 82; BNG создаёт её по первому пакету (DHCP Discover либо любой неклассифицированный IP/MAC-пакет), а не по отдельному протоколу. Авторизация идёт в RADIUS: User-Name = MAC или Circuit-ID/Remote-ID из option 82 (sub-option 1 и 2, RFC 3046), поэтому абонент не вводит пароль и привязан к порту. Для неавторизованных (первое включение, нулевой баланс) BNG создаёт "ограниченную" сессию в walled garden: DNS и HTTP-редирект на портал оплаты, после ввода данных биллинг отправляет CoA, и сессия переводится в рабочий профиль. DHCPv6 использует IA_NA/IA_PD и option 18/37 (Interface-ID/Remote-ID). Стандарты по IP-сессиям - Broadband Forum TR-101 и TR-146.
Живость IPoE-сессии BNG определяет косвенно: по аренде DHCP и по ARP/ICMP-проверкам клиентского адреса; при отсутствии ответа сессия закрывается и учёт останавливается. Ограничение на число адресов на порт и привязка MAC-IP (IP source guard/anti-spoofing) выполняются на BNG с опорой на привязку из DHCP.
Сравнение и выбор модели
| Параметр | PPPoE | IPoE |
|---|---|---|
| Идентификация | логин/пароль или realm в имени | MAC, Circuit-ID/Remote-ID |
| MTU | 1492 (или 1500 по RFC 4638 при MTU 1508) | 1500 |
| Состояние | PPP Session-ID на каждого | запись DHCP + IP-сессия |
| Multicast IPTV | нужен отдельный VLAN/профиль, IGMP не идёт внутри PPP | нативный IGMP от STB |
| Разрыв неплательщика | PADT/CoA Disconnect | CoA Disconnect, перевод в walled garden |
| Нагрузка | инкапсуляция PPP на каждый кадр в CPE и BNG | чистый IP |
Современный BNG пересылает оба вида трафика в аппаратуре, поэтому разница в основном - в контрольной плоскости (PPP-автомат, CHAP, keepalive) и в клиентском оборудовании.
MTU и MSS
MSS для IPv4 по PPPoE: 1492 - 20 (IP) - 20 (TCP) = 1452; для IPv6: 1492 - 40 - 20 = 1432. Если фильтруется ICMP "fragmentation needed" (type 3 code 4) или ICMPv6 Packet Too Big, Path MTU Discovery ломается и сайты с большими ответами зависают после TCP-handshake. Лечение - MSS clamping на BNG (ip tcp adjust-mss, tcp-mss/change-tcp-mss) и разрешение ICMP. Для IPoE MTU совпадает с Ethernet, но на пути до BNG учитывайте теги (4 байта на каждый).
