Ещё один регистратор отдал последний блок адресов IPv4

    В 2015 году ARIN (отвечает за североамериканский регион) стал первым регистратором, исчерпавшим пул IPv4. А в ноябре адреса закончились и у RIPE, которая распределяет ресурсы в Европе и Азии.


    / Unsplash / David Monje

    Ситуация в RIPE


    В 2012 году RIPE объявили о начале раздачи последнего блока /8. С того момента каждый клиент регистратора мог получить лишь 1024 адреса, что немного замедлило истощение пула. Но в 2015 году у RIPE осталось 16 млн свободных IP, летом 2019-го это число уменьшилось до 3 млн.

    В конце ноября RIPE опубликовали письмо, в котором сообщили, что регистратор отдал последние IP и его ресурсы исчерпаны. С этого момента пул будут пополнять только за счет адресов, которые возвращают в оборот различные организации. Распределять их будут в порядке очереди блоками /24.

    У кого еще остались адреса


    IPv4 остались еще у трех регистраторов, но последние несколько лет они работают в «режиме жесткой экономии». Например, в африканском AFRINIC ввели ограничения по количеству выдаваемых адресов и строгие проверки их целевого использования. Несмотря на все меры, эксперты прогнозируют, что IPv4 африканского регистратора закончатся уже в марте 2020 года. Но есть мнение, что это произойдет даже раньше — в январе.

    Немного ресурсов осталось у латиноамериканского LACNIC — он раздает последний блок /8. Представители организации говорят, что выдают максимум 1024 адреса на одну компанию. При этом приобрести блок могут лишь те клиенты, которые никогда раньше их не получали. Аналогичные меры приняли в азиатском APNIC. Но в распоряжении организации осталась лишь пятая часть пула /8, который также опустеет в ближайшее время.

    Еще не конец


    Эксперты отмечают, что можно продлить «срок службы» IPv4. Достаточно вернуть невостребованные адреса в общий пул. Например, за автопроизводителем Ford Motor Company и страховой фирмой Prudential Securities закреплено более 16 млн публичных IPv4. В тематическом треде на Hacker News высказали предположение, что этим организациям не нужно такое количество IP.

    При этом выдавать возвращённые адреса стоит не блоками как раньше, а в строго необходимых количествах. Другой резидент HN рассказал, что провайдеры Spectrum/Charter и Verizon уже перенимают такую практику — они выдают один IP из /24 вместо целого блока /30.

    Пара материалов из нашего блога на Хабре:



    / Unsplash / Paz Arando

    Другим решением проблемы недостатка адресов может стать их покупка и продажа на аукционах. Например, в 2017 году инженеры MIT обнаружили, что вуз владеет 14 млн неиспользуемых IP, — большую часть из них решили продать. Аналогичная история произошла в начале декабря в России. Научно-исследовательский институт развития общественных сетей (РосНИИРОС) объявил о закрытии локального интернет-регистратора LIR. После этого он передал примерно 490 тыс. IPv4 чешской компании Reliable Communications. Общую стоимость пула эксперты оценили в 9–12 млн долларов.

    Но если компании начнут массово перепродавать друг другу IP, это приведет к разрастанию таблиц маршрутизации. Однако и здесь есть решение — протокол LISP (Locator/ID Separation Protocol). Здесь авторы предлагают использовать при адресации в сети два адреса. Один для идентификации устройств, а второй — для создания тоннеля между серверами. Такой подход позволяет удалить из BGP-таблиц адреса, которые нельзя объединить в один блок — в результате таблица маршрутизации растёт медленнее. Поддержку LISP в свои решения уже внедряют такие компании, как Cisco и LANCOM Systems (разрабатывают SD-WAN).

    Кардинальным решением проблемы с IPv4 станет массовый переход на IPv6. Но несмотря на то что протокол разработали более 20 лет назад, он до сих пор не получил широкого распространения. На текущий момент его поддерживает 15% сайтов. Хотя ряд компаний предпринимает шаги, чтобы изменить ситуацию. Так, многие западные облачные провайдеры ввели плату за неиспользуемые IPv4. При этом задействованные адреса (подключенные к виртуальной машине) предоставляют бесплатно.

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

    О чем мы пишем в корпоративном блоге VAS Experts:

    VAS Experts
    Разработчик платформы глубокого анализа трафика

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

      0
      Мне кажется что переход на IPv6 — неизбежен, но тормозит его в первую очередь большое количество мелких провайдеров, которым апгрейд железа для IPv6 — очень проблемная тема.

      Ну и потом, почему-то даже на VPS-ке поднять IPv6 оказывается в разы сложнее чем IPv4 (по моему личному опыту). Тут скорее костность сознания — как моего так и поддержки хостера. IPv4 все уже понимают что называется интуитивно, а вот с IPv6 эта интуиция пока мало у кого есть…

      Я вот поднять IPv6 через подсеть в докере на VPS я вот так и не смог, завязал контейнер на HOST сетку в итоге. А изгуглил все и вопросов пробовал задавать знающим людям — все смотрят на тебя большими глазами и ничем толковым помочь не могут.
        0
        ТТК и Ростелеком мелкими провайдерами назвать никак нельзя. На самом деле если посчитать, то переход на новое железо(без учёта прочих затрат) окажется меньше месячного дохода провайдера. Но даже те, у кого всё оборудование поддерживает IPv6 не стремятся его внедрять. А зачем? Иногда стараниями одного админа в личном кабинете появляется галочка включающая IPv6. Но рисковать переводя всех, без какой либо возможной прибыли не готов никто.

        По поводу VPS сейчас многие хостеры выдают IPv6 адреса очень "щедро", давая их в аренду поштучно. Если это Ваш случай, то в лучшем случае можно настроить ndp-proxy на виртуальный интерфейс, куда роутить адреса так же поштучно, тогда контейнер по крайней мере не будет подключен к интерфейсу хоста напрямую. Про стандартные radvd и /64 на интерфейс можно забыть.
          0
          Не с VPS там нормально дали /64, но роутинг по их манам настроить было невозможно (тупо /etc/netvork/interfaces вместо netplan-а который у них в образе + неверный гейтвей).

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

          В Docker завести IPv6 — это отдельная песня…

          Попробовал дома на роутере 6to4 поднять — ну роутер то пингуется с двух сторон но из локалки выход всеть по IPv6 так и не удалось настроить пока.

          Нет я понимаю что я не специалист. Но я точно такой же неспециалист в IPv4, f а вот его поднять и настроить я разве что на утюге не смогу.

          И вот я не понимаю: технологии IPv6 уже много лет, Ее поддержка формально заявлена в куче продуктов и решений, но по факту все жутко сыро, и гуглеж не сильно помогает эту сырость обходить.
            0
            Хостер вероятно запихнул все VPS на один интерфейс с общей /64. Для назначения интерфейсу контейнеров сети /64, нужно чтобы на Ваш хост смаршрутизировали минимум /64. Иначе костыли с ndp-proxy или подключением к HOST сетке или NAT.Инструкция тоже предлагает использовать ndp-proxy в вашей ситуации.

            То, что всё сыро это абсолютная правда, кроме кучки энтузиастов отличия IPv6 от IPv4 никто толком не понимает. В особенности программисты, которые хорошо понимать устройство сети в общем то не обязаны. А базовые знания по IPv4 имеет каждый школьник.
            Обычные домашние роутеры хорошо если тестируются в абсолютно тепличных условиях(DHCPv6 PD + RA, возможно через PPPoE). В вашем случае работу 6to4 очевидно никто не проверял. В моём роутере статическая конфигурация IPv6 возможна только через Telnet, а через Web можно только выключить IPv6. Ведь никому, кроме кучки энтузиастов это всё не нужно.
              0
              Нет хостер мне целиком /64 дает. Контейнерам ndp-proxy накручивать пробовал… да чего я там за неделю гуглежа только не перепробовал. Подключил к HOST и на этом остановился. Но это не решение а просто костыль — я пытался добиться для докерной подсетки рабочего IPv6 доступной как извне так и наружу. И это я не осилил :(.

              У меня на роутере OpenWRT — там и вебморда приличная и ssh есть на все случаи жизни.

              Но у меня како-то несварение с файерволом кажись — не врубаюсь как там нужно форвардинги настраивать, хотя вроде все просто. Но как подкручу там что-нибудь так сразу домашние набегают с воплями — ты нафига интернет сломал :) Пока так и не удалось выкроить времени без посторонних потребителей IPv4 на полноценное копание с IPv6 в домашней локалке. На роутере то все работает.
                0
                Нет хостер мне целиком /64 дает

                Это не трудно проверить, настроить tcpdump на интерфейс хоста и адрес из диапазона не прописанный на интерфейсе. И пропинговать этот адрес снаружи. Если пакеты не приходят, то ничего Вам хостер не даёт. Иначе sysctl net.ipv6.conf.all.forwarding=1 && ip -6 route add $MY6PREFIX::/64 dev docker0 && ip6tables -P FORWARD ALLOW достаточно для работы. А уж потом думать как это по конфигам распихать.
                P.S Если $MY6PREFIX и тот, что на интерфейсе хоста совпадают, то интерфейсу хоста нужно урезать сеть до /128. Если gateway имеет адрес вашей сети, то прописать маршрут к нему.
                  0
                  Да пробовал я много адресов из /64 — все мои и пингуются. Хостер пишет так:

                  ipv6: 2a0a:2b41:xxxx:xxxx::/64
                  Шлюз:2a0a:2b41::1
                  Маска:ffff:ffff::

                  Ну xxxx:xxxx — там я свои цифиьки закрыл на всяк случай.

                  Форвард включал и роутинг настраивал, префикс на части пробовал разделять — адрес докер интерфейса пингуется извне, а контейнеры в BRIDGE сетке хоть свои IPv6 и получают, но ни с наружи не пингуются ни с них наружу ничего не уходит…

                  Вот похоже именно настройки ip6tables мне не хватило. Благодарю за подсказку, попробую.

                  У меня вообще похоже с файерволингом и iptables некий пробел в понимании. Надо будет почитать потренироваться с этим…
                    0
                    Я надеюсь Вы не использовали эту маску /32. Эти настройки аналогичны:
                    IPv4: 10.5.8.0/24
                    Шлюз: 10.0.0.1
                    Маска: 255.0.0.0
                    Что здесь может пойти не так?
                      0
                      Нет, маска, как я понимаю это к той подсетке /32 которую они клиентским боксам раздают.
                      У них еще подсетка 2a0a:2b42::/32 есть и они в FAQ умудрились от нее гейт для всех написать. И я не сразу просек что гейт 2a0a:2b42::1 для моей подсетки 2a0a:2b41:: мягко говоря не катит. Но это для IPv4 распознается с первого раза, а столкнувшись первый раз с IPv6 даже такие косяки почему то глазом не зацепляются. Это они уже после долгой переписки со со мной добавили инфу про гейт прямо в свойства бокса в их панели управления.
                      Раньше у них там только голый IP (v4 и v6) выводился.

                      Ну а ваш пример косячный ибо гейт не в той посетке что IP. Примерно так как у меня получилось в первый раз, когда я по их FAQ настроил. Но вот с IPv4 это с первого взгляда видно, а на IPv6 видимо еще глаз не натренирован…
                        0
                        Сеть полученная от RIPE вообще /29, это всё одна сетка, соединённая в единую локалку. Вероятно если прописать ip -6 route add 2a0a:2b40::1/128 via eth0, то и он найдётся. То есть готовый рабочий конфиг должен выглядеть как то так.

                        auto eth0
                        iface eth0 inet6 static
                            address 2a0a:2b4X:xxxx:xxxx::1
                            netmask 128
                            gateway 2a0a:2b40::1
                            pre-up ip route add 2a0a:2b40::1 dev eth0 scope link
                            pre-down ip route del 2a0a:2b40::1 dev eth0 scope link

                        128 потому, что они эту сеть роутят(вероятно на MAC-адрес)и не будут в локалке искать 2a0a:2b41:xxxx:xxxx::/64 поэтому и ndp-proxy не работает. Но вообще такой поиск шлюза это костыль. Может ещё MAC-адрес шлюза запишем для надёжности? А то вдруг какой то клиент шалить начнёт. А если фильтрацию настраивать, то и с router advertisement всё прекрасно работать будет, а главное везде, независимо от кривизны рук админа.
                          0
                          Вот какой рабочий netplan конфиг для VPS (ubuntu server 18.04) вышел в результате переписки с саппортом:

                          $ cat /etc/netplan/01-netcfg.yaml 
                          # This file describes the network interfaces available on your system
                          # For more information, see netplan(5).
                          network:
                            version: 2
                            renderer: networkd
                            ethernets:
                              ens3:
                                addresses:
                                - 185.185.x.x/22
                                - 2a0a:2b41:y:y::/80
                                gateway4: 185.185.68.1
                                gateway6: 2a0a:2b41::1
                                routes:
                                - to: 2a0a:2b41::1
                                  scope: link
                                nameservers:
                                    addresses:
                                    - 8.8.8.8
                                    - 4.4.4.4
                                    - 2001:4860:4860::8888
                                    - 2001:4860:4860::8844
                          

                          Причем тут ИМХО масло масленное — и gateway6 и роутинг. Но если хоть одно из них убрать — то почему то netplan applay дефолтовый роутинг на гейт не создает.

                          Но это сам хост сделало с рабочим IPv6, а вот в докере — только завязка на HOST спасла.
                            0
                            Вы раз разбираетесь помогли бы мне лучше с 6to4 разобраться:
                            Сам интерфейс на роутере поднялся и работает (пингую и наружу IPv6 и в локалку с роутра), снаружи IPv6 интерфейса тоже пингуется.

                            Нужный перфикс роутер (OpenWRT) раздает локальным машинам, и с локальной машины пингуется IPv6 интрефейса на роутрере, но наружу ничего не пингуется — Destination unreachable: Port unreachable

                            На firewall уже вроде бы все что можно разрешил и открыл — форвардинги из лан в WAN6 и обратно разрешены. Ну вообще не понимаю что за хрень такая.
                              0
                              Какой такой WAN6? OpenWRT нынче рекомендует обзывать 6to4 интерфейс '6rd'. У Вас он WAN6?
                              ip6tables при REJECT по умолчанию кидает код 'port unreachable'. Я не знаю насколько OpenWRT Linux, но хотелось бы увидеть ip link и ip6tables --list-rules, а так же файл /etc/config/firewall. Первые 32-бита адреса можете заменить на 2001:db8 и наверное в личку.
                                0
                                Ну там у виртуального интерфейса имя составное. Я назвал его WAN6 а OpenWRT приписала 6to4. Получилось полное имя 6to4-wan6 но в настройках файера (в GUI) фигурирует именно короткое имя WAN6.

                                И да — OpenWRT вполне себе Linux, только немного облегченный и заточенный на работу на флешке, всякие ip, ip6tables там есть.

                                Сейчас подготовлю листинги и пришлю в личку.
                0

                Давно поднял дома 6to4 через туннель от he.net, все отлично работает. Да, сначала у меня не завелось, но не завелось из-за того, что я пытался натянуть сову на глобус NAT на все это дело.
                Настроил раздачу реальных v6 адресов из выданного мне префикса локальным устройствам и все поехало :)

                  0
                  У меня белый статичный IPv4 есть, с ним тунель he.net не нужен и благодаря подсказкам none7 я таки нашел ошибки у себя в настройках роутера и 6to4 наконец поднял дома. Раздачу IPv6 домашним устройствам тоже настроил. Так что теперь могу на любой домашний комп по IPv6 зайти на ssh… только не откуда :/ — на работе IPv6 — нет. Если только с работы на VPS по IPv4, а с него уже по IPv6 домой, но если через посредника, то проще через роутер. А с роутера там без разницы каким IP.
                    0

                    У меня тоже белые IPv4 (несколько аплинков). Я почему-то совсем забыл что можно через 192.88.99.1 поднять туннель. Но, все же до he.net у меня пинг ниже :)
                    Но да, нужно будет попробовать еще и так поднять туннель.

            –2
            Ну и потом, почему-то даже на VPS-ке поднять IPv6 оказывается в разы сложнее чем IPv4 (по моему личному опыту).

            По моему личному опыту — его поднимает хостер, и ничего делать не нужно. Он уже просто есть.
            апгрейд железа для IPv6 — очень проблемная тема

            Простите, а что там апгрейдить?
            завязал контейнер на HOST сетку в итоге.

            Все правильно. Роутер с RADV и SEND в локалке — и NAT в docker-е не нужен.
              0

              банально пакет большего размера, а это проц и память, те грубо надо в 2 раза поднять мощность текущего железа.

                0
                Пакет это же не только адреса — почему в 2 раза?
                  0
                  Заголовок. 320 бит у ipv6 против 160 у ipv4. Но у ipv4 может быть поле options и это может увеличить размер до 480 бит максимум.
                    0
                    Там с размером пакета — отдельная тема…

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

              Самое читаемое