Кратко

  • RFC 4957 рассматривает уведомления канального уровня как входные данные для обнаружения сетевого присоединения, а не как завершённый результат IP или сервиса.
  • Смена точки доступа может происходить в той же подсети, а изменение IP-конфигурации — без нового события link up.

«Link up» звучит как окончательный вывод: радиосвязь установлена, станция Wi‑Fi присоединилась к точке доступа или Ethernet уже способен посылать кадры. На панели инцидентов это легко переименовать в «сервис восстановлен». RFC 4957 не позволяет подменять одно утверждение другим.

Этот информационный RFC, одним из редакторов которого был Suresh Krishnan, описывает сведения, которые технологии доступа могут передать IP-уровню при смене точки присоединения устройства. Их задача — ускорить проверку конфигурации. Они не удостоверяют ни пригодный адрес, ни доступный шлюз по умолчанию, ни работающий прикладной сервис.

Новое соединение канального уровня может побудить хост искать дальнейшие признаки, например отправить router solicitation. RFC прямо говорит, что одно уведомление не даёт всех входов, нужных для обнаружения сетевого присоединения. По-прежнему требуются объявленные префиксы, достижимость шлюза и иные IP-доказательства. Сигнал запускает машину состояний, но не является её конечным состоянием.

Роуминг Wi‑Fi делает различие наглядным. Устройство может покинуть одну точку доступа и присоединиться к другой, не меняя IP-подсеть. Считать каждую ассоциацию перенастройкой IP — значит порождать лишнюю работу и неверные метрики. Верно и обратное: перенумерация IPv6 способна потребовать изменения IP без нового уведомления link up.

RFC допускает и недетерминированный link up, когда интерфейс готов, но передача данных где-то в сети ещё может блокироваться. Даже последующее детерминированное уведомление описывает условие канального уровня, определённое конкретной реализацией. Оно не доказывает завершение SLAAC или DHCP, разрешение политикой, работу DNS, ответ удалённого сервиса или то, что клиент увидел результат.

Для оператора это прежде всего задача построения доказательств. link_up может быть полезным локальным наблюдением: интерфейс, точка присоединения, время и технический контекст. Его нельзя переименовывать в online, считать восстановлением приложения или единолично использовать для закрытия заявки. Каждая более широкая метка утверждает то, чего сигнал не наблюдал.

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

Урок RFC 4957 ограничен и потому прочен: событие канала доказывает событие канала. Его ценность в запуске следующей проверки. Обманчивым оно становится, когда его выдают за квитанцию о пути, сервисе или опыте клиента, которых оно никогда не наблюдало.

Источники