Каждый из вариантов имеет свои преимущества и недостатки. Первый вариант не требует добавления или изменения протоколов, но ведет к разрастанию таблиц маршрутизации Internet. Информация о внутренней структуре сети распространяется повсюду, хотя она мало кому нужна и в большинстве случаев не используется за пределами организации. В некоторых реализациях шлюзов может возникать проблема нехватки пространства в таблице маршрутов, поэтому такой вариант лучше не использовать.
Второй вариант требует использования неких соглашений или протоколов, позволяющих объединить множество ЛВС в одну сеть IP. Например, этот вариант можно реализовать в ЛВС, где каждый адрес IP транслируется в аппаратный адрес с использованием протокола ARP, имея мосты между ЛВС, которые будут перехватывать запросы ARP для нелокальных адресатов. Однако такое решение возможно не для всех технологий ЛВС, особенно в тех случаях, когда технология не использует протокол ARP или ЛВС не поддерживает широковещания. Более фундаментальная проблема заключается в том, что мосты должны узнавать к какой ЛВС принадлежит хост, возможно используя для этого широковещательные рассылки. По мере увеличения числа ЛВС расходы на поддержку такого широковещания будут быстро возрастать; расти будет и размер кэша трансляции в мостах, требуемого для преобразования адресов.
Третий вариант рещает ключевую проблему — существующие стандарты предполагают, что все хосты в сети IP подключены к одной ЛВС. Решение заключается в явной поддержке подсетей. Этот вариант тоже имеет недостатки — в частности, требуется модификация протокола IP, которая влечет за собой необходимость изменения существующих реализаций IP (если планируется использовать их с подсетями). Однако требуемые изменения сравнительно невелики и после их внесения проблема будет эффективно решена. Кроме того, этот вариант не требует каких-либо изменений, которые будут несовместимы с существующими хостами в сетях без разбиения на подсети.
После выбора одного из вариантов может оказаться, что хосты, которые предполагалось использовать в среде без подсетей, попадут в одну из подсетей, как описано ниже. Такое решение может быть полезно в тех случаях, когда нет возможности явно поддерживать подсети или требуется постепенный переход. С учетом этого для использования второго варианта, описанного выше, нет достаточно веских причин.
В остальной части этого документа описывается модель разбиения сетей IP на подсети.