Кратко

  • RFC 1918 выделил три повторно используемых блока IPv4. Адрес в них уникален лишь внутри одного предприятия или группы, согласовавшей общий план, а глобальная регистрация для него не проводится.
  • Две изолированные сети вправе назначить одно число разным узлам. Слияние меняет область, в которой требуется уникальность, и превращает два корректных локальных назначения в общий конфликт.
  • Запись адреса, маршрут, трансляция, удостоверение стороны и результат приложения отвечают на разные вопросы. Успешная доставка пакета не гарантирует, что ответил задуманный узел.

Маршрут не знает историю адреса

Пусть в сети A 10.3.2.1 означает сервер каталогов, а в сети B — контроллер здания. У каждого адреса есть внутреннее имя, шлюз и ответственная команда. Пока домены разделены, получателю не нужно указывать, к какой компании относится число: кабельная и административная граница уже дала этот контекст.

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

Именно здесь проявляется экономия RFC 1918. Координацию не требовали до локального использования. Платой стала будущая работа, если множество взаимодействующих узлов расширится. Уникальность осталась необходимой, но область её действия была уменьшена.

Спор о будущем начался в 1994 году

RFC 1597, опубликованный в марте 1994 года, предложил резервировать повторно используемое пространство для частных сетей. Он разделил узлы по потребности во внешней связности. Кассовые аппараты, внутренние рабочие станции, информационные экраны и интерфейсы маршрутизаторов могли использовать TCP/IP внутри предприятия, не занимая глобально уникальный ресурс.

В июле появился RFC 1627 — критика под названием Network 10 Considered Harmful. Авторы защищали глобальную уникальность не как административный ритуал, а как возможность непредвиденного будущего взаимодействия. Компании сотрудничают и сливаются, закрытый сервис становится внешним, лицензии и конфигурации закрепляют число. Документ приводит пример перенумерации в Apple, однако данный пакет не содержит независимого подтверждения числа узлов, затрат или полного результата. Этот эпизод показывает аргумент авторов, а не измеренную частоту проблемы.

В феврале 1996 года RFC 1918 стал BCP 5 и объявил устаревшими как RFC 1597, так и RFC 1627. Eliot Lear подписал и критику, и итоговый документ. Новая практика не вычеркнула предупреждение. Она сохранила повторное использование и прямо включила в список недостатков перенумерацию при объединении ранее несогласованных частных сетей.

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

Частное использование — правило области, а не титул

Три блока RFC 1918: 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16. Предприятие может использовать их без согласования с IANA или Internet Registry; другие предприятия могут выбрать те же числа. Документ обещает уникальность только внутри предприятия либо набора предприятий, совместно координирующих это пространство.

Нынешний реестр IANA по-прежнему помечает эти блоки как Private-Use и не Globally Reachable. Такая запись не устанавливает, кто «настоящий» владелец частного /24. Мирового приоритета не существует, потому что повторяемость задана намеренно.

Но адресный план работает лишь при согласованности границ. RFC 1918 запрещает распространять сведения о частных маршрутах по межкорпоративным каналам, не рекомендует пересылать через них пакеты с частным источником или назначением и требует удерживать косвенные ссылки, включая DNS, внутри предприятия. Локальный адрес и глобально видимое имя описывают разные аудитории и создают неоднозначность.

Частный адрес не является и средством аутентификации. В разделе Security Considerations RFC 1918 сказано, что вопросы безопасности не рассматриваются. Фильтр может ограничивать путь, но само число не удостоверяет узел или пользователя.

При слиянии нет стороны с лучшим правом на 10/8

RFC 1918 отдельно рассматривает два риска: объединение нескольких частных internets и последующее желание организаций установить IP-связность. В обоих случаях уникальность может нарушиться. Совет случайно выбирать внутренние подблоки уменьшает вероятность совпадения, но не создаёт гарантии или координатора.

