Здравствуйте, mrTwister, Вы писали:

N>>Читай документы IANA, и разных RIRов, как RIPE NCC.
N>>/32 на провайдера (PA), от /32 до /48 на PI.
N>>У провайдера от /48 до /56 для не-collocation клиента (который подключен проводом любого типа).
N>>Клиент распределяет их своими средствами на энное количество локалок, каждая по /64.
N>>Вот это то, что установлено в реале, а не то, что ты вычислил по трещинам на потолке.

T>А, ты про это. Я просто хотел на пальцах показать что не все 128 бит используются для адресации, соответственно столько там квантилионов получается — это не важно. Важно, что адрес поделен на куски и значительная часть адреса используется для кодирования разной информации.

В том и дело, что в основной схеме такого нет.
Мировой адрес состоит из
— Префикса основного unicast блока — 3 бита (пока раздаётся только один такой).
— id провайдера — 29 бит (рассматриваем PA (provider-allocated) варианты).
— Номера блока внутри провайдера — штатно от 16 до 24 бит.
— Номера блока для конкретного эзера внутри клиента — соответственно от 8 до 16 бит.
— Адрес в локалке — это или маленький красивый адрес, или EUI-64, который формируется из MAC-адреса расширением на 2 байта.

Вот примеры:

$ host ns.ripe.net.
ns.ripe.net has address 193.0.9.6
ns.ripe.net has IPv6 address 2001:67c:e0::6
$ host nn.ns.ua.
nn.ns.ua has address 194.58.197.4
nn.ns.ua has IPv6 address 2a01:3f1:c001::53

Тут, очевидно, красивые адреса.

$ ip a
...
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
...
    link/ether 0a:1f:47:40:b2:db brd ff:ff:ff:ff:ff:ff
    inet6 fe80::81f:47ff:fe40:b2db/64 scope link proto kernel_ll 
       valid_lft forever preferred_lft forever

Виртуалка на AWS. Тут fffe посреди адреса — кодирование факта "это EUI-64", остальное это MAC адрес (один бит флипнут).

$ ip a
...
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether 56:00:05:mn:ij:kl brd ff:ff:ff:ff:ff:ff
    inet6 2a05:f480:2400:1c5f:5400:5ff:femn:ijkl/64 scope global dynamic mngtmpaddr noprefixroute

Виртуалка на vultr, мировой адрес, часть адреса я замаскировал. Аналогичное fffe.

Что тут "для кодирования"? Префикс провайдера и сети? MAC адрес?
Максимум что "для кодирования" в мировом варианте это 3+16 бит.

N>>Принципы формирования локальной части IPv6 адреса, не пересекающейся с EUI-64, отданы на откуп локальным правилам. Тем более то, что ты описал, это на 200% внутренняя кухня и не имеет отношения к обсуждаемым вопросам.

T>Ну и что что локальная кухня, почему она не имеет отношения к обсуждаемым вопросам? Кто-то на этой локальной кухне будет свой фаерволл настраивать, кто-то еще что придумает.

Не имеет отношения потому, что всё обсуждение посвящено основному варианту применения адреса, он на десятилетия, если не на века.
А что там у облачников внутри — может меняться каждый год.

Здравствуйте, netch80, Вы писали:

vsb>>Я не обосную, я в этом разбираюсь плохо. Но я уверен, что протокол проектировали люди, которые потратили куда больше времени на обдумывание вариантов

N>В том и проблема, что нет, ничего они не обдумывали.

Ладно, убедили. В любом случае орать на облака смысла большого я не вижу. По непонятной мне причине от IPv4 переезжают на IPv6, это факт. Причина мне не понятна, т.к. юзерам уж точно NAT хватит, а серверам для большинства протоколов хватает reverse proxy по hostname (т.к. протоколы чаще всего оборачивают в TLS или тупо в HTTPS). А если бы порт внесли куда-то в DNS, то можно было бы и без hostname использовать. Но тем не менее факт остаётся фактом, IPv6 уже весьма широко внедрён и никуда от него не деться, как и от IPv4, очевидно. Так что дуал-стек это наше обозримое будущее.

Здравствуйте, vsb, Вы писали:

vsb>Ладно, убедили. В любом случае орать на облака смысла большого я не вижу. По непонятной мне причине от IPv4 переезжают на IPv6, это факт. Причина мне не понятна, т.к. юзерам уж точно NAT хватит,

