Bogon

BOGON

/ip firewall address-list
add list="BOGONS" address=0.0.0.0/8
add list="BOGONS" address=10.0.0.0/8
add list="BOGONS" address=100.64.0.0/10
add list="BOGONS" address=127.0.0.0/8
add list="BOGONS" address=169.254.0.0/16
add list="BOGONS" address=172.16.0.0/12
add list="BOGONS" address=192.0.0.0/24
add list="BOGONS" address=192.0.2.0/24
add list="BOGONS" address=192.168.0.0/16
add list="BOGONS" address=198.18.0.0/15
add list="BOGONS" address=198.51.100.0/24
add list="BOGONS" address=203.0.113.0/24
add list="BOGONS" address=224.0.0.0/4

Описание BOGON сетей

Bogon IP или Bogon network - это зарезервированные диапазоны IP адресов, которые не маршрутизируются в Интернет:

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 года, IPv4-адреса закончились, но для IETF будущее еще не наступило, потому что из всей большой подсети /4 до сих пор используется только один адрес. Но, наверное, если посчитать статистику по всем подсетям всех организаций мира, этот адрес окажется в лидерах, потому что сервисы, использующие broadcast, обращаются к адресу 255.255.255.255, который и принадлежит описанному диапазону.