Кратко

  • RFC 3316 описывает GPRS и UMTS как каналы IPv6 типа «точка-точка»: после обнаружения маршрутизатора единственным соседом узла был его маршрутизатор по умолчанию, а канальных адресов, которые требовалось бы разрешать, не существовало.
  • Это устраняло разрешение адресов, но не необходимость знать, доступен ли маршрутизатор. Обнаружение недостижимости соседа (NUD) оставалось важным; сигналы TCP, RTCP или SIP иногда могли ограниченно подтвердить связь по IP в обоих направлениях и избавить от лишней проверки.

Анализ

Когда IETF опубликовала RFC 3316 в 2003 году, в заголовке документа было осторожно сказано «для некоторых» сотовых узлов второго и третьего поколений. Это информационное руководство предназначалось разработчикам узлов для GPRS и отдельных выпусков UMTS. Оно не создавало нового стандарта IPv6 и не было универсальным перечнем требований для любого радиоинтерфейса, ноутбука или сотового маршрутизатора. Во введении отдельно сказано, что без подробного анализа документ нельзя считать исчерпывающим списком функций для других видов сотовых каналов.

Эта граница важна, потому что обычные процедуры IPv6 здесь столкнулись с другой моделью канала. В общей сети Ethernet узлу может потребоваться преобразовать IPv6-адрес соседа в канальный адрес, прежде чем отправить пакет. RFC 3316 описывает GPRS и UMTS иначе: канал похож на соединение «точка-точка», единственным соседом узла является маршрутизатор по умолчанию, а обнаружение маршрутизатора уже определило его. На этом интерфейсе нет канальных адресов, поэтому разрешение адресов и определение следующего перехода не нужны.

Отсюда легко сделать неверный вывод: если MAC-адрес не нужно искать, значит, не нужно и отслеживать состояние соседа. RFC 3316 этого не утверждает. В том же разделе от узла по-прежнему требуется поддерживать обнаружение недостижимости соседей (NUD) из общей архитектуры Neighbor Discovery для IPv6. Разрешение адреса отвечает на вопрос, как сформировать адрес назначения на канальном уровне. NUD проверяет, доступен ли уже известный сосед. Первый вопрос может исчезнуть, а второй — остаться.

Причина практическая. Чтобы отправлять данные за пределы непосредственно подключённого канала, узлу по-прежнему нужен работающий следующий переход. Соединение «точка-точка» показывает, какой маршрутизатор находится на другом конце, но не гарантирует, что он будет доступен в любой последующий момент. Обнаружение маршрутизатора, настройка адреса, разрешение канального адреса и доступность соседа связаны между собой, но это разные свидетельства.

Ограниченная пропускная способность сотовой сети также заставляла задуматься о повторяющихся управляющих сообщениях. RFC 3316 предлагает использовать подтверждения доступности с верхних уровней, когда узел уже может подтвердить двустороннюю связь по IP. TCP может дать такое подтверждение способом, описанным в спецификации Neighbor Discovery. Для RTP поверх UDP отчёт RTCP о приёме пакетов мог указывать, что данные дошли до собеседника, а значит, и до соседа. Ответы SIP могли подтвердить получение запросов другой стороной; в более узком случае на стороне сервера приём SIP ACK мог показать, что предшествующий ответ дошёл.

Сам UDP такого подтверждения не обеспечивает.

Речь не о том, что прикладной трафик делает NUD ненужным. Уже имеющийся в сети полезный ответ иногда позволяет решить ограниченный вопрос доступности без дополнительной проверки. Но у каждого свидетельства есть пределы: RTCP-отчёт говорит о приёме пакетов, SIP-ответ — об обмене SIP. Ни то ни другое не доказывает завершение операции приложения, исправность всех маршрутов или получение услуги пользователем. Молчание UDP нельзя считать доказательством успеха только потому, что на канале нет MAC-адреса.

Другие сотовые адаптации в RFC подтверждают это различие. Раздел об IPv6 поверх PPP рассматривает идентификатор интерфейса link-local, который мобильный терминал предлагает подключённому оборудованию; он не запрещает этому оборудованию использовать другие идентификаторы для глобальных или временных адресов приватности. Описание Stateless Address Autoconfiguration также опирается на префиксы, уникальные в своей области, чтобы не выполнять обнаружение дублирующихся адресов на сотовом интерфейсе. Это точечные решения на разных уровнях, а не общее освобождение от проверок IPv6.

В 2013 году RFC 7066 заменила RFC 3316 и расширила описанный контекст 3GPP, добавив Evolved Packet System к GPRS и UMTS. Она сохранила объяснение отсутствия канальных адресов и требование поддерживать NUD, а также отметила, что GGSN или PGW может вовсе не отвечать на запрос разрешения адреса. Эта преемственность показывает, как менялся профиль вместе с охватом 3GPP, но не сообщает, какая доля устройств реализовала конкретное поведение. Сегодня общие требования к узлам IPv6 рассматривает RFC 8504, поэтому RFC 3316 нельзя представлять как полный современный список требований к хостам.

Главный инженерный урок точнее и полезнее фразы «сотовые каналы особенные». Тип канала может сделать ненужной одну общую операцию, не устранив вопрос, на который та помогала отвечать. Здесь не требовалось обнаруживать канальный адрес, однако узлу всё ещё нужны были свидетельства доступности соседа. Сигналы верхнего уровня могли сократить дублирующие проверки, но не становились доказательством исправности всей услуги.

Источники

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