dxdt.blog: занимательный интернет-журнал

Папская энциклика (англ.) Magnifica Humanitas, которую уже повсеместно называют “первая энциклика про ИИ”, ещё не вышла на латыни. Так что – нужно пождать. Латынь – официальный язык папских энциклик, поэтому – латинский вариант должен быть самым точным. Интересны и некоторые современные слова, и цитата из Толкина (Tolkien) – кто бы мог подумать: цитируются слова мага из книги с волшебниками.

В общем, пока латинского текста нет, можно только строить предположения о первых словах: название “Magnifica Humanitas” наводит на очевидные варианты. Естественно, много кто уже догадался попробовать перевести текст “про ИИ” при помощи ИИ; например, с итальянского на латынь – но, понятно, это будет лишь упражнение в развитии постиронии: LLM не слишком хороши в подобных переводах.

В IETF запустили новую версию сайта rfc-editor.org – это сервис для редактирования и публикации RFC. Официальное сообщение об этом залито штампами (наверное, не обошлось без влияния ИИ): “Вместе с профессиональными UX-дизайнерами и специалистами по удобству использования (accessibility) мы переделали сайт на базе современного веб-фреймворка” (Working with professional UX designers and accessibility specialists, we have rebuilt the site in a modern web framework). Так сказать, очередной этап в развитии IETF: cайт требует JavaScript и загружает какие-то массивные JS-библиотеки. То есть, без JavaScript даже в публичной части сайта выводится предупреждение, что будут работать не все функции (в том числе, если просто попробовать почитать RFC через rfc-editor.org).

Сам я довольно широко использую JavaScipt (JS) в вебе со стороны разработки, что уж там: без JS сейчас не очень удобно. Например, общедоступный сервис ТЦИ для анализа настроек интернет-узлов – audit.statdom.ru – содержит здоровенный кусок JS-кода, который необходим для отображения отчётов на веб-странице, и я имею к этой ситуации самое прямое отношение. Но, как нетрудно догадаться, я противник всяких JS-фреймворков – если уж у вас есть JS-код в вебе, то пусть это будет, что назвается, “ванильный JavaScript”, понятный и написанный собственными руками. При этом, например, на основных страницах dxdt.blog – никакого JS-кода не требуется: скрипты хороши там, где без них совсем не обойтись (поэтому на dxdt.blog со скриптами вы встретитесь, если прямо решите залогиниться и использовать веб-интерфейс; но, отмечу, это особенность WordPress, а к разработке CMS WordPress – я никакого отношения не имею).

Относительно запуска и исполнения JS-кода в вебе есть мнение, что, мол, “не хочу позволять работать на моём компьютере произвольному чужому программному коду, загружаемому в браузер, поэтому и отключен JS”. Я отношусь к такому мнению с уважением, оно вполне обосновано, но несколько размыто: дело в том, что тогда и рендеринг современной HTML-разметки браузером – это исполнение чужого программного кода, и уж тем более – обработка CSS (последний я вообще уже давно рекомендую называть “языком программирования CSS”; да-да, именно так, в отличие от “языка разметки HTML”).

Так что, конечно, без JS сейчас в вебе никуда, но и сообщать о том, что страница вывода RFC в формате HTML может “не работать без JavaScript” – довольно странное решение.

Процитирую записку из 2013 года:

“Интернет – это группа постапокалиптических технологий, не дождавшихся своего часа”.

Вообще, это цитата из статьи в журнале “Доменные имена”. Конечно, речь там идёт об известной легенде, традиционно связываемой с присхождением Интернета, как совокупности IP-сетей. Эта легенда гласит, что Интернет проектировали для связи в разрушенном ядерной войной мире. История уходит своими корнями в конец 60-х годов прошлого века, и ее можно смело назвать одним из ранних произведений, самым прямым образом затрагивающих постапокалипсис в чисто технологическом разрезе. Отсюда, собственно, и вывод, что Интернет – группа постапокалиптических технологий.

Понятно, что легенда о том, как технологии межсетевой маршрутизации помогают восстановить связность между немногими уцелевшими центрами управления, это легенда лишь отчасти: за ней стоят вполне реальные, осуществившиеся проекты, которые позволили на деньги оборонного бюджета США построить систему удалённого доступа к вычислительным ресурсам разных университетов (для чего всё и затевалось). А уже из этого – выросла глобальная Сеть.

