Почему все нули в хост-части IP-адреса не могут быть использованы для хоста?

Я знаю, что если у меня есть сеть 83.23.159.0/24 тогда у меня есть 254 используемых IP-адреса хоста, потому что:

83.23.159.0      (in binary: host portion all zeros) is the subnet address
83.23.159.1-254  are host addresses
83.23.159.255    (in binary: host portion all ones) is the broadcast address

Я понимаю использование широковещательного адреса, но не понимаю, для чего когда-либо использовался адрес подсети. Я не вижу причин, по которым адрес назначения IP-пакета будет установлен на адрес подсети, так почему же самой подсети нужен адрес, если она никогда не станет конечной точкой для потока IP AN? Мне кажется, что это пустая трата - не разрешать использовать этот адрес в качестве адреса хоста.

Подводя итог, мои вопросы:

  1. Установлен ли в качестве получателя IP-адреса IP-адрес подсети?
  2. Если да, то в каких случаях и почему?
  3. Если нет, то почему бы не освободить этот адрес для использования любым хостом?
Источник

9 ответов

Решение

Установлен ли в качестве получателя IP-адреса IP-адрес подсети?

Да. Это действительный IP-адрес, поэтому его можно использовать.

Если да, то в каких случаях и почему?

Это просто один из 255 используемых IP-адресов в /24

Если нет, то почему бы не освободить этот адрес для использования любым хостом?

Если у вас устаревшее оборудование, вам нужно проверить, использует ли оно первый или последний адрес в качестве сетевого адреса. (.0 или.255 для сетей с маской FF.FF.FF.00)

Это делает хорошей привычкой пропускать этот IP. И привычки, усвоенные давно, трудно игнорировать.

И люди, которые не знают фон, не используют его, "потому что другие тоже не используют его, поэтому его использование должно быть неправильным" или потому, что они не понимают, что "0" может быть первым числом.

[Редактировать] Grezzo только что протестировал его в Windows XP, где графический интерфейс Windows Network 'услужливо' предотвратил эту настройку. Windows 7 имеет такое же поведение. Я тогда попробовал это на хосте не-Windows, где это только работает. Если вы используете Windows, вам, возможно, придется настроить сеть вручную через IPconfig, чтобы установить для нее все нули.

192.168.1.0_on_win7192.168.1.0_on_FreeBSD

[Редактировать 2]

Чем дольше я работаю с этим, тем больше путаюсь.

Rfc4632 - Бесклассовая междоменная маршрутизация, по-видимому, не запрещает это, но и явно не допускает.

В этом посте ServerFault упоминается: "По историческим причинам многие операционные системы рассматривают первый адрес как широковещательный. Например, пинг xxx0 из OS X, Linux и Solaris в моей локальной (/24) сети получает ответы. Windows не позволяет вам пинговать первый адрес по умолчанию, но вы можете включить его с помощью метода SetIPUseZeroBroadcast WMI. Интересно, можете ли вы использовать.0 в качестве адреса хоста в сети, работающей под управлением Windows? ",

Это тот же вопрос, но не ответ.

Сетевой адрес также используется в таблицах маршрутизации. Но я не понимаю, почему это не сработает из-за этого. Те же обозначения в таблицах маршрутизации будут направлены в нужную сеть. Оказавшись в нужной сети, он достигнет ПК с IP 0.

(Все это для 192.168.1/24.
Если вы использовали 192.168.0/23, тогда 192.168.1.0 будет допустимым и безопасным значением в середине диапазона)

[Редактировать 3]

Еще одна ссылка на тот же вопрос. Похоже, что-то популярное в обмене стека:

https://superuser.com/questions/379451/why-can-a-network-address-not-be-a-valid-host-address

И одна мысль:

Destination_IP, вероятно, выполняется с помощью сетевой мачты (быстрая аппаратная операция) перед сравнением с записями в таблицах маршрутизации. Но:

(Полуслучайный IP) 192.168.0.42 И 255.255.255.0 даст 192.168.0.0
Но 192.168.0.0 И 255.255.255.0 также приведут к 192.168.0.0

[Изменить 4 - Задолго после того, как этот ответ был написан - возможно, мне придется переписать весь пост из-за этой новой информации]

