Кратко

  • RFC 5149 определяет Service Selection Mobility Option для Binding Update в Mobile IPv6.
  • Опция называет запрошенный контекст услуги, но не предоставляет право на него.
  • В одном обновлении допускается не более одной опции: после MN-NAI, если он есть, и до опций авторизации или аутентификации.
  • Тип 20 несёт непустой UTF-8-идентификатор длиной 1–255 октетов, нормализованный по NFKC.
  • Идентификатор обязан быть уникальным только среди домашних агентов, у которых этому узлу разрешена регистрация.
  • Домашний агент аутентифицирует узел и отдельно проверяет разрешение на выбранную услугу.
  • Отказ возвращается со статусом 151 SERVICE_AUTHORIZATION_FAILED.
  • Смена услуги требует повторной авторизации, а неудача может удалить прежнее связывание.
  • Выбор способен влиять на адрес, префикс, маршрутизацию, межсетевой экран, безопасность, политику и QoS, не доказывая их применения.
  • Узел-корреспондент без общего знания каталога должен молча игнорировать опцию.
  • ESP может скрыть идентификатор в канале, но не подтверждает право или доставку.
  • Регистрация, установка политики, путь данных, расчёты и пользовательский результат требуют разных доказательств.

Контрольное решение заканчивается раньше пути данных

Выбор услуги может определить Home Address или Home Network Prefix, исходящий маршрут, настройки межсетевого экрана, политику безопасности, другие политики и QoS. Это список возможных последствий, а не перечень результатов, автоматически подтверждённых одним ответом.

Binding Acknowledgement сообщает исход регистрации у домашнего агента. Он не опрашивает компилятор политики, не читает состояние точки применения и не отправляет трафик к целевому приложению. Выданный префикс может не иметь обратного маршрута. Правило может существовать в контроллере и отсутствовать на устройстве. Назначенный класс QoS может никогда не проявиться в измерениях.

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

Тип 20 задаёт контекст, а не право

Одной мобильной идентичности недостаточно, когда подписка включает обычный Интернет, корпоративный доступ, закрытые домены или особую политику обслуживания. Service Selection Mobility Option сообщает домашнему агенту, какой именно контекст следует проверить.

Формат намеренно узок. В типе 20 находится от одного до 255 октетов UTF-8 после нормализации NFKC; пустое значение недопустимо, а в Binding Update может быть лишь одна такая опция. При наличии MN-NAI выбор располагается после него и перед опциями, связанными с авторизацией и аутентификацией.

Порядок позволяет включить выбор в защиту сообщения. Но корректная целостность не превращает строку в credential. Домашний агент всё равно аутентифицирует мобильный узел и сверяет названную услугу с профилем подписки. Даже похожий на домен идентификатор не доказывает контроль DNS или глобальное право на имя.

Уникальность также локальна: достаточно исключить коллизии среди домашних агентов, где конкретному узлу разрешено регистрироваться. Если то же значение попадает в биллинг, аналитику или партнёрскую сеть, к нему необходимо прикреплять административную область.

Повторная авторизация способна стереть прежнюю опору

Если услуга не разрешена, домашний агент отклоняет регистрацию со статусом 151 SERVICE_AUTHORIZATION_FAILED. При смене контекста это не всегда безопасный отказ, после которого всё остаётся как было.

Разные услуги могут потребовать разных адресов или префиксов. Когда Binding Update указывает смену услуги, агент проводит авторизацию заново. При неудаче он отклоняет запрос и удаляет любое связывание для существующего Home Address или Home Network Prefix. Мобильный узел, получивший статус 151, также обязан удалить совпадающее связывание. Спецификация рекомендует вообще снять текущую регистрацию до запроса новой.

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

Значение по умолчанию тоже проходит авторизацию

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

Отсутствие поля определяет вопрос системе авторизации, а не готовый ответ. Мониторинг не должен превращать selector absent в Internet available: требуется решение по подписке, состояние связывания, применённая политика и реальная проба данных.

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

Секретность, номенклатура и реальность — разные слои

Выбранная услуга может раскрывать чувствительный контекст. При необходимости RFC рекомендует ESP в транспортном режиме с ненулевым шифрованием для Binding Update и Acknowledgement. Это защищает строку от наблюдателя, но не исправляет профиль подписки и не подтверждает применение политики.

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

Назначенные IANA значения — тип 20 и статус 151 — обеспечивают стабильную документальную координацию. Они не свидетельствуют о поддержке конкретным домашним агентом или о совместимости в действующей сети. Исходная база RFC 3775 позднее была заменена RFC 6275; последующие ссылки показывают происхождение идей, а не текущий парк внедрений.

Источники

  1. RFC 5149, HTML
  2. RFC 5149, текст
  3. Карточка RFC Editor
  4. Карточка IETF Datatracker
  5. История RFC 5149
  6. Ссылки RFC 5149
  7. Ошибки RFC 5149
  8. RFC 3775
  9. RFC 6275
  10. RFC 4877
  11. RFC 4283
  12. RFC 6089
  13. RFC 5778
  14. RFC 5779
  15. RFC 6097
  16. RFC 7222
  17. Minimum Initial Specification
  18. On Reality Layers
  19. Running-Code Primacy