Вряд ли расположившиеся глубоко в скальных породах центры управления, упомянутые выше, были озабочены интернетами, как средством восстановления связи – слишком сложно: куда понятнее и надёжнее древние системы проводной телефонии и радиосвязи, – в том числе, подземной, – которые долгое время держали на консервации, как раз, на подобный случай. Не озаботятся интернетами эти центры управления и сейчас, когда случай представится (не сомневайтесь), пусть IP-сети и нашли массовое специальное применение.

Это всё, впрочем, не отменяет постапокалипсиса в истории Интернета. Но, как в цитате выше, эта группа технологий не дождалась своего часа – то есть, не была применена в соответствии с легендой. И уже не будет. Сейчас схемы иные.

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

Поэтому-то шансов на разыгрывание легенды по привычному сценарию – больше нет.

У меня в GitHub тоже есть аккаунт, которым, впрочем, я почти не пользуюсь. Но это не отменяет важности GitHub, конечно. Я под своим там аккаунтом довольно давно опубликовал реализацию шифра “Кузнечик” с оптимизацией на ассемблере Go (гораздо более новая версия, с поддержкой ARM64, есть у меня на сайте, если это вообще кому-то нужно). Кроме того, на GitHub я как-то выложил Runic32 – реализация Base32 на алфавите из англосаксонских рун (“футарк/футорк”, условно говоря). Этот проект является шуточным – потому что как-то зашёл разговор о том, что “TLS-сертификаты отображаются какими-то крючками”: ну, вот, при помощи утилты runic32 можно сертификаты записывать прямо рунами (если есть Unicode).

При этом, как ни странно, но аккаунт в данной “социальной сети” GitHub (известная филологическая английская шутка) я завёл для того, чтобы написать в один из проектов IETF, которая IETF, следуя странной моде, перенесла основную часть своей деятельности по подготовке стандартов в GitHub (спорное решение, мягко говоря). К сожалению, реальность такова, что, фактически, сейчас без GitHub мало что из “рабочих вопросов”, для меня, обходится: начать с того, что с GitHub среди разработчиков принято тянуть очень много из критически важных библиотек, а какие-то библиотеки – просто негде взять удобным способом: скажем, вот полезнейшая CIRCL от Cloudflare.

Я сам сторонник того, чтобы написать всё своё. Да, именно так, и большой плюс – если на ассемблере. Однако, такое нынче – это из области фантастики. В нынешней ситуации – подобный подход не находит понимания в широких массах современных разработчиков на ЯВУ, а приводит только к смешкам и попыткам кидаться штампами вроде “зачем нам изобретать велосипед”, при том, что разработка с нуля – это не изобретение велосипеда, а попытка велосипед сделать самостоятельно, научившись делать велосипеды, а не педалировать чужие. Ну да ладно, тема для другой записки. (Кстати, например, сейчас даже весьма квалифицированный, – реально, – разработчик (не кодер) – ассемблера не знает, да и требовать такого знания – это считается лишним.) В общем, поскольку с таким положением приходится мириться, то и важность “социальной сети” GitHub становится совершенно бесспорной и – растёт дальше. Проблема, конечно, что это централизованный сервис, который, в рамках “битвы за банхаммер”, все хотят отломить. Но, к сожалению, это не уменьшает практической важности. Более того, во многих крупных проектах нынче только через GitHub принимают сообщения об ошибках и прочие технические запросы, что ещё усиливает центральное положение GitHub.

Даниэль Стенберг (утилита curl) сообщает, что “страшная-ужасная” система поиска уязвимостей в ПО Mythos нашла в коде утилиты curl “пять” “подтверждённых уязвимостей” (“подтверждённых” – по мнению данного ИИ-LLM), которые, после проверки разработчиками, превратились в одну действительно подтверждённую уязвимость с низким уровнем опасности. Четыре остальных представленных описания – это ложные срабатывания и обнаруженная ошибка, – не уязвимость, – в коде. Результат никак не превосходит уже имеющиеся на стороне разработки curl инструменты.

