Как стать автором
Обновить

RIPE распределил последний блок /22 из последнего блока /8. Что дальше?

Время на прочтение 6 мин
Количество просмотров 27K
Всего голосов 35: ↑35 и ↓0 +35
Комментарии 86

Комментарии 86

НЛО прилетело и опубликовало эту надпись здесь
ipv6 access-list 1 deny ipv6 0000:: /0… oh, shi~
Надо 2000::/3
так там ещё штук 13 сетей /3
Они все reserved, использоваться вряд ли когда-либо будут, так же как в ipv4.
Напоминает ситуацию с биткоинами. Ну намайнили все 21 млн. Разве это конец жизни? Адреса же никуда не исчезают. Просто надо чуть более честно перераспределить. А IPv6 так и не нужен, как был не нужен 10 лет назад.
А сейчас они не честно распределены? И кто будет определять как должно быть?

Цена. Если, предположим, за адрес потребуется платить десять центов в год, министерство обороны дважды подумает, на самом ли деле им нужно 200 млн адресов или может им хватит 100 млн? А этих лишних 100 млн хватило бы на 20 лет при текущей скорости распределения.


Вопрос, кто и куда будет собирать деньги, опущу, просто отмечу, что распределение точно станет более равномерным — адреса будут попадать тем, кому они реально нужны и кто их использует.

тем более за индивидуальную внешку оконечные абоненты и так платят почти всегда. Вот, кстати, да, почему такая несправедливость… мы платим, а всякие Ксероксы, владеющие миллионами адресов, не платят никому эти самые миллионы баксов в месяц

Подумает… Ну да, мы с вами заплатим на 1% налога больше, чтобы они не думали.

А кому пойдут деньги? Райпу? Он работу будто бы и не делал лет 10 последние. Ну, кроме криков «все пропало, все кончается!»

Мы с вами? Во-первых, не знаю, почему вы решили, что я живу в США, но это не так. Во-вторых, бюджет согласуется через конгресс, министерство обороны напрямую налоги не собирает и не повышает. Хотят — покупают патроны. Хотят — платят за адреса. И не факт, что конгресс выделит им вообще на всё, что им хочется.


И есть другие организации — они тоже сами пусть решают, хотят платить за адреса или нет.


А деньги могут пойти, например, на внедрение IPv6, раз уж без него никак.

А IPv6 так и не нужен, как был не нужен 10 лет назад.

IPv6 нужен.

Откуда такая нелюбовь к ipv6? Оборудование один фиг обновляется не реже, чем раз в несколько лет. Все ОС уже давно его поддерживают. Вопрос сугубо в том, чтобы однажды всем заморочиться и всё настроить.

Уже писал где-то, повторю тут — он плохо спроектирован, избыточен, неудобен. Начиная с того что надо было додуматься выделить 128 бит под адрес, из которых 64 сразу выкинув в помойку, но свои лишние 16 байт в каждом пакете они будут занимать, и не только там. Есть и много других дефектов. В конце концов, он просто эстетически некрасив.

Что касается оборудования, то сейчас может работать (а где-то, уверен, и работает) в инете оборудование/софт, которому 25 лет. И, думаю, очень много где работает оборудование возраста 10-15 лет (закупленное во время активного проникновения интернета в массы). И очень плохо из-за выдуманной проблемы (нехватка адресов — именно такая, потому как их раздавали всем подряд бесплатно) взять и всё испортить.
ipv6 уже больше 20 лет, его поддержка в ОС появилась далеко не вчера. Для приложений не умеющих в ipv6 вы всегда можете оставить немного оборудования в дуалстеке/ipv4 only на местах локально, и внутри туннелей, более-менее новое клиентское оборудование точно вытянет, это провайдерам придётся заморачиватся с обновлением своего железа. А 64 бита не улетают в трубу, это всего лишь часть механизма автоконфигурации, да, возможно кто то считает что это избыточный объём.

А по поводу плохой архитектуры — это спорно, спроектирован он лучше чем ipv4, роутить это добро проще, кое что надстроенное для ipv4 имеется в нём из коробки. Единственное что изначально механизма NAT не предусмотрено ввиду его архитектуры, но при желании и его можно выстроить для каких то своих специфических целей.
Соглашусь, правда, с тем, что для привыкшего работать с ipv4 адресами адреса 6й версии выглядят не очень
Только одна переменная — приоритет протоколов — оказался заныкан далеко и глубоко. Я про то, что в dual stack варианте, если у хоста есть и A, и AAAA запись, на какой адрес сначала клиент пойдет — зависит от ОС клиента, а в ней зависит от настроек, и от версии к версии меняется дефолт.

