В 2015 году ARIN (отвечает за североамериканский регион) стал первым регистратором, исчерпавшим пул IPv4. А в ноябре адреса закончились и у RIPE, которая распределяет ресурсы в Европе и Азии.
/ Unsplash / David Monje
В 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. Но они регулярно сталкиваются со сложностями при миграции. Об этих сложностях и способах их решения мы подготовим отдельный материал.
/ 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:
Комментарии (15)
ne_kotin
19.12.2019 16:19Ну и потом, почему-то даже на VPS-ке поднять IPv6 оказывается в разы сложнее чем IPv4 (по моему личному опыту).
По моему личному опыту — его поднимает хостер, и ничего делать не нужно. Он уже просто есть.
апгрейд железа для IPv6 — очень проблемная тема
Простите, а что там апгрейдить?
завязал контейнер на HOST сетку в итоге.
Все правильно. Роутер с RADV и SEND в локалке — и NAT в docker-е не нужен.
tankistua
19.12.2019 17:41банально пакет большего размера, а это проц и память, те грубо надо в 2 раза поднять мощность текущего железа.
Extravert34
19.12.2019 22:37Пакет это же не только адреса — почему в 2 раза?
Balling
21.12.2019 12:23Заголовок. 320 бит у ipv6 против 160 у ipv4. Но у ipv4 может быть поле options и это может увеличить размер до 480 бит максимум.
Sly_tom_cat
Мне кажется что переход на IPv6 — неизбежен, но тормозит его в первую очередь большое количество мелких провайдеров, которым апгрейд железа для IPv6 — очень проблемная тема.
Ну и потом, почему-то даже на VPS-ке поднять IPv6 оказывается в разы сложнее чем IPv4 (по моему личному опыту). Тут скорее костность сознания — как моего так и поддержки хостера. IPv4 все уже понимают что называется интуитивно, а вот с IPv6 эта интуиция пока мало у кого есть…
Я вот поднять IPv6 через подсеть в докере на VPS я вот так и не смог, завязал контейнер на HOST сетку в итоге. А изгуглил все и вопросов пробовал задавать знающим людям — все смотрят на тебя большими глазами и ничем толковым помочь не могут.
none7
ТТК и Ростелеком мелкими провайдерами назвать никак нельзя. На самом деле если посчитать, то переход на новое железо(без учёта прочих затрат) окажется меньше месячного дохода провайдера. Но даже те, у кого всё оборудование поддерживает IPv6 не стремятся его внедрять. А зачем? Иногда стараниями одного админа в личном кабинете появляется галочка включающая IPv6. Но рисковать переводя всех, без какой либо возможной прибыли не готов никто.
По поводу VPS сейчас многие хостеры выдают IPv6 адреса очень "щедро", давая их в аренду поштучно. Если это Ваш случай, то в лучшем случае можно настроить ndp-proxy на виртуальный интерфейс, куда роутить адреса так же поштучно, тогда контейнер по крайней мере не будет подключен к интерфейсу хоста напрямую. Про стандартные radvd и /64 на интерфейс можно забыть.
Sly_tom_cat
Не с VPS там нормально дали /64, но роутинг по их манам настроить было невозможно (тупо /etc/netvork/interfaces вместо netplan-а который у них в образе + неверный гейтвей).
Для меня было камнем преткновения то, что просто Gateway6 в netplan прописать оказывается недостаточно нужно именно роутинг на гейт прописывать. Но выяснить это удалось где-то на втором десятке писем с саппортом.
В Docker завести IPv6 — это отдельная песня…
Попробовал дома на роутере 6to4 поднять — ну роутер то пингуется с двух сторон но из локалки выход всеть по IPv6 так и не удалось настроить пока.
Нет я понимаю что я не специалист. Но я точно такой же неспециалист в IPv4, f а вот его поднять и настроить я разве что на утюге не смогу.
И вот я не понимаю: технологии IPv6 уже много лет, Ее поддержка формально заявлена в куче продуктов и решений, но по факту все жутко сыро, и гуглеж не сильно помогает эту сырость обходить.
none7
Хостер вероятно запихнул все VPS на один интерфейс с общей /64. Для назначения интерфейсу контейнеров сети /64, нужно чтобы на Ваш хост смаршрутизировали минимум /64. Иначе костыли с ndp-proxy или подключением к HOST сетке или NAT.Инструкция тоже предлагает использовать ndp-proxy в вашей ситуации.
То, что всё сыро это абсолютная правда, кроме кучки энтузиастов отличия IPv6 от IPv4 никто толком не понимает. В особенности программисты, которые хорошо понимать устройство сети в общем то не обязаны. А базовые знания по IPv4 имеет каждый школьник.
Обычные домашние роутеры хорошо если тестируются в абсолютно тепличных условиях(DHCPv6 PD + RA, возможно через PPPoE). В вашем случае работу 6to4 очевидно никто не проверял. В моём роутере статическая конфигурация IPv6 возможна только через Telnet, а через Web можно только выключить IPv6. Ведь никому, кроме кучки энтузиастов это всё не нужно.
Sly_tom_cat
Нет хостер мне целиком /64 дает. Контейнерам ndp-proxy накручивать пробовал… да чего я там за неделю гуглежа только не перепробовал. Подключил к HOST и на этом остановился. Но это не решение а просто костыль — я пытался добиться для докерной подсетки рабочего IPv6 доступной как извне так и наружу. И это я не осилил :(.
У меня на роутере OpenWRT — там и вебморда приличная и ssh есть на все случаи жизни.
Но у меня како-то несварение с файерволом кажись — не врубаюсь как там нужно форвардинги настраивать, хотя вроде все просто. Но как подкручу там что-нибудь так сразу домашние набегают с воплями — ты нафига интернет сломал :) Пока так и не удалось выкроить времени без посторонних потребителей IPv4 на полноценное копание с IPv6 в домашней локалке. На роутере то все работает.
none7
Это не трудно проверить, настроить 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 имеет адрес вашей сети, то прописать маршрут к нему.
Sly_tom_cat
Да пробовал я много адресов из /64 — все мои и пингуются. Хостер пишет так:
ipv6: 2a0a:2b41:xxxx:xxxx::/64
Шлюз:2a0a:2b41::1
Маска:ffff:ffff::
Ну xxxx:xxxx — там я свои цифиьки закрыл на всяк случай.
Форвард включал и роутинг настраивал, префикс на части пробовал разделять — адрес докер интерфейса пингуется извне, а контейнеры в BRIDGE сетке хоть свои IPv6 и получают, но ни с наружи не пингуются ни с них наружу ничего не уходит…
Вот похоже именно настройки ip6tables мне не хватило. Благодарю за подсказку, попробую.
У меня вообще похоже с файерволингом и iptables некий пробел в понимании. Надо будет почитать потренироваться с этим…
none7
Я надеюсь Вы не использовали эту маску /32. Эти настройки аналогичны:
IPv4: 10.5.8.0/24
Шлюз: 10.0.0.1
Маска: 255.0.0.0
Что здесь может пойти не так?
Sly_tom_cat
Нет, маска, как я понимаю это к той подсетке /32 которую они клиентским боксам раздают.
У них еще подсетка 2a0a:2b42::/32 есть и они в FAQ умудрились от нее гейт для всех написать. И я не сразу просек что гейт 2a0a:2b42::1 для моей подсетки 2a0a:2b41:: мягко говоря не катит. Но это для IPv4 распознается с первого раза, а столкнувшись первый раз с IPv6 даже такие косяки почему то глазом не зацепляются. Это они уже после долгой переписки со со мной добавили инфу про гейт прямо в свойства бокса в их панели управления.
Раньше у них там только голый IP (v4 и v6) выводился.
Ну а ваш пример косячный ибо гейт не в той посетке что IP. Примерно так как у меня получилось в первый раз, когда я по их FAQ настроил. Но вот с IPv4 это с первого взгляда видно, а на IPv6 видимо еще глаз не натренирован…
none7
Сеть полученная от 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 всё прекрасно работать будет, а главное везде, независимо от кривизны рук админа.