Кратко

  • RFC 3355 размещал L2TP на виртуальном канале ATM AAL5, но требовал помещать каждый PDU L2TP в один PDU AAL5; внешняя MTU ограничивала туннель и все сеансы PPP.
  • Выбор инкапсуляции, установка, защита и очистка VC оставались фактами среды. Согласование формата не доказывало внутреннюю доставку, а очистка SVC завершала сеансы.

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

RFC 3355 вышел в августе 2002 года на Standards Track и определил L2TP поверх ATM Adaptation Layer 5. Базовый L2TP проектировался независимо от носителя и требовал пакетной двухточечной связи. Виртуальный канал AAL5 между LAC и LNS мог стать такой связью.

Ключевое правило требовало переносить каждый PDU L2TP одним PDU AAL5. Поэтому MTU соединения AAL5 ограничивала MTU туннеля и MRU всех PPP-соединений внутри. Логически разные сеансы разделяли один внешний конверт.

Реализация обязана была поддерживать PPP MRU не менее 1500 октетов. Рекомендовалась вместимость IP-пакета не менее 9180 октетов внутри PPP PDU. Это требования способности и рекомендация, а не факт активного пути. PVC мог быть настроен иначе, SVC получить другие параметры, а PPP — договориться о меньшем MRU.

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

AAL5 представлялся как бит-синхронное, полнодуплексное, двухточечное звено. VC мог быть постоянным или коммутируемым по запросу. Требовался негарантированный message mode без доставки повреждённых данных и интерфейс целых октетов.

Граница сообщения, длина и CRC подтверждали свойства рамки, но не надёжность целиком. Они не аутентифицировали отправителя, не давали конфиденциальность и не доказывали принятие L2TP или получение приложением.

Содержимое называлось двумя способами. LLC/SNAP явно помещал идентификатор IANA для L2TP в каждый PDU. VC-multiplexing убирал заголовок, потому что стороны заранее согласовали назначение канала. Идентичность находилась либо в сообщении, либо в контексте.

LLC на PVC был обязательным, LLC на SVC и VC-multiplexing — опциональными. Концы PVC должны были иметь одинаковую конфигурацию. Два устройства с L2TP могли по-разному понять байты при несовпадающем контексте.

Для SVC выбор переносился в плоскость управления ATM через B-LLI. Вызывающая сторона предлагала LLC, VC-multiplexing или оба в порядке предпочтения. При принятии двух вариантов вызываемая сторона выбирала один. Предложение только неподдерживаемого варианта отклонялось.

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

Сброс показывал власть скрытой зависимости. При сбросе туннеля на SVC обе стороны очищали SVC, и все пользовательские сеансы завершались. Новый клиент мог вызвать новую установку, но она не продолжала прежние сеансы прозрачно.

Уведомление об очистке AAL5 SVC также требовало разобрать туннель и вернуть управляющее соединение в idle. Внешнее событие уничтожало звено, на котором жил внутренний статус. Независимость от деталей не была независимостью от отказа.

После сбоя установки решение считать узел недоступным и решение о его возврате оставались реализационными. Без активных сеансов любая сторона могла очистить SVC. Меткам «недоступен», «очищен» и «idle» нужны слой, наблюдатель, событие и поколение.

Несколько AAL5-соединений могли разделять QoS клиентов. Обратное мультиплексирование одного туннеля по нескольким VC оставалось будущей работой. Параметры PVC согласовывались, SVC запрашивались. Запрос и конфигурация не доказывали наблюдаемую производительность.

Корректная инкапсуляция не давала безопасность. RFC 3355 предупреждал об атаках на ATM и указывал на заголовки аутентификации, шифрованную нагрузку или защиту ATM. Правильные PID, B-LLI и CRC не заменяли криптографию.

RFC 2661 задаёт состояние L2TP, RFC 1661 — PPP и MRU, RFC 2684 — LLC и VC поверх AAL5, RFC 2364 — прямой PPP/AAL5, RFC 2331 — сигнализацию. RFC 3070 описывает другой носитель, Frame Relay. RFC 3193 добавляет IPsec. RFC 4459 позже рассматривает MTU и фрагментацию туннелей вообще.

Реестр IANA координирует значения L2TP, но не подтверждает их использование. Источники не доказывают продукт, развёртывание, трафик, инцидент или восстановление RFC 3355.

Исторический урок — в честной абстракции. L2TP мог скрыть ATM от PPP. AAL5 VC всё равно задавал размер, способ идентификации и судьбу сеансов при очистке. Среда исчезала из поля зрения, не теряя влияния.

Sources