Занятно, что Mythos сейчас, в рамках “маркетингового трюкачества”, продвигают на правах настолько “опасной системы”, что её нельзя выпускать в открытый доступ – поэтому, мол, доступ предоставляется только “ограниченному кругу лиц” (куда, в том числе, входят корпорации, непосредственно участвующие в разгоне хайпа). Стенберг при этом пишет, что ему доступ к новой системе предоставить обещали, он подписал контракт, но доступ так и не предоставили, а, выждав время, предложили, что кто-то ещё, со стороны Mythos, проведёт сканирование за Стенберга и перешлёт уже готовые результаты – и это очень забавно само по себе, особенно, на фоне всех этих заявлений про “невиданный уровень в разработке программных систем”, который, якобы, демонстрируют ИИ-LLM.

В DENIC опубликовали некие сведения о причинах недавней поломки DNSSEC в зоне .DE (DENIC – оператор). Как ни странно, но, похоже, причина именно в некорректном использовании тегов ключей. Я как раз в прошлой записке по этой теме такое и предположил: “возможно, тоже перепутали ключ из-за совпадающих тегов”. Выходит, что снова использовали теги для индексирования ключей в процессе подписи. Теги – могут запросто совпадать у разных ключей. К сожалению, как это нередко бывает, в опубликованном пояснении формулировка расплывчатая:

Consequently, for the same “key tag” (33834), three different key pairs were generated instead of a single one, of which only the public key of a single pair was stored in the DNSKEY RR, meaning that only about a third of the RRSIG RRs could be validated. (В результате, для одинакового “тега ключа” (33834) были сгенерированы три разных ключевых пары вместо одной, из которых только открытый ключ единственной пары был размещён в DNSKEY-записи, что привело к тому, что только треть из RRSIG-записей могли быть валидированы.)

Ну, то есть, можно предположить, что раз только треть валидировалась, значит – остальное подписывалось другими секретными ключами, из пар, имевших один и тот же тег открытого ключа, а ПО ссылалось на ключи по значению тега (чего делать при подписывании нельзя категорически). Тут может возникнуть сомнение: как же тогда так получилось, что для трёх разных ключей совпал тег? Да, чтобы тег заведомо совпал для ключей, сгенерированных на небольшом интервале времени, ключи нужно специально перебирать (но и это нетрудно – там всего-то 16 битов в теге). Но дело в том, что ключи подписи зоны постоянно заменяются при штатной работе, так что эти пары с совпавшими тегами скорее всего были старыми ключами, сгенерированными ранее, и не удалёнными из системы. Теги же совпадут с большой вероятностью, так или иначе, если просто генерировать ключи штатным образом – только будет несколько дольше по времени: вероятность там много больше, чем 1/65535, как продолжают думать, – ведь это типовое воплощение парадокса дней рождения.

Собственно, в недавней записке об аварии DNSSEC в .DE я поэтому и упомянул конфликты тегов ключей DNSSEC, которые теги используют не по назначению. Цитата:

В DNSSEC выбрана неудачная система тегирования ключей при помощи 16-битных номеров, которые, понятно, то и дело совпадают для разных ключей; данные теги нельзя использовать в качестве индекса при выборе ключей для подписи, об этом написано в RFC, об этом много писал и говорил я, и не только я, но теги всё равно регулярно используют с такой целью; однако насчёт данного случая с DE – не факт, что в этом была проблема.

Оказалось – в этом и была проблема. Что тут ещё сказать? Бывает, конечно: ведь с пониманием сложных процессов – сейчас трудности везде.

В Англии NHS (система здравоохранения) собирается закрыть доступ к собственным репозиториям с открытым (ранее) исходным кодом информационных систем и с сопутствующими (публичными) данными, мотивируя это тем, что, мол, такой ход снизит риск обнаружения уязвимостей при помощи LLM (конечно же, ссылаются на “страшный и опасный” миф под названием Mythos). Очевидно, что решение – так себе, мягко говоря. Естественно, в ответ на такой “ловкий ход”, в сообществе уже подготовли открытое письмо, требующее не закрывать репозитории с исходными кодами (и данными), тем более, что они разработаны в интересах местных налогоплательщиков (казалось бы).

