Кратко

  • RFC 2516 отделил обнаружение без состояния сеанса от сеанса PPP «точка—точка». Хост и концентратор выделяли ресурсы виртуального интерфейса только после установления сеанса.
  • Необязательный AC-Cookie позволял концентратору проверить, вернулось ли отправленное значение с адреса источника. Host-Uniq и Relay-Session-Id обслуживали отдельные задачи корреляции хоста и ретранслятора.
  • Эти непрозрачные теги несли ограниченный контекст пакета. Ни один не удостоверял человека и не доказывал последующую настройку PPP, передачу трафика или оказание коммерческой услуги.

Широковещательный запрос без таблицы сеансов

В феврале 1999 года RFC 2516 описал передачу PPP по Ethernet, которым совместно пользовались несколько хостов и концентраторов доступа. Хост рассылал PADI; способные обслужить его концентраторы могли ответить PADO. Хост выбирал одно предложение, направлял выбранному концентратору unicast-запрос PADR и получал PADS с подтверждённой услугой и идентификатором сеанса. Документ явно разделил обнаружение и сеанс PPP: до установления сеанса обнаружение не создавало его состояние. После установления и хост, и концентратор должны были выделить ресурсы виртуального PPP-интерфейса.

Так общая среда не превращала каждое видимое обращение в долговременное обязательство хранить состояние сеанса. «Без состояния» не означает, что обработка пакетов бесплатна; это граница, за которой выделяются ресурсы именно выбранного соединения PPP.

Значение должно было вернуться

Концентратор мог включить в PADO необязательный тег AC-Cookie. Хост обязан был без изменений вернуть его в PADR и не интерпретировал содержимое. RFC рекомендовал концентратору уметь заново вычислить значение по адресу источника из PADR. Это позволяло проверить, может ли адрес, получивший предложение, отправить значение обратно, и ограничивать число одновременных сеансов для этого адреса.

В качестве примера документ приводит HMAC от MAC-адреса хоста с ключом, известным только концентратору. Алгоритм не предписан; RFC прямо предупреждает, что cookie не защищает от всех DoS-атак. Механизм откладывает выделение ресурсов до возврата значения, но не устанавливает, кто находится за сетевым адресом.

У остальных тегов другие владельцы. Хост выбирает Host-Uniq, чтобы сопоставить ответ со своим запросом; концентратор возвращает байты без интерпретации. Relay-Session-Id может добавить промежуточный ретранслятор; для обоих конечных узлов он непрозрачен и возвращается неизменным. Корреляция не превращается в идентификацию.

PADS меняет состояние ресурсов

Принятый PADS содержит ненулевой SESSION_ID и имя согласованной услуги. Отказ сопровождается тегом ошибки и нулевым ID. Сеанс PPPoE задаётся совместно MAC-адресами источника и назначения и SESSION_ID; одного 16-битного номера недостаточно.

PADS переводит обмен к этапу PPP Session, но не выполняет описанные в RFC 1661 согласование LCP, возможную аутентификацию и настройку сетевых протоколов NCP. Эта статья не повторяет соседнюю тему RFC 4638 о размере полезной нагрузки и пределе 1492 байта. Здесь рассматриваются момент выделения ресурсов и границы трёх тегов, а не доставка последующей услуги.

RFC 2516 документирует проектное решение по защите ресурсов и заявленные ограничения. Он не измеряет экономию памяти, не доказывает современное применение и не подтверждает аутентификацию либо трафик конкретного сеанса.

Источники: RFC 2516; RFC 1661; RFC 2104; RFC 4638 (соседняя тема размера пакета, здесь исключена).