Кратко

  • В доступе PPP IPv6CP следует после LCP, а аутентификация и авторизация RADIUS могут завершиться до назначения адреса. Поэтому NAS может ещё не знать, будет ли узел использовать IPv4, IPv6 или оба варианта.
  • RFC 3162 разрешил включать атрибуты обоих семейств в одно сообщение RADIUS и оставил NAS выбор тех, которые может использовать клиент. Авторизованное значение само по себе не доказывает, что адрес, префикс, маршрут или работающий сервис уже существуют.

Ответ пришёл раньше вопроса

Серверу доступа нужно решение политики до открытия сеанса абонента. Но когда он спрашивает сервер RADIUS, можно ли допустить пользователя, итоговая конфигурация сетевого уровня узла может быть ещё не определена. Эта последовательность — самый примечательный аспект RFC 3162 «RADIUS and IPv6», опубликованного в августе 2001 года.

Документ рассматривает две связанные, но разные задачи. RADIUS может работать поверх IPv6; отдельно сообщения RADIUS могут нести атрибуты для предоставления пользователю доступа к сети IPv6. IPv6-адрес, используемый для передачи RADIUS, не означает, что абоненту уже назначили IPv6-префикс. Стандарт касается обоих случаев, однако временная проблема относится ко второму.

RFC 3162 объясняет порядок на примере доступа через Point-to-Point Protocol. Link Control Protocol (LCP) выполняется раньше IPv6 Control Protocol (IPv6CP). Аутентификация и авторизация RADIUS могут завершиться до назначения адресов. Поэтому в момент отправки Network Access Server (NAS) сообщения Access-Request он может ещё не знать, будет ли узел использовать IPv4, IPv6 или оба протокола.

Из-за этого не подходит простое решение: сначала спросить, какое семейство адресов будет использовать клиент, и вернуть лишь относящиеся к нему атрибуты. NAS должен получить решение раньше, чем последующее согласование даст ответ. RFC 3162 предлагает не угадывать. Атрибуты IPv4 и IPv6 можно передавать в одном сообщении RADIUS, а NAS выбирает применимые. Он должен назначать только адреса и префиксы, которыми клиент действительно сможет пользоваться.

Авторизация не равна настройке

Сами атрибуты различаются по назначению. NAS-IPv6-Address идентифицирует устройство, запрашивающее аутентификацию. Framed-Interface-Id относится к идентификатору интерфейса IPv6. Framed-IPv6-Prefix передаёт префикс и соответствующий маршрут, которые следует настроить пользователю. Framed-IPv6-Route содержит сведения о маршрутизации, а Framed-IPv6-Pool называет настроенный пул для выдачи префиксов. Это разные контрольные точки, а не взаимозаменяемые доказательства связности.

Некоторые значения прямо обозначены как подсказки. Если IPv6CP успешно согласовал опцию Interface-Identifier, NAS помещает предпочитаемый им идентификатор в Access-Request. Серверу RADIUS рекомендуется учесть эту подсказку, но это не обязательно. NAS также может предложить предпочтительный IPv6-префикс, а сервер вправе его проигнорировать. Access-Accept — ответ политики, но не запись о том, что интерфейс клиента принял предпочтение или что пакеты уже достигают Интернета.

RFC 3162 ограничивает и применение полученных данных. Нет нужды резервировать адрес IPv4 для узла, поддерживающего только IPv6; узлу, использующему только IPv4 или 6to4, не нужен префикс IPv6. Этот узкий совет проясняет ответственность: сервер RADIUS выдаёт атрибуты политики, а NAS видит согласованное состояние сеанса и должен избегать настройки семейства, недоступного клиенту.

Таким образом, обмен авторизацией терпит неопределённость, разрешая более широкий набор атрибутов, а затем сужает фактическое применение в точке с лучшим контекстом сеанса. Это не просто выбор формата сообщения. Это граница между тем, что центральный сервер политики может разрешить заранее, и тем, что устройство доступа узнаёт лишь после согласования протокола.

Уровни остаются раздельными

Дальше следуют другие шаги. Запрос может содержать предпочтение NAS; ответ может разрешить или вернуть префикс; IPv6CP может согласовать идентификатор интерфейса; NAS может настроить адрес или маршрут. Только последующий сквозной тест покажет, доступен ли сервис. RFC 3162 определяет атрибуты и их место в обмене, но не описывает реальный сеанс абонента и не подтверждает результат дальнейших действий.

Это важно, потому что аутентификацию, авторизацию и учёт часто сводят к одному слову — «доступ». Однако успешный ответ аутентификации не равен настроенному адресу, а установленный префикс не означает, что сервис работает. При разборе журналов оператору нужно понимать, какой именно уровень подтверждают имеющиеся данные.

RFC 3162 зарезервировал для сведений IPv6 шесть номеров атрибутов RADIUS — с 95 по 100. Позднее словарь расширился: RFC 4818 определил атрибут делегированного префикса, RFC 6911 добавил атрибуты сетей доступа IPv6, а RFC 8044 обновил рекомендации по типам данных RADIUS. Поэтому документ 2001 года — не полный перечень современного предоставления доступа. Его исторический вклад точнее: он сделал возможной авторизацию обеих адресных семей до того, как стало известно, какую из них использует сеанс.

Заметка Лу Хэна № 20 даёт редакционную оптику: формальное описание и наблюдаемое состояние системы — разные уровни. В применении к этой RFC атрибут фиксирует, что сервер запросил, предпочёл или разрешил; он сам по себе не доказывает, что настроил NAS или куда пользователь мог попасть. Это редакционная интерпретация, а не утверждение авторов RFC 3162.

Источники

  1. RFC 3162 — RADIUS and IPv6
  2. Запись RFC 3162 в RFC Editor
  3. RFC 2865 — Remote Authentication Dial In User Service (RADIUS)
  4. RFC 2866 — RADIUS Accounting
  5. RFC 2868 — RADIUS Attributes for Tunnel Protocol Support
  6. RFC 2472 — IP Version 6 over PPP
  7. RFC 2460 — Internet Protocol, Version 6 Specification
  8. RFC 3056 — Connection of IPv6 Domains via IPv4 Clouds
  9. RFC 4818 — RADIUS Delegated-IPv6-Prefix Attribute
  10. RFC 6911 — RADIUS Attributes for IPv6 Access Networks
  11. RFC 8044 — Data Types in RADIUS
  12. RFC 2044 — UTF-8, a Transformation Format of Unicode and ISO 10646
  13. Лу Хэн, заметка 20