Можно ли смешивать IPv4 и IPv6 в одной подсети?

Короткий ответ: смешивать IPv4 и IPv6 «в одной подсети» в смысле одного логического L3-префикса нельзя — это разные протоколы и семейства адресов. Однако на одном и том же канальном сегменте (например, в одном VLAN) их можно и рекомендуется запускать одновременно как dual-stack: каждому интерфейсу выдаются независимые адреса IPv4 и IPv6, а маршрутизатор анонсирует два префикса. Итак, в одном L2-сегменте — да, в одном L3-префиксе — нет 🔗🌐.

Термины и смысл вопроса 🧭

Под «одной подсетью» часто подразумевают разные вещи: L3-префикс (например, 192.0.2.0/24) или L2-сегмент/VLAN. Для IPv4 и IPv6 не существует общего L3-префикса, так как это разные адресные семейства. Но один и тот же L2-сегмент может нести одновременно оба стека, и устройства будут общаться по любому из них независимо.

На практике это выглядит так: в VLAN 10 у шлюза SVI настраивается IPv4-адрес 192.168.10.1/24 и IPv6-адрес 2001:db8:10::1/64, а хосты в том же VLAN получают свои адреса обоих типов. Такой режим и называется dual-stack 🧩.

Сопоставление механизмов IPv4 и IPv6 📊

Как выглядит «смешивание» на практике (dual-stack) 🔧

Dual-stack означает, что один и тот же порт/интерфейс L2 несёт два логических L3-пространства адресов. Устройства получают один IPv4-адрес и один или несколько IPv6-адресов (глобальный, временный для приватности, link-local). При выборе пути приложения ориентируются на DNS и локальные правила (Happy Eyeballs, RFC 6555), чаще предпочитая IPv6 при равной доступности.

Пример адресного плана для одного VLAN: 192.168.10.0/24 и 2001:db8:10::/64. Шлюз: 192.168.10.1 и 2001:db8:10::1. Клиент ПК: 192.168.10.50 (DHCPv4), 2001:db8:10::abcd (SLAAC) и fe80::… (link‑local). Всё это одновременно и без конфликтов 🚦.

Минимальная конфигурация (примеры) 💻

Cisco IOS (SVI для VLAN 10):

interface Vlan10
 ip address 192.168.10.1 255.255.255.0
 ipv6 address 2001:db8:10::1/64
 ipv6 nd managed-config-flag   ! если ожидается DHCPv6
 ipv6 nd other-config-flag     ! если только дополнительная инфа (DNS)
 no shutdown

Linux (systemd-networkd, пример):

[Match]
Name=eth0

[Network]
Address=192.168.10.50/24
Gateway=192.168.10.1
Address=2001:db8:10::50/64
Gateway=2001:db8:10::1
DNS=192.168.10.10
DNS=2001:db8:53::10

Проверка связности:

# IPv4
ping 192.168.10.1

# IPv6
ping -6 2001:db8:10::1
ping fe80::1%eth0

Когда это уместно и почему это работает 📦

Одновременная работа IPv4 и IPv6 уместна, когда часть сервисов доступна только по IPv4, а часть — по IPv6, либо когда вы переходите к IPv6‑first/IPv6‑only архитектуре и сохраняете обратную совместимость. Стек TCP/IP позволяет держать параллельные протоколы L3 и развивать маршрутизацию и политики независимо. Сетевое оборудование давно умеет обрабатывать такие кадры и метаданные, разделяя IPv4/ARP/IPv6/ICMPv6 на уровне EtherType.

Типовые шаги внедрения dual-stack 🧱

• 🧭 Спланируйте префиксы: для каждого VLAN назначьте один IPv4-префикс и один IPv6-префикс (/64 на LAN).
• ⚙️ Обновите маршрутизаторы/коммутаторы: включите IPv6, RA, политики безопасности (RA Guard, ACLv6).
• 🛡️ Синхронизируйте firewall: дублируйте правила для IPv4 и IPv6, учтите отсутствие NAT в IPv6.
• 📡 Настройте DNS: добавьте записи A и AAAA, проверьте предпочтения резолвера и таймауты.
• 🧪 Проведите тесты: проверка PMTUD, доступности сервисов, работоспособности DHCPv4/DHCPv6/SLAAC.
• 📈 Мониторинг: отдельные графики и алерты по v4 и v6, Netflow/IPFIX с обоих стеков.

Особенности и подводные камни 🐾

Безопасность. Многие сети полагаются на NAT44 как на «щель безопасности»; в IPv6 такого слоя нет, и это хорошо с архитектурной точки зрения, но требует чётко настроенных stateful-файрволов и ACLv6. Правила фильтрации должны быть настроены и проверены для обоих стеков 🛡️.

RA и DHCPv6. В IPv6 существует Router Advertisement (RA), который объявляет префиксы и шлюз. Неправильные или злонамеренные RA могут «увести» трафик (rogue RA). Включайте RA Guard на access-портах и следите за тем, кто может рассылать RA в сегменте 🚨.

MTU и PMTUD. IPv6 опирается на Path MTU Discovery и не допускает фрагментации на маршрутизаторах. Неправильно настроенные промежуточные устройства или фильтрация ICMPv6 ломают большие потоки. Разрешайте необходимые типы ICMPv6 и проверяйте MTU, особенно на туннелях ✈️.

Размер префикса на LAN. Для SLAAC ожидается /64. Уменьшение префикса на LAN может приводить к несовместимостям с большинством стеков и функций (например, privacy extensions). Используйте /64 на обычных канальных сегментах и /127 на p2p‑линках 📐.

DNS и выбор стека. Добавив AAAA, вы можете неожиданно переключить часть клиентов на IPv6, где ещё нет эквивалентной фильтрации или наблюдаемости. Раскатывайте AAAA поэтапно, используя канареечные записи, и контролируйте поведение клиентов (Happy Eyeballs) 🐤.

Пример проектирования для одного VLAN 🧭

1. Назначьте VLAN 10: IPv4 192.168.10.0/24; IPv6 2001:db8:10::/64.
2. Шлюз L3 (SVI): 192.168.10.1; 2001:db8:10::1.
3. Включите RA и, при необходимости, DHCPv6 (Managed/Other флаги).
4. DHCPv4 выдаёт .50–.200, DNS — v4 и v6 адреса резолвера.
5. Firewall: явные правила inbound/outbound для TCP/UDP/ICMP в обоих стекаш, разрешите обязательный ICMPv6.
6. Мониторинг: проверки ping v4/v6, HTTP(S) по A/AAAA, экспорт Netflow v9 + IPFIX.

Снипы конфигураций и записи DNS 🧩

Пример фрагмента DNS-зоны:

www     IN A     198.51.100.42
www     IN AAAA  2001:db8:20::42
api     IN A     203.0.113.17
api     IN AAAA  2001:db8:30::17

ACL на граничном маршрутизаторе (идея):

ip access-list extended OUTBOUND_V4
 permit tcp any any eq 80
 permit tcp any any eq 443
 deny   ip any any log

ipv6 access-list OUTBOUND_V6
 permit tcp any any eq 80
 permit tcp any any eq 443
 deny   ipv6 any any log

Документы и стандарты (в качестве источников) 📚

• RFC 8200 — Internet Protocol, Version 6 (IPv6) Specification.
• RFC 4861 — Neighbor Discovery for IP version 6 (ND).
• RFC 4862 — IPv6 Stateless Address Autoconfiguration (SLAAC).
• RFC 4291 — IP Version 6 Addressing Architecture.
• RFC 6724 — Default Address Selection for IPv6.
• RFC 6555 — Happy Eyeballs: Success with Dual-Stack Hosts.
• RFC 7421 — Analysis of the 64-bit Boundary in IPv6 Addressing.
• RFC 6177 — IPv6 Address Assignment to End Sites.

Кратко об ответе на главный вопрос 🧠

Смешивать IPv4 и IPv6 в одном L3-префиксе нельзя, но на одном L2-сегменте их одновременно запускать можно и нужно (dual-stack). Планируйте раздельные префиксы (например, /24 и /64), настраивайте RA/DHCPv6, дублируйте политики безопасности и мониторинга, и следите за MTU и ICMPv6. Это обеспечит плавный переход и высокую совместимость 🌉.

FAQ по смежным темам ❓

Нужен ли NAT в IPv6 и чем он отличается от NAT в IPv4? 🛂

В классической модели IPv6 NAT не нужен: глобально маршрутизируемые адреса позволяют строить сквозную связность и упрощают архитектуру. Защита периметра обеспечивается не NAT, а stateful-фильтрацией и грамотными ACLv6. Существуют механизмы NPTv6 (prefix translation), но применяются они редко и для специфических задач, а не как универсальная замена NAT44. При миграциях к IPv6-only иногда используют NAT64/DNS64 для доступа к IPv4-ресурсам; это не «NAT для IPv6», а трансляция между семьями адресов. Практика показывает, что отказ от NAT как от средства «безопасности по умолчанию» требует дисциплины в настройке фаерволов и аудита. Если вы всё ещё полагаетесь на NAT как на барьер, пересмотрите модель угроз и примените сегментацию, фильтрацию и микросегментацию. В итоге, IPv6 и безопасность отлично уживаются без NAT, но операционные процессы должны это учитывать.

Можно ли сделать сеть только на IPv6 и как дать ей доступ к ресурсам IPv4? 🌉

Да, сеть IPv6-only становится всё популярнее, особенно в мобильных и облачных средах. Чтобы такие клиенты доставали IPv4-ресурсы, применяют комбинации NAT64 + DNS64, а также 464XLAT (CLAT на хостах и PLAT в сети). Эти механизмы инкапсулируют или транслируют трафик так, чтобы приложения, не знающие о различиях стеков, продолжали работать. Важно обеспечить корректную резолюцию DNS: когда у домена нет AAAA, DNS64 синтезирует запись на основе A и префикса NAT64. Не все приложения одинаково дружелюбны к таким схемам, поэтому пилотирование и совместимость критичны. Производительность NAT64 зачастую отличная, но внимательно выбирайте оборудование и следите за асимметрией маршрутов. В операционных сетях IPv6-only даёт выигрыш в адресном пространстве и упрощении, но потребует обучения команды и отдельного мониторинга.

Как выбрать размер префикса IPv6 для LAN и можно ли использовать /120? 📐

Для обычных локальных сегментов рекомендуемый размер — /64, так требует и ожидает SLAAC и множество реализаций. Использование /120 ради «экономии адресов» в IPv6 лишено смысла и может ломать автоконфигурацию, приватные временные адреса и некоторые функции безопасности. На точках точка‑точка оправдано /127, что предотвращает избыточные адреса и некоторые атаки. В дата-центрах можно применять /64 на серверных VLAN, а планирование выполняют за счёт множественных /64, а не экономии внутри одного префикса. Если вы используете DHCPv6 без SLAAC, теоретически можно уйти от /64, но совместимость и поведение драйверов/OS могут неприятно удивить. При проектировании учитывайте будущий рост и целостность схемы адресации. В большинстве сценариев придерживайтесь /64 и проблем будет меньше.

Какие типичные ошибки при внедрении dual-stack встречаются чаще всего? 🐞

Первая ошибка — забыть про политику безопасности для IPv6 и оставить сегмент «дырявым», считая, что фильтры IPv4 достаточно покрывают угрозы. Вторая — некорректно настроенный ICMPv6, что ломает PMTUD и вызывает загадочные «подвисания» приложений. Третья — публикация AAAA-записей без проверки доступности сервиса по IPv6 и маршрутов обратной стороны. Четвёртая — игнорирование RA Guard, что открывает дорогу для rogue RA от случайно включённых маршрутизаторов. Пятая — неучёт приватных временных адресов на клиентах, усложняющих логирование и корреляцию событий. Шестая — попытка «экономить» адресное пространство IPv6 через /120 в LAN, приводящая к несовместимостям. И, наконец, отсутствие мониторинга и метрик отдельно по v4 и v6 мешает быстро локализовать проблемы.

Как правильно тестировать доступность сервисов по A/AAAA и поведение клиентов? 🧪

Начните с проверки резолюции: nslookup/dig должны возвращать и A, и AAAA для целевых имён. Затем проверьте маршрутность: traceroute/traceroute6 позволит увидеть, где теряется трафик. Используйте curl -4/-6 и браузеры с включённой телеметрией сетевых запросов, чтобы оценить реальные тайминги и Happy Eyeballs. Обязательно проверьте работу крупного MTU и реакцию на ICMPv6 Packet Too Big. Добавьте синтетические проверки в мониторинг, разделяя IPv4 и IPv6, а также гистограммы задержек. Проведите канареечный релиз AAAA — добавляйте записи постепенно и наблюдайте за ошибками и откатами. Наконец, соберите логи на балансировщиках и фаерволах с разбивкой по семействам адресов, чтобы быстро видеть диспропорции и регрессии.

По материалам сайта посвященному аренде подсети /24