Кратко

  • RFC 3025 напечатала 37 для критического CVSE и 133 для обычного NVSE. IANA зарегистрировала 38 и 134. В апреле RFC 3115 объявила февральский документ устаревшим, потому что существующие реализации следовали IANA.
  • Внешний тип задавал цену незнания: неизвестное расширение 0–127 заставляло молча отбросить всё сообщение; тип 128–255 можно было пропустить и продолжить обработку.

Один байт превращал запрос в тишину

Мобильный узел отправляет Registration Request. Foreign agent получает пакет, но не узнаёт расширение после фиксированной части. Если его type находится ниже 128, обработка прекращается. Датаграмма отбрасывается целиком, а отправитель не получает сообщения об ошибке.

«Silently discard» в RFC 3115 не означало отсутствие внутреннего следа. Реализация не должна была продолжать обработку или уведомлять отправителя, но ей следовало уметь записать ошибку вместе с содержимым отброшенной датаграммы и увеличить счётчик. Тишина в сети и отсутствие доказательств на принимающей стороне были разными состояниями.

Именно для таких type в 2001 году разошлись два источника. RFC 3025, опубликованная в феврале, определила Critical Vendor/Organization-Specific Extension, CVSE, как 37, а обычную NVSE как 133. В репозитории IANA стояли 38 и 134.

Через два месяца RFC 3115 перечислила расхождения в редакторском примечании и заменила RFC 3025. Причина была операционной: текущие реализации следовали назначениям IANA.

Источники не называют продукты и версии, не считают установки и не описывают аварию. Нельзя утверждать, что все реализации выбрали одну пару. Но факт достаточен в своей узкой форме: наблюдаемая практика имела такой вес, что Standards Track документ изменили вслед за ней.

Critical и normal означали разные последствия незнания

RFC 2002 разделила пространство расширений Mobile IP. Неизвестный type от 0 до 127 делал всё сообщение непригодным: его требовалось молча отбросить. Неизвестный type от 128 до 255 игнорировался, а Length позволял найти следующее расширение и обработать остальное.

Поэтому CVSE 38 находился в непропускаемой половине, а NVSE 134 — в пропускаемой. «Критический» не значило просто «важный для поставщика». Это было обещание, что без понимания расширения смысл оставшейся части нельзя безопасно использовать. «Обычный» допускал потерю частной функции без уничтожения всего обмена.

И 37, и 38 лежали ниже 128; 133 и 134 — выше. Ошибка не переносила расширение через границу политики, но ломала точное распознавание. Parser, ожидающий 38, видел 37 как другой неизвестный критический type и уничтожал запрос. Parser, ожидающий 134, мог пропустить 133 и продолжить, создав видимость успеха без ожидаемой частной функции.

Первый сбой выглядел как потеря пакета. Второй — как неполный успех. Поле конечного статуса не объясняло ни один случай. Нужны исходный octet, версия parser и выбранная ветвь.

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

RFC 3115 различала два уровня неизвестности. Получатель мог совсем не знать внешний type 38. Либо мог знать структуру CVSE, но не поддерживать Vendor/Org-ID или Vendor-CVSE-Type внутри.

В первом случае действовало базовое правило 0–127: молчаливый discard. Во втором parser уже понимал границы полей, поэтому отказ становился явным. Request с известной оболочкой CVSE и неизвестной организацией или подтипом должен был получить соответствующий denial.

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

Запись «unknown vendor extension» стирает архитектуру. Следует сохранять внешний type, версию parser, результат распознавания оболочки, enterprise number, подтип, направление, роль узла, проверку длины, drop/skip/reject и выпущенный code. Устаревшая внешняя константа — не то же самое, что отсутствующая частная возможность.

Enterprise number давал пространство имён, а не полномочие

Обе структуры несли четырёхоктетный Vendor/Org-ID. Старший октет равнялся нулю, три младших содержали SMI Network Management Private Enterprise Code. Организация управляла двухоктетным подтипом и его значением.

Контроль был разделён. IANA назначала внешние Mobile IP types и коды отказа. Реестр enterprise numbers закреплял частное пространство. Организация определяла подтипы. Отправитель выбирал расширения. Получатель выбирал поддерживаемую семантику. Security association Mobile IP аутентифицировала сообщение там, где это требовалось. Локальная политика решала, разрешён ли результат.

Enterprise number сам по себе не аутентифицировал отправителя. Аутентифицированное сообщение не объясняло неизвестный подтип. Распознавание не означало авторизацию. Принятая регистрация ещё не доказывала рабочий пользовательский трафик.

