Кратко

  • RFC 3316 предлагал использовать новое подтверждение TCP, отчёт о приёме RTCP или ответ SIP как положительное свидетельство того, что недавно отправленный трафик прошёл через маршрутизатор первого перехода.
  • Вывод был ограниченным: он мог обновить состояние соседа и отменить лишний зонд NUD, но не доказывал завершение приложения, долговечность связи и не превращал любой входящий пакет в проверку прямого пути.

На сотовом канале IPv6 начала 2000-х дорогой пакет не всегда нёс пользовательские данные. Иногда он задавал служебный вопрос, ответ на который хост уже получил от другого протокола.

Neighbor Unreachability Detection, или NUD, отслеживает, был ли следующий переход доступен в недавнем прошлом. Когда срок такой уверенности истекает, а передача продолжается, хост может отправить одноадресный Neighbor Solicitation и дождаться вызванного им Neighbor Advertisement. В Ethernet этот обмен естественно соседствует с разрешением адресов. Каналы GPRS и UMTS из RFC 3316 были устроены иначе: они напоминали соединение «точка — точка», единственным соседом хоста был уже найденный маршрутизатор по умолчанию, а канальные адреса отсутствовали. Разрешать адрес не требовалось, но обнаруживать отказ первого перехода всё равно было нужно.

Поэтому профиль предлагал сначала спросить: не доказал ли другой протокол, что недавно отправленный пакет уже продвинулся вперёд?

Общее правило Neighbor Discovery давало логику вывода. Новое подтверждение TCP означает, что ранее отправленные данные дошли до удалённого узла. Если он находится вне локального канала, пакет не мог попасть к нему, миновав первый маршрутизатор отправителя. Сквозное подтверждение содержит и локальный факт: в момент прохождения пакета следующий переход был доступен. Хост может обновить этим фактом Neighbor Cache, не расходуя отдельный обмен только на проверку маршрутизатора.

RFC 3316 распространил рассуждение на сотовые приложения поверх UDP. Сам UDP не подтверждает доставку, поэтому приложение должно было выдать сигнал с нужной причинной связью. Для RTP подходил блок отчёта RTCP, показывающий, что часть пакетов дошла до удалённой стороны. Для SIP ответ на запрос свидетельствовал, что запрос достиг адресата. Если сотовый хост работал на серверной стороне SIP, одной отправки ответа обычно было мало; последующий ACK мог показать, что прежний ответ на INVITE дошёл до другой стороны.

Эти сигналы не были взаимозаменяемыми зелёными лампочками. Каждый должен был подразумевать доставку недавно отправленного трафика. Посторонняя входящая датаграмма не подходила. Незапрошенный Router Advertisement тоже: он показывал лишь путь от маршрутизатора к хосту, тогда как NUD проверял направление от хоста через следующий переход. Наличие активности ещё не доказывает именно тот путь, который оценивается.

Полученное состояние не было вечным сертификатом. Подтверждение верхнего уровня могло перевести запись Neighbor Cache в REACHABLE на ограниченное время. Без свежих доказательств запись старела до STALE; при новой отправке проходила через DELAY к PROBE, после чего специальные Neighbor Solicitation возобновлялись. RFC 3316 не отменял NUD. Он позволял не задавать повторный вопрос, пока активное приложение уже давало правильный ответ.

Экономия имела практическое основание. Радиополоса была ограничена, а пользователь мог платить за объём передачи. Удаление лишних сообщений могло беречь ёмкость и деньги. Но RFC не измерял сокращение пакетов, расхода батареи или счёта. Он описывал профиль реализации, выведенный из топологии и уже существующих сигналов потока.

Механизм пережил документ. RFC 7066 заменил RFC 3316 в 2013 году, добавил EPS, сохранил примеры TCP, RTCP и SIP и включил ответ DNS. Это показывает, что вывод оставался частью профиля, но не сообщает, какие устройства его реализовали и сколько проверок он устранил.

Исторический урок не в том, что приложение должно управлять маршрутизацией. Машина состояний может переиспользовать доказательство другого уровня только при явной причинной связи. Отчёт удалённого узла говорит о первом переходе потому, что недавний исходящий пакет обязан был пройти через него. На этом вывод заканчивается: отчёт RTCP не доказывает хорошее качество медиа, ответ SIP — завершённый звонок, доступный маршрутизатор — доступную службу, а успех одного пакета — успех следующего.

Источники: RFC 3316, RFC 2461, RFC 4861, RFC 7066, RFC 7849, RFC 8504, RFC 3550 и RFC 3261.