Распределение IP-адресов в 185/8, последнем свободном блоке RIPE, в 2012 году (слева) и 2018 году (справа), источник

17 апреля 2018 года Сетевой координационный центр RIPE — одна из пяти Региональных регистратур — распределил последние 1024 адресов IPv4 из последнего блока /8, полученного от IANA в 2011 году. Хотя последний блок 185/8 полностью распределён между европейскими компаниями, но в пуле RIPE NCC осталось 9 млн «восстановленных» адресов (то есть адресов, изъятых у бывших владельцев). По расчётам Координационного центра, этого хватит ещё примерно на два года, если выдавать по заявкам локальных регистраторов по /22 каждому.

На данный момент каждый адрес IPv4 — исключительно дефицитный товар, а последние выделенные IP-адреса используются очень интенсивно. Поэтому особенно неприятны ситуации вроде нынешней массовой блокировки IP-адресов в России. На пике блокировки 18 млн заблокированных Роскомнадзором IP-адресов соответствовали 5,5 млн заблокированных доменов — это около 2,45% из 223 млн известных доменов в интернете.

К счастью, сейчас российский регулятор постепенно снимает блокаду. Сейчас в блокировке осталось лишь 14,6 млн адресов по статистике бота RKNSHOWTIME или 14,7 млн по статистике другого сервиса RKN block digest. Разница связана с тем, в первом случае считаются только явно указанные IP-адреса, а во втором — и IP-адреса, и домены (некоторые записи в выгрузке Роскомнадзора содержат только название домена).

Как распределялся последний блок /8


Когда RIPE NCC получил последний /8 (блок 185/8, 16 777 216 адресов), в пуле RIPE оставалось около 75 млн адресов, так что они продолжали свободно распределяться по заявкам локальных регистраторов (LIR). Но в сентябре 2012 года единственным свободным блоком остался 185/8 — и тогда вступил в действие раздел 5.6 Политики распределения адресов IPv4 в европейском регионе. Эти правила специально приняли, когда стало понятно, что дефицита адресов не избежать.

Правила распределяют дефицитный ресурс в ограниченных количествах (по одному блоку каждому локальному регистратору). По итогу можно сказать, что правила очень помогли. Последний блок /8 растянули на 5,5 лет, в то время как предыдущий блок /8 по старым правилам раздали за пять месяцев.

Ниже приводим раздел 5.6 из новых правил в некотором сокращении. В частности, мы сократили часть по выделению адресов точкам обмена трафиком, для которых зарезервировали один диапазон /16 (65 536 адресов). Он распределяется блоками от /24 до /22, то есть от 256 до 1024 адресов.
5.6 Использование последнего блока /8 (Use of last /8 for PA Allocations)

Когда RIPE NCC начнёт выделять блоки адресов IPv4 из последнего блока /8, полученного от IANA, будет применяться политика, изложенная ниже.

  1. Выделение блоков для LIR из последнего /8.

    Порядок удовлетворения заявок LIR на адреса IPv4 следующий:

    1. LIR может получить только один блок из последнего блока /8. Размер блока — /22.
    2. LIR получит только один блок /22, даже если потребность в адресах намного выше.
    3. LIR может запросить этот блок и получить его в соответствии с политикой распределения адресного пространства, которая действовала на момент запроса.
    4. Блоки IPv4 будет выданы только тем LIR'ам, которые получили адреса IPv6 от вышестоящего локального регистратора (upstream LIR) или от RIPE NCC.
  2. Выделение точкам обмена трафиком (Internet Exchange Point).
  3. Непредвиденные обстоятельства (Unforeseen circumstances).
    1. Блок /16 будет зарезервирован для будущих непредвиденных целей. Если таковых не окажется, то к моменту, когда последний /8 будет израсходован, этот блок будет распределен в соответствии с п. 1.
  4. Повторное использование адресов (Post-depletion Address Recycling)

    Данные положения касаются только адресного пространства, возвращённого в RIPE NCC и не подлежащего возврату в IANA.
    1. Любое адресное пространство, возвращённое в RIPE NCC, будет распределяться по правилам, описанным в части 1.
    2. Минимальный размер блока, выделяемого из последнего /8, может быть при необходимости изменён.
  5. Если адресов для выделения блока /22 будет недостаточно, адреса будут выделены несколькими блоками (multiple allocations), но в количестве, эквивалентном /22.

Итак, в течение пяти с половиной лет RIPE NCC выделял блоки /22 из последнего /8 по этим правилам, за исключением двух блоков /16, зарезервированных для непредвиденных обстоятельств и для точек обмена трафиком.

Суть новых правил в том, что независимо от потребностей локальных регистраторов им выдавали только по 1024 адреса, то есть только по одному блоку /22 — и только когда они уже получили блок IPv6. Тем не менее, по статистике за 2012?2018 годы, скорость выделения адресов IPv4 в Европе росла в соответствии с квадратичной функцией. RIPE NCC объясняет это тем, что регистрировалось всё больше и больше локальных регистраторов.


Этот рост регистраций RIPE NCC использует для прогноза по распределению остатков адресов IPv4

Сетевой координационный центр отметил увеличение количества регистраций в качестве членов RIPE NCC организаций, которые сами не распределяют адреса, а обслуживают конечных пользователей. По мнению специалистов, для организаций членство в RIPE NCC оказалось наиболее дешёвым способом раздобыть дополнительные адреса IPv4 для собственной инфраструктуры.

Оказалось также, что стимулы к переходу на IPv6 тоже не работают. Большинство организаций, которые зарегистрировали диапазоны IPv6-адресов перед получением блока IPv4, никак их не использовали. Более того, чтобы избежать бесполезной траты адресного пространства IPv6, в марте 2015 года RIPE вообще убрал требование об обязательной регистрации блока IPv6.

В ноябре 2015 года RIPE запретил регистрацию дополнительных локальных регистраторов членами RIPE NCC, но это тоже не помогло, так что в мае 2016 года ограничение сняли. К этому моменту организации начали регистрировать новые юридические лица, чтобы получить дефицитные блоки /22. Как сообщается, некий член RIPE NCC сумел получить 66 блоков /22, хотя выдавали только по одному на каждого локального регистритора. Ограничение сняли, потому что решили, что лучше пусть организации воспользуются легальной лазейкой в действующие процедуре, а не будут искать обходные пути.

Вот как распределились дефицитные ресурсы по странам (файл статистики). Для упрощения цифры на карте округлены до /22, хотя многие блоки разбивались на /23 и /24.



На карте можно заметить некоторые аномалии: например, необычно мало блоков выделено организациям из Бельгии, Португалии и Беларуси, по сравнению с их более «предприимчивыми» соседями.

Только к 2015 году специалисты RIPE NCC осознали, что большое количество блоков /22 сразу после выделения меняют своего владельца и в течение нескольких дней или недель переходят к другому регистратору (transfer). Тогда регулятор запретил трансферы для адресов IPv4 до истечения 24 месяцев после выделения. Но судя по графику ежемесячных трансферов, это тоже не помогло, просто на два года заморозило трансферы свежих диапазонов.



Когда закончатся последние адреса IPv4?


Как уже упоминалось, в пуле RIPE NCC осталось около 9,03 млн адресов IPv4, которых хватит ещё примерно на два года. Из них четыре миллиона — это 1/5 от 20 млн адресов, которые восстановила IANA (Администрация адресного пространства Интернет) и раздала пяти региональным регистратурам в течение последних четырёх лет. Ещё 5 млн адресов RIPE забрал самостоятельно, проведя «перекличку» организаций. По условиям процедуры, если отклика от владельца не было получено, то IP-адреса у него изымались.

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

Если экстраполировать график, то нынешнего пула хватит примерно до мая 2020 года.