На фоне ситуации, когда клиент просто не умеет проверить, напр., что ipv4 или ipv6, даже если имеется, но не работает (связности нет), имеем глюки вроде таймаутов и прочего — комп ждёт таймаута, а клиент-человек переживает паузу. В результате внедрять ipv6 в обычной жизни опасно, т.к. в случае проблем с ним часть клиентов будет все равно первым делом ломится на него, и будут испытывать паузы в работе.
НЛО прилетело и опубликовало эту надпись здесь
Нет. Я про другое: хотим внедрить IPv6. Провайдер говорит «у меня ipv6 есть, но в тесте» (и он прав, он сам предвидит грабли). Хорошо, настроили, работаем. При этом в сети, например, Windows 7, Windows 10, Mac-и, может, еще что-то, плюс смартфоны. Если начинаем проверять, каждый из клиентов в dual stack сети исповедует разный приоритет протоколов, и начинают стучаться кто на A, а кто на AAAA записи ресурсов, с которыми работают.

Но вот IPv6 почему-то глюканул, и трафик посредством его стал ходить медленно либо вообще не стал ходить. Или ресурс, куда заходили, временно поломался по IPv6. Идеально бы было, чтобы клиенты, которые сначала идут на IPv6, а потом, как fallback, на ipv4, постучались по «шестерке», не дождались, и начали работать в режиме IPv4 first в течении какого-то времени. Но нет, при каждом обращении в мир к хостам, которые имеют A и AAAA записи, соединение сначала будет пробовать устанавливаться по IPv6, а только по таймауту — по IPv4.

Это неприятно, а для пользователей выглядит и вовсе глупо: у части компов все работает (да-да, в ОС, где IPv4 first, согласно настрокам ОС), у части же — работает с дикими тормозами.
НЛО прилетело и опубликовало эту надпись здесь
В реальности — скорее это повод «не внедрять» лишнее. Увы.

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


А 64 бита не улетают в трубу, это всего лишь часть механизма автоконфигурации, да, возможно кто то считает что это избыточный объём.

80% оверхед в ip-заголовке ради автоконфигурации?


механизма NAT не предусмотрено

А если и не надо предусматривать (в IPv4 тоже никто специально не предусматривал вроде), он просто возможен.


Соглашусь, правда, с тем, что для привыкшего работать с ipv4 адресами адреса 6й версии выглядят не очень

А ещё они не влезают в машинное слово, в отличие от первых. Очень хорошо, когда избавились от legacy-протоколов типа IPX, можно делать IP4-only софт, и адреса хранить и обрабатывать как uint32 без каких-либо спец. обёрток. Кстати, про обёртки. Это не то что бы строгий огрех, но ipv6 адреса ещё не влезают в абстрактную struct sockaddr. Были бы 64-битными — влезали бы. А так получается что sizeof(struct sockaddr)==sizeof(struct sockaddr_in) — в обеих есть паддинг до нужного размера, а вот sizeof(sockaddr_in6)>sizeof(struct sockaddr). Выглядит тоже некрасиво.


ipv6 уже больше 20 лет, его поддержка в ОС появилась далеко не вчера.

И как итог: был бы он продуманный и удобный, его бы уже 10-15 лет назад везде внедрили и никому бы не создалось проблем. Но видимо что-то не так.

80% от чего, от заголовка? А если посчитать процент от полезных данных? Не одни же заголовки передаём. Капля в море…

Зачем IP-адресу влезать в машинное слово? Проблема встанет разве что на программном роутинге и т.п. нынче типичный размер кеш-линии процессора 64 байта, поэтому проблема производительности не очень актуальна в этом плане — процессор успеет обработать 4 адреса за одно чтение из памяти. Немного усложнится работа с адресами на низком уровне — но это лишь один раз написать библиотеку и проблемы больше нет. Это не постоянные грабли на которые надо будет наступать.

всё таки есть в ipv4 что-то тёплое, ламповое… поднял натик, одних в одну сеточку, других в другую, чувствуешь себя как в домике (да, да, я знаю, что домик дырявый, но мы же про психологию), всё своё, родное, просто и понятно (бывают исключения, но я про средние массы). А снаружи да хоть ipv666 — как-то там работает и ладно. Поэтому долго еще оно заходить в народ будет.
PS ярый сторонник ipv6, юзаю где только можно и нельзя, даже с туннелями в ущерб пингу… но давайте будем реалистами ))

Для меня ipv6 жутко неинтуитивен. Я никак не могу на глаз опередить принадлежность адреса к конкретному диапазону и тому подобное. Теперь ещё и проблема firewall. Я, кажется, накриворучил. Deny all после разрешающих правил отрубает к чертям Google с его сервисами. Медитативно ковыряюсь пока.
А чего не так с файрволом то? всё настраивается аналогично ipv4, разрешить форвард всех/определённых соединений на нужные сервера/роутеры напрямую и разрешить форвард для established,related соединений в «локальную» сеть, остальное deny.
У меня сейчас как-то так выглядит кусок с ipv6 firewall:

/ipv6 firewall filter
add action=drop chain=input connection-state=invalid
add action=accept chain=input connection-state=established,related in-interface=ISP_pppoe
add action=accept chain=input protocol=icmpv6
add action=accept chain=input dst-port=546 in-interface=ISP_pppoe protocol=udp
add action=drop chain=input
add action=accept chain=forward connection-state=established,related in-interface=ISP_pppoe out-interface=bridge-local
add action=accept chain=forward protocol=icmpv6
add action=accept chain=forward in-interface=!ISP_pppoe out-interface=ISP_pppoe
add action=drop chain=forward in-interface=!bridge-local
У меня попроще, долго мучался с выбором схемы, ибо помимо домашней /64 есть ещё /48 для подключения других точек при необходимости и в двух прошлых конфигах случалось так что 3 сети прекрасно ходят в глобальный ipv6, а вот друг к другу не очень, либо городил ещё с десяток лишних правил, в итоге остановился на такой конфигурации:
/ipv6 firewall filter
add action=accept chain=forward comment="allow all to 2001:470:1f0b:1658::2 from all" dst-address=2001:470:1f0b:1658::2/128 in-interface=sit1
add action=accept chain=forward comment="allow all to 2001:470:1f0b:1658::3 from all" dst-address=2001:470:1f0b:1658::3/128 in-interface=sit1
add action=accept chain=forward dst-address=2001:470:98fc:6::/64
add action=accept chain=forward dst-address=2001:470:98fc:6000::/52
add action=accept chain=forward comment="allow established/related" connection-state=established,related dst-address=2001:470:1f0b:1658::/64 in-interface=sit1
add action=drop chain=forward comment="drop all to local /64" dst-address=2001:470:1f0b:1658::/64 in-interface=sit1
add action=accept chain=forward comment="allow established/related" connection-state=established,related dst-address=2001:470:98fc::/48 in-interface=sit1
add action=drop chain=forward comment="drop all to local /64" dst-address=2001:470:98fc::/48 in-interface=sit1

В итоге под файрвол попадает только трафик приходящий из туннеля 6to4 (native не завезли к сожалению). Трафик с остальных подключений не попадает под него и маршрутизация между «локальными» сетями работает свободно. Единственное не проходит тест скорости на yandex.ru/internet на upload, но как оказалось то-же самое происходит при отключенном файрволе, видимо что-то сломалось на их стороне
6to4 к Hurricane Electric, поднимал просто скопировав из их шаблона
UPD: не из их, до этого был sit0 который 6to4 через 192.88.99.1, отказался из-за нестабильной работы, а HE остался sit1
Блин, твой конфиг весьма сложно понять. Ты по факту и так разрешаешь коннектиться извне кому угодно внутрь.
Просто у меня порезано на несколько сетей, основная домашняя 2001:470:1f0b:1658::/64, там только разрешён весь трафик на два сервера (::2/::3) и established/related.
Потом разрешено всё к 2001:470:98fc:6::/64 (сеть на даче) и разрешено всё к 2001:470:98fc:6000::/52 (пул для VPN подключений), там у меня как правило разруливает локальный роутер.
Ну и на последок accept established/related & drop для всей сети /48, мало-ли куда ещё выделю — чтобы не лезло ничего.
В интерфейсе WinBox оно как-то проще выглядит
image
P.S: да, забыл изначально для 6::/64 и 6000::/52 указать in-interface, да не особо важно
А вот держать открытыми в мир MySQL 5.7.22-0ubuntu0.16.04.1 на ::2 (он же «WEXTER-SRV0») и самбу на ::3 (он же WIN-H5D10T4ST0S) — все же не стоит, мало ли кто из интернета приползет.
А там ничего интересного и нету :)
А не факт что придут что-то забирать, могут наоборот подарков оставить…
Возможно, вам стоит обратить внимание на стандартный набор правил для ipv6 firewall в свежих версиях RouterOs. Они не появляются сами по себе при активации ipv6.
/system default-configuration print
Они вполне себе вменяемы и откомментированны.
IPv6 не решает проблему, а просто ее откладывает. Особенно с раздачей в /32 каждому провайдеру.

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

Можно сразу было бы срезать тонну обрубков с сетей как VLAN и другая адаптивность к реалиям. Интернет создавался эволюционно, но IPv6 это не переработка и планирование, а просто говно какое-то.

Ответ давно дан Bitcoin. Вместо IPv6 нужно использовать криптографические ключи. В замену соединений ip-port — уникальный канал, который является хешем других каналов и дополнительного nonce который постоянно обновляется с каждым пакетом (mitm защита). Транзакция на локе.

В замену всей лабуды с аукс системами, вроде dns, bgp, ospf — федеративный блокчейн, где токены являются разными сервисами.

По сути ответ у нас уже 10 лет перед глазами, но все ждут какого-то internet2.

Такой системой мы сразу убиваем возможность ddos (токенодаватель может выдавать конкретное количество пакетов и каналов для своей системы полностью нивелируя возможность ddos атаки, т.к. доступ будет съедать средства ддосера и передавать их токенодавателю), arp/mac/bgp poisoning (а нет больше мака — это теперь ключ, арпа (который заменен на прямую делегацию через ключи), бгп вообще по сути арп для l3 на уровне верхних подсетей со свистелками и перделками, которые приводят к bgp poisoning и другим проблемам).
Даже с /32, он откладывает проблему пусть и не до тепловой смерти Вселенной, но явно как минимум до расширения Солнца до орбиты Земли.

Блокчейн — это лишь медленная база данных, для адресации в интернете не подходит никак.
Блокчейн — это лишь медленная база данных, для адресации в интернете не подходит никак.


Ethereum блоки каждые 15 секунд кидает, есть вообще сабсекундные блокчейны, для адресации проблем с 15 секунд нет, тем более что с нашей системой мы можем поддерживать нативно мультиканалы с разным приоритетом полностью нивелируя переключения между провайдерами и рутерами.

Даже с /32, он откладывает проблему пусть и не до тепловой смерти Вселенной, но явно как минимум до расширения Солнца до орбиты Земли.

Ни черта он не откладывает, когда спамеры начнут забирать по тонне /32 каждый год

rednectar.net/2012/05/24/just-how-many-ipv6-addresses-are-there-really

К тому же у всего рутинга проблемы IPv6 не решает. Никто не знает, что будет когда будет 5 триллионов /64 (минимальный размер) делегирований в сети. Как рутеры с full bgp будут с этим дружить?
А блокчейн без гарантированного времени (точного) ответа — решает? Сабсекундные — это в идеальных условиях, интернет не всегда такой. Ну и выбирать между «спросить у всего блокчейна, куда роутить, и потерять секунды пинга» и «держать внутри каждого маломощного раутера все хэши» выглядит… странно.

> 5 триллионов /64

И когда они будут?

> спамеры начнут забирать по тонне /32 каждый год

Их 4 миллиарда. Если спаммеров будет сильно много — можно это регулировать централизованно.
Блокчейн решает, нам не надо все транзакции гнать через один единый блокчейн аля биткоин.

Я насколько вижу здесь нет специалистов по блокчейну. Открою Вам секрет. Блокчейн это не только классический лог Биткоина.

Вот например федеративный блокчейн — что это за зверь (ведь кто читал слово федеративный в моем тексте ни разу не задал вопрос)? У нас есть много малодецентрализованных нод, которые оперируют связностью между друг другом (пиры и их коннективити). Смысла каждому такому соединению писать в один единый блокчейн между миллионом нод не имеет смысла. Для этого мы разделяем state (channel — наш канал) и разбиваем блокчейн на смысловые блоки между каждыми L2 пирами, т.к. в нашем случае у нас авторитет вышестоящих провайдеров по распределению ресурсов, но нет авторитета на контент этих ресурсов! Для этого поднимается «мини»-блокчейн (т.к. абсолютного доверия рутинга у нас нет ни в локальном уровне ни в глобальном), где мы покупаем токены (неважно как, можно и через смарт контракт, можно в магазине, эмитент — апстрим), а наша сеть жгет их с каждым пакетом. Т.к. токены всего лишь запись в таблице, а не физически передаются с каждым пакетом — это никак не влияет на производительность.

Их 4 миллиарда. Если спаммеров будет сильно много — можно это регулировать централизованно.


Ага, столько же ipv4 было. И где мы теперь? Нарегулировались? Зарегал 100 фирм и получил 100 /32, тут же их закрыл, 1000 спаммеров так сделала и мы уже минус 100к подсетей, загадили подсети, пошли регать дальше. Особенно в странах где это бесплатно. Или в странах с коррумпированным устройством.
Если честно, то я совсем запутался. Допустим, есть умеющий в федеративные блокчейны роутер, есть пакет, в заголовке которого — один (1) хэш непонятно кого. Что роутер должен сделать, чтобы определить, что:

* этот пакет вообще валиден для конкретно него и его нужно роутить
* куда именно его роутить
* кого спросить, куда роутить, если сам роутер об этом не может быть в курсе по определению (он же не хранит 100% адресов внутри себя?!)

Какой безумный оверхэд появляется из-за того, что роутер даже в теории не может определить ничего полезного для своей основной задачи из заголовка пакета самостоятельно и вынужден каким-то образом консультироваться с распределённой (!!!) базой данных каждый раз, когда пропускает через себя пакет?

> Зарегал 100 фирм

Это не так дёшево и даёт не так много IPv6-адресов.
этот пакет вообще валиден для конкретно него и его нужно роутить


Это не его задача, а ендпоинтов (как впрочем и с v6).
* куда именно его роутить