Понятно, что, во-первых, хайп – он и есть хайп, и никакого прорывного результата, без участия специалистов-людей, LLM-инструменты не дают, а технологии “фаззинга” и подобные им – были давно: но, конечно, с ростом вычислительной базы и на волне хайпа – эффективность увеличилась. Во-вторых, сокрытие исходных кодов, если преподносить его как инструмент “снижения рисков”, имеет сомнительную ценность. Особенно – в данном случае: исходные коды, которые пытаются скрыть, уже так или иначе есть в этой самой LLM – их скачали раньше, скачали из других репозиториев, из внутренних инструментов “ИИ-разработки” и т.д., и т.п. Это кроме того, что формат распространения кода программы – не особенно влияет на сокрытие уязвимостей, а исполняемый машинный код – может являться таким же “исходным”, если приложить к нему некоторые детерминированные и строгие инструменты, типа современного дизассемблера.

Кстати, по этой теме ещё модно говорить, что для LLM уровня Mythos (что бы это ни значило), типа, нет разницы, на каком языке подан код программы (а машинные коды – это тоже язык, не забывайте). Это, конечно, не так: подобные системы сами никаких уязвимостей не находят, но могут генерировать вывод, который совпадает с описанием уязвимости (или не совпадает). Это хорошо подтверждается тем, что уровень качества “исправлений”, сгенерированных той же LLM, ниже уровня “обнаружения” (должно быть наоборот, если уязвимость находит реальный интеллект). То же, кстати, видно и в “решении” математических задач LLM: генератор текста – он и есть генератор текста.

Поэтому, если основной базой обучения был код на Python, то именно эта база и не позволит непосредственно, без потерь, перейти на обработку машинного кода или выдачи дизассемблера. Так что некоторое минимальное зерно разумности в желании закрыть код от LLM найти можно, при желании. Другое дело, что, с одной стороны, кто сказал, что LLM не обучили и на ассемблерных распечаnках, и на машинном коде? Никто не сказал, да. И, с другой стороны, это минимальное “зерно разумности” – никак не может перевесить массы прочих вредных эффектов, типа того, что начнут надеяться на мнимую “безопасность”, связывая её с “секретностью” исходных кодов или недоступностью кодов исполняемых, которые вертятся во внутренних системах только (см. впрочем, про принцип Керкгоффса).

Хотя – хайп. Хайп не все хотят пропустить.

В домене .DE на некоторое время сломались подписи DNSSEC. Сейчас уже пишут, что починили. Возможно, тоже перепутали ключ из-за совпадающих тегов. (Лирическое отступление: в DNSSEC выбрана неудачная система тегирования ключей при помощи 16-битных номеров, которые, понятно, то и дело совпадают для разных ключей; данные теги нельзя использовать в качестве индекса при выборе ключей для подписи, об этом написано в RFC, об этом много писал и говорил я, и не только я, но теги всё равно регулярно используют с такой целью; однако насчёт данного случая с DE – не факт, что в этом была проблема.)

Интересна тут реакция Cloudflare, как оператора одного из самых распространённых в этих интернетах сервиса DNS-резолвинга – 1.1.1.1: в Cloudflare, после локализации ошибки на стороне DE, валидацию DNSSEC для этой зоны просто отключили. Ну, то есть, очередной пример реальной ценности DNSSEC в современой глобальной DNS: если что не так, то систему валидации принято отключать; но, конечно, не просто так отключать, а информированно отключать.

Есть даже RFC 7646, который, кто бы мог подумать, прямо предписывает так делать. Естественно, речь тут идёт об операторах DNS-сервисов, которые могут убедиться, что, мол, “это не атака подмены”, а это DNSSEC сломали сами администраторы ключей, очередной раз. Хотя, строго говоря, достоверно определить, что подписи стали расходиться не из-за атаки, а из-за ошибки – весьма и весьма сложно: атака могла быть на уровне оператора реестра, например. Может ли тут что-то с уверенностью – и, главное, быстро, – сказать внешний наблюдатель, даже если он оператор резолвера? Ну, это вряд ли. Остаётся полагаться на ответы оператора реестра и, что называется, кликать виртуальную универсальную кнопку “Всё равно продолжить” для всех пользователей своего “валидирующего” резолвера. Такая вот нынче стала на практике эта технология – DNSSEC. Ничего не поделать.