Предложения по купле-продаже или аренде IPv4 обсуждаются на форумах провайдеров и на Хабре. Судя по всему, сдача в аренду адресов IPv4 превратилась в неплохой бизнес.

Утилизация IPv4 и IPv6


Очень многие организации зарегистрировали на себя огромные по нынешним временам диапазоны IPv4, которые практически не используют и не собираются отдавать (например, 16,8 млн адресов в блоке 44.0.0.0/8, зарегистрированных якобы для любительского радио, или 218 млн IP-адресов у Министерства обороны США: 11.0.0.0/8, 22.0.0.0/8, 26.0.0.0/8, 28.0.0.0/8, 29.0.0.0/8, 30.0.0.0/8 и 33.0.0.0/8 ).

Другие блоки используются очень интенсивно. Например, визуализация кривыми Гильберта хорошо показывает, как распределено адресное пространство из примерно 4,2 млрд (2??) адресов.


Распределение адресного пространства IPv4, апрель 2018 года (кликабельна)

Для сравнения, вот как выглядит на сегодняшний день распределение адресного пространства IPv6.


Распределение адресного пространства IPv6, апрель 2018 года

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


  1. reversecode
    07.05.2018 12:07
    +1

    Страшный сон РКН блокировки ipv6…


    1. SergeyMax
      07.05.2018 14:12
      -1

      ipv6 access-list 1 deny ipv6 0000:: /0… oh, shi~


      1. gx2
        07.05.2018 17:08

        Надо 2000::/3


        1. Wexter
          07.05.2018 17:09

          так там ещё штук 13 сетей /3


          1. gx2
            07.05.2018 17:21

            Они все reserved, использоваться вряд ли когда-либо будут, так же как в ipv4.


  1. mspain
    07.05.2018 12:08
    -1

    Напоминает ситуацию с биткоинами. Ну намайнили все 21 млн. Разве это конец жизни? Адреса же никуда не исчезают. Просто надо чуть более честно перераспределить. А IPv6 так и не нужен, как был не нужен 10 лет назад.


    1. Gansterito
      07.05.2018 12:22
      +2

      А сейчас они не честно распределены? И кто будет определять как должно быть?


      1. Hardcoin
        07.05.2018 13:09
        +1

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


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


        1. Marwin
          07.05.2018 13:24

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


        1. achekalin
          08.05.2018 00:44

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

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


          1. Hardcoin
            08.05.2018 09:07
            +1

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


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


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


    1. Bonio
      07.05.2018 15:00

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

      IPv6 нужен.


    1. KivApple
      07.05.2018 17:40

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


      1. firk
        07.05.2018 17:58
        -2

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

        Что касается оборудования, то сейчас может работать (а где-то, уверен, и работает) в инете оборудование/софт, которому 25 лет. И, думаю, очень много где работает оборудование возраста 10-15 лет (закупленное во время активного проникновения интернета в массы). И очень плохо из-за выдуманной проблемы (нехватка адресов — именно такая, потому как их раздавали всем подряд бесплатно) взять и всё испортить.


        1. Aelliari
          07.05.2018 19:12

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

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


          1. achekalin
            08.05.2018 00:40

            Только одна переменная — приоритет протоколов — оказался заныкан далеко и глубоко. Я про то, что в dual stack варианте, если у хоста есть и A, и AAAA запись, на какой адрес сначала клиент пойдет — зависит от ОС клиента, а в ней зависит от настроек, и от версии к версии меняется дефолт.

            На фоне ситуации, когда клиент просто не умеет проверить, напр., что ipv4 или ipv6, даже если имеется, но не работает (связности нет), имеем глюки вроде таймаутов и прочего — комп ждёт таймаута, а клиент-человек переживает паузу. В результате внедрять ipv6 в обычной жизни опасно, т.к. в случае проблем с ним часть клиентов будет все равно первым делом ломится на него, и будут испытывать паузы в работе.


            1. ivlad
              08.05.2018 09:55

              На фоне ситуации, когда клиент просто не умеет проверить, напр., что ipv4 или ipv6, даже если имеется, но не работает (связности нет), имеем глюки вроде таймаутов и прочего

              Вы посмотрели, какие таймауты у happy eyeballs, правда?


              1. achekalin
                08.05.2018 10:04

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

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

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


                1. ivlad
                  08.05.2018 10:08

                  Идеально бы было, чтобы клиенты, которые сначала идут на IPv6, а потом, как fallback, на ipv4, постучались по «шестерке», не дождались, и начали работать в режиме IPv4 first в течении какого-то времени.

                  Возможно. А возможно, это способ заставить сетевых инженеров провайдеров быстрее чинить IPv6 связанность.


                  1. achekalin
                    08.05.2018 10:24

                    В реальности — скорее это повод «не внедрять» лишнее. Увы.


          1. firk
            08.05.2018 14:13

            Приложения не умеющие 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 лет назад везде внедрили и никому бы не создалось проблем. Но видимо что-то не так.


            1. Alexeyslav
              08.05.2018 15:11

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

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


  1. Marwin
    07.05.2018 12:19

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


    1. Meklon
      07.05.2018 12:32

      Для меня ipv6 жутко неинтуитивен. Я никак не могу на глаз опередить принадлежность адреса к конкретному диапазону и тому подобное. Теперь ещё и проблема firewall. Я, кажется, накриворучил. Deny all после разрешающих правил отрубает к чертям Google с его сервисами. Медитативно ковыряюсь пока.


      1. Wexter
        07.05.2018 14:20

        А чего не так с файрволом то? всё настраивается аналогично ipv4, разрешить форвард всех/определённых соединений на нужные сервера/роутеры напрямую и разрешить форвард для established,related соединений в «локальную» сеть, остальное deny.


        1. Meklon
          07.05.2018 15:23

          У меня сейчас как-то так выглядит кусок с 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


          1. Wexter
            07.05.2018 15:30

            У меня попроще, долго мучался с выбором схемы, ибо помимо домашней /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, но как оказалось то-же самое происходит при отключенном файрволе, видимо что-то сломалось на их стороне


            1. Meklon
              07.05.2018 15:33

              У меня тоже не нативный, а от Hurricane Electric. sit1 — это что за интерфейс?


              1. Wexter
                07.05.2018 15:34

                6to4 к Hurricane Electric, поднимал просто скопировав из их шаблона
                UPD: не из их, до этого был sit0 который 6to4 через 192.88.99.1, отказался из-за нестабильной работы, а HE остался sit1


                1. Meklon
                  07.05.2018 15:37

                  Блин, твой конфиг весьма сложно понять. Ты по факту и так разрешаешь коннектиться извне кому угодно внутрь.


                  1. Wexter
                    07.05.2018 15:46

                    Просто у меня порезано на несколько сетей, основная домашняя 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, да не особо важно


                    1. kornerz
                      07.05.2018 21:12

                      А вот держать открытыми в мир MySQL 5.7.22-0ubuntu0.16.04.1 на ::2 (он же «WEXTER-SRV0») и самбу на ::3 (он же WIN-H5D10T4ST0S) — все же не стоит, мало ли кто из интернета приползет.


                      1. Wexter
                        07.05.2018 21:13

                        А там ничего интересного и нету :)


                        1. Alexeyslav
                          08.05.2018 10:18

                          А не факт что придут что-то забирать, могут наоборот подарков оставить…


          1. Cayp
            08.05.2018 11:33

            Возможно, вам стоит обратить внимание на стандартный набор правил для ipv6 firewall в свежих версиях RouterOs. Они не появляются сами по себе при активации ipv6.
            /system default-configuration print
            Они вполне себе вменяемы и откомментированны.


  1. equand
    07.05.2018 12:24
    -1

    IPv6 не решает проблему, а просто ее откладывает. Особенно с раздачей в /32 каждому провайдеру.

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

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

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

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

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

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


    1. 3al
      07.05.2018 12:40
      +4

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

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


      1. equand
        07.05.2018 12:53

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


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

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

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

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

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


        1. 3al
          08.05.2018 07:22
          +1

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

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

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

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

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


          1. equand
            08.05.2018 13:15

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

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

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

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


            Ага, столько же ipv4 было. И где мы теперь? Нарегулировались? Зарегал 100 фирм и получил 100 /32, тут же их закрыл, 1000 спаммеров так сделала и мы уже минус 100к подсетей, загадили подсети, пошли регать дальше. Особенно в странах где это бесплатно. Или в странах с коррумпированным устройством.


            1. 3al
              08.05.2018 14:51

              Если честно, то я совсем запутался. Допустим, есть умеющий в федеративные блокчейны роутер, есть пакет, в заголовке которого — один (1) хэш непонятно кого. Что роутер должен сделать, чтобы определить, что:

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

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

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

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


              1. equand
                08.05.2018 16:19

                этот пакет вообще валиден для конкретно него и его нужно роутить


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

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

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

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

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

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

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


          1. equand
            08.05.2018 13:23

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


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

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


    1. achekalin
      07.05.2018 19:27
      +2

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


      1. equand
        08.05.2018 00:16
        -2

        Прекрасно разбираюсь и в том и в другом. Есть аргументы? Вперед!


        1. achekalin
          08.05.2018 00:30
          +2

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

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

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


          1. equand
            08.05.2018 01:48
            -1

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


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

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


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

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

            В локальной сети сохранить безопасность сети и упростить пакеты в старые времена было сложно. Именно поэтому мы используем названия с повторениями в реальной жизни и используем тонну сопутствующей информации для адресации и все равно допускаем ошибки (почта). Интернет (арпанет) писался по принципу и подобию. Соответственно сначала была сделан статическая связность с единым авторитетом рутинга. Как выяснилось с множеством агентов (разворот на интернет) это не было скалируемым решением. Началась работа над 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. immaculate
    07.05.2018 12:30
    +3

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


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


    1. SirEdvin
      07.05.2018 12:32
      +4

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


      1. navion
        07.05.2018 13:50

        Скорее дело в ARPU и росте мобильных пользователей.
        США всегда были королями legacy, однако по внедрение IPv6 они на первых местах.


    1. semmaxim
      07.05.2018 13:57
      +1

      В Камбодже и Лаосе не переходили на ipv6. Там не с чего было переходить. Они просто так с самого начала поставили.


      1. immaculate
        08.05.2018 04:49

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


        1. zikasak
          08.05.2018 08:54

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


        1. semmaxim
          08.05.2018 12:53

          Инфраструктура обычно не меняется сразу вся. Она меняется по отдельным частям. И каждая новая часть должна быть совместима со всеми остальными. Даже по глюкам.


  1. pda0
    07.05.2018 12:53

    Карта распределения ipv6 порадовала. Посмотрел на неё — заметил одинокую белую точку. На всякий случай потёр экран в этом месте — оказалась пылинка прилипла.


    1. u007
      07.05.2018 13:56

      GlobalSign_admin, предлагаю в конец статьи дописать:

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


      1. Marwin
        07.05.2018 14:15

        +100500


      1. Serge78rus
        07.05.2018 15:47

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


  1. staticlab
    07.05.2018 13:20
    +3

    Ещё можно раскулачить Ford, Daimler, Apple и HP.


    1. achekalin
      07.05.2018 16:24
      +1

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

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

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


  1. achekalin
    07.05.2018 15:08
    +1

    Да неужели они хоть слово скажут хоть кому-то, кто уже владеет сетью? Особенно — крупной.

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

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

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


    1. firk
      07.05.2018 15:54

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


      1. achekalin
        07.05.2018 16:08

        Не хватит: никто из владельцев не отдаст даже /29.

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

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

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

        Я бы раз был увидеть IPv6 в работе, но их и правда широко раздают, так что хватит (если и когда начнут серьезно использовать) не факт что на десятилетия.


        1. Wexter
          07.05.2018 16:57

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


        1. Hardcoin
          07.05.2018 19:16

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


          1. achekalin
            07.05.2018 19:23

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


    1. navion
      07.05.2018 16:07

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

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

      По-моему это давно прикрыли, но сейчас можно выдумать приватное облако.


      1. achekalin
        07.05.2018 16:14

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

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

        Райп вообще любит отписываться по формальным причинам (читай «у вас помарка в анкете»), т.к. типа они чем-то заняты, а как они могут диктовать схему сети, которую строит конечник?


        1. ivlad
          08.05.2018 10:18

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

          Для end-to-end связанности. Интернет вообще был придуман, как сеть с end-to-end связанностью.


          SLB — это стейт. Стейт — это дорого. Tomahawk II сейчас даёт 64 * 100 Gbps. SLB делают на 40Gbps — 50Gbps при немалых ухищрениях, довольно длинных сессиях и т.п. Быстрые штуки делают без стейта. Если делать их без стейта, тогда всё равно придётся делать 1-to-1 маппинг адресов. Зачем тогда серые адреса?


    1. ivlad
      08.05.2018 10:05

      Сегодня принять правила, обязывающие не фильтровать до /29 (например), и методы решения для тех, у кого BGP поднят на устройствах с небольшим числом ресурсов

      … И помрут TCAM по всему миру. Серьезно, всю эту энергию по гальванизации трупа IPv4 уже можно потратить с куда большей пользой на современный протокол.


      1. achekalin
        08.05.2018 10:21

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


        1. ivlad
          08.05.2018 12:16

          Но вот сейчас точка такова, что и вперед тяжело, и назад сложно.

          Есть мнение, что в среднем по миру мы сейчас находимся в точке между early adopters и early majority на кривой распространения технологий. Если верить книге "Crossing the chasm", этот разрыв имеет свои сложности и проблемы, но для России это нерелевантно.


          image


          Россия, если посмотреть на проникновение IPv6, находится в области innovators, даже не early adopters. Иначе говоря, в настоящий момент внедрение IPv6 не гарантирует никакого возврата инвестиций, формирования нового "голубого океана", ключевого дифферциатора, ничего. Таким образом, для принятия решения о внедрении IPv6 сейчас, техническому руководителю необходимо иметь глубокое понимание технологии, видеть (или верить в) её потенциал, а ещё — иметь волю (и яйца) для принятия этого решения и горизонт планирования больше 12 месяцев. Почему тогда Яндекс запустил IPv6 (как я рассказывал аж в 2012 году) и даже имеет IPv6-only датацентры? На мой взгляд, дело в том, что люди в Яндексе видят себя не в России (есть даже внутренняя шутка на этот счёт) и в своих суждениях и технологических решениях ориентируются не на, скажем, Ростелеком (смешно же), а на то, что делают в Google, Facebook или, на крайняк, в Amazon. Иначе говоря, Яндекс в 2012 году уже жил в мире 0.5% проникновения и экспоненциального роста (я хорошо помню, что я смотрел на график Google и, когда он достиг 2%, обсуждал с менеджером Главной страницы вопрос поддержки IPv6 аргументируя именно внутренним правилом про 2%), а типовой российский провайдер этого момента ещё не достиг.


          Но мировой интернет пока не отрубили, а там проникновение растёт. ЦК КПК принял решение ускорить проникновение в Китае и поставил местной индустрии задачу достичь проникновения 20% к концу года. Я буквально сегодня был на совещании по этому поводу и практически уверен, что 20% проникновения, все федеральные и top 50 коммерческих сайтов Китая будут на IPv6 в срок — в тюрьму никто не хочет. Это означает, что к концу года мир будет находиться в области early majority (Китай даст +7 — +10 процентных пунктов), а там заработают другие механизмы. Будущее наступило, просто оно неравномерно распределено.


          Россия, очевидно, в этой области отстала, я не знаю, сможет ли она догнать, но это уже не моя проблема. :) Я поймал себя на мысли, что мне любопытно наблюдать за этим со стороны, оттуда, где область early majority уже достигнута.


          Такие дела. :)


          1. achekalin
            08.05.2018 12:25

            Вне тему ipv6, ваша фраза про (сокращаю):

            люди в Яндексе… ориентируются… на то, что делают в Google

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


            1. ivlad
              08.05.2018 14:08

              Я полагаю, думал бы.


              Например, насколько я знаю, когда у Яндекса уже был IPv6-only датацентр, про такие у Google ещё не было слышно. Я сказал, что Яндекс ориентируется на мировые компании, но не в том смысле, что он всё за гуглом повторяет, а в том, что он ощущает себя в этой лиге (обосновано или нет, другой вопрос).


              1. achekalin
                08.05.2018 14:17

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


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


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


                1. ivlad
                  08.05.2018 15:08

                  Мне кажется, вы просто не понимаете мою точку зрения. Для меня этот вопрос звучит, как «а вот переход с паровых машин на двигатели внутреннего сгорания — он того стоил или это because we can». :)


                  Американские провайдеры едут на v6 потому, что адреса кончились и NAT придётся делать в любом случае. Но если внедрить v6, то доля трафика в NAT64 будет постепенно уменьшаться, при этом главные поставщики трафика, типа YouTube и Facebook уже с v6 и NAT не требуют. Это — естественное бизнес-решение в ситуации early majority.


        1. ivlad
          08.05.2018 12:17

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

          да, я как раз в 2012 году про это рассказывал :)


          Да вы и сами знаете.

          да. :)


  1. yetanotherman
    07.05.2018 18:06

    Вы будете удивлены, но 44.0.0.0/8 по факту используется. Роутится в интернет правда весьма ограничено.


    1. DarkByte
      07.05.2018 21:13

      В данной сети почти нет живых адресов. Большая часть сайтов из данной сети лежит по адресу 44.0.0.1. Недавно пробовал получить у них адрес, в ответ получил отказ под предлогом того, что в России запрещён VPN, а с настройкой ip-тоннелей они разобраться не смогли, говорят что работают не стабильно у них.


      1. yetanotherman
        07.05.2018 22:08

        Свяжитесь с админами dstar.su — они вполне успешно использовали эти адреса для нескольких радиолюбительских проектов, сейчас оно вроде работает на них же.


  1. grey_rat
    07.05.2018 22:49

    В Беларуси тотальный NAT к которому все привыкли. Собственно, оно видно по IPv6 распространению и приобретению IPv4 (зачем распылять силы и средства на IPv4 или IPv6, когда есть резиновый NAT).


    1. Aelliari
      07.05.2018 23:12
      -1

      У моего провайдера в РБ 2 варианта подключения, ipoe и l2tp туннель. Так вот, на ipoe белый ip придётся покупать, на l2tp — он белый всегда. А если подключатся не по доменному имени к l2tp серверу а по ip к конкретному (там штук 16 серверов в локальной сети) — так у тебя ещё будет псевдо статический, теоретически сменится может в любой момент — но если промежутки короткие (только переподключение когда оборвался l2tp туннель) почти без шансов его упустить:)


      1. grey_rat
        07.05.2018 23:37

        Это всё танцы с бубном. По факту, самые крупные провайдеры что МТС, что Velcom-Атлант, что Белтелеком как сидели так и будут сидеть со своим NAT пока это будет возможно.


  1. achekalin
    07.05.2018 23:56

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


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


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


  1. qwertyqwerty
    08.05.2018 22:46

    Почему айпишек не 999.999.999.999 или больше?


    1. Aelliari
      09.05.2018 00:28

      связано с тем, что ipv4 адрес — 32 бита информации
      11111111.11111111.11111111.11111111 = 255.255.255.255
      ipv6 — 128 бит, адресов соответственно больше