Summary
- RFC 1383 предлагал искать шлюз к периферийной сети с несколькими подключениями по обратному DNS, не публикуя каждый её внутренний маршрут в глобальных таблицах.
- Описанный прототип запускал DNS-запрос после ICMP-сообщения о недоступности. Автор предупреждал о возможной потере первого пакета; запись о шлюзе сама по себе не означала работающий путь.
Пакет уходит. Маршрутизатор отвечает: сеть назначения неизвестна. Программа перехватывает этот отказ, обращается к DNS и готовит путь для следующих пакетов. Так выглядел механизм в RFC 1383 Кристиана Уитемы от декабря 1992 года. Отказ становился поводом узнать дорогу. Первый пакет мог остаться без неё.
Причина эксперимента — растущие таблицы. В документе названы более 5000 сетей в таблицах NSFNET и более 7000 у EBONE на тот момент. Каждый новый анонс занимал память транзитных маршрутизаторов, увеличивал обмен маршрутами и порождал вопросы политики. Иерархическая адресация и агрегация помогали, но сеть с двумя провайдерами могла хотеть сохранить свои адреса, даже если менялся способ подключения.
Уитема взял принцип почтового MX и применил его к входу в IP-сеть. Периферийная область D имела два шлюза I1 и I2, видимых из Интернета. Они знали внутренние маршруты D, не объявляя их все глобально. Отправитель запрашивал in-addr.arpa для адреса получателя, читал экспериментальные данные RX, выбирал шлюз и направлял пакет по маршруту, указанному источником. На раннем этапе RX помещали в обычную запись TXT: метка, предпочтение и IP-адрес шлюза. Отдельный тип DNS ещё не был создан.
Выбор требовалось сделать один раз рядом с отправителем. Если бы каждый промежуточный узел сам обращался к DNS, пришлось бы обновить множество маршрутизаторов. Один мог выбрать I1, следующий I2 — и пакет пошёл бы кругами. Два шлюза уменьшали зависимость от единственной точки отказа и поставщика. Но каталог не сообщал текущее состояние линии. Из списка надо было убрать заведомо недоступные шлюзы, а скорость обнаружения такой недоступности оставалась открытой задачей.
Сам каталог тоже должен был быть достижим из ядра сети. Информацию RX пришлось бы копировать на доступные извне серверы имён. Справочник, запертый за сломанным маршрутом, не помогает найти этот маршрут. Пока DNS отвечал, пересылающий модуль держал пакеты в очереди и уменьшал их срок жизни. Если подходящего RX не находилось, он уничтожал очередь и помечал цель недоступной.
Прототип слушал ICMP, чтобы не менять обычный код маршрутизации. RFC предпочитал прямую интеграцию с IP-маршрутизацией там, где её можно было сделать: тогда первый пакет не служил бы наживкой для сообщения об ошибке. Официальный реестр сохраняет статус Experimental, а заключение говорило о продолжающейся разработке кода в INRIA. Коммерческий замысел тоже был явным: если независимые сетевые анонсы станут платными, клиент может оказаться вынужден перейти на адреса провайдера; RX предлагал иную сделку.
Транзитная сеть держала бы меньше общего состояния, отправитель отвечал бы за поиск, выбор и исправление старой информации. DNS мог назвать ворота. Открыты ли они, показывала только доставленная посылка.
Sources
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров





