Кратко

  • RFC 2373 выделял anycast-адреса из пространства unicast: биты не показывали, что адрес разделяют несколько интерфейсов, и не называли получателя пакета.
  • «Ближайший» означал выбранный текущей метрикой протоколов маршрутизации, а не географически ближайший, самый быстрый, исправный, свободный или неизменный узел.

Один адрес без записанного победителя

Адресная архитектура RFC 2373 начиналась с интерфейсов. Unicast определял один интерфейс. Multicast определял множество и доставлял всем его участникам. Anycast тоже определял множество, но доставка выполнялась только одному участнику — «ближайшему» по мерке маршрутизации.

Главным было отсутствие особого формата. Anycast выделялся из пространства unicast и использовал его синтаксис, поэтому по записи их различить было невозможно. Когда один unicast-подобный адрес назначался нескольким интерфейсам, участвующие узлы требовали явной настройки, сообщавшей им о режиме anycast.

Следовательно, строка адреса в журнале не была реестром участников. Она не говорила, стоит ли за назначением один интерфейс или множество, кто ответит и почему маршрут выбрал именно его.

«Ближе» решала маршрутизация

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

Такая экономия позволяла обычной пересылке выбрать участника без нового поля в пакете. Но вместе с маршрутами мог измениться и получатель. Две точки наблюдения могли по одному адресу достичь разных интерфейсов; одна точка могла позднее попасть на другой интерфейс. Стабильная строка была местом встречи с сервисом, а не постоянным именем машины.

Скрытое множество находилось в маршрутах

RFC 2373 задавал самый длинный префикс P, охватывавший топологическую область всех участников anycast-множества. Внутри P каждый участник должен был появляться отдельной записью, то есть хостовым маршрутом. Снаружи P адрес можно было агрегировать с маршрутом самого префикса.

Здесь проявлялась цена масштабирования. Если общей топологической области не было, P мог стать пустым префиксом, а отдельный маршрут пришлось бы распространять по всему Интернету. Документ называл это серьёзным ограничением и ожидал, что глобальные множества окажутся недоступны или будут строго ограничены.

Сам адрес не нёс такого реестра. Операторы создавали множество настройками интерфейсов и маршрутными объявлениями. Агрегация могла намеренно скрыть отдельных участников от удалённых таблиц.

Нулевой идентификатор мог означать «один из маршрутизаторов»

Обязательный Subnet-Router anycast делал неоднозначность наглядной. Он соединял префикс подсети с полностью нулевым идентификатором интерфейса. Синтаксически это совпадало с unicast-адресом интерфейса номер ноль. В работе его должны были распознавать все маршрутизаторы подсети, но пакет получал один из них.

Остальные адреса реализации должны были считать unicast, если они явно не настроены как anycast. Часть классификации существовала за пределами 128 бит — в локальной конфигурации и состоянии пересылки.

Первые ограничения фиксировали неопределённость

RFC 2373 прямо указывал на небольшой опыт произвольного anycast в масштабе Интернета. Документ временно запрещал использовать его как адрес источника и разрешал назначение только маршрутизаторам. Последующие спецификации IPv6 сняли эти ограничения, сохранив основу: unicast-формат, настроенное множество и выбор посредством маршрутизации.

Нельзя читать 1998 год через позднейшие разрешения. Минимальная начальная спецификация повторно использовала знакомые форматы и пересылку, вводила обязательный случай для маршрутизаторов и ограничивала малоизученную область. Позднее смягчение не доказывает, что ранние риски уже были устранены, и не превращает RFC 2373 в описание современной эксплуатации сервисов.

Что могла доказать ответная передача

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

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

Принцип Lu Heng о первенстве работающего кода помещает полномочие в реально действующие конфигурацию и пересылку, а не в адресную метку. Минимальная начальная спецификация объясняет повторное использование формы. Слои реальности требуют считать адрес, маршрут, ответ и завершённое действие соседними, но разными фактами.

RFC 2373 позволил одному адресу найти одного участника множества. Это удалось именно потому, что адрес не притворялся, будто заранее знает, кто им окажется.