Недавно наткнулся на эту ветку: (Спросили, есть ли NAT64/DNS64 в планах развития ROSv5). Ну, спустя 6 лет, можно с уверенностью сказать — ответ на тот вопрос был категоричным «да ну его». За эти годы я в целом стал на сторону идеологов, которые чуть ли не религиозно против всякого NAT в мире IPv6. Я до сих пор считаю, что stateful NAT66 с возможностью many-to-one — это зло, которое не должно вторгаться в IPv6. Можно было бы избавиться от всей этой возни с обходом NAT, к которой мы так привыкли. Так ведь и задумывалось — всё должно было работать иначе. Раньше не было таких проблем, можно вернуться к нормальному состоянию!
Но теперь я понимаю, что есть случаи, когда NAT в мире IPv6 оправдан:
NAT64 и Stateless prefix translation
NAT64 (и stateless, и stateful) — вот основная тема того форума, что я прикрепил выше. Многие (включая меня) поначалу скептически относились, считая, что двойной стек — это единственно правильный путь, и что NAT — это проблема. IPv6 с самого начала, по идее, должен быть свободен от NAT, и так будет всегда. Мне всё еще кажется, что двойной стек — лучший вариант, но теперь я понимаю, что это не валидный аргумент против NAT64.
NAT64 — это функция межсетевого взаимодействия, которая даёт возможность напрямую общаться параллельным мирам internet4 и internet6. Когда-нибудь, в далёком будущем, последний IPv4-адрес отключат, и все будут рады. В тот день NAT64 уже не понадобится, так что нет смысла критиковать NAT64, мол, лучше двойной стек, чем межсетевое взаимодействие.
Похоже, большинство (включая меня) не до конца поняли суть NAT64. Обычно его считают инструментом для ранних пользователей IPv6, которые выкидывают IPv4 из сети и используют NAT64+DNS64 для доступа к «старому» IPv4-интернету. Только кто-то, кто всерьёз идеализирует эту тему, станет сразу отказываться от IPv4 в своей сети, рискуя получить проблемы с NAT64.
Так что хотя NAT64+DNS64 позволяет кому-то начать использовать IPv6 (а честно говоря, уже странно называть внедрение IPv6 сегодня «ранним» — посмотрите, Netflix уже можно смотреть только по IPv6), основное назначение NAT64 совсем в другом.
NAT64 позволяет сетям конечных пользователей работать как острова двойного стека, переходящие через океан IPv6, чтобы добраться до IPv4-интернета. Настоящая польза NAT64 — в инфраструктуре провайдеров, где IPv4-адреса обязательно должны быть публичными, а их количество практически иссякло и действует жёсткий контроль.
Stateless NAT64 в ROS позволил бы использовать роутеры Mikrotik как компонент CLAT в развертывании 464XLAT. 464XLAT гораздо удобнее для конечных пользователей, чем просто v6-only с NAT64.
Почему? Из-за IPv4-адресов в явном виде! Если нужно общаться с хостом только по его IPv4-адресу, DNS64 тут не поможет, и IPv6-хост просто не сможет с ним связаться (если не поставить CLAT у каждого устройства, а это, по-моему, совсем нереально). Если в сети пользователя внутренне двойной стек, устройства могут спокойно работать без каких-либо дополнительных настроек и даже не подозревать, что их IPv4 — отдельный остров.
По факту, даже сегодня IPv4 — это уже остров, только остров с RFC1918 (частными адресами), которые перед выходом в интернет переводятся на публичные IP. NAT64 просто меняет «океан» с пресной воды IPv4 на солёную воду IPv6, образно говоря.
NAT64 не только освобождает провайдера от необходимости выдавать уникальный публичный IP каждому клиенту (как CGNat), но и избавляет клиента от двойного NAT. Провайдер может запустить централизованный (или распределённый) IPv4-шлюз (stateful NAT64) в роли PLAT в архитектуре 464XLAT, и NAT будет происходить прямо между внутренним частным IPv4 клиента и пулом публичных IPv4-серверов.
Кстати, PLAT не обязательно должен запускать провайдер. Новые провайдеры могут с самого начала работать только на IPv6, а IPv4-соединение просто передавать через внешнего поставщика. Для клиентов это прозрачно — когда они решат, что IPv4 им больше не нужен, могут просто отключить его. Раз — и готово.
Stateless Prefix Translation
Это ещё одна NAT-технология в IPv6, которую я теперь принимаю, несмотря на прошлый категоричный запрет NAT. Многопровайдерные сети скорее всего потребуют такой функционал, чтобы не заводить BGP. Ещё это полезно для организаций, чьи провайдеры настойчиво меняют IPv6-префиксы. Представьте, что IP вашего принтера постоянно меняется по прихоти провайдера.
Я не так сильно в восторге от префиксного транслятора, как от NAT64, но считаю его полезным инструментом. Хотелось бы, чтобы такие задачи решались более современными способами. Например, проблему с мульти-хомингом можно решить через протоколы вроде MPTCP и SCTP. Если у устройств будет по адресу от каждого провайдера, они смогут автоматически распределять нагрузку между всеми доступными каналами без сложных настроек в роутерах.
А вопрос с динамическими префиксами у провайдеров — это остаток менталитета IPv4, когда ресурсы надо назначать динамически из-за ограниченности пулов, оверселлинга и для ограничения запуска серверов у домашних пользователей. При таком большом адресном пространстве не вижу причин, почему пользователям нельзя было бы выделять постоянные адреса, а провайдеры при помощи условий обслуживания просто блокировали бы входящие соединения для «бизнес-класса».
Однако для этого нужно менять массовое мышление в сообществе интернет-провайдеров, и в ближайшем будущем к такой практике переходить не стоит ждать. Пока что префиксная трансляция — это способ обойти проблему, не дожидаясь, когда мир проснётся.
Знаю, получилось целое эссе, но если вы дочитали, надеюсь, я помог немного прояснить, почему NAT не всегда зло в мире IPv6, при этом оставаясь приверженцем идеи прямой адресации от конца до конца как цели Интернета.
Но теперь я понимаю, что есть случаи, когда NAT в мире IPv6 оправдан:
NAT64 и Stateless prefix translation
NAT64 (и stateless, и stateful) — вот основная тема того форума, что я прикрепил выше. Многие (включая меня) поначалу скептически относились, считая, что двойной стек — это единственно правильный путь, и что NAT — это проблема. IPv6 с самого начала, по идее, должен быть свободен от NAT, и так будет всегда. Мне всё еще кажется, что двойной стек — лучший вариант, но теперь я понимаю, что это не валидный аргумент против NAT64.
NAT64 — это функция межсетевого взаимодействия, которая даёт возможность напрямую общаться параллельным мирам internet4 и internet6. Когда-нибудь, в далёком будущем, последний IPv4-адрес отключат, и все будут рады. В тот день NAT64 уже не понадобится, так что нет смысла критиковать NAT64, мол, лучше двойной стек, чем межсетевое взаимодействие.
Похоже, большинство (включая меня) не до конца поняли суть NAT64. Обычно его считают инструментом для ранних пользователей IPv6, которые выкидывают IPv4 из сети и используют NAT64+DNS64 для доступа к «старому» IPv4-интернету. Только кто-то, кто всерьёз идеализирует эту тему, станет сразу отказываться от IPv4 в своей сети, рискуя получить проблемы с NAT64.
Так что хотя NAT64+DNS64 позволяет кому-то начать использовать IPv6 (а честно говоря, уже странно называть внедрение IPv6 сегодня «ранним» — посмотрите, Netflix уже можно смотреть только по IPv6), основное назначение NAT64 совсем в другом.
NAT64 позволяет сетям конечных пользователей работать как острова двойного стека, переходящие через океан IPv6, чтобы добраться до IPv4-интернета. Настоящая польза NAT64 — в инфраструктуре провайдеров, где IPv4-адреса обязательно должны быть публичными, а их количество практически иссякло и действует жёсткий контроль.
Stateless NAT64 в ROS позволил бы использовать роутеры Mikrotik как компонент CLAT в развертывании 464XLAT. 464XLAT гораздо удобнее для конечных пользователей, чем просто v6-only с NAT64.
Почему? Из-за IPv4-адресов в явном виде! Если нужно общаться с хостом только по его IPv4-адресу, DNS64 тут не поможет, и IPv6-хост просто не сможет с ним связаться (если не поставить CLAT у каждого устройства, а это, по-моему, совсем нереально). Если в сети пользователя внутренне двойной стек, устройства могут спокойно работать без каких-либо дополнительных настроек и даже не подозревать, что их IPv4 — отдельный остров.
По факту, даже сегодня IPv4 — это уже остров, только остров с RFC1918 (частными адресами), которые перед выходом в интернет переводятся на публичные IP. NAT64 просто меняет «океан» с пресной воды IPv4 на солёную воду IPv6, образно говоря.
NAT64 не только освобождает провайдера от необходимости выдавать уникальный публичный IP каждому клиенту (как CGNat), но и избавляет клиента от двойного NAT. Провайдер может запустить централизованный (или распределённый) IPv4-шлюз (stateful NAT64) в роли PLAT в архитектуре 464XLAT, и NAT будет происходить прямо между внутренним частным IPv4 клиента и пулом публичных IPv4-серверов.
Кстати, PLAT не обязательно должен запускать провайдер. Новые провайдеры могут с самого начала работать только на IPv6, а IPv4-соединение просто передавать через внешнего поставщика. Для клиентов это прозрачно — когда они решат, что IPv4 им больше не нужен, могут просто отключить его. Раз — и готово.
Stateless Prefix Translation
Это ещё одна NAT-технология в IPv6, которую я теперь принимаю, несмотря на прошлый категоричный запрет NAT. Многопровайдерные сети скорее всего потребуют такой функционал, чтобы не заводить BGP. Ещё это полезно для организаций, чьи провайдеры настойчиво меняют IPv6-префиксы. Представьте, что IP вашего принтера постоянно меняется по прихоти провайдера.
Я не так сильно в восторге от префиксного транслятора, как от NAT64, но считаю его полезным инструментом. Хотелось бы, чтобы такие задачи решались более современными способами. Например, проблему с мульти-хомингом можно решить через протоколы вроде MPTCP и SCTP. Если у устройств будет по адресу от каждого провайдера, они смогут автоматически распределять нагрузку между всеми доступными каналами без сложных настроек в роутерах.
А вопрос с динамическими префиксами у провайдеров — это остаток менталитета IPv4, когда ресурсы надо назначать динамически из-за ограниченности пулов, оверселлинга и для ограничения запуска серверов у домашних пользователей. При таком большом адресном пространстве не вижу причин, почему пользователям нельзя было бы выделять постоянные адреса, а провайдеры при помощи условий обслуживания просто блокировали бы входящие соединения для «бизнес-класса».
Однако для этого нужно менять массовое мышление в сообществе интернет-провайдеров, и в ближайшем будущем к такой практике переходить не стоит ждать. Пока что префиксная трансляция — это способ обойти проблему, не дожидаясь, когда мир проснётся.
Знаю, получилось целое эссе, но если вы дочитали, надеюсь, я помог немного прояснить, почему NAT не всегда зло в мире IPv6, при этом оставаясь приверженцем идеи прямой адресации от конца до конца как цели Интернета.
