Кратко

  • RFC 3102 позволял частному узлу использовать целый публичный адрес либо общий адрес с выделенными портами, тогда как пул, bind, lease и правила оставались под контролем шлюза.
  • Видимость публичного параметра не решала маршрут: узел должен был различать локальное назначение и публичный туннель, а общей схемы для многопартийных приложений между realms не существовало.

Публичное присутствие стало состоянием узла

Традиционный NAT принимал главное решение на границе. Узел создавал пакет с частным источником, транслятор менял адрес или порт и пытался восстановить соответствие на обратном пути. Это упрощало внедрение, но мешало протоколам, которые передавали адрес в payload или требовали неизменных заголовков.

RFC 3102–3105, опубликованные в октябре 2001 года, распределили работу иначе. RSIP host сначала договаривался со шлюзом между двумя адресными realms. Полученные публичные параметры ставились в собственный стек. Внутренний пакет создавался с одолженным источником и по tunnel доставлялся шлюзу. Тот снимал внешнюю оболочку и пересылал пакет без новой правки внутреннего адреса.

RSA-IP давал одному узлу уникальный публичный адрес на время lease. RSAP-IP разрешал нескольким узлам делить адрес, выделяя каждому непересекающиеся порты. Первый режим одалживал всю дверь, второй — отдельные входы под одним номером.

В обоих случаях параметр был виден узлу, но долговременное владение не передавалось. Шлюз сохранял пул, решал, что выдать, и мог ограничить или вернуть ресурс. Посредничество становилось явным, а не исчезало.

Выдача распадалась на несколько свидетельств

RFC 3103 описал жизненный цикл сообщениями. После регистрации узел получал client ID. Ответ о назначении мог содержать адрес, порты, bind ID, срок, тип tunnel и flow policy. Отдельные сообщения продлевали, запрашивали, открывали входящее прослушивание, освобождали и закрывали регистрацию.

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

Ни одна запись не доказывала следующую ступень. Assignment response не подтверждала установленный route. bind не подтверждал работающий tunnel. Отправленный узлом пакет не означал приём шлюзом. Выход наружу не означал возврат ответа. Рабочий путь подтверждали только наблюдения всей цепочки.

Узел мог предложить адрес или порт, но шлюз мог отказать из-за занятости, нехватки или политики. Пакеты с невыданным адресом, tuple, удалённой целью или tunnel должны были отбрасываться. Узел писал публичный источник; шлюз решал, относится ли использование к живому grant.

Локальность нужно было определить до отправки

Имея две формы присутствия, host выбирал для каждого назначения: отправить прямо в частную сеть или использовать RSIP interface и публичный tunnel. В простой подсети могла помочь маска. В сложной RFC 3102 предлагал шлюзу хранить частные сети и отвечать на queries.

Такая информация старела вместе с routing. Если topology менялась быстрее сессии, запрос мог понадобиться для каждого назначения. Документ честно признавал: надёжное общее решение разработать трудно, а практическая тяжесть проблемы неизвестна.

Многопартийные приложения показывали противоречие. Один участник мог передать IP address как глобальный endpoint, не зная realm получателя. Частный адрес был недоступен снаружи; публичный мог заставить локальных соседей идти через шлюз. Известного общего решения RFC не давал.

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

Срок заканчивался раньше старого состояния

Lease ограничивал полномочие и возвращал дефицитные ресурсы в пул. Узел мог продлить или освободить, шлюз — дождаться истечения или отозвать. Но административные часы не стирали transport state одновременно.

TCP мог держать прежний tuple в TIME_WAIT. Если адрес и порт сразу выдавались другому узлу, запоздалые пакеты или защита старого соединения сталкивались с новым grant. Истечение lease и безопасное повторное использование были разными событиями.

Сбой разделял память сторон. После reboot узла шлюз мог помнить bindings, забытые клиентом. После reboot шлюза узел мог считать действительными параметры, потерянные сервером. RFC 3103 задавал обмен для восстановления, но ни одна копия не становилась полной истиной.

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

Общий адрес переставал быть одной идентичностью

При RSA-IP динамический DNS напоминал DHCP: один host временно контролировал весь адрес. При RSAP-IP несколько FQDN могли указывать на один номер, хотя разные порты принадлежали разным узлам. Публичный peer мог ошибочно считать все службы одним логическим субъектом. RFC 3102 советовал осторожность с таким DNS.

RFC 3104 провёл ту же границу для IPsec. Несколько RSIP clients за одним публичным адресом могли начать IKE/IPsec к peer, не знающему RSIP. Видимый source address не мог идентифицировать реального peer; эту роль выполняли IKE identifiers.

Ответы IKE разделялись по destination port, initiator cookie и destination address. AH или ESP — по protocol, SPI и адресу. SPI должен был быть уникален и у клиента, и в общем пространстве шлюза. Адрес оставался точкой доставки, не криптографическим principal.

Расширение имело пределы: оно в основном касалось инициированных клиентом сессий, требовало участия IPsec implementation и не обещало неизменной работы bump-in-the-stack. Прозрачность заголовка не равнялась прозрачности приложения.

Обнаружение не давало права на ресурс

RFC 3105 использовал SLP для публикации URL service:rsip, возможностей, lifetime и необязательной нагрузки. Scopes направляли группы клиентов к серверам; клиент мог выбрать шлюз с меньшим объявленным числом соединений.

Но SLP scope не был access control. Advertisement показывал заявленную услугу, а не право клиента. Load мог устареть до подключения. После discovery всё равно требовались registration, grant, установка пути и проверка пакетов.

Роли оставались различимы. Администратор направлял discovery. Шлюз выдавал ресурсы и policy. Host выбирал locality и строил пакеты. Удалённый peer принимал identity и session. Результат показывал только трафик в обе стороны.

Эксперимент ценен своей честной ценой

RFC 3102–3105 имели статус Experimental, а не Internet Standard. В примечании IESG были отмечены значительные изменения host и gateway, проблемы плавающих портов и эксплуатационная сложность. Framework прямо говорил, что RSIP не является долгосрочным ответом на нехватку IPv4. Источники не доказывают широкого внедрения или вытеснения NAT.

Историческая ценность в другом. RSIP разложил скрытый внутри транслятора state на registration, allocation, bind, lease, policy, discovery, recovery и locality. Перенос публичного параметра к host сделал очевидным: совместное использование адреса — задача распределения состояния и власти.

Одолженный публичный адрес показывал, в каком realm хочет появиться пакет. Он не доказывал постоянное право, единую идентичность, правильный путь, authentication или доставку. Шлюз одалживал locator; согласованные записи, running state и пакеты в обоих направлениях превращали его в услугу.

Источники

  1. https://www.rfc-editor.org/rfc/rfc3102.html
  2. https://www.rfc-editor.org/info/rfc3102
  3. https://datatracker.ietf.org/doc/rfc3102/
  4. https://www.rfc-editor.org/rfc/rfc3103.html
  5. https://www.rfc-editor.org/info/rfc3103
  6. https://datatracker.ietf.org/doc/rfc3103/
  7. https://www.rfc-editor.org/rfc/rfc3104.html
  8. https://www.rfc-editor.org/info/rfc3104
  9. https://datatracker.ietf.org/doc/rfc3104/
  10. https://www.rfc-editor.org/rfc/rfc3105.html
  11. https://www.rfc-editor.org/info/rfc3105
  12. https://www.rfc-editor.org/rfc/rfc1631.html
  13. https://www.rfc-editor.org/rfc/rfc2663.html
  14. https://www.rfc-editor.org/rfc/rfc2993.html
  15. https://www.rfc-editor.org/rfc/rfc3022.html