RFC 3115 разрешала несколько CVSE и NVSE после фиксированной части и указывала промежуточным узлам не менять их порядок. Сортировка TLV при записи может уничтожить последовательность, покрытую authenticator, созданную отправителем и увиденную следующими parser.

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

Четыре кода сохранили путь между тремя ролями

100 и 101 относились к отказу foreign agent. Первый обозначал неподдерживаемый критический Vendor-ID или подтип от mobile node, второй — от home agent. 140 и 141 относились к home agent и также различали происхождение от mobile node и foreign agent.

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

Foreign agent мог быть транзитом для Reply от home agent: понять оболочку, не понять внутренний CVSE и превратить ответ в новый reject для mobile node. Лог home agent тогда не содержал финала, а mobile node видел только отказ. Нужны вход, решение и выход каждого hop.

Онлайн-реестр становился живой частью протокола

RFC 1700 была статическим снимком Assigned Numbers 1994 года. RFC 3232 в 2002 году зафиксировала, что онлайн-базы IANA заменили такие снимки, а RFC 1700 стала неполной и местами неверной. RFC 3115 показала этот переход на год раньше.

Живой реестр мог отражать назначения без выпуска нового сборника. RFC подробно описывал поля и переходы, но замораживал момент публикации. Один не заменял другой. IANA знала 38 и 134, но не содержала всей логики transit и reject; RFC 3025 содержала логику, но напечатала другие числа.

Сегодня Mobile IPv4 Numbers по-прежнему указывает CVSE 38, NVSE 134 и четыре кода со ссылкой на RFC 3115. Это доказательство текущего состояния, не полный журнал изменений. Для истории 2001 года нужны обе замороженные RFC.

Последующие спецификации показывают случаи, а не масштаб

RFC 4332 определила расширения Cisco для home network prefix, gateway, DNS, DHCP и configuration URL. RFC 4784 задала три расширения Verizon Wireless с type 38 и enterprise number 12951 для dynamic key update в cdma2000.

Это конкретные опубликованные применения. Они не измеряют количество установок, пакетов, успешных взаимодействий или коммерческий охват. Нормативное MUST не является runtime trace.

RFC 5612 позже зарезервировала enterprise number 32473 для примеров. Даже вымышленным данным нужен номер, который не совпадёт с реальной организацией: примеры попадают в тесты, код и захваты. RFC 6709 обобщила риск: частные расширения дают гибкость, но слабая экспертиза и неясное поведение при неизвестных значениях создают эксплуатационные, межоперационные и защитные проблемы.

RFC 3115 уже указала цену. Незнание critical теряло сообщение; незнание normal — функцию. Исправление type возвращало общую договорённость о том, какую цену назначил отправитель.

Работающий код был свидетелем, а не верховным судом

Этот эпизод не говорит, что реализация всегда права. В коде бывают ошибки; реестры и RFC меняются. Решение было уже: документ противоречил органу назначения, а документ-замена сообщил, что реализации следуют органу.

Захват пакета доказывает отправку, но не интерпретацию. Parser log доказывает локальное решение, но не успешную регистрацию. Reject code доказывает один переход, но не пользовательскую услугу. Формула «current implementations» сильнее проектного намерения и слабее полного обследования.

При таких границах цепь остаётся ясной. RFC 3025 напечатала 37 и 133. IANA назначила 38 и 134. Работающая сеть уже выбрала вторую пару. RFC 3115 не уничтожила норму — она исправила её, потому что отдельно сохранённые реестр и операционная практика показали расхождение.

Источники

  1. https://www.rfc-editor.org/rfc/rfc3115.txt
  2. https://www.rfc-editor.org/rfc/rfc3025.txt
  3. https://www.rfc-editor.org/rfc/rfc2002.txt
  4. https://www.rfc-editor.org/rfc/rfc1700.txt
  5. https://www.rfc-editor.org/rfc/rfc2119.txt
  6. https://www.rfc-editor.org/rfc/rfc2344.txt
  7. https://www.rfc-editor.org/rfc/rfc2356.txt
  8. https://www.rfc-editor.org/rfc/rfc3232.txt
  9. https://www.rfc-editor.org/rfc/rfc3344.txt
  10. https://www.rfc-editor.org/rfc/rfc4332.txt
  11. https://www.rfc-editor.org/rfc/rfc4784.txt
  12. https://www.rfc-editor.org/rfc/rfc5612.txt
  13. https://www.rfc-editor.org/rfc/rfc5944.txt
  14. https://www.rfc-editor.org/rfc/rfc6709.txt
  15. https://www.iana.org/assignments/mobileip-numbers/mobileip-numbers.xml