Роутить куда он будет знать из блокчейна. Блокчейн будет работать не только по принципу PoW (не хрен жарить впустую), а по гибридному принципу PoS и PoW. Токены выпускаются на конкретный канал за счет «предпокупки» этих токенов апстримом у ендпоинта создателя канала, покупка производится инициализацией канала, когда сетевые интерфейсы обмениваются пакетами на максимальной скорости без ограничений не замедляя другие каналы.
Токены генерируются по принципу channel-packet/sec (дебаты, возможно что-то лучше? я это называю proof-of-bandwidth).
* кого спросить, куда роутить, если сам роутер об этом не может быть в курсе по определению (он же не хранит 100% адресов внутри себя?!)

Так что роутер знает только если у него есть доступ к ендпоинту и ресурсы для проведения операции.

Засчет этого канал прописывается далее в сети через каждый федеративный блокчейн в один глобальный (аналог bgp propagation, который может доходить до 30 минут, только в отличие от него, у нас есть конкретные каналы с конкретными ресурсами доступными внутри них). Федеративные блокчейны это локальный мемпул аналог local-bgp, глобальный блокчейн это лог каналов со снапшотами (чтобы не хранить гигабайты данных, мы храним только актуальные обновляющиеся каналы за время T -30сек, для сохранения чейна использовать снапшоты).

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

Это не так дёшево и даёт не так много IPv6-адресов.

Зарегать 100 фирм стоит 0 например у нас в стране. После этого получить одну площадку по знакомству на 100 фирм и два анонса проще пареной репы. Ждать пару дней после каждого запроса и получать себе 100 подсетей в течение года. Вполне реально. Сделать им налоговые потери и банкротить после этого. Вуаля — 100 подсетей.
И когда они будут?


FIB у большинства рутеров нашего времени рассчитан на 1млн в4 и 500-700к в6, не суммарно!
В 2019-2020 году многие рутеры уже будут плакать и требовать замены.
bgphelp.com/2017/01/01/bgpsize

Если рост продолжиться, то к 2030 году мы опять столкнемся с проблемой рут таблиц, только уже более тяжелого v6

Кажется, вы ни в том, ни в том не разобрались.

Прекрасно разбираюсь и в том и в другом. Есть аргументы? Вперед!
Давайте не будем, чтобы вам и мне не было стыдно перечитывать этот тред год спустя. Вы смешиваете теплое и мягкое, это никогда к добру не вело.

Судя по минусам вашему комменту выше, идея блокчейна (бд, где элементы подтверждают истинность предыдущих) вам полностью затмила простой вопрос: как передать данные от точки А в Америке в точку Б в Европе через промежуточные хопы, в мире, где число хостов растет, и где все ежесекундно меняется. Хоть токены, хоть что вы в блокчейна положите — на роутинг это не может повлиять в лучшую сторону. Не говоря, что для передачи нужны пары адресов: от кого и кому, а где они в вашей идее?

Либо, если вы прямо видите гениальность вашей идеи, напишите пост. Лично обещаю поставить плюс, если будет понятно и по делу. А если придумаете, как на существующей инфраструктуре интернета разом ввести ваше новое, то цены посту вообще не будет.
Либо, если вы прямо видите гениальность вашей идеи, напишите пост. Лично обещаю поставить плюс, если будет понятно и по делу. А если придумаете, как на существующей инфраструктуре интернета разом ввести ваше новое, то цены посту вообще не будет.


Я пытаюсь подбросить идею, а не описать ее. К сожалению, с семьей тяжело сконцентрироваться на хобби. Писать то пишу, но идет медленно.

Судя по минусам вашему комменту выше, идея блокчейна (бд, где элементы подтверждают истинность предыдущих) вам полностью затмила простой вопрос: как передать данные от точки А в Америке в точку Б в Европе через промежуточные хопы, в мире, где число хостов растет, и где все ежесекундно меняется. Хоть токены, хоть что вы в блокчейна положите — на роутинг это не может повлиять в лучшую сторону. Не говоря, что для передачи нужны пары адресов: от кого и кому, а где они в вашей идее?


Ок попробую разъяснить для чего федеративный блокчейн и токены. Я не предлагаю использовать текущую сеть например перегруженного этереума или же перегруженного биткоина или даже свободного биткоин кеша. Эти сети предназначены для другого.

У нас не свободная сеть, у нас сеть с единым авторитетом, т.к. мы соединены с реальным миром напрямую (интерфейсы и кабели).

В локальной сети сохранить безопасность сети и упростить пакеты в старые времена было сложно. Именно поэтому мы используем названия с повторениями в реальной жизни и используем тонну сопутствующей информации для адресации и все равно допускаем ошибки (почта). Интернет (арпанет) писался по принципу и подобию. Соответственно сначала была сделан статическая связность с единым авторитетом рутинга. Как выяснилось с множеством агентов (разворот на интернет) это не было скалируемым решением. Началась работа над CIDR и сопутствующим протоколом BGP.

Факт есть факт, никто не думал в то время об адресации через криптографические хеши и ключи.

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

IPv6 является хорошим изменением по сути, но это изменение, а не пересмотр всей системы. Очень уменьшили пакет. Перекинули фрагментирование и чексамминг на endpointы. Но опять же source и destination адресы.