Вот тут существенная засадочка. NAT даёт кучу проблем, не все из которых удобно преодолеваются и не все вообще можно преодолеть.
NAT нормально позволяет работать только с вариантом наличия application level server или gateway/proxy на гарантированно белых публичных адресах при соответствующим образом подточенных протоколах.
Да, таких ≈99% (если не больше) от всех использований, потому что раздача котиков и порно, а в промежутках между ними очередных супергероев с нетфликса. Но не 100%.
А раньше было ещё меньше.
Ну и сейчас — конечно, приходится, например, условному Zoom голос/видео гонять через центральные сервера, но им же самим было бы удобнее, если бы это делалось напрямую между юзерами. (А то и через других юзеров, как раньше делал Skype.)

IPv6 задумывался как раз чтобы избежать всего этого и сделать снова плоский доступ без костылизации, везде. Но они там недоучли хакеров с одной стороны и тупость абдулкумаров с другой стороны.

А дальше начинается то, что, например, у каждого телефон и он подключен к сотовому оператору, которому удобнее каждому давать свой IP напрямую, а не через NAT своего уровня, потому что потом зашьёшься для одних разбираться, почему голос не проходит, а для других искать, кто из хакеров сломал очередную фбр. Все телефоны одного оператора в одной небольшой стране, или в одной области большой страны, можно запихнуть в /64, сгенерировав локальную часть для них.

vsb> а серверам для большинства протоколов хватает reverse proxy по hostname (т.к. протоколы чаще всего оборачивают в TLS или тупо в HTTPS). А если бы порт внесли куда-то в DNS, то можно было бы и без hostname использовать. Но тем не менее факт остаётся фактом, IPv6 уже весьма широко внедрён и никуда от него не деться, как и от IPv4, очевидно. Так что дуал-стек это наше обозримое будущее.

Да.

K>>кмк, проблема IPv6 не в избыточных байтах, а в том, что для него не сделали удобной человекочитаемой формы записи адресов.
K>>Вот если Вася Пете диктует по телефону "пингани адрес <такой-то>". Для IPv4 адрес продиктуется легко и ненапряжно, его легко записать и в крайнем случае его даже не так трудно запомнить. А для IPv6 придется заморачиваться.
O>Передать 16 байт через клипборду — это заморачиваться, а передать мегабайты оцифрованного голоса — это ненапряжно. Странная у этих программистов арифметика.

Не с той стороны смотришь на проблему. Сколько байт передается — вообще пофиг (в разумных пределах). Важно, сколько действий надо предпринять, сколько кнопок нажимать, каковы ограничения на такой способ применения и каковы шансы ошибиться.
Вот попробуй представить по шагам — если Петя как-то связываетя с Васей и задал вопрос "почему наша система не работает? срочно надо!", кто из них что должен сделать дальше в каждом из вариантов. Чтобы задача была не такой тривиальной — пусть Вася в это время находится за рулем, но у него имеется гарнитура или громкий режим на телефоне.

N>Ну и сейчас — конечно, приходится, например, условному Zoom голос/видео гонять через центральные сервера, но им же самим было бы удобнее, если бы это делалось напрямую между юзерами. (А то и через других юзеров, как раньше делал Skype.)
Если бы им это было нужно, они бы делали это и сейчас там где возможно, так как белын ип адреса в принципе встречаются довольно часто, а еще иногда работает UPnP port forwarding. Но мне кажется им хочется держать все яйца данные клиентов под полным своим контролем. Именно поэтому микрософт первым делом купив скайп — отключил эту фичу.

O>>Передать 16 байт через клипборду — это заморачиваться, а передать мегабайты оцифрованного голоса — это ненапряжно. Странная у этих программистов арифметика.
K>Не с той стороны смотришь на проблему. Сколько байт передается — вообще пофиг (в разумных пределах). Важно, сколько действий надо предпринять, сколько кнопок нажимать, каковы ограничения на такой способ применения и каковы шансы ошибиться.
K>Вот попробуй представить по шагам — если Петя как-то связываетя с Васей и задал вопрос "почему наша система не работает? срочно надо!", кто из них что должен сделать дальше в каждом из вариантов. Чтобы задача была не такой тривиальной — пусть Вася в это время находится за рулем, но у него имеется гарнитура или громкий режим на телефоне.
Во-первых, специально для не-pro-связистов придумали DNS, чтобы называть вещи своими именами (а не номерами, ёмкость которых в голове быстро заканчивается).
В-нулевых, не надо за рулём на такие сложные вещи отвлекаться, станет вообще не до систем и не только Васе.

Здравствуйте, klopodav, Вы писали:

K>Не с той стороны смотришь на проблему. Сколько байт передается — вообще пофиг (в разумных пределах). Важно, сколько действий надо предпринять, сколько кнопок нажимать, каковы ограничения на такой способ применения и каковы шансы ошибиться.
K>Вот попробуй представить по шагам — если Петя как-то связываетя с Васей и задал вопрос "почему наша система не работает? срочно надо!", кто из них что должен сделать дальше в каждом из вариантов. Чтобы задача была не такой тривиальной — пусть Вася в это время находится за рулем, но у него имеется гарнитура или громкий режим на телефоне.

Вася должен сказать — "Петя, иди в Ж###, я в отпуске!" и выключить телефон.
Петя должен наконец-то сообразить позвонить дежурному админу сидящему в офисе и вежливо попросить решить проблему с системой "имя системы" четко и внятно описав симптомы.

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

Дежурный админ уже посмотрит в талмуд, узнает что у "имя системы" 7 интерфейсов, на каждом по 3 IP адреса, попингует их и выяснит что все работает хорошо, а упала система мониторинга zabbix и шлет фейковые алерты кому не надо, а кому надо не шлёт.

на этом этапе конкретный ip адрес вообще вреден.

Все проблемы от жадности и глупости

Здравствуйте, Shmj, Вы писали:

Pzz>>Объем добавленной работы никак не зависит от 128-битности IPv6-х адресов, и связан только с добавленной необходимостью поддерживать два разных, хотя и семантически весьма близких, протокола.
S>Зависит. Начнем с того что даже в C|C++ нет нейтивных 128-битных типов и нужно городить свое — включая сравнение и пр.
Это правильно и не зависит от битности.

Здравствуйте, Stanislaw K, Вы писали:

SK>Слушай, а можешь сформулировать простыми словами, для не очень умного человека — какую проблему ты хочешь этим решить?

Экономия ресурсов. 8 байт требуют меньше вычислительных мощностей и меньше памяти, чем 16. При этом 8 байт хватит для триллиона людей + каждому по 16 млн. личных адресов, что более чем достаточно. Разумно распределить — дело протокола, главное что их точно с большим запасом хватит нашей планете.

Здравствуйте, B0FEE664, Вы писали:

Pzz>>>Объем добавленной работы никак не зависит от 128-битности IPv6-х адресов, и связан только с добавленной необходимостью поддерживать два разных, хотя и семантически весьма близких, протокола.
S>>Зависит. Начнем с того что даже в C|C++ нет нейтивных 128-битных типов и нужно городить свое — включая сравнение и пр.
BFE>Это правильно и не зависит от битности.

Напиши на C++ поиск по IP-адресам из черного списка. Сначала напиши для 8-байтных адресов (а это делается нейтивным типом), потом для 16 байт. Сравни скорость работы.

Здравствуйте, Shmj, Вы писали:

S>>>Этого ПРОСТО достаточно с прицелом на долгие долгие тысячи лет вперед.
Pzz>>Мешает-то чем, я не пойму?
S>А собаке пятая лапа будет мешать?
Считайте, что хвост — это и есть пятая лапа.

S>Вы понимаете что даже 1 байт лишний — уже приведет к неразумному расходу энергии, если это лишний байт добавлять в каждый пакет долгие годы? Даже если сожмете — это ресурсы процессора на распаковку/упаковку. А тут вы добавили целых 8 байт просто для прикола как бы.

Интернет изначально создавался с большой избыточностью и именно поэтому он всё ещё существует.

Здравствуйте, Shmj, Вы писали:

SK>>Слушай, а можешь сформулировать простыми словами, для не очень умного человека — какую проблему ты хочешь этим решить?

S>Экономия ресурсов. 8 байт требуют меньше вычислительных мощностей и меньше памяти, чем 16.

Что экономить? Какие вычисления производятся над ip адресами?


S> При этом 8 байт хватит для триллиона людей + каждому по 16 млн. личных адресов, что более чем достаточно. Разумно распределить — дело протокола, главное что их точно с большим запасом хватит нашей планете.

Вопрос не про это. на время отложи в сторонку.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

SK>Что экономить? Какие вычисления производятся над ip адресами?

Да хотя бы поиск по адресам в памяти. 16 байт потребуют введения спец. типа или создавать процессоры в которых есть нейтивный 16-байтный тип а так же потребуют в 2 раза больше памяти для хранения. И это на всех уровнях, в т.ч. даже если вашей прикладной программе, не сетевой — есть черный список IP-адресов.

Притом что такая избыточность ничем не оправдана.

S>> При этом 8 байт хватит для триллиона людей + каждому по 16 млн. личных адресов, что более чем достаточно. Разумно распределить — дело протокола, главное что их точно с большим запасом хватит нашей планете.

SK>Вопрос не про это. на время отложи в сторонку.

И это тоже.

Здравствуйте, Shmj, Вы писали:

S>Напиши на C++ поиск по IP-адресам из черного списка. Сначала напиши для 8-байтных адресов (а это делается нейтивным типом), потом для 16 байт. Сравни скорость работы.
Угу по сравнению с заголовками HTTP и прочей байды типа мак адреса.
А ведь есть еще и тело сообщения! То по сравнению со всеми передаваемыми данными лишние 8 байт такая мелочь, зато удобно манипулировать 16 байтами не заморачиваясь на будущие хотелки и протоколы.

Здравствуйте, ononim, Вы писали:

O>Лет через сто человечество или вымрет или потребуется ipv7 с квантовыми адресами, создатели конечно заложат адресов с запасом

Лет через сто человечество окончательно одичает, и там будут строки в reverse DNS нотации. Да еще и локализованные по IDN. И нечувствительные к регистру символов, во всей своей локализации.

Вот тогда заживем!

Здравствуйте, Serginio1, Вы писали:

S>>Напиши на C++ поиск по IP-адресам из черного списка. Сначала напиши для 8-байтных адресов (а это делается нейтивным типом), потом для 16 байт. Сравни скорость работы.
S>Угу по сравнению с заголовками HTTP и прочей байды типа мак адреса.
S>А ведь есть еще и тело сообщения! То по сравнению со всеми передаваемыми данными лишние 8 байт такая мелочь, зато удобно манипулировать 16 байтами не заморачиваясь на будущие хотелки и протоколы.

IP-адреса участвуют в роутинге — их нужно хранить в таблицах с индексами, осуществлять поиск и т.д. А HTTP-заголовок — это просто данные.

Здравствуйте, Shmj, Вы писали:

S>>>Напиши на C++ поиск по IP-адресам из черного списка. Сначала напиши для 8-байтных адресов (а это делается нейтивным типом), потом для 16 байт. Сравни скорость работы.
S>>Угу по сравнению с заголовками HTTP и прочей байды типа мак адреса.
S>>А ведь есть еще и тело сообщения! То по сравнению со всеми передаваемыми данными лишние 8 байт такая мелочь, зато удобно манипулировать 16 байтами не заморачиваясь на будущие хотелки и протоколы.

S>IP-адреса участвуют в роутинге — их нужно хранить в таблицах с индексами, осуществлять поиск и т.д. А HTTP-заголовок — это просто данные.
Тебя так 8 байт волнуют? Хранение это вообще проблема?
Ладно бы там еще конец 20 го века, но сейчас ...
Ты бы лучше свою энергию в другое русло направил!

Здравствуйте, Serginio1, Вы писали:

S>Тебя так 8 байт волнуют? Хранение это вообще проблема?
S>Ладно бы там еще конец 20 го века, но сейчас ...
S> Ты бы лучше свою энергию в другое русло направил!

Главным образом — архитектура процессора. 8 байт — это 64 битный процессор. А 16 байт — это спец. архитектура, которая не совместима со стандартной и ее нужно делать отдельно только для обработки IP-адресов.

В стандартном С есть нейтивный тип 8 байт, но нет 16 байт — даже в С вам нужно городить структуру для IP + и операции с ней реализовывать на базе операций с 8-байтным типом.

Здравствуйте, Shmj, Вы писали:

SK>>Что экономить? Какие вычисления производятся над ip адресами?

S>Да хотя бы поиск по адресам в памяти.

Зачем поиск?

В процентном отношении как часто производится эта странная операция?

S> И это на всех уровнях, в т.ч. даже если вашей прикладной программе, не сетевой — есть черный список IP-адресов.

Зачем НЕ сетевой программе знать о каких-то ip адресах?

В процентном отношении как часто производится эта странная операция НЕ сетевой программой?

S>Притом что такая избыточность ничем не оправдана.

Эмоции убери в сторону. Избыточность ещё не доказана.

S>>> При этом 8 байт хватит для триллиона людей + каждому по 16 млн. личных адресов, что более чем достаточно. Разумно распределить — дело протокола, главное что их точно с большим запасом хватит нашей планете.

SK>>Вопрос не про это. на время отложи в сторонку.

S>И это тоже.

Давай для ясности, за один раз решать одну проблему. К этому вопросу вернемся позже.

Все проблемы от жадности и глупости

Здравствуйте, Stanislaw K, Вы писали:

SK>Зачем поиск?
SK>В процентном отношении как часто производится эта странная операция?

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

S>> И это на всех уровнях, в т.ч. даже если вашей прикладной программе, не сетевой — есть черный список IP-адресов.
SK>Зачем НЕ сетевой программе знать о каких-то ip адресах?

Хотя бы чтобы проверить по черному списку IP-адресов. Или для защиты от DDOS.