RFC 1918 — документ IETF «Address Allocation for Private Internets», принятый в феврале 1996 года. Определяет три блока IPv4-адресов для использования в частных сетях без регистрации в IANA. Маршрутизаторы интернет-провайдеров блокируют трафик этих адресов на границе автономных систем — пакеты с приватными source/destination IP не уходят во внешнюю сеть.
Три диапазона RFC 1918
| Диапазон | CIDR | Количество адресов | Типичное применение |
|---|---|---|---|
| 10.0.0.0 – 10.255.255.255 | 10.0.0.0/8 | 16 777 216 | Корпоративные сети, дата-центры |
| 172.16.0.0 – 172.31.255.255 | 172.16.0.0/12 | 1 048 576 | Docker (172.17.0.0/16 по умолчанию) |
| 192.168.0.0 – 192.168.255.255 | 192.168.0.0/16 | 65 536 | Домашние роутеры, офисы |
Дополнительно: 169.254.0.0/16 — link-local (APIPA, RFC 3927), 127.0.0.0/8 — loopback, 100.64.0.0/10 — shared address space (RFC 6598, для Carrier-grade NAT).
Как работает
Устройства в частной сети получают RFC 1918-адреса через DHCP или статически. Для выхода в интернет трафик проходит через NAT на граничном маршрутизаторе, который подменяет приватный адрес источника на публичный. Внутри инфраструктуры данные центра серверы используют RFC 1918-адреса для межсерверного взаимодействия — это экономит публичные IP и упрощает архитектуру.
В облачных платформах (AWS, GCP, Яндекс.Облако, Selectel) внутренняя сеть между инстансами строится на RFC 1918-пространстве. Публичный IP при необходимости назначается отдельно (Elastic IP в AWS). Docker использует 172.17.0.0/16 для bridge-сети контейнеров, KVM/libvirt — 192.168.122.0/24 для NAT-сети виртуальных машин.
История
До RFC 1918 организации формально должны были регистрировать любые используемые IP-адреса в InterNIC. На практике многие использовали произвольные адреса, что создавало конфликты при подключении к интернету. В 1994 году рабочая группа IETF разработала RFC 1597 (предшественник RFC 1918) с теми же тремя диапазонами. RFC 1918 (1996) заменил его и стал стандартом де-факто. Параллельно RFC 1631 (1994) ввёл NAT — механизм для выхода RFC 1918-сетей в интернет.
На что обращать внимание
Конфликт RFC 1918-адресов — распространённая проблема при VPN-подключении: если домашняя сеть использует 192.168.1.0/24, а корпоративная VPN тоже 192.168.1.0/24, возникает конфликт маршрутизации. Решение: использовать нестандартные подсети (например, 10.200.0.0/24) для корпоративных VPN. При проектировании Docker-сетей следите за перекрытием с существующими подсетями хоста.
Типичные ошибки при использовании RFC 1918
Первая ошибка — выбор 192.168.1.0/24 для корпоративной сети: этот диапазон используется по умолчанию в большинстве домашних роутеров, что вызывает конфликты при VPN-подключении с домашних ПК. Используйте 10.0.0.0/8 или нестандартные подсети 172.16–172.31. Вторая ошибка — не учитывать перекрытие с Docker-сетями: Docker по умолчанию использует 172.17.0.0/16, что конфликтует с RFC 1918 172.16.0.0/12. Задавайте кастомные подсети: docker network create --subnet=10.100.0.0/16. Третья ошибка — не настроить PTR-записи для внутренних адресов: ряд приложений требует корректный reverse DNS даже для RFC 1918-адресов.