Распределение IPv6 осталось в прошлом и по сути повторяет IPv4, только теперь вместо одного IP мы даем подсеть, пущай все будет в WAN!

NDP запутанный протокол, который посути не решает проблем, которые должен был решить (и не надо мне про экспериментальщины с костылями из крипты поверх NDP).

Короче говоря имхо — полный провал.

Начнем с L2. Что нам нужно? Безопасность локальной сети. Она должна быть доступна только администратору и никому другому. У нас нет доверия endpointам.

Решение очевидно!
Вот этот унитаз: en.wikipedia.org/wiki/File:Ipv6_header.svg
выбрасываем.
Уменьшаем хедеры с 320 бит до 160бит (да да, до длины одного хеша)
Хешируем мы ident (зашифрованный публичным ключом рутера уникальный код системы, например MAC (но его желательно расширить с 48бит, он более не используется нигде у нас)), нонс. Т.к. рутер должен знать о новом ендпоинте, то вопрос идентификации и гашения канала решается легко и быстро: Не понял? Выключил.
Это замена статической аутентификации ендпоинта. Можно еще и шифрование данных добавить.
Не обязательно использовать RSA, Ed25519 и другую ассиметрячину, можно использовать и HMAC и другие симметричные алгоритмы шифрования, но в принципе это можно модулировать и изменять программированием типов шифрования до подключения (аля выбор сейчас статика, слаак, дхцп6 и т.п.) в соответствии с настройками рутера. Чем меньше знаний о рутере у конечной точки, тем меньше вероятность взлома.
Наш хедер стал «каналом» подключения к рутеру.

Такой схемой безопасность LAN становиться полноценной. В такой конфигурации нам не надо прятаться за VLAN, т.к. каждая система является ограниченной шифрованием данных внутри пакетов после хедера. Это не отбирает у нас возможность отобрать или дать L2 соседство у хостов, LAN определяется доступом к каналу, только главный рутер знает какие ноды общаются с кем, к нему обращаются за доступом к сети и ендпоинты и все посередные рутеры и свитчи. Но самое интересное, что главный рутер не может расшифровать траффик если это необходимо, т.к. рутеры оперируют только каналами и ключами теперь.

Это только L2. Статья с картинками будет позже.

Как Вы понимаете L3 намного сложнее, нам нужно заменить легко обнаружаемые порты на директ каналы и разработать протокол обмена токенов для поддержания обмена данными в пределах выставленных лимитов ендпоинтом, а не промежуточными системами, для этого и нужен федеративный блокчейн (федеративный, потому что между двумя или несколькими нодами как в текущей системе AS, блокчейн, т.к. больше нет портов и ACL, т.к. мы не знаем конечный пункт и начальный, мы оперируем каналами, может ли канал пропустить 500гб в течение 1 секунды или нет знает только ендпоинт, к которому отослан запрос и от которого отправлен). Главной проблемой я вижу бутстраппинг безопасности, ибо нам нужно получить честный первоначальный блок. В текущей схеме этим занимается ОС и браузеры, которые получают корневые сертификаты при установке. В нашей схеме генезис блок должен идти в поставке с ОС.

P.S.:
бд, где элементы подтверждают истинность предыдущих


Это не БД! А лог.

Я за последние 1.5 месяца побывал в 3-х странах: Вьетнам, Камбоджа, Лаос. Это не самые экономически развитые и сильные в IT страны. Тем не менее, едва ли не в каждой забегаловке мой ноутбук и телефон получают IPv6 адрес, и обращаются к сайтам по IPv6.


Что мешает всем остальным наконец перейти, если даже в Камбодже и Лаосе уже перешли на IPv6?..

Великая сила легаси. Чем раньше у вас появляется интернет, тем он у вас хуже, потому что никто не может или не хочет вкладывать там много денег с интернет-коммуникации.
Скорее дело в ARPU и росте мобильных пользователей.
США всегда были королями legacy, однако по внедрение IPv6 они на первых местах.
В Камбодже и Лаосе не переходили на ipv6. Там не с чего было переходить. Они просто так с самого начала поставили.

В России, например, инфраструктура с момента появления IPv6 менялась несколько раз, уверен в этом (IPv6 появился 22 года назад, черновики на несколько лет раньше, сомневаюсь, что где-то до сих пор работают роутеры, свитчи, и прочее оборудование, сделанное 22 года назад). Тем не менее, до сих пор с IPv6 в России не сталкивался ни разу.

Ну, если быть честным, внедрение идёт. Но очень-очень медленно. Например, московский Ростелеком в некоторых районах уже даёт ipv6 подсеть /56. Но не гарантирует работу, выделенная подсеть может измениться в любой момент.