Поэтому решение не должно следовать старшинству использования. Необходимо выяснить, какой сегмент легче изменить, какой сервис превратил адрес в устойчивую деловую идентичность, кто контролирует конфигурацию, кто способен проверить результат и кто понесёт простой. Одни зоны можно перенумеровать, другие связать через proxy или трансляцию, третьи оставить разделёнными.

В RFC 1918 сказано, что перевод узла между частным и публичным статусом требует изменить IP, соответствующие DNS-записи и файлы конфигурации на других узлах. DHCP способен облегчить механику, но не назначает ответственность и не обнаруживает все скрытые зависимости.

Спор «чья сеть неправильна» отвлекает от распределения стоимости. Обе сети могли соблюдать прежнее правило. Новая область требует нового решения.

Address realm возвращает пропущенную координату

RFC 2663 в 1999 году определил address realm как сетевой домен, где адреса уникально назначены сущностям, а маршрутизация находит их по этим адресам. Термин позволяет записать полное значение: не просто число, а число в конкретном realm.

Традиционный NAT связывает частный и внешний realm заменой представления, но предполагает, что пространства не перекрываются. Если один адрес уже имеет значение с обеих сторон, RFC 2663 описывает twice NAT, меняющий источник и назначение. На каждой стороне появляется пригодное для маршрутизации представление другой, но исходное частное число не становится глобально уникальным.

RFC 3022 раскрывает эксплуатационные последствия. Basic NAT отображает адреса, NAPT включает транспортные идентификаторы. Запрос и ответ должны проходить через согласованное состояние. При смене устройства поток может оборваться, если новый транслятор не знает отображения. Метод сохраняет внутреннюю нумерацию, но лишает IP-адрес сквозного значения и переносит дополнительную память в сеть.

Карта становится доказательством. Для расследования нужны исходный realm, время, протокол, внутреннее и внешнее представления и устройство, владевшее состоянием. Один правильный адрес без этих координат способен обозначать несколько событий.

Неверный узел может ответить без ошибки транспорта

RFC 5684 опубликован в 2010 году как Independent Submission, а не документ IETF Standards Track. Он разбирает перекрытие частных пространств при многоуровневом NAT и удалённом VPN. В одном примере адрес вышестоящего DNS-резолвера совпадает с локальным узлом; запрос доставляется локально. В другом удалённый сервис может быть принят за ожидаемый корпоративный.

Документ называет это mistaken end host identity. Сбой коварен тем, что ответ возможен. Для описанных схем предлагаются неперекрывающиеся или глобальные адреса для некоторых критичных сервисов и сквозная аутентификация вместо доверия только к исходному IP.

RFC 5684 не измеряет распространённость таких случаев при слияниях. Его доказательная ценность уже: он показывает механизм, при котором доступность и идентичность расходятся. Конфигурация подтверждает локальное назначение, маршрут — решение пересылки, карта — преобразование, credential — сторону, приложение — деловой результат. Зелёный тест одного слоя не заменяет остальные.

100.64/10 принадлежит другому операционному периметру

RFC 6598 в 2012 году выделил 100.64.0.0/10 как Shared Address Space для соединения CGN провайдера с оборудованием клиента. Документ прямо отличает его от корпоративного частного пространства RFC 1918. В таблице IANA обе категории специального назначения не являются глобально достижимыми, но имеют разные предполагаемые границы и ответственных операторов.

Домашняя сеть, предприятие и сеть провайдера — не единое «внутреннее» пространство. Каждое имеет свой realm, правила маршрутизации, имена и поверхность столкновения. Одинаковый признак недоступности из глобальной сети не делает назначения взаимозаменяемыми.

RFC 1918 не отказался от уникальности. Он сделал её локальной там, где глобальная была не нужна. Поэтому две сети оставались одновременно правильными, пока жили отдельно. После соединения общий оператор должен вернуть отсутствующий контекст: сохранить границы, создать проверяемые отображения либо изменить номера — и отдельно удостоверить, какой узел действительно ответил.

Источники