Одним из важных преимуществ современной сотовой связи является то, что это радиосвязь с высокой степенью распределённой автономности. То есть, и базовая станция с автономным питанием, и у всех абонентов тоже – терминалы с автономным питанием: провода не нужны, а в случае критической ситуации все абоненты, находящиеся в зоне доступа данной базовой станции, получают возможность связи, как минимум, между собой (оставим сейчас за скобками всякие контроллеры и авторизацию – здесь речь о критической ситуации и о теории вопроса). Получается, что достаточно поднять базовую станцию, с автономным питанием, а автономные терминалы у абонентов уже есть (это телефонные аппараты с аккумуляторным питанием).

Для старой проводной связи, – которую зачем-то (см. ниже) едва ли не повсеместно изжили, – как минимум, отсутствует мобильность и по связи, и по питанию: нужны провода. Причём, понятно, электропитание-то может быть автономным и на стороне каждого абонента с проводами (“покрутил ручку/поставил батарейку”), но штатная массовая схема, например, в городах, подразумевала независимое питание аппарата со стороны сети связи (со станции или с ближайшего подходящего узла – не важно). То есть, в штатной схеме – “гудок в трубке был и при отключении электричества”. Но привязки к проводам это не отменяет, а восстановление связи – требует восстановления проводов и напряжения в этих проводах, потому что рассчитывать на то, что у абонентов есть автономные аппараты – не приходилось.

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

И поэтому всегда удивительно наблюдать, как, – в текущих реалиях, – на базовых станциях систем резервного питания явно не хватает, и всякая мало-мальски масштабная авария сетей обычного электроснабжения (аварии – уже не редкость) тут же приводит к тому, что не только пропадает свет в оптоволокне интернет-канала, заведённого в дом, но в округе и моментально тухнут только что доступные базовые станции GSM/LTE. Хотя – казалось бы. Но нет, это уже практика: времена поменялись – подходы скорректировали.

Сейчас много околотехнических обсуждений по теме методов определения того, пришёл ли веб-клиент на некий крупный веб-сервис “c VPN или без VPN”. Оставим за скобками набравшую сейчас популярность трактовку того, что такое VPN – термин обобщили до невозможности. Но в технической стороне процесса “определения” сетевых настроек есть пара занятных моментов, которые как-то пропускают.

Момент первый: измерение параметров времени для TCP-соединения. Например, к некоторому веб-сервису подключается клиент, скажем, браузер. При помощи выполнения некоторых скриптов не очень трудно померить время “сетевой задержки” между средой веб-страниц этого браузера и серверной средой. То есть, это будет время доставки запроса, измеренное от контекста DOM в браузере до веб-сервера. Предположим, это 50 ms. Но это всё по HTTP, а HTTP-соединение использует TCP.

TCP-соединение устанавливается не с браузером, а с логически ближайшим к серверному сетевому стеку узлом. Это может быть клиентский компьютер, то есть, ОС на этом компьютере. Но может быть и выходной узел, выполняющий трансляцию адресов, например. Обычно – именно так и есть: клиентский компьютер редко стоит прямо за маршрутизируемым IP-адресом. Тогда, если измерять и задержку в браузере, и задержку на серверном TCP, то получится, скажем, что, в рамках одной логической HTTP-сессии, TCP-задержка – 10 ms, а браузерная задержка, до DOM в HTTP-клиенте, – 50 ms. Большая разница – 40 ms. Это означает, что от клиента транслированные запросы ещё где-то там внутри долго ходят, пока доберутся до выходного узла, который к нам по TCP подключился.

Если же выходной TCP-узел примерно совпадает с логическим узлом, где работает клиентский браузер, то разница между двумя задержками будет минимальной, например: 10 ms TCP и 11 ms – браузерная задержка, читай – Javascript в DOM-контексте. Здесь под “примерно совпадает” имеется в виду, что между клиентским компьютером и выходным узлом нет большого сетевого плеча: компьютер и выходной узел стоят технически рядом (простейший случай: локальный пограничный “роутер” с NAT и подключенный к этому “роутеру” по локальному порту компьютер в локальной IP-сети над Ethernet-ом).