Инфраструктура обычно не меняется сразу вся. Она меняется по отдельным частям. И каждая новая часть должна быть совместима со всеми остальными. Даже по глюкам.
Карта распределения ipv6 порадовала. Посмотрел на неё — заметил одинокую белую точку. На всякий случай потёр экран в этом месте — оказалась пылинка прилипла.
GlobalSign_admin, предлагаю в конец статьи дописать:

Я знаю, что ты сейчас сделал, хабраюзер
Заголовок спойлера
Протёр монитор?

+100500

Лайфхак для ленивых: чтобы понять, является ли точка грязью на экране и не тянуться тереть экран, достаточно немного покрутить колесо скроллинга мыши.
НЛО прилетело и опубликовало эту надпись здесь
Вспомнилось:
— Вот этого, этого и этого расстрелять! Запиши их в список!
— Я не хочу!
— Ну, раз не хочет, вычеркивай этого из списка расстреливаемых!

Мне кажется, что никто особо мнения райпа не спросит, скажут, что все адреса прям очень нужны — а райпу и крыть-то будет нечем.

И будет, как в известном кино:
— Вы арестованы!
— А пистолетик-то есть?
— Тогда — задержаны!
Да неужели они хоть слово скажут хоть кому-то, кто уже владеет сетью? Особенно — крупной.

У RIPE вообще есть процедура отзыва адресов, которые не используются по назначению (или вообще не используются)?

Что характерно, норма, что BGP «маленькие» (меньше /24, а иные одаренные и крупнее размер «мелким» называет) сети фильтрует, создала такой вот геморой. Когда компании нужно было, скажем, десяток PI адресов, приходилось покупать /24, а то и /23, анонсируя их как две /24, чтобы разные сервисы на разные каналы приорететно развесить. И мы все дружно писали райпу в анкетах про сотни рабочих станций и сотни же VPN-юзеров, а они так же серьезно это глотали, помните?

С такой раздачей об экономии можно было не заикаться. Сегодня принять правила, обязывающие не фильтровать до /29 (например), и методы решения для тех, у кого BGP поднят на устройствах с небольшим числом ресурсов — и можно было бы тогда попробовать выкупать или как-то выманивать назад адреса, только пряник должен быть продуманным…
Это ещё раз подтверждает ненужность IPv6. Если кому-то памяти не хватает на приём /29 аноносов (а кто-то и /24 не принимал, пока это не стало критичным), то от включения IPv6 её количество не увеличится само собой. А если её увеличить (всем) и принимать тот же /29, то адресов вдруг станет надолго хватать и без IPv6.
Не хватит: никто из владельцев не отдаст даже /29.

Я видел провайдеров, у которых даже откровенные точка-точка сети были сделаны на публичных адресах, и с приличным запасом — им, может, можно было бы дизайн сети сменить и отдать часть освободившегося, но кто же это сделает?!

Другой пример: есть офис, в котором 20 ПК и 2 сервера. На них всех /24 сеть. Зато в правилах брандмауэра прописали /24 — и все. А можно было бы сделать красиво, выделить на 22 хоста сеть /27, остальное под другие цели направить… Ага, ищите дураков, ломать то, что уже настроено!

RIPE не имеет процедуры отнимания адресов даже у тех, кто за них годами не платит (может, уже и придумали, но было так), а уж как они у компании размером с AT&T или MS (понятно, что это не в епархии райпа, но я про размер) попросят добровольно отдать ненужные адреса — хочется посмотреть.

Я бы раз был увидеть IPv6 в работе, но их и правда широко раздают, так что хватит (если и когда начнут серьезно использовать) не факт что на десятилетия.
Мегафон/РТК по всей россии на точки выдаёт по /30 (в паре регионов выдавал /29 или /28, но это прям редкость), точек порядка 200+, что выходит в 800 белых адресов на 200 точек… и это при том что в одном регионе около 30 сетей идут друг за другом, видимо им проще выдать 30 сетей /30, чем отдать одну /26 с запасом

Так проблема в процедуре возврата адресов. Интересно, почему ей не занимаются. Внедрять IPv6 проще?

Нет, просто инструментов нет. Ещё один комитет (средство коллективной безответственности), что они могут сделать-то?

Сегодня принять правила, обязывающие не фильтровать до /29

Тогда ляжет половина интернета.
И мы все дружно писали райпу в анкетах про сотни рабочих станций и сотни же VPN-юзеров, а они так же серьезно это глотали, помните?

По-моему это давно прикрыли, но сейчас можно выдумать приватное облако.
Так вопрос не в том, что писать, а в том, что райп прямо подводит к мысли писать чушь, если написать правду: «мне нужна сеть /23, чтобы по-разному анонситься на двух моих аплинков, имея в сети 20 хостов и 2 сервера», ответят «мало оснований выдать /23», при этом кто там рекомендовал фильтровать сети короче /24?

А писать про облако — та же чушь, как про 200 VPN-юзеров: зачем серверам в приватном облаке вообще белые адреса? Адреса нужны на балансировщике, а облачные сервера лучше спрятать в приватную сетку. Но — прокатывает же!