RFC923 утверждает на странице 3, что:

  In certain contexts, it is useful to have fixed addresses with
  functional significance rather than as identifiers of specific
  hosts.  When such usage is called for, the address zero is to be
  interpreted as meaning "this", as in "this network".  The address
  of all ones are to be interpreted as meaning "all", as in "all
  hosts".  For example, the address 128.9.255.255 could be
  interpreted as meaning all hosts on the network 128.9.  Or, the
  address 0.0.0.37 could be interpreted as meaning host 37 on this
  network.

Цитирование jdelator на нашем сайте сетевой jdelator

Я полагаю, что первая документация этого поступает из RFC950, который ссылается на RFC943 (который устарел RFC923 выше, но использует тот же язык для специальных адресов):

     It is useful to preserve and extend the interpretation of these
     special addresses in subnetted networks.  This means the values
     of all zeros and all ones in the subnet field should not be
     assigned to actual (physical) subnets.
Источник

Адрес с нулевой частью хоста относится к самой сети, а не к какому-либо конкретному хосту.

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

Итак, я должен не согласиться с некоторыми другими ответами: нет, ноль - не совсем удобный адрес хоста. Если вам нужно более 254 адресов, вам нужно создать большую подсеть.

Смотри, мой маршрутизатор Linksys, чей адрес .1 отвечает на звоны .0, (Сетевая маска 255.255.255.0, поэтому последний октет соответствует номеру хоста.)

webserver:~# ping  192.168.1.0
Do you want to ping broadcast? Then -b
webserver:~# ping -b 192.168.1.0
WARNING: pinging broadcast address
PING 192.168.1.0 (192.168.1.0) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.46 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.812 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.819 ms

Если бы я назначил .0 обращаясь к какому-либо хосту, я не смог бы пропинговать его, если бы маршрутизатор не включал его ответы. И, как вы можете видеть, некоторые инструменты, такие как версия этого маршрутизатора ping лечить 0 как трансляция.

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

Дело в точке.

Я работал в компании, которая проектировала сетевой узел, построенный на 14-слотовом шасси, на котором работали многочисленные независимые образы ОС на нескольких типах карт, и все они общались через объединительную плату. Была сетевая настройка через объединительную плату с соглашением, которое 127.X.0.Y является внутренним IP-адресом узла Y в слоте X, все пронумерованы от 1.

В основном мы использовали подсеточный адрес для наших собственных целей. Чтобы заставить его работать, нам пришлось исправлять ядро ​​Linux тут и там, и IIRC, немного пользовательского пространства.

Так как эта сеть использовалась только внутри коробки, и большинство программ, которые требуют обратной связи, используют 127.0.* сеть (и на самом деле конкретный адрес 127.0.0.1) которая продолжала нормально работать, все было круто.

Источник

На самом деле это зависит от маски сети, например, для сети 83.23.159.0/23, 83.23.159.0 - это идеально используемый IP-адрес

Источник

Похоже, здесь есть небольшая путаница с базовыми сетями.

"Старое оборудование", упомянутое в одном из ответов, не будет использовать ноль IP-подсети - использование ip-адреса xxx0 с сетью, настроенной на /24 CIDR или маску подсети 255.255.255.0, является совершенно другой проблемой.

IP Подсеть Ноль

  • Старые устройства не будут использовать IP Subnet Zero - это означает, что они не будут использовать первую подсеть в сетевой системе с несколькими подсетями. Таким образом, в сети / 23 или 255.255.254.0 подсеть XXX0 и все ее адреса не будут использоваться. Современные маршрутизаторы не имеют этого ограничения, но могут быть настроены на использование этой старой модели IE, не используя нулевую подсеть, если это необходимо.

Используемые IP-адреса хоста в подсети

  • Основные сети:
    • С / 24 т.е. маска подсети 255.255.255.0
    • ххх0 зарезервирован как сетевой адрес. Маршрутизаторы и протоколы маршрутизации (EIGRP, RIP2 и т. Д.) Используют сетевой адрес для определения сегментов сети для перемещения пакетов внутри и за пределами границ сети.
    • ххх255 зарезервирован для широковещательного адреса
    • Обычной практикой является использование адресов.1 или.254 на маршрутизаторах, чтобы оставить 253 используемых IP-номера.

Сетевой адрес и широковещательный адрес зарезервированы и не могут (по текущим и предыдущим сетевым стандартам) быть назначены устройству. Использование xxx0 для адреса хоста в системе / 24 является неправильным. Даже если Linux позволяет вам использовать его, это не значит, что он прав, это просто означает, что Linux думает, что вы знаете, что делаете.

Если ваша система позволяет вам назначить хосту xxx0 в качестве IP4-адреса, и он, кажется, работает - возможно, конкретный хост получает ВСЕ трафик, предназначенный для ЛЮБОГО устройства в этой сети, поэтому его сеть, вероятно, не работает оптимально.

Источник

RFC 1122 ("Требования к интернет-хостам - коммуникационные уровни") запрещает:

IP-адресам не разрешается иметь значение 0 или -1 для любого из полей , или

Источник

Во-первых, стоит отметить, что нулевые адреса в IPv6 определены в RFC4291 как «Требуемый адрес произвольной рассылки», то есть адреса, на которые будет отвечать хотя бы один маршрутизатор в сегменте, но не обязательно все из них. (Адресы Anycast как в IPv6, так и в IPv4 могут иметь ненулевые части хоста.) Таким образом, ответ однозначно «нет» для IPv6, если только вы не используете его для предоставления услуг Anycast.

Как упоминалось в других ответах, использовать эти адреса IPv4 в качестве адресов хостов в широковещательной среде небезопасно: по историческим причинам многие хосты будут отвечать на пакеты с этими адресами, как если бы они были широковещательными пакетами. Однако запрещать использование этих адресов в восходящем направлении также небезопасно, даже если у вас есть четкое указание (из записи маршрутизации), что адрес находится в нижней части подсети... адрес может использоваться в нешироковещательной сети. подсеть, например пул NAT, или /31, используемый в качестве проводного адреса маршрутизатора. Это означает, что защита от DoS-атак, подобная «smurf», должна, если это вообще возможно, применяться к напрямую подключенному маршрутизатору, который должен знать, является ли носитель широковещательным доменом или нет. И эта защита присутствует в обычном случае, так что это вторая причина, по которой использование этих адресов в качестве одноадресных адресов в широковещательной среде не будет работать: маршрутизатор не может позволить трафику из внесегмента достичь их.

Если экстраполировать RFC923, нулевым хостом будет «Этот хост в определенной сети». Делать такую ​​экстраполяцию небезопасно, поскольку RFC обращается только к сетевому адресу, а не к адресу хоста. Однако вполне возможно, что некоторый протокол согласования IP-адреса мог быть развернут, когда хост знает подсеть, к которой он хочет принадлежать, но не знает своего адреса хоста и запрашивает автоконфигурацию в этой конкретной сети, указав нулевой адрес хоста. Это еще одна возможная интерпретация, на которую следует обратить внимание.

Источник

На самом деле ответ является основой подсетей. IP-адрес "все нули" вашей подсети в сочетании с идентификатором сети используется для расчета того, куда должен быть отправлен пакет.

В вашем примере у вас есть подсеть 255.255.255.0. Любое устройство, которое знает протокол TCP/IP, будет использовать маску сети, объединенную с IP-адресом, чтобы вычислить, предназначен ли пакет для локальной сети (путем выполнения логической операции И) или что он должен быть отправлен через шлюз / маршрутизатор.

Поэтому я предполагаю, что причина того, что IP не может быть использован, заключается в том, что он уже используется для "определения" границ сети вместе с маской сети.

Источник

Согласно RFC1812 4.2.3.1, маршрутизатор ДОЛЖЕН молча отбрасывать при получении (т. е. даже не доставлять приложениям на маршрутизаторе) любой пакет, адресованный0.0.0.0или{ <Network-prefix>, 0 }. Если эти пакеты не отбрасываются автоматически, они ДОЛЖНЫ рассматриваться как широковещательные IP-передачи. МОЖЕТ существовать опция конфигурации, позволяющая получать эти пакеты. Эта опция ДОЛЖНА по умолчанию отбрасывать их.

Таким образом, все 0 бит номера хоста не могут использоваться для хоста.

К вашему сведению, все 0-битные номера хостов представляют собой нестандартные широковещательные IP-адреса, вышеуказанное требование в RFC1812 обусловлено главным образом историческими причинами.

Кроме того, RFC3021 создает исключение для/31сети, разрешите все 1 биты и все 0 бит номера хоста.

Источник

Мне было предложено опубликовать свой ответ от NetworkEngineering, поэтому я сделаю это с некоторыми изменениями для этого сайта.

В RFC919 он ссылается на общее принятие сетевого адреса:

However, as a notational convention, we refer to
networks (as opposed to hosts) by using addresses with zero fields.
For example, 36.0.0.0 means "network number 36"

Это обеспечивает соглашение, которое должно прояснить наше понимание, если кто-то упомянул "10.1.2.0" как сеть, а не как хост в сети.

Оттуда использование "0" в IP-адресах было определено в RFC923 и перенесено в последовательных RFC:

Special Addresses:

  In certain contexts, it is useful to have fixed addresses with
  functional significance rather than as identifiers of specific
  hosts.  When such usage is called for, the address zero is to be
  interpreted as meaning "this", as in "this network".  The address
  of all ones are to be interpreted as meaning "all", as in "all
  hosts".  For example, the address 128.9.255.255 could be
  interpreted as meaning all hosts on the network 128.9.  Or, the
  address 0.0.0.37 could be interpreted as meaning host 37 on this
  network.

В этом примере указан конкретный хост в текущей сети (0.0.0.37) с использованием 0 в сетевых частях адреса, но в действительности он не проясняет противоположный случай (0 в хостовой части адреса). Однако, поскольку это действительно определяет "0" как "это".

В RFC1060 адрес "0.0.0.0" был четко задокументирован как "этот хост в этой сети":

     (a)   {0, 0}

        This host on this network.  Can only be used as a source
        address (see note later).

Поскольку все нули для части адреса узла означают "этот узел", из этого логически следует, что он непригоден в качестве адреса узла.

Возвращаясь к непосредственному ответу на ваши вопросы:

  1. Установлен ли в качестве получателя IP-адреса IP-адрес подсети?
  2. Если да, то в каких случаях и почему?
  3. Если нет, то почему бы не освободить этот адрес для использования любым хостом?

Согласно тому, что я нахожу в RFC, это не должно использоваться. Я признаю, что это не так четко определено, как хотелось бы, но это часто встречается во многих стандартах. Когда стандарты немного менее точны, отрасль, похоже, "соглашается" на общепринятую интерпретацию.

Кроме того, на основе содержимого программного обеспечения RFC может быть написано предположение, что этот адрес используется для адресации сети, а не конкретного хоста. Или даже более буквально, как своего рода "петля" (то есть этот хост в указанной сети).

Так почему же некоторые ОС явно разрешают его использование? Я хотел бы представить, как многие вещи, которые сводятся к времени / ресурсам разработчика, или никто действительно не думал, чтобы добавить проверку достоверности. Логика должна быть немного более сложной, чем "если она заканчивается на 0", так как большая подсеть (a /23 или больше) будет содержать действительный IP-адрес.255 и.0 (т. Е. 10.1.2.0/23 содержит оба действительных IP-адреса адрес 10.1.2.255 и 10.1.3.0). Хотя некоторые организации также избегают использования этих действительных адресов в больших подсетях, чтобы избежать каких-либо странных проблем с программным обеспечением, которое не поддерживает современные подсети правильно.

Что касается того, почему бы не освободить этот один IP-адрес, это просто сводится к стоимости / выгоде. Потребовалось бы много времени и усилий, чтобы внести это изменение, чтобы получить обратно один IP-адрес на подсеть, и в скольких случаях, когда вам нужны дополнительные IP-адреса, будет ли достаточно только одного адреса? Гораздо проще добавить вторую подсеть или увеличить текущую подсеть, потенциально предоставляя вам много адресов для использования вместо одного, при этом не внося существенных изменений в любое программное или аппаратное обеспечение.

Источник
Другие вопросы по тегам