Немаршрутизируемые в Интернет адреса (bogon networks)
Всегда хочется иметь список под рукой не выискивая его в интернет, особенно для такой не частой задачи как адресное пространство для организации локальной/частной сети.
Ниже представлен список наиболее статичных диапазонов сетей, которые IETF предписывает не использовать в глобальной сети Интернет. Зарезервированные диапазоны также называются Bogon/bogus networks. Официальный перечень описан в RFC6890, RFC5735 и некоторых других.
0.0.0.0/8
Диапазон описан в RFC1122, RFC3330 и RFC1700 как Этот хост, в этой сети (this host on this network), хотя, учитывая варианты применения, правильнее было бы назвать его как "любой адрес". В частности, IP-адрес 0.0.0.0 используется для:
- обозначения в конфигурационных файлах серверов и выводе netstat информации о том, что определенный сервис "слушает" запросы на всех IP-адресах данного сервера;
- конфигурации маршрута по умолчанию на активном сетевом оборудовании;
- использования в качестве src address в запросах на получение IP-адреса (DHCPDISCOVER);
- обозначения IP-адреса в суммированных событиях безопасности IDS/IPS/WAF/etc (например, TCP Host Sweep - обозначение dst host в случае инициации коннектов к большому количеству IP-адресов).
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
Три вышеописанных диапазона не маршрутизируются в Интернет, поскольку зарезервированы под организацию локальных сетей ИТ-инфраструктуры компаний. Описаны изначально в RFC1918. При этом любая организация вправе использовать любой из вышеописанных диапазонов для IP-адресного плана либо все вместе на свое усмотрение. Для взаимодействия с внешними ресурсами и партнерами во избежание пересечения адресного пространства должен использоваться NAT.
100.64.0.0/10
В соответствии с RFC6598, используется как транслируемый блок адресов для межпровайдерских взаимодействий и Carrier Grade NAT. Особенно полезен как общее свободное адресное IPv4-пространство RFC1918, необходимое для интеграции ресурсов провайдеров, а также для выделения немаршрутизируемых адресов абонентам. Конечно, в последнем случае никто не мешает использовать RFC1918 - на откуп сетевым архитекторам.
127.0.0.0/8
В случае, если сервису необходим для работы функционирующий сетевой стек, который не будет давать сбоев при отключении от сети, используются loopback-адреса. Выделение 127.0.0.0/8 под внутренние loopback-адреса определено в RFC1122. В отличие от адресов RFC1918 и RFC6598, адреса для loopback не должны присутствовать и обрабатываться ни в одной сети, только во внутренней таблице маршрутизации хоста.
169.254.0.0/16
В соответствии с RFC3927, определен как Link-Local для автоматической конфигурации. Думаю, каждый человек хоть раз в жизни, но успел столкнуться с ситуацией, когда ПК, не получив IP-адрес от DHCP-сервера, присваивает сам себе непонятный и нигде не прописанный ранее IP, начинающийся на 169.254... Это и есть реализация рекомендаций из RFC3927.
192.0.0.0/24
Блок не встречается в повседневной жизни, поскольку зарезервирован под IANA для нужд IETF в соответствии с RFC6890.
192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24
Эти три подсети, в соответствии с RFC5737, зарезервированы для описания в документах. Многие, думаю, сталкивались с ситуацией, когда для статьи в журнале либо презентации на конференции нужно показать некоторое адресное пространство, которое, с одной стороны, не должно ассоциироваться с локальными RFC1918-адресами и как бы показывать Интернет, но, в то же время, и не принадлежать никому, чтобы не было лишних вопросов со стороны владельца адресов. Для этого и были выделены три подсети /24 по принципу "дарю, пользуйтесь".
192.88.99.0/24
Частный случай из подсети 192.0.0.0/24, описанной выше, но заслуживает отдельного описания из технологического интереса. В связи с необходимостью взаимодействия новых IPv6-облаков между собой в преобладающем IPv4-транзите необходим NAT 6to4. При этом некоторые межконтинентальные сервисы, наиболее критичные из которых - корневые сервера DNS, используют технологию anycast. Подсеть, выделенная под anycast, может терминироваться в любой автономной системе для обеспечения отказоустойчивости. В RFC3068 был выделен пул адресов 192.88.99.0/24 для NAT 6to4 сервисов, использующих anycast. Как видим, выделен был этот пул еще в 2001 году, после чего, нахлебавшись проблем на практике, в 2015 году издается RFC7526, отменяющий RFC3068, но при этом подсеть 192.88.99.0/24 остается зарезервированной под нужды IETF.
198.18.0.0/15
Диапазон выделен под лаборатории нагрузочного тестирования (Benchmarking) в соответствии с RFC2544 и уточнением в RFC6815, что данный диапазон не должен быть досутпен в Интернет во избежание конфликтов. Опять же, никто при этом не отменяет использование RFC1918, но для больших сетей с крупными лабораториями лишний блок /15 явно не помешает.
224.0.0.0/4
Этот диапазон в исторической классификации еще называется как Class D. Выделен под Multicast, уточнение специфики работы которого тоже вроде как отдельная заметка. В RFC5771 подробно расписано использование подсетей внутри блока, но суть остается той же: эти адреса не закреплены ни за каким провайдером, и, соответственно, через Интернет не должны светиться.
240.0.0.0/4
В соответствии с RFC1122, данный диапазон IP-адресов, исторически также известный как Class E, зарезервирован под использование в будущем. Юмор ситуации в том, что RFC1122 издавался еще в августе 1989 года, сейчас 2023 год, IPv4-адреса закончились, но для IETF будущее еще не наступило, потому что из всей большой подсети /4 до сих пор используется только один адрес. Но, наверное, если посчитать статистику по всем подсетям всех организаций мира, этот адрес окажется в лидерах, потому что сервисы, использующие broadcast, обращаются к адресу 255.255.255.255, который и принадлежит описанному диапазону.
