Кратко

  • draft-ietf-dtn-bibe-00 от 7 сентября 2026 года возвращает Bundle-in-Bundle Encapsulation в работу группы DTN, но теперь ограничивает её инкапсуляцией и сегментацией без прежнего механизма custody transfer.
  • Каждый внешний bundle создаётся как самостоятельный объект BPv7. Его доставка не доказывает, что все сегменты попали одному элементу, сохранились, были собраны и представлены BPA как внутренний bundle.
  • Отчёты BP видят путь до декапсуляции и после неё, но не внутренние отказы, вытеснение и истечение срока. Эти события должны фиксировать локальные журналы и счётчики.

Четыре внешних подтверждения вполне совместимы с отсутствием внутреннего приёма. Если у endpoint два участника без закрепления потока, две оболочки могут попасть одному элементу декапсуляции, а две — другому. Оба набора корректны и оба неполны. По истечении срока состояние удаляется. Все внешние отчёты правдивы, но ни один BPA не увидел внутренний bundle.

В этом состоит узкая практическая новость revision 00. Документ опубликован 7 сентября как работа группы DTN, но остаётся Internet-Draft, который может измениться, быть заменён или истечь. Статус рабочей группы означает совместную разработку, а не RFC, окончательный консенсус, внедрение или проверенную совместимость.

BIBE захватывает пересылаемый bundle как непрозрачную последовательность октетов. Она помещается целиком в одну внешнюю полезную нагрузку либо делится между несколькими. Входной узел создаёт каждую оболочку как новый bundle, а не изменённую копию внутреннего. Внешние адрес назначения и источника, время, lifetime, report-to, флаги, расширения и защита относятся к отдельному пути.

Такое разделение полезно. Шифрование внешней нагрузки способно скрыть весь внутренний bundle, включая его источник и назначение. Промежуточный домен применяет собственные правила маршрутизации, очередей и безопасности, не меняя внутренние байты. Через сеть одной версии BP можно переносить bundle другой версии.

Но появляются два журнала. Внешняя доставка завершена, когда payload достиг зарегистрированного элемента endpoint. Внутренний приём возникает только после принятия целого payload либо полного восстановления всех байтов и передачи результата BPA по RFC 9171. Между ними находятся необязательная функция, конечная память и локальная политика.

Порог сегментации настраивается заранее для каждого endpoint и ограничивает лишь внутренние байты. Размер оболочки включает ещё primary block, расширения, CBOR и BPSec. Transfer ID, общая длина и offset описывают части. Идентификатор имеет смысл вместе с внешними source node ID и destination EID и не сообщает порядок, возраст или потерю.

После запуска первого сегмента BIBE не предоставляет abort или cancellation. Если отправитель остановился, получатель не отличит это от потери на пути. Частичное состояние сохраняется до общего expiry либо раньше удаляется локальной политикой. Пока прежняя передача может быть жива, повторное использование ID для той же пары опасно.

Сборка отвергает несогласованные данные. Сегмент за пределами total length неверен. Изменение общей длины или перекрытие с различным содержимым повреждает передачу и удаляет её состояние; идентичный дубль допустим. Поддержка сборки необязательна, поэтому неспособный элемент обязан отбросить сегментированные нагрузки, даже если их оболочки доставлены.

Способный элемент тоже не обещает бесконечное хранение. Локальная политика ресурсов может вытеснить неполное состояние до expiry. В таком случае внутренний bundle никогда не передаётся BPA. Внешний отчёт остаётся корректным, но не содержит внутреннего решения.

Привязка сегментов к одному элементу — часть работоспособности. Singleton endpoint удовлетворяет условию. Подходит и доставка полного набора каждому участнику. Неопределённое распределение отдельных оболочек не подходит: сегменты расходятся по разным состояниям. Успешное разрешение endpoint и маршрут не создают общей сборки автоматически.

Сам BIBE не вводит подтверждений и повторной передачи. Для инкапсулятора forwarding заканчивается успешной передачей новых оболочек нижележащей сети. Надёжность обеспечивает convergence layer, повторение, отдельный механизм custody или acknowledgement либо приложение. Протокол IETF 126 прямо фиксирует возрождение работы без custody transfer и с фокусом на инкапсуляции и сегментации.

Отчёты RFC 9171 полезны, если не смешивать объекты. Внешние отчёты показывают приём, forwarding, удаление и доставку в туннеле. Внутренние возобновляются только после передачи BPA. Если все внешние доставки подтверждены, а ожидаемого внутреннего reception report нет, поиск сужается до декапсуляции, а не всего транзита.

Причина всё равно остаётся локальной. Отсутствие поддержки, зарезервированный формат, несовпадающая длина, конфликт, вытеснение памятью и expiry происходят после внешней доставки, но до появления внутреннего bundle. Draft говорит, что эти решения нельзя выразить status report ни для одного объекта; их должны показывать журналы и счётчики выходного узла.

Общий lifetime ограничивает состояние, но не заменяет защиту получателя. Все оболочки передачи истекают одновременно и не позже внутреннего bundle. После этого можно очистить память и использовать ID снова. Однако срок заявляет отправитель. Неисправный или враждебный peer способен указать далёкую дату и не прислать один сегмент. Получателю нужен собственный предел удержания.

Доверие тоже не наследуется. Защита внешней нагрузки может аутентифицировать tunnel peer и остановить поддельные сегменты до выделения памяти. Она не аутентифицирует источник, указанный внутри. А непрозрачность, защищающая адреса, может обойти промежуточную фильтрацию, поэтому выходной узел обязан заново применить обычные правила admission.

Подход Heng Lu сохраняет границы реальности. Метка рабочей группы — состояние координации. Внешний отчёт — наблюдение транспорта. Сборка — локальный результат. Приём BPA — новый факт протокола. Обработка приложением и внешний итог находятся дальше. Удобный сигнал не получает полномочия следующего слоя.

Надёжный журнал должен связывать внешний источник, endpoint, Transfer ID, expiry, диапазоны, фактический принимающий элемент, причину отказа или вытеснения, завершение, hash результата, внутреннюю идентичность и приём BPA. Четыре отчёта доказывают прибытие четырёх payload к границе туннеля. Внутренний приём доказывает только вся цепочка.

Источники

  1. IETF Datatracker — Bundle-in-Bundle Encapsulation
  2. Текущий draft рабочей группы, revision 00
  3. Протокол группы DTN на IETF 126
  4. Предыдущий индивидуальный draft
  5. Истёкший draft BIBE-CT
  6. RFC 9171 — Bundle Protocol Version 7
  7. RFC 9172 — Bundle Protocol Security
  8. RFC 9758 — Обновление URI-схемы ipn
  9. RFC 6169 — Риски безопасности IP-туннелей
  10. RFC 4459 — MTU и фрагментация в туннелях
  11. RFC 2473 — Универсальный туннель пакетов в IPv6
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality Layers