Естественно, измерять задержки TCP-стека для веб-сервиса (не веб-сервера) – несколько сложнее, чем померить что-то внутри веб-логики. Для таких измерений нужно зацепить “щупы” прямо в сетевой стек, причём, на входном узле, а не на бэкенде, куда проксируются HTTP-запросы. Очевидно, что на “веб-уровне”, даже для сервера, TCP в таких деталях не виден. Но измерять всё равно можно – это не суперсложная задача, и решение вполне под силу специализированной компании, сохранившей инженерный подход среди своих разработчиков. Мы же тут, как раз, речь ведём о крупных профильных компаниях, где, вполне возможно, понимающие инженеры есть – верно?

Понятно, что сравнение задержек по времени на уровне браузерного движка с задержками на уровне TCP-стека не является каким-то волшебным зеркалом, которое всё показывает: большие задержки бывают при использовании радиоканалов, из-за перегруженного оборудования, из-за потерь пакетов на стороне клиента и т.д. Тем не менее – фактор это достаточно важный, чтобы о нём не забывать.

Момент второй: геометрия сетевых подключений. Если наш гипотетический веб-сервис имеет только одно подключение к общему Интернету, – которое называют “аплинк”, – то этот веб-сервис не может различить пути поступления сетевых пакетов извне в локальную сеть, в рамках какой-то веб-сессии. Ну, как не может – путь для таких пакетов тут один, потому что один “аплинк”. Соответственно, различать нечего. Однако в совсем крупных компаниях, связанных с веб-сервисами, есть несколько подключений, несколько “аплинков”, своя автономная система (или несколько) и свой центр управления сетью, населённый инженерами NOC.

Для опытного инженера NOC, IP-адрес – это сетевой номер, идентификатор, а не “интернет-узел”. С точки зрения физической организаци сети, IP-адрес может указывать куда угодно, а доставка IP-пакетов – просто происходит на другом уровне, чем работает сама вверенная сеть. Поэтому IP-пакеты можно различать по физическим портам коммутаторов или по логическим маршрутам, которые ниже IP и связаны с внутренним устройством сетей оператора (см. MPLS и пр.). Так что для IP-пакетов, с разными адресами источника, и разными правилами, могут использоваться разные порты подключения – эти пакеты, проще говоря, приходят “с разных сторон”, что создаёт внутренний различительный признак. Как ни странно, но этот признак зависит от внешних факторов (где какие фильтры, кто к кому подключен и пр.).

Сюда же попадает и повсеместная путаница, связанная с распределением блоков IP-адресов (префиксов). У всякого IP-префикса есть администратор – автономная система (AS). Это верно. Но ещё есть маршрутизация и BGP. И вот в рамках BGP, технически, быть источником (origin) для данного IP-префикса может любая (подчёркиваю: технически – любая, даже с тестовым номером) автономная система. То есть, административно, префикс принадлежит одной AS, но анонсирует его в Интернет – совсем другая. Или даже несколько других AS – в зависимости от того, какой оператор из какой точки сети смотрит на BGP. Да, для штатного анонсирования префикса должно быть разрешение от его администратора, сейчас это даже подтверждается в RPKI. Да, конкретная ситуация с приёмом IP-пакетов зависит от фильтров, настроенных оператором. Но это только подчёркивает то, что одно дело – административная принадлежность, другое – BGP и маршрутизация в реальности.

BGP – это хорошо, но при чём здесь сетевые задержки? Вот при чём: даже во внешнем BGP, например, не видны многие и многие внутренние каналы между операторами, более того, административная принадлежность префикса не позволяет судить о реальных характеристиках сетевой связности вообще никак; однако разные пути доставки тут всё равно образуются, и разное время доставки, наблюдаемое внутри, вполне себе может служить признаком для классификации.

Кто-то опубликовал черновик (draft) с описанием IPv8, очевидно, сгенерированный при помощи LLM: там во первых же строках предлагается аутентификация узлов с OAuth2, JWT-токенами, “из локального кеша”, и валидация каждого интернет-пакета через специальный DNS8 – дальше же можно не читать черновик, не тратить время. Печально, но теперь пишут на профильных сайтах, что это “организация IETF” выставила “черновик новой версии протокола IP”. Однако на странице данного черновика прямо, на специальной плашке, написано, что IETF никак данный черновик не поддерживает: “This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process”. Что, конечно, не удивительно: потому что не требуется одобрение и поддержка IETF для публикации черновика – кто угодно может опубликовать черновик.