Райп вообще любит отписываться по формальным причинам (читай «у вас помарка в анкете»), т.к. типа они чем-то заняты, а как они могут диктовать схему сети, которую строит конечник?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Для начала, мне идея сделать все на новом протоколе нравится.
Но вот сейчас точка такова, что и вперед тяжело, и назад сложно. И так, и так придется менять кучу железок. Только вера в то, что «мы заменим не старой циске софт, и она будет уметь IPv6» — это тоже неправда, т.к. «железно» она его не будет уметь, а что такое гонять все это на процах — мы все знаем. Будем объективны, вложений в приход IPv6 предстоит ещё много.
Но вот разумная мысль: если мы «настрогали» в нем адресов аж /128, но решили, что мы режем их по /64, то все равно менее, чем /64, но все же много префиксов нам надо как-то в голове устройств уложить. Если старые циски стонут от числа просто даже всех /24 префиксов (от того и фильтровали менее /23, а особо ограниченные ресурсами — и того меньше), то от «меньше, чем /64» префиксов нового протокола они никак не обрадуются.
А с v6 все плохо еще и потому, что его никто не просит у провайдеров, провайдеры его не внедряют (а зачем?), сайтам он не так и нужен. И все кивают на остальные части этой формулы: сайты говорят, что зачем им лишние сложности с безопасностью, если все равно протокол не массовый, юзерам по больше части пофиг, а провайдеры откровенно даже боятся внедрять: лишний геморой, проблемы с биллингом, шейпингом, непонятно, как клиенты будут его настраивать, и как им помогать при проблемах с IPv6.
Да вы и сами знаете.
НЛО прилетело и опубликовало эту надпись здесь
Вне тему ipv6, ваша фраза про (сокращаю):
люди в Яндексе… ориентируются… на то, что делают в Google

вообще хорошо описывает мое личное восприятие того, что делает Я. На самом деле, наверное, и не так, но — «выглядит-то оно именно таким образом».
Другими словами, если бы не Г, Я бы про шестерку не думал бы?
НЛО прилетело и опубликовало эту надпись здесь

Да, именно так. Хотя ipv6-only ДЦ — он того стоил, или это просто "because we can"?


Я под ДЦ рисую себе большое здание с серверами, но это может быть и неправдой, конечно.


А с v6 — в той же Америке провайдеры исповедуют раздачу клиентам только ipv6, и строят nat на пути трафика в мир ipv4, гемора масса, но у них зато процент проникновения высок.

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Вы будете удивлены, но 44.0.0.0/8 по факту используется. Роутится в интернет правда весьма ограничено.
В данной сети почти нет живых адресов. Большая часть сайтов из данной сети лежит по адресу 44.0.0.1. Недавно пробовал получить у них адрес, в ответ получил отказ под предлогом того, что в России запрещён VPN, а с настройкой ip-тоннелей они разобраться не смогли, говорят что работают не стабильно у них.
Свяжитесь с админами dstar.su — они вполне успешно использовали эти адреса для нескольких радиолюбительских проектов, сейчас оно вроде работает на них же.
В Беларуси тотальный NAT к которому все привыкли. Собственно, оно видно по IPv6 распространению и приобретению IPv4 (зачем распылять силы и средства на IPv4 или IPv6, когда есть резиновый NAT).
У моего провайдера в РБ 2 варианта подключения, ipoe и l2tp туннель. Так вот, на ipoe белый ip придётся покупать, на l2tp — он белый всегда. А если подключатся не по доменному имени к l2tp серверу а по ip к конкретному (там штук 16 серверов в локальной сети) — так у тебя ещё будет псевдо статический, теоретически сменится может в любой момент — но если промежутки короткие (только переподключение когда оборвался l2tp туннель) почти без шансов его упустить:)
Это всё танцы с бубном. По факту, самые крупные провайдеры что МТС, что Velcom-Атлант, что Белтелеком как сидели так и будут сидеть со своим NAT пока это будет возможно.

Правила по сути сказали: просто так не даём, но если вы фиктивно себя запишите LIR-ом...


Несколько лет назад (давно, до дефицита ещё) в поисках того, у кого купить pi подсеть, я обзвонил и обписал половину российских lir-ов. Все ответили: да, мы lir-ы, но адреса продавать не умеем/не хотим, так что звоните другим. А это, на минутку, была их обязанность. Райпу тогда было удобно на это закрывать глаза, и сегодня закрывают. Разница для них — больше lir-ом и больше отчислений, но и всё, всем понятно, что речь о фикции.


Сколько там сегодня стоит lir-а завести себе?

Почему айпишек не 999.999.999.999 или больше?
связано с тем, что ipv4 адрес — 32 бита информации
11111111.11111111.11111111.11111111 = 255.255.255.255
ipv6 — 128 бит, адресов соответственно больше
Зарегистрируйтесь на Хабре , чтобы оставить комментарий