Кратко

  • Туннель L2F создаётся на MID=0, а каждая клиентская связь принимается отдельно на ненулевом MID; это разные состояния.
  • CLID, MID, Challenge и Key указывают на протокольный контекст NAS–Home Gateway, но не удостоверяют человека или прикладную сессию.
  • Для трафика данных L2F не гарантирует надёжную доставку, поэтому исправный control plane не доказывает судьбу каждого кадра.

Виртуальная близость и реальные границы

RFC 2341 описывает виртуальный коммутируемый доступ. Пользователь физически звонит по PSTN или ISDN на Network Access Server провайдера. Однако PPP- или SLIP-соединение завершается на удалённом Home Gateway. L2F переносит между ними кадры канального уровня, отделяя место доступа от места завершения протокола.

В результате одна пользовательская попытка распадается на цепочку состояний. Вызов достигает NAS. PPP запускает LCP. NAS получает лишь достаточно данных о видимой личности, чтобы выбрать Home Gateway. Устройства создают туннель. Gateway отдельно решает судьбу конкретного клиента. Затем могут идти дополнительная аутентификация, NCP, передача кадров, прикладный вход, запрос и результат. Ни одно раннее состояние не наблюдает все последующие.

Управление туннелем использует MID=0. Стороны обмениваются L2F_CONF и L2F_OPEN, включая Name, Challenge и назначенные CLID. После этого туннель доступен для установления клиентов. Формулировка фиксирует возможность, а не наличие принятого клиента.

Каждому клиенту назначается ненулевой MID. NAS отправляет отдельный L2F_OPEN, который может содержать тип аутентификации и сведения CHAP, PAP или LCP. Ответ L2F_OPEN от Home Gateway означает принятие именно этой клиентской связи. Только затем начинается пересылка PPP- или SLIP-кадров. У клиентов внутри одного туннеля разные жизненные циклы OPEN/CLOSE.

Идентификатор не наследует свойства личности

CLID разделяет перемешанные туннели, когда нижележащая среда не различает их надёжно. MID выбирает клиента внутри туннеля. Ноль зарезервирован для состояния туннеля, ненулевые значения — для клиентов. Повторно используемый после закрытия MID должен быть инициализирован как совершенно новое соединение.

Это ссылки на записи состояния. Они не показывают, кто контролирует терминал, какими полномочиями обладает человек сейчас и какого субъекта признало приложение. Использовать MID как удостоверение — значит приписать ключу мультиплексирования отсутствующее свойство.

Сам RFC называет первую цель ISP поиском «apparent identity» пользователя и нужного Home Gateway. Решение о приёме или отказе принимает gateway. После приёма возможен третий этап PPP- или SLIP-аутентификации вне области L2F. CHAP из RFC 1994 тоже имеет собственную границу challenge-response. Получение имени, передача данных, проверка секрета, сетевое разрешение и прикладной вход — отдельные события.

Управление повторяется, данные могут теряться

Контрольные сообщения L2F подлежат повторной передаче. Для данных спецификация не предоставляет ни flow control, ни надёжной доставки: восстановлением занимается вложенный протокол. Обычный трафик данных, как правило, даже не использует поле L2F Seq.

Следовательно, подтверждённый OPEN, ответ ECHO, верный Key или растущий счётчик туннеля не подтверждают каждый payload frame. Они свидетельствуют об ответе peer, существовании контекста либо наблюдении на одной границе. Сквозной квитанцией это не становится.

Для PPP L2F переносит канальный кадр после удаления физического framing, transparency и FCS. PPP Echo, переговоры NCP и TERMREQ остаются туннелируемыми HDLC-like frames. L2F сам не распознаёт PPP TERMREQ; результат на PPP endpoint должен вызвать переход к L2F_CLOSE. Переносящая система не знает автоматически смысла переносимого результата.

PPP отдельно проходит LCP, необязательную аутентификацию и настройку сетевого уровня через NCP. Потом приложение устанавливает свою сессию. Даже полностью успешный путь до client OPEN не сообщает, состоялся ли прикладной запрос.

Key защищает ограниченный контекст

При создании туннеля стороны используют общий секрет и challenge-response. Последующие пакеты могут нести 32-битный Key, полученный из ответа аутентификации; пакеты с неизвестным CLID, неверным Key или ошибочным форматом должны отбрасываться. Это защита от некоторых видов spoofing в настроенном отношении NAS–Home Gateway.

Она не доказывает конфиденциальность payload, авторизацию конечного пользователя, прикладную идентичность или результат. Поздний RFC 3193 для L2TP/IPsec разделяет tunnel authentication, целостность каждого пакета, replay protection, конфиденциальность и end-to-end security. Нельзя приписывать эти свойства L2F задним числом, но их разделение показывает узость туннельного подтверждения.

Historic не означает ни провал, ни внедрение

RFC 2341 сейчас имеет статус Historic. В Status of Memo сказано, что документ не задаёт Internet standard какого-либо вида. IETF Datatracker относит его к Legacy stream без IETF endorsement и formal standing в процессе стандартизации. Это сохраняет техническую запись, но не подтверждает масштаб внедрения, совместимость реализаций, текущее использование или соответствие продукта.

Практическое наследие — точная цепочка квитанций. Следует отдельно хранить физический вызов, LCP, выбор gateway, туннель по CLID, клиента по MID, последующую аутентификацию, кадры на обоих концах, NCP, прикладную сессию и видимый результат. Счётчики NAS и Home Gateway нельзя преждевременно объединять. Состояние подтверждает только ту границу, где оно было измерено.

Источники