Привет! Я Лев, системный администратор технической поддержки в Selectel. Мы с вами живем в мире, окутанном «волшебными» тайнами. Как говорится, в интернете все кажется физикой, когда не знаешь магию.
Вот уже много лет слышно про вот‑вот ожидающийся переход на шестую версию IP‑протокола. И все никак этого не происходит. Да и мало кто задумывается, сколько этих версий вообще существует.
Что такое IP
Переместимся ненадолго во вторую половину прошлого века.
В 1969 году Агентство передовых исследовательских проектов (ARPA, Advanced Research Projects Agency) Министерства обороны США запустило экспериментальную сеть ARPANET, ставшую прародительницей современного интернета. У проекта было несколько целей:
- устранить несовместимость различных хостов из-за разрозненных форматов сообщений;
- сделать сеть децентрализованной, чтобы она оставалась рабочей, даже при выходе отдельных частей из строя;
- повсеместно перейти к коммутации пакетов, а не каналов, чтобы не занимать монопольно всю среду передачи — дробление же сообщений на небольшие независимые фрагменты позволит обмениваться данными одновременно множеству хостов на одной физической линии связи.
Цели хорошие. Но как их осуществить?
Компьютеры сети ARPANET соединялись через специальные шлюзы — маршрутизаторы IMP (Interface Message Processor), которые умели передавать пакеты данных. Однако конечные хосты зачастую «не понимали» друг друга — сказывалась несовместимость разных операционных систем и внутренних стандартов.
Нужен был единый протокол передачи данных.
Его разработкой занялась NWG (Network Working Group) — группа молодых ученых под руководством Стива Крокера, аспиранта из Калифорнийского университета в Лос-Анджелесе.
Примечательно, что руководители ARPA сознательно давали полную свободу молодым романтикам вроде Крокера. И седые профессора, и крупные телекоммуникационные компании того времени, как та же AT&T, попросту не верили в перспективность пакетных сетей и отказывались ими заниматься.
Энтузиасты из NWG справились с задачей. В декабре 1970 года вышел NCP (Network Control Program) — первый единый протокол «хост–хост». Через несколько месяцев его успешной эксплуатации также и сетевой интерфейс ARPANET стал стандартом.
Теперь любой университет или лаборатория ARPA легко подключались к сети — достаточно было просто установить ПО с поддержкой NCP. Он стал основой для первых в истории протоколов прикладного уровня Telnet и FTP и первой сетевой электронной почты.
В 1972 году ARPA была переименована в DARPA (Defense Advanced Research Projects Agency), чтобы подчеркнуть военную направленность (Defence — оборонный).
Именно такое название встречается чаще всего, однако на многих документах тех лет можно заметить первоначальную аббревиатуру — ARPA.
С ростом ARPANET все сильнее сказывались критические архитектурные ограничения NCP. Протокол не поддерживал связь разнородных сетей — таких как, спутниковых и радиосетей. В обработке ошибок NCP полагался на саму ARPANET и при потере пакета не мог запросить его повторную отправку.
Предстояло решить новую задачу, иного уровня — объединить разрозненные сети.
В 1974 произошло знаковое событие, которое сильно повлияло на архитектуру будущей глобальной сети. Винтон Серф и Роберт Кан опубликовали статью «A Protocol for Packet Network Intercommunication» в журнале «IEEE Transactions on Communications», где описали архитектуру нового протокола, получившего название TCP (Transmission Control Protocol).
Самое время задаться вопросом: «Статья же про IP, а TCP тут причем?»
Дело в том, что изначально TCP был единым протоколом, объединяющим функции современных TCP и IP. Его главными преимуществами стали:
- аппаратная независимость — функционирование протокола обеспечивалось поверх любых типов сетевых технологий;
- надежность передачи — реализовывались механизмы управления передачи данных и автоматической ретрансляции утерянных пакетов данных;
- сквозная глобальная адресация — каждому сетевому узлу назначался уникальный идентификатор в масштабах всей сети;
- межсетевое взаимодействие — для интеграции разнородных сетей применялись специализированные устройства.
В 1978 году TCP разделился на две части: собственно сам TCP, отвечающий за надежную доставку данных и управление потоком, а также максимально простой и универсальный IP — фокусирующийся исключительно на адресации и маршрутизации пакетов между сетями. Рождение IP зафиксировали в серии документов — включая исторический IEN 28/RFC 760, позже, в 1981 году, обновленный до знакомого всем RFC 791.
Управление соединениями в то время находилось целиком в ведении сетей. IP снимал с них всю заботу: сам принимал пакет, сам сверял адрес, сам перенаправлял при необходимости. Немаловажно, что при этом IP никак не гарантировал ни правильную очередность движения данных, ни даже сам факт их доставки. Вся ответственность за логику обработки пакетов — на TCP.
Физические сети разной природы IP объединил, в том числе, и благодаря способности «перенарезать» пакеты под требования промежуточных сетей, после чего, на выходе, пересобирать их обратно.
Каналам связи и программам больше не требовалось адаптироваться — они теперь могли вообще ничего не знать друг о друге. Такая архитектурная независимость упростила разработку и повысила надежность ПО. IP оказался способен передавать данные любым способом: по проводам, радиоволнам, телефонным линиям…
Пришло время сплотить абсолютно разнородные сети.
Объединение произошло 1 января 1983 года и получило неофициальное название Flag Day — в американской культуре означающее радикальный, фундаментальный переход из одного состояния в другое. В эту ночь сеть ARPANET целиком перешла с NCP на современный TCP/IP.
Сейчас нам кажется, что речь идет просто об очередном витке развития технологий — каких уже и не счесть. Тогда же происходила настоящая технологическая драма.
Чиновники в DARPA осознавали, что поэтапный, — а значит, и спокойный — переход неосуществим из‑за принципиальной несовместимости протоколов. Обновление должно произойти быстро и повсеместно.
Пришлось не только развернуть информационную кампанию, но и мотивировать участников, даже оказывать на них психологическое давление. Дедлайн был назначен за несколько лет. Владельцам мейнфреймов поручалось написать или установить код для работы с TCP/IP на своих операционных системах.
В новогоднюю ночь администраторы ARPANET полностью и окончательно отключили механизмы обработки NCP на всех маршрутизаторах IMP. Сеть раскололась на две части: из успешно прошедших и опоздавших. Последние, хоть физически и были подключены, оказались не способны обмениваться данными — их пакеты уходили «в никуда».
Прозевавшие дедлайн администраторы — в праздничный день, без сна и новогоднего настроения — в спешке перенастраивали свои мейнфреймы на TCP/IP. Вскоре практически вся ARPANET заработала на новом сетевом стеке.
Провались переход тогда, глобальный интернет появился бы, но с задержкой и был бы другим. Разрозненные ведомственные и коммерческие сети еще долго нащупывали бы путь, как работать совместно.
Прошло несколько месяцев после Flag Day, и ARPANET разделилась. Военная часть закрылась в MILNET, а оставшаяся — вышла в мир и превратилась в то, что мы теперь называем «интернет». Связующей и стал IP, название которого дословно описывает его роль — Internet Protocol.
В современных сетях IP — это протокол третьего уровня модели OSI, он отвечает за идентификацию устройств.
IPv1, IPv2, IPv3
Сколько себя помним, на слуху только IPv4 — не так ли? Но были ли предшественники? Небольшой исторический экскурс удовлетворить любознательность.
Самый первый прообраз IP появился внутри раннего описания объединенного протокола TCP (версия 0 TCP, март 1977 года). В нем еще не было четкого разделения на транспортный и межсетевой уровни, но зачатки IP-функций (адресация, маршрутизация) уже присутствовали.
Информации о первой версии сохранилось очень мало. Известно, что она существовала в виде черновых спецификаций и экспериментальных реализаций в конце 1977 – начале 1978 года.
Вторая версия стала уже задокументированным протоколом. В августе 1977 года в заметке IEN 2 (Internet Experiment Note) она описывалась как отдельный межсетевой протокол с собственным заголовком, в поле Version которого прямо указывалось значение 2.
В феврале 1978 года Винт Серф предложил доработанный формат заголовка в документе IEN 26.
Именно в этот период оттачивались ключевые поля: «время жизни» (TTL), тип сервиса и контрольная сумма. Все это приблизило протокол к его современному виду.
Параллельно в IEN 28 вышла уточненная спецификация, фактически содержавшая элементы будущей третьей версии.
IPv4 не бесконечный
В сентябре 1981 года был опубликован RFC 791, определивший Internet Protocol Version 4, который оказался стандартом на десятилетия.
Основными характеристиками протокола стали:
- 32-битное адресное пространство — дает теоретический максимум в 4,3 миллиарда уникальных адресов;
- фрагментация и сборка дейтаграмм — позволяет передавать данные через сети с различными значениями MTU (Maximum Transmission Unit, определяющий максимальный размер пакета в байтах для прохождения без предварительного разбиения на части);
- заголовок переменной длины — содержит поля для управления маршрутизацией и служебной обработкой пакетов;
- поле TTL — механизм, предотвращающий бесконечное блуждание пакетов в сети за счет ограничения количества переходов.
На момент создания и проектирования IPv4 казалось, что такого количества адресов устройств хватит надолго. К концу 1980‑х годов стали появляться первые коммерческие интернет-провайдеры, предоставляющие доступ к сети на основе TCP/IP для бизнеса и частных лиц.
Интернет стал охватывать все больше и больше людей во всем мире, и уже к началу 1990‑х годов стало очевидно, что 32‑битное адресное пространство IPv4, теоретически позволяющее адресовать около 4,3 млрд устройств, окажется недостаточным для растущего интернета. В 1992 году инженеры IETF начали работу над следующим поколением Internet Protocol.
Во время разработки нового стандарта IP архитекторы сети задумались, как еще можно решить проблему исчерпания адресов в сети и устранить другие ограничения IPv4.
Ответом стала технология NAT (Network Address Translation), позволяющая локальной сети использовать частные IP-адреса из диапазонов RFC 1918 — 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — и выходить в интернет через один публичный IP провайдера.
При исходящем запросе роутер заменяет частный IP источника на свой публичный и записывает порт в таблицу трансляции (NAT table); входящий ответ возвращается по порту тому же устройству. Это работает для TCP/UDP-сессий, где соединение инициируется клиентом, — серверы в интернете «не видят» внутренние адреса.
Технологию трансляции сетевых адресов можно разделить на три подвида.
1. Статический NAT создает фиксированное соответствие «один к одному» между частным IP (например, 192.168.1.10) и публичным (например, 203.0.113.10), которое администратор настраивает вручную.
2. Динамический NAT использует пул публичных IP-адресов, выдавая их внутренним устройствам по принципу «первым пришел — первым обслужен». Когда сессия заканчивается (по таймауту), адрес возвращается в пул для повторного использования — это «многие ко многим» без портов.
3. PAT (Port Address Translation) — самый экономичный вид, где множество устройств (до 65 тыс на IP) делят один публичный адрес, различаясь портами. Роутер ведет таблицу трансляций, сопоставляя внутренние пары «IP‑адрес и порт» с внешними, отслеживая состояние сессий для обратного маршрута. Операторы такой тип NAT называют CGNAT.
Провайдер применяет ту же логику к тысячам клиентов, используя зарезервированный диапазон 100.64.0.0/10 (RFC 6598) для внутренних адресов. Шлюз CGNAT связывает частную «IP‑адрес и порт» клиента с публичной, отслеживая активные сессии в огромной таблице, вмещающей до нескольких миллионов записей.
Один публичный IP, например 203.0.113.1, делится на 50−65 тыс портов между 100−500 пользователями. Такое соотношение вызвано современной сетевой нагрузкой. Одна только набитая рекламой, скриптами и аналитикой веб‑страница может сходу занять десятки портов. Вдобавок, часто за одним IP скрывается целый домашний зоопарк устройств.
«Бесконечный» IPv6
IPv5
Пятая версия была зарезервирована не для продолжения основной линейки IP, а для экспериментального протокола Internet Stream Protocol (ST), ориентированного на передачу мультимедиа в реальном времени.
Позже появилась его обновленная спецификация ST2 (с тем же номером версии), но широкого распространения этот стандарт так и не получил. Источник: ipv4.global.
Разработка нового протокола, первоначально известного как IPng (IP Next Generation), завершилась в 1995 году публикацией RFC 1883, которая и определила IPv6 (Internet Protocol Version 6). Ключевых инноваций оказалось несколько.
1. 128-битная адресация — количестов уникальных адресов равно примерно 340 ундециллионам, что делает их исчерпание практически невозможным.
2. Упрощенная структура заголовка — фиксированный базовый заголовок, оптимизированный для высокоскоростной обработки маршрутизаторами.
3. Автоконфигурация — возможность автоматической настройки сетевых параметров без участия DHCP-серверов. Взамен новая версия предлагает использовать SLAAC — механизм, позволяющий устройствам самостоятельно генерировать уникальный адрес без использования DHCPv6-сервера.
4. NDP (Neighbor Discovery Protocol) вместо ARP — построен на ICMPv6 и полностью заменяет функции предыдущего протокола, а также добавляет обнаружение маршрутизаторов с перенаправлением трафика. Ключевые сообщения включают:
- RS / RA (Router Solicitation / Router Advertisement) — для поиска маршрутизаторов и их настройки;
- NS / NA (Neighbor Solicitation / Neighbor Advertisement) — для сопоставления IP с MAC через solicited-node multicast вместо широковещательной рассылки;
- Redirect — для указания лучших путей.
| Параметр | IPv4 (DHCP/ARP) | IPv6 (SLAAC/NDP) |
| Автоконфигурация адресов | DHCP-сервер | SLAAC без сервера и stateless DHCPv6 |
| Разрешение адресов | ARP broadcast | NDP multicast ICMPv6 |
| Нагрузка на сеть | Высокая от broadcast-запросов | Низкая от multicast-запросов |
| Безопасность | Уязвим к spoofing‑атакам | Использование опций CGA (Cryptographically Generated Addresses) и SEA (Signed Extension Authorization) |
5. Поддержка QoS — встроенные механизмы приоритезации трафика через поле Flow Label минимизируют задержки и потерю пакетов для важных приложений, таких как видеозвонки.
6. Мобильность (Mobile IPv6) — оптимизированная поддержка роуминга и смены точек подключения без разрыва существующих соединений.
Технические и организационные барьеры
Так почему же человечество сразу не перешло на более продвинутый протокол?
Тому несколько причин — например, отсутствие прямой совместимости.
IPv4 и IPv6 — это два совершенно разных протокола, которые не понимают друг друга напрямую. Пакет, отправленный с IPv6-адреса, не может быть доставлен на устройство с IPv4-адресом без специальных переходников. Для этого придумали следующие механизмы.
Dual-Stack — это сетевая конфигурация, которая одновременно поддерживает как IPv4, так и IPv6. Она позволяет устройствам и сетевой инфраструктуре взаимодействовать с использованием взаимозаменяемых протоколов IPv4 или IPv6, обеспечивая совместимость как со старым IPv4, так и с новым IPv6.
Технология Dual Stack (двойной стек) может применяться и на отдельном устройстве, и в масштабах всей сети. Во втором случае одновременную работу с IPv4 и IPv6 должны поддерживать все сетевые узлы, а на их интерфейсах необходимо настроить оба типа IP-адресов.
Клиент понимает, к какому стеку обращаться, в первую очередь благодаря DNS. При запросе домена резолвер возвращает все доступные записи: A для IPv4 и AAAA для IPv6. Наличие AAAA-записи лишь сигнализирует клиенту о том, что сервер поддерживает современный протокол, но не обязывает использовать именно его. Итоговый выбор всегда зависит от приоритетов операционной системы и конкретного приложения.
Для выбора протокола клиент использует алгоритм Happy Eyeballs. Сначала клиент пытается подключиться по IPv6 (с таймаутом 250−300 мс), параллельно инициируя соединение по IPv4. Если ответ по шестой версии приходит быстрее, используется она, в противном случае — IPv4. Такой подход минимизирует задержки в смешанных сетях, где современный протокол иногда работает медленнее предшественника или вовсе недоступен.
На практике это выглядит так.
- Клиент отправляет DNS-запрос для нужного домена — например, example.com.
- В ответ приходят записи обоих типов, например: A (192.0.2.1) и AAAA (2001:db8::1).
- Клиент практически одновременно инициирует TCP-соединение по всем полученным адресам.
- Для работы используется тот протокол, который ответил первым. Этот успешный выбор кешируется вплоть до завершения текущей сессии.
NAT64 — это технология, которая позволяет транслировать адреса между сетями IPv4 и IPv6. Ее ключевое отличие — базовая единица сети использует только одну версию протокола (это может быть, например, локальный компьютер). Важное преимущество такого подхода — перенос всей вычислительной нагрузки по взаимодействию с протоколом IP на маршрутизатор. Оконечные устройства освобождаются от необходимости поддерживать двойной стек.
Каждый из этих методов не только добавляет задержку и сложность в настройке, но и является потенциальной точкой отказа.
Существенное техническое препятствие на пути к полному переходу на IPv6 — наличие в мире большого числа legacy-оборудования. Купленный пять лет назад домашний маршрутизатор, скорее всего поддерживает IPv6.
Теперь представим огромные корпоративные сети с множеством сетевого оборудования десятилетней давности. Значительная часть этой инфраструктуры либо вообще не работает с IPv6, либо делает это чисто номинально, с урезанной функциональностью. Замена такого парка — колоссальные затраты.
Среди множества организационных причин, осложняющих переход на новую версию, можно выделить несколько основных.
Во-первых, финансовый аспект: большинству бизнесов, работающих сейчас с сетевым оборудованием, экономически невыгодно переходить на IPv6. Большие компании, конечно, уже внедряют эту технологию, но предпочтение пока отдается IPv4. Смена стандарта — значительная статья расходов на обучение персонала, обновление ПО, замену железа, время на тестирование, — причем не приносящая сиюминутной прямой прибыли.
Во-вторых, дефицит квалифицированных кадров. На данный момент на рынке доминирует IPv4, и системных администраторов или сетевых инженеров, умеющих работать с шестой версией, все еще мало. Изучение нового стека потребует времени и вложений в сотрудников, что неизбежно повлечет и дополнительные издержки.
В‑третьих, далеко не все сетевое оборудование полноценно поддерживает IPv6.
Текущий уровень внедрения IPv6
Оценить масштабы внедрения IPv6 помогает статистика Google, которая ведется с 2009 года. По данным на апрель 2026 года, с новым протоколом работают 45% пользователей Google. Активнее всего эту версию используют в Индии, Германии и США.
В России уровень внедрения IPv6 составляет около 10%, и в основном протокол применяется мобильными операторами связи и некоторыми провайдерами. В нашей панели управления также можно познакомиться с IPv6 и арендовать адреса этой версии для выделенных серверов.
Утилиты сетевой диагностики для разных версий IP
Для работы с IPv6 на сервере и на локальном компьютере нужно настроить сеть. Рассмотрим примеры конфигурации для Windows Server и Linux.
Windows
Для проверки текущих сетевых параметров в командной строке (cmd) используются следующие команды.
ipconfig /all— отображает полную информацию о конфигурации TCP/IP всех сетевых адаптеров на компьютере. Можно увидеть IP-адрес, маску подсети, основной шлюз, DNS- и DHCP-серверы, MAC-адрес, статус аренды IP и другие параметры для каждого интерфейса (Ethernet, Wi‑Fi, виртуальные адаптеры).route print— выводит таблицу маршрутизации IPv4 и IPv6, показывая, как система направляет пакеты к разным сетям. Отображаются интерфейсы, метрики, а также постоянные и активные маршруты.
Также для Windows можно проверить настройки сетевого адаптера:
По умолчанию в Windows Server ICMP-запросы заблокированы. Перед проверкой необходимо отключить эту блокировку в настройках межсетевого экрана:
Set-NetFirewallRule -Name FPS-ICMP-ERQ-In -Enabled True -Profile Any -Action Allow
Проверим доступность IP‑адреса сервера из нашего примера, а затем удостоверимся, что порт удаленного рабочего стола открыт. По умолчанию служба RDP (Remote Desktop Protocol) использует порт 3389:
ping -6 2a00:ab00:533:1::100
nmap -6 -Pn -p 3389 2a00:ab00:533:1::100
Также для проверки можно воспользоваться сайтом CentralOps.net.
Linux
Посмотрим также, как настройка сети будет выглядеть на Linux. Для проверки используем стандартные команды:
ip address
ip route
Для настройки IPv6 в дистрибутивах Linux, использующих утилиту Netplan (например, Ubuntu), потребуется отредактировать конфигурационный файл в формате YAML. Чаще всего он располагается по пути /etc/netplan/50-cloud-init.yaml.
Файл открывается в любом текстовом редакторе с правами суперпользователя, например:
sudo nano /etc/netplan/50-cloud-init.yaml
На изображении ниже приведен пример конфигурационного файла сети (в разных дистрибутивах могут встречаться несущественные отличия). Также рекомендуем ознакомится со статьей документации о том, как «Подключить дополнительные публичные IP-адреса»:
После внесения изменений в конфигурационный файл сети, изменится IP‑адрес сервера, шлюз, а также добавятся DNS:
Заключение
Кажется, что переход на IPv6 — вопрос времени, а не выбора. Технические преимущества стандарта очевидны: 128-битная адресация, механизм автоконфигурации SLAAC и расширенные возможности для мобильных устройств. Однако на практике глобальная сеть по‑прежнему остается двухстековой.
Сказываются как организационные, так и сугубо технические факторы. С одной стороны, миграцию тормозят высокая стоимость, дефицит профильных специалистов, множество устаревших систем и отсутствие быстрой окупаемости для бизнеса. С другой — аппаратные реализации IPv6 на многих сетевых устройствах все еще остаются «сырыми» и могут содержать критические ошибки.
Вот и получается, что протокол нового поколения успешно применяется лишь в определенных сегментах — мобильные сети, современные облачные сервисы, — где ПО сразу разрабатывалось с учетом новых стандартов. В масштабах же всего интернета ситуация иная.
Наверное, окончательная смена архитектуры неизбежна. Однако IPv4 будет с нами еще очень долго — возможно, не одно десятилетие. Срок полного отказа от старой инфраструктуры теперь зависит исключительно от экономических стимулов, требований регуляторов и стратегий магистральных провайдеров. Вопрос о том, когда именно произойдет этот качественный сдвиг — через пять, десять или двадцать лет, — остается открытым.
