Кратко

  • Хост мог успешно идти к X через шлюз по умолчанию и дважды пересекать одну локальную сеть: H передавал пакет G1, а G1 — соседнему G2. ICMP Redirect позволял доставить первый пакет и подсказать H прямой следующий переход.
  • Сообщение не было миниатюрным протоколом маршрутизации. Хост должен был узнать в отправителе свой текущий первый переход, проверить предложенный шлюз в сети поступления и сохранить лишь узкое исключение для конкретного назначения.
  • В IPv6 локальная граница стала проверяемой: link-local источник, Hop Limit 255 и ограничения Target. SEND мог удостоверить говорящего относительно настроенной цепочки доверия, но не доказывал вечную оптимальность пути или право собственности на X.

Исправление после успеха

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

RFC 791 разделяет имя, адрес и маршрут. IP строится из последовательных решений хостов и шлюзов. H знает адрес X, но не обязан знать, какой сосед G1 лучше ведёт дальше.

Представим H, G1 и G2 в одном LAN. H выбрал G1 шлюзом по умолчанию. Таблица G1 указывает, что к X следует идти через G2, который находится на том же канальном сегменте. Пакет проходит H–G1–G2. Доставка работает, но локальная сеть переносит две стороны лишнего треугольника.

RFC 792 дал G1 сообщение Redirect. G1 сначала пересылает датаграмму, а затем называет H адрес G2. Следующая передача может миновать G1.

Это не обычный отчёт об ошибке. Механизм появляется потому, что пакет удалось провести и по успешной доставке обнаружился лучший локальный выбор. Управляющая подсказка хранит память о событии плоскости данных.

Совет со встроенной квитанцией

Redirect содержит адрес предлагаемого шлюза, исходный IP-заголовок и первые 64 бита данных вызвавшей его датаграммы. Хост может сопоставить совет с тем, что недавно отправлял.

Цитата даёт контекст, но не карту Интернета. Она не раскрывает удалённые политики, не обещает доступность G2 завтра и ничего не говорит о владельце X. Она связывает утверждение с наблюдением и только.

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

Поэтому RFC 1122 потребовал обрабатывать даже Network Redirect как специфичный для хоста. Наблюдение над X создаёт запись для X, а не власть над неувиденными адресами вокруг него.

До принятия действуют две проверки отношений. Новый шлюз должен находиться в той же логической подсети, откуда пришло сообщение. Источник Redirect должен совпадать с первым шлюзом, которым H уже пользовался для этого назначения.

Особенно важна вторая проверка. Полномочие даёт не способность собрать ICMP-пакет и не просто присутствие в LAN. G1 вправе комментировать передачу, потому что H сам отдал её G1. Посторонний сосед этой предыстории не имеет.

Исключение с конечной памятью

Принятый совет попадает в локальный кэш маршрута или назначения. Он не становится новым default для всего трафика, не распространяется другим маршрутизаторам и не превращает хост в участника протокола маршрутизации.

Запись на одно назначение соответствует масштабу доказательства. Одновременно она позволяет истечение и возврат. G2 может исчезнуть, интерфейс смениться, а G1 узнать иную топологию. Без срока жизни вчерашнее улучшение превращается в сегодняшнюю неподвижность.

RFC 1256 чётче развёл обнаружение и выбор. Router Solicitation и Router Advertisement позволяют найти локальные маршрутизаторы по умолчанию, их предпочтения и срок объявления. Документ подчёркивает: Router Discovery не является протоколом маршрутизации.

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

Разделение сохраняет путь восстановления. Если исключение устарело, H снова пользуется известным default. Оптимизация безопаснее, когда система может без неё обойтись.

Маршрутизатору нельзя учиться так же

Подсказка, полезная простому хосту, опасна в плоскости управления. RFC 1812 запрещает маршрутизатору, использующему протокол маршрутизации, учитывать пути, изученные из Redirect, при пересылке пакетов.

Между маршрутизаторами действует иной процесс доказательства: метрики, политики, таймеры, сходимость и защита от петель. Если совет для края проникнет туда, единичное локальное наблюдение сможет обойти правила, объясняющие общее состояние.

RFC 1812 ограничивает и отправку. Пакет должен выйти через тот же физический интерфейс, через который пришёл; следующий переход должен быть в той же логической подсети, что и источник; source route отсутствует. Эти условия точно восстанавливают треугольник H–G1–G2.

Утверждение G1 остаётся скромным: во время обработки этого пакета G2 был локально достижимым следующим переходом по таблице G1. Из него не следует, что G2 всегда лучше, соблюдает всякую политику или представляет X.

IPv6 очертил локальность полями

IPv6 сохранил Redirect внутри Neighbor Discovery. RFC 4861 разрешает маршрутизатору указать лучший первый переход либо сообщить, что само назначение находится on-link.

Источник обязан быть link-local, а Hop Limit при приёме — ровно 255. Пересылающий маршрутизатор уменьшил бы значение, поэтому 255 служит свидетельством отсутствия маршрутизируемого перехода. Отправитель также должен быть текущим первым переходом к назначению.

Destination сообщения Redirect не может быть multicast. Target является link-local адресом предлагаемого маршрутизатора либо совпадает с Destination, когда конечный узел — непосредственный сосед. «Локальный» превращается в набор проверяемых связей.

После принятия хост обновляет Destination Cache. Опция Redirected Header цитирует исходный пакет, а Target Link-Layer Address может дополнить Neighbor Cache. Это разные виды состояния хоста; маршрутизатор по-прежнему не должен превращать их в свой маршрут пересылки.

Подлинный говорящий не всеведущ

Общий канал не гарантирует доверия. Злоумышленник может попытаться выдать себя за G1, воздействовать на Neighbor Discovery или предложить подконтрольный G2. При этом новый хост нуждается в локальных сведениях раньше, чем доберётся до внешнего сервиса проверки.

RFC 3971 определил Secure Neighbor Discovery, SEND. Криптографически сгенерированные адреса, подписи и сертификаты авторизации маршрутизаторов, связанные с trust anchor, удостоверяют сообщения и полномочия в настроенной модели.

Подпись показывает связь ключа с неизменённым сообщением. Цепочка может показать разрешение относительно выбранного якоря. Ни то ни другое не доказывает, что G2 останется доступен, удовлетворит будущую политику, даст глобально лучший путь или владеет X.

Наличие стандарта также не доказывает всеобщего внедрения. Реальную поддержку и настройку надо наблюдать в конкретной среде. Возможность протокола и распространённость практики — разные факты.

Право указать на соседа

Redirect образует короткую цепочку делегирования. H выбирает G1. G1 видит пакет и соседа G2 на том же сегменте, исполняет первоначальную пересылку, затем возвращает совет с цитатой. H проверяет и сам решает судьбу кэша.

Глаголы удерживают границы. G1 предлагает, но не пишет состояние в H. H сохраняет, но не объявляет маршрут другим. Протокол маршрутизации остаётся источником знания маршрутизаторов. Таймер лишает локальную память вечной власти.

Пакет в трассировке доказывает отправку предложения, не его принятие. Кэш доказывает локальное решение, не глобальную оптимальность. На один переход короче не значит безопаснее, дешевле, политически допустимее или институционально законнее.

Исторический урок ICMP Redirect — соразмерность полномочия. Тот, кто только что увидел обход, может показать сокращение. Но его мандат привязан к пакету, первому переходу, каналу, назначению и времени. Маршрутизатор указывает вбок, не забирая себе дорогу.