Существует несколько причин, по которым в сети IP может использоваться несколько физических сетей:
- Различные топологии — зачастую (особенно в исследовательских организациях) в сети может использоваться несколько ЛВС различных типов (например, Ethernet и сети с кольцевой топологией).
- Присущие используемым технологиям ограничения — большинству топологий ЛВС присущи те или иные ограничения (электрические параметры, число хостов в ЛВС, общая протяженность кабеля). Использование подсетей позволяет достаточно просто преодолеть эти ограничения (особенно ограничение протяженности кабеля).
- Насыщение сети — в локальных сетях могут возникать ситуации, когда небольшая группа хостов фактически монополизирует полосу пропускания сетевой среды. Общим решением таких проблем является сегментирование сети (разбиение на несколько фрагментов) с организацией раздельных кабельных систем.
- Использование каналов "точка-точка" — иногда "локальная сеть" (например, кампусная сеть университета) разделена на несколько фрагментов (например, ЛВС отдельных зданий), соединенных между собой скоростными каналами "точка-точка".
Организации, имеющие более одной ЛВС могут выбрать один из трех вариантов распределения адресов IP:
- Получить отдельный блок адресов для каждой локальной сети и не использовать подсетей.
- Использовать для всей организации общий номер сети и распределять адреса независимо от расположения хостов (принадлежности хостов к ЛВС). Такой вариант получил название transparent subnets (прозрачные подсети).
- Используя один номер сети, разделить адресное пространство на несколько подсетей в соответствии с имеющимися ЛВС. Такой вариант называется explicit subnets (явные подсети).
Каждый из вариантов имеет свои преимущества и недостатки. Первый вариант не требует добавления или изменения протоколов, но ведет к разрастанию таблиц маршрутизации Internet. Информация о внутренней структуре сети распространяется повсюду, хотя она мало кому нужна и в большинстве случаев не используется. В некоторых реализациях шлюзов может возникнуть проблема нехватки пространства в таблице маршрутов, поэтому такой вариант лучше не использовать.
Второй вариант требует использования неких соглашений или протоколов, позволяющих объединить множество ЛВС в одну сеть IP. Например, этот вариант можно реализовать в ЛВС, где каждый адрес IP транслируется в аппаратный адрес с использованием протокола ARP, имея мосты между ЛВС, которые будут перехватывать запросы ARP для нелокальных адресатов (см. RFC-925 [2]). Однако такое решение возможно не для всех технологий ЛВС, особенно в тех случаях, когда технология не использует протокол ARP или ЛВС не поддерживает широковещания. Более сложная проблема состоит в том, что мосты должны узнавать к какой ЛВС принадлежит хост, возможно используя для этого широковещательные рассылки. По мере увеличения числа ЛВС расходы на поддержку такого широковещания будут быстро возрастать; расти будет и размер кэша трансляции, требуемого для преобразования адресов.
Третий вариант используется для явной поддержки подсетей. Он тоже имеет свои недостатки — в частности, требуется модификация протокола IP, которая влечет за собой необходимость изменения существующих реализаций IP (если планируется использовать их с подсетями). Однако требуемые изменения сравнительно невелики и после их внесения проблема будет эффективно решена. Кроме того, этот вариант не требует каких-либо изменений для обеспечения совместимости с существующими хостами и сетями, не поделенными на подсети.
После выбора одного из вариантов может оказаться, что хосты, которые предполагалось использовать в среде без подсетей, попадут в одну из подсетей (см. RFC-917 [1]). Такое решение может быть полезно в тех случаях, когда нет возможности явно поддерживать подсети или требуется постепенный переход.