Как-то, очередной раз настраивая роутер с LTE модемом, обратил внимание, что IP адрес оператором мне был выдан из сети 11.0.0.0/8. Уже не помню точно, что за оператор это был, да и не имеет это значения, но задумался: а как так-то? Ведь вряд ли сотовый оператор будет бесплатно раздавать динамические публичные IP адреса, а локальными с детства привычно использование адресов 10.0.0.0/8, 192.168.0.0/16 и 172.16.0.0/12. Так же есть сеть 100.64.0.0/10, но с ней тоже всё не просто. Полный список не маршрутизируемых адресов можно посмотреть, например, тут.

Проверил WHOIS - сеть публичная, и значится за некоей "DoD Network Information Center" с датой регистрации 1984-01-19.

Так зародилась данная статья. Не претендую на 100% точность и достоверность информации и не рекомендую использовать информацию из этой статьи. В чём‑то данная статья имеет схожесть с «Ищем свободные IPv4 в BGP full‑view», но она немного о другом.

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

Каковы достоверные причины использования данной сети 11.0.0.0/8 у сотового оператора мне не известно, но предполагаю, что причина простая - в минимизации пересечения адресного пространства с абонентскими устройствам. Но как же так, наверняка многие спросят, - сеть то публичная и есть не нулевая вероятность, что в этой сети будет какой-нибудь полезный или не очень ресурс.

Анализ

На этот счёт есть то, что может вероятно однозначно ответить, есть ли там что-то полезное или нет - это full-view BGP. К сожалению доступа к роутеру с BGP у меня на текущий момент нет, поэтому можно воспользоваться имеющимися данными с официального ресурса RIPE.

Можно брать информацию с http://rrc00.ripe.net, но там много лишней маршрутной информации, которая мне не нужна. Поэтому я решил использовать данные https://data.ris.ripe.net/rrc13/latest-bview.gz с сервера "rrc13.ripe.net at Moscow, Russia. Collects route updates announced by the MSK-IX members from Apr 2005."

Это файл, который в распакованном виде умеет читать утилита bgpdump.

Но что же я хочу получить? Анализировать пол миллиона маршрутов не хочется, да и зачем? Вспомним немного историю интернета, а точней её часть, где выдавали IP адреса компаниям в США. На заре интернета, несколько крупных американских компаний получило сети с маской /8, потому что тогда еще никто не понимал, к чему придёт современный интернет. Значит и анализировать BGP full-view будем по данной маске, да и это самое простое и не требующее никаких усилий.

Штош, приступим:

sudo apt install bgpdump
wget https://data.ris.ripe.net/rrc13/latest-bview.gz
gzip -d latest-bview.gz 
#следующая команда займёт несколько минут
bgpdump latest-bview |grep PREFIX|awk '{print $2}'|grep -E "^[0-9]{1,3}\."|sort -u > latest-bview-prefix-ipv4.txt
#анализируем
for x in `seq 1 255`; do echo -n "$x.0.0.0/8,"; cat latest-bview-prefix-ipv4.txt|grep -E "^$x\." -c ; done > routes.csv

Полный готовый результат можно посмотреть тут.

Оставлю тут самую интересную часть:

Это список /8 сетей, в которых имеется меньше 100 маршрутов в таблице BGP.

Сети 11.0.0.0/8, о которой я говорил в самом начале, нет в списке - поскольку в ней 285 маршрутов, что тоже не так много. Вообще интересных сетей больше 36 штук /8 с числом маршрутов в BGP меньше 1000 - но с ними сложней. Вы можете самостоятельно их изучить по ссылке выше или получить данные самостоятельно.

И что с этим делать?

Зачем же это всё надо и в чём отличие от статьи «Ищем свободные IPv4 в BGP full‑view»? В том, что я предлагаю немного использовать эти адреса для внутренних нужд локальной сетевой инфраструктуры. Хотя в той статье как раз было предположение, что эти сети сейчас вероятно уже используются этими организациями для внутренних нужд и так. Так же оставили комментарий, что на рабочем компьютере уже используются такие адреса.

Я по своей сфере деятельности довольно часто сталкиваюсь с пересечением маршрутов в локальной сети. Казалось бы, есть 3 сети (10.x, 192.168.x, 172.16.x), которые можно и нужно использовать для локальной сети и вроде там полно адресов, но по каким-то причинам всё же могут встречаться пересечения. Причина в основном банальная - отсутствие какой-то базы подсетей, выделение чрезмерных блоков для простых задач (например /24 для p2p стыка), чрезмерное планирование масштабов (например для VPN /16 сеть).

Так же очень во многих крупных организациях в принципе используются все 3 локальных сети для различных целей и требуется время для выделения какой-то новой сети для, например стыка или взаимодействия site-to-site. Иногда если одна организация меньше другой, приходится использовать сеть, выделенной более крупной у себя. Ну или когда крупных организаций много, то приходится становиться еще более гибкими.

Некоторые для стыка используют 169.254.0.0/16, например, но для полноценного site-to-site это не подходит.

Еще есть сеть 100.64.0.0/10, цели которой по RFC я до конца не понял. Вроде как её цель - использоваться на абонентских устройствах на WAN интерфейсе, вместо динамического или статического публичного адреса или вместо адреса из стандартных локальных адресов. В целом некоторые российские ШПД операторы так эту сеть и используют. Но почему тогда сотовые операторы решили 11.x сеть использовать?

Я лично активно использую сеть 100.64.0.0/10 для внутренней адресации серверов в своей компании и пока проблем не было.

Итого

Подводя итоги, что касается вот этих вот сетей, я лично решил для себя потихоньку их использовать для своих внутренних нужд. Например, мне надо было временно сделать NAT сети 192.168.88.0/24 (что бы получать доступ к этой сети, но не добавлять маршрут конкретно на эту сеть, т.к. она слишком стандартная). Я взял сеть 48.99.88.0/24 и настроил 1в1 NAT этой сети в 192.168.88.0/24. Это лишь один из примеров использования. Можно использовать эти адреса в своём собственном VPN для своих личных доступов. Можно использовать эти адреса для стыков. Где-то по согласованию можно использовать для site2site.

Когда-то давно, я использовал сеть 172.32.x для локальной домашней сети - по WHOIS это "T-Mobile USA, Inc.". А для своих VPN до сих пор использую 172.12.x - это "AT&T Corp. (AC-3280)"

Минусы

Однако есть и минусы всего этого, про которые нельзя забывать:

1. Это совсем не по RFC.

2. По причине пункта 1, некоторые устройства не смогут нормально работать, используя эти сети. Их скорее всего немного, но они есть. Особенно совсем простые устройства с защитой от "дурака".

3. Кроме того, что, выбирая сеть, нужно проверить по таблице BGP, не занята ли она, а если занята, то кем. В случае 172.32.x и 172.12.x мне было не важно, что они заняты операторами связи из США. Даже имея небольшой проект в РУ сегменте, меня не сильно беспокоило, что пользователи из этих сетей вероятно не смогут зайти на мой сайт.

4. По причине пункта 1 и 3 и каким-то своим убеждениям, некоторые коллеги или партнёры могут не согласиться использовать эти сети, но для стыков, как мне кажется, можно использовать смело.

5. Нужно в теории мониторить эти сети, не начнут ли из них раздавать адреса всем подряд.

6. Если у вас крупный проект, а особенно международный, риск использования этих сетей для внутренних коммуникаций может многократно увеличиться, поскольку в случае внезапной раздачи адресов, например из блока 19.0.0.0/8, какие-то коммуникации могут сломаться. Вряд ли эти адреса будут раздавать под внешние адреса каких-то пользователей, скорее они будут использоваться для серверов, но всё же.

Заключение

На этом кажется всё. Я ни к чему не призываю, но считаю, что нужно иметь это ввиду. Если в чём-то сильно не прав - пишите. За нарушение RFC пока не штрафуют, однако в случае проекта с внешними пользователями, нужно использовать это с осторожностью, хоть и риск минимален. А в случае с 100.64.0.0/10 вообще рисков никаких нет, кроме того, что в теории могут быть проблемы с VPN у некоторых сотрудников, но они могут быть и в случае если провайдер сотрудника использует любую из локальных сетей.

Хотел еще добавить ссылки на историю выделения самых первых IPv4 адресов, но что-то пока не нашёл этой информации.

Наглядный инструмент для проверки: https://radar.qrator.dev/search?query=9.0.0.0%2F8

Случай, когда использование "пустых" сетей, привёл к проблемам: https://habr.com/ru/articles/146382/