IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

Тоже 1 апреля 1996, но из Австралии, а не с Бермудских островов. 😉

Почему у тиранозавра маленькие ручки?

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

Что, конечно, может намекать, на то, что короткими руками не дотянуться до эрогенных зон, поэтому размножение улучшилось.

Однако, нет фактов подтверждающих то, что сначала у тианозавров были длинные передние конечности, а потом они стали короче. Факты больше за то, что просто размеры тела увеличивались быстрее. 😉

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

вечном статусе полувнедрения хорошего ничего тоже нет

Кто сказал вечный? Через год будет 50%, через 18 лет все 75% или немного больше. По-моему, мы заметно операжаем график перехода со 110 В на 230 В, но немного медленнее, чем с 32-х бит процессоров на 64-е битные.

Полагаю, что всем заранее было понятно, что переход займёт лет 50. 😉

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

Насчёт NAT с межсетевым экраном дело тёмное, если динамические правила запрещены, то может, они и помогут.

А если каждый “термометр” в локальной сети может открыть порт NAT одним из стандартных протоколов управления NAT, и для него правила модифицируют, то некоторое количество уязвимостей уже встречалось...

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

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

Исследователь смог превратить «cat readme.txt» в выполнение произвольного кода в iTerm2

Что-то до боли знакомое, знакомое. А, ЕМНИП, VT220 имел Esc-последовательность для возврата копии экрана, эмулятор XTerm её тоже имитировал. 😉

Троичная логика: суть и немного истории. Как мир мог не стать двоичным

На троичном компьютере аналогом binary32 (8 бит экспонента, 23+1 мантисса или 7,2 цифры в диапазоне ), может быть ternary18 (3 трайта):

• Кодировка: 5 + 13 трит (со скрытым старшим тритом, т.е., знак экспоненты - знак числа) тогда можно получить: 6,4 цифры в диапазоне ;

• Вариант кодировки: 6 + 12 трит (со скрытым старшим разрядом, т.е., знак экспоненты - знак числа) или 5,9 цифры в диапазоне ;

• Как я понимаю, в Сетуни (ИП-3 и ПОЛИЗ) использовалась кодировка: 4 + 14 трита без скрытых старших разрядов, экспонента: ±40, мантисса: ±2'391'484 или 6,4 цифры в диапазоне .

Аналогом binary64 (11 бит экспонента, 52+1 мантисса или 15,95 цифры в диапазоне ), может быть ternary36 (6 трайтов):

• Кодировка 8 + 28 трита (со скрытым старшим тритом, т.е., знак экспоненты - знак числа) или 13,5 цифры в диапазоне .

Правда, float немного не попадает требования стандарта языка C23, Implementation limits:

• FLT_DIG = 6, FLT_MAX_10_EXP = 37, FLT_MIN_10_EXP = -37;

• DBL_DIG = 10, DBL_MAX_10_EXP = 37, DBL_MIN_10_EXP = -37.

Да и вообще система типов C для троичного компьютера немного не попадает в C23 Implementation limits:

• char - 1 трайт - ±364 ();

• short - 2 трайт - ±265'720 ();

• long - 3 трайта - ±193'710'244 (, C23 требует );

• long long - 6 трайтов - ±75'047'317'648'499'560 (, C23 требует ).

Будем посмотреть, когда дело дойдёт до драки.

Но и десятичные типы с плавающей точкой на троичном компьютере тоже могут быть:

• decimalT18 (3 трайта): 6 цифр, ;

• decimalT36 (6 трайтов): 14 цифр, .

Что такое Decimal64 из Decimal floating point из IEEE 754 или точные десятичные числа с плавающей запятой в компьютере

в числе 8,1 binary64 начнёт писать 8,09999…

Это Вы зря. Если по K&R, то точность печати по умолчанию - 6 значащих цифр, поэтому напишет: 8.1

Если по C++23, то точность печати по умолчанию - минимально необходимая для представления с ±0,5 ULP, поэтому тоже напишет: 8.1. Хотя, если постараться, то можно напечатать и иначе. 😉

int main(void) {
    double t81 = 8.1;
    std::println("t81 = {} in [{} ... {}]", t81,
            std::nextafter(t81, -INFINITY), std::nextafter(t81, INFINITY));
    std::println("Избыточно (незначащие): {:.9999g}", t81);
}

Результат:

t81 = 8.1 in [8.099999999999998 ... 8.100000000000001]
Избыточно (незначащие): 8.0999999999999996447286321199499070644378662109375

Троичная логика: суть и немного истории. Как мир мог не стать двоичным

Хм, как бы, на двоичных машинах, например, 0.1f или 0.3f, не имеют точного представления, только `0.25f, 0.5f, 0.75f` можно точно представить.

А на троичных машинах, вообще проблемы с вычислительными методами и форматными преобразованиями, ни одна десятичная дробь не имеет точного представления. Мало того, и наоборот тоже. 😉

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

Замечательное наблюдение, но у товарища с Бермудских островов, уже третья редакция https://datatracker.ietf.org/doc/draft-thain-ipv8/

Происхождение жизни — а там ли мы вообще ищем?

Если эта звезда уже обладала планетами с жизнью на уровне одноклеточных организмов...

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

"Poor metal", как написано в заголовке статьи, на которую Вы сослались, это не фигура речи 😉

Разве что, биологическая эволюция начиналась прямо в Космосе, в облаках космической пыли, но там концентрации очень низкие (по нашему, это глубокий вакуум).

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

...There is a specific case for cellular phones to be assigned a single /64 per each PDP context, but this is out of the scope of this document...

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

жду с нетерпением октября, посмотрим как закроют этот черновик

Черновики не закрывают, но, возможно, автор его перестанет обновлять?

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

... 64:ff9b::/96 работает только внутри сети провайдера...

Как бы, нормативный документ IANA IPv6 Special-Purpose Address Space не имеет такового ограничения:

• Source: True;

• Destination: True;

• Forwardable: True;

• Globally Reachable: True.

Но никто не мешает написать черновик на одну страничку и заслать в IETF с целью уточнения данного разночтения (константный Globally Reachable префикс, но не anycast). Примерно так, как это сделал Jamie Thain с Бермудских островов, прости Господи. Творчество которого и породило данную дискуссию.

Желаете инициировать данное действие? Что бы этот префикс был бы зарегистрирован ещё в одной таблице IANA.

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

Конечно, стоило бы более точно систематизировать и определить, что именно Вас интересует, когда Вы говорите "безопасность обеспечивается".

Однако, ИМХО, при прочих равных:

• IPv6 с маршрутизатором на много порядков безопаснее IPv4 с маршрутизатором;

• IPv6 с маршрутизатором на два-три порядка безопаснее IPv4 с NAT;

• IPv6 с межсетевым экраном в разы безопаснее IPv4 с межсетевым экраном;

• Сравнение с IPv8 не имеет смысла, поскольку безопасность IPv8 - отрицательна. 😉 Пока рядом не стояла, и требует массы дополнительного времени под проектирование с непредсказуемым результатом.

P.S.

Но, конечно, поскольку мы все млекопитающие, сначала появился анус, а потом уже IPv6 (IPv4). 😉

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

Кстати, 64:ff9b::808:808 и 64:ff9b::8.8.8.8 - синонимы, но только объявить его anycast немного недостаточно. Без DNS64 его польза немного ограничена. Собственно, рекомендации IETF для поставщиков "только IPv6", как бы, и так имеются в RFC 6586.

Возможно, кто-то где-то их выполняет не в полном объёме, ну так экцессы исполнителей случаются. 😔

@meizuflyme префикс 64:ff9b::/96 заведомо глобальный: IPv6 Special-Purpose Address Space , для приватных преобразований, к примеру, преобразований приватных адресов и/или преобразований иными методами есть 64:ff9b:1::/48, к примеру: 64:ff9b:1:fffe::192.0.2.1.

P.S.

Что до префикса, ::ffff:0:0/96, то в RFC 6052 поясняется, что он для другого алгоритма, и иногда, некоторые ОС выполняют преобразование на месте, что иногда нежелательно.

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

Есть впечатление что весь белорусский ipv6 был заведен для частных энтузиастов и медийного эффекта (возможно есть и серьёзные причины, но обывателю они не ясны).

Как бы, если у меня установлен "только IPv6" здесь, а лично у меня он установлен, то и у вас он будет работать точно также. Удобно, как минимум, для путешественников.

А вот местные организации: всякие порталы новостные или госы — никто не умеет в ipv6.

А смысл, если поставщики "только IPv6", согласно рекомендаций IETF, обязаны иметь IPv4/IPv6 Translators (NAT64)?

Возможно, в будущем, лет через 20, когда доля IPv6 абонентов подберётся к 75%, кто знает? Но сейчас, таковых всего 43%.

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

Если мы делаем честное "туннелирование" 8to4, то в после IPv4 заголовка (Version == 4), мы должны дать идентификатор опции и её длину - 2 байта, потом тело опции, ну и плюс 2 байта выравнивания. И тогда пакет будет восприниматься старым оборудованием, если оно не DPI. Итого: 4 дополнительных байта.

Если Version == 8, то вопрос философский.

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

Как бы, пусть в домашней сети 1000 термометров, датчиков и счётчиков, которые лезут в облака.

В случае IPv4, даже если не рассматривать специализированные NAT атаки, они все имеют открытые NAT порты (номер порта - 16 бит, предположим, случайный). Сколько пакетов надо, что бы им всем устроить DoS?

А в случае IPv6, сколько пакетов надо для DoS?

IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит

В принципе, возможный вариант реализации 8to4 при помощи опций IPv4, но могут быть проблемы с межсетевыми экранами и/или DPI.

Как я понял, они выбрали "ip8 внутри ip4" - "...8to4 tunnelling. HTTPS tunnelling is the preferred encapsulation...", со ссылкой на ещё неопубликованный draft-thain-routing-protocols-00. (Странный выбор, но для запоздалой первоапрельской шутки - нормально)