Как сказано в первом комментарии, я также настоятельно рекомендую перейти на двойной стек, поскольку в долгосрочной перспективе это дешевле, чем реализация решений NAT. (Вам все равно придется это сделать, так почему бы не сделать это сейчас?)

Но все же для вашей проблемы есть два возможных решения / обходных пути:

• маршрутизатор с NAT64 ;
• балансировщик нагрузки с собственной поддержкой IPv6, балансирующий серверы за ним через IPv4.

Такой способ сделать службы IPv4 доступными через IPv6 довольно распространен. Вам нужен брандмауэр, который может выполнять статические сопоставления NAT64. Я сам сделал это, используя блоки Juniper SSG.

Однако я заметил некоторые проблемы с фрагментацией. Поскольку заголовок IPv6 больше заголовка IPv4, при преобразовании размер пакета будет немного больше. Это может привести к фрагментации пакета IPv6, и я видел устройства, которые игнорируют весь фрагментированный трафик. Чтобы избежать проблем с пользователями, у которых есть такое неисправное устройство, лучше немного уменьшить MTU на стороне IPv4 (1480 или 1400 - обычные значения), чтобы даже после преобразования размер пакета был меньше 1500 байт.

Ага, Mem совершенно права. Двойной стек и только на общедоступной стороне сети - это обязательный первый шаг ... это реальная задержка. Это не говоря уже о готовности ТАКЖЕ просто отказаться от IPv4.

Устройства NAT будут делать то, что они делали всегда. IPv6 предоставляет частное адресное пространство, но нет возможности гарантировать его глобальную уникальность ... поэтому нам все еще нужен NAT, чтобы гарантировать это. Большинство людей все еще используют NAT и будут постоянно, несмотря на то, что NAT использовалось несколько десятилетий назад. Нет особой необходимости навязывать IPv6 чему-либо внутри вашей сети, которая находится под NAT / SNAT с использованием NAT444 / CGNAT

. Это исследование IPv6, проведенное в 2013 году на правительственном уровне. Отражает временную шкалу и руководство о том, насколько далек мир от доминирования IPv6 и отказа от IPv4, а также все промежуточные требования двойного стека, которые должны будут действовать в течение всего периода перехода.

http: //www.govtech. com / wireless / What-Happened-to-IPv6.html

При поиске устройств для этого NAT ищите поддержку NAT444 / CG-NAT ... Это не то же самое, что NAT64, NAT44 и т. д.

IPv4 будет здесь до 2148 года. Статья ниже http://venturebeat.com/2013/06/07/at-our-current-rate-of-progress-ipv6-will-be-fully-implemented-on-may-10-2048/

Да, конечно, можете. Фактически, это самый мудрый поступок.

Не верьте людям, которые говорят: «О ... вам придется в конце концов переключить всю свою сеть на Ipv6, так что не откладывайте»

Абсолютная чушь.

Я прошел через это на уровне оператора связи.

IPv4 никуда не денется. Он отлично работает для подавляющего большинства организаций из-за RFC1918.

Если ваша организация имеет менее 17 миллионов устройств, требующих IP-адресов, находящихся под вашим прямым юридическим контролем. Тогда IPv6 будет не более чем ограничителем скорости и, конечно же, не повлияет на ваши серверы / рабочие столы. Вот как это сделать:
Предполагая, что вы разбираетесь в классическом дизайне сети.

Ваши пограничные маршрутизаторы используют MPLS / IPv6 / IPv4
Ваши основные маршрутизаторы используют MPLS / IPv6 / IPv4
Ваши маршрутизаторы Distro используют MPLS / IPv6 / IPv4
Внешние интерфейсы вашего балансировщика нагрузки / брандмауэра - IPv6 / IPv4 и подключаются к дистрибутиву в восходящем направлении. F5 поддерживает это довольно честно и без особых усилий, а LTM в качестве входящего межсетевого экрана (намного быстрее, чем межсетевые экраны juni / cisco), поэтому нам не нужно использовать ACLS на маршрутизаторах Distro. Все внутренние интерфейсы Loadbalancer / Firewall являются чистым IPv4 и подключаются к вашей магистрали / листу или к маршрутизаторам и коммутаторам служб / доступа уровня 2, которые также все остаются IPv4, если они даже уровня 3.

Таким образом, вы сохраняете NAT. Вы поддерживаете жесткую границу publicIP / privateIP NAT с такими устройствами, как F5 BIGIP и межсетевые экраны, которые легко обрабатывают IPv6 в IPv4 NAT. Они соединяют ваш публичный уровень дистрибутива с вашим частным уровнем обслуживания / доступа.

Теперь все, что вы решите сохранить NAT (что, вероятно, уже есть), остается IPv4, и все это дерьмовое программное обеспечение хоста IPv6 может быть удалено безнаказанно, потому что только ваш высокий Конечное сетевое оборудование, работающее на общедоступной границе сети yoru, должно беспокоиться об IPv6

Серьезно, будьте мудры. IPv6 никоим образом не обгоняет IPv4 в нашей жизни. При нынешних темпах принятия он не будет соответствовать размерам таблиц IPv4 BGP в течение следующих 200 лет.

Можно ли?

Да.

Вам понадобится реализация NAT64 с отслеживанием состояния. Обычно они используются для предоставления локальным клиентам IPv6 доступа к ресурсам в общедоступном Интернете IPv4, но ничто не мешает вам использовать его, чтобы позволить клиентам IPv6 в общедоступном Интернете получать доступ к локальным ресурсам IPv4. Брандмауэры могут использоваться для ограничения доступа к хостам через шлюз NAT64.

Следует ли это делать?

В общем, я бы сказал нет.

Ключевая проблема этого подхода состоит в том, что вы потеряете информацию об исходном IP-адресе трафика. Просто невозможно втиснуть 128-битный IP-адрес источника в 32-битное поле. Так что будет сложно отследить и сообщить о злоупотреблениях.

Какие есть альтернативы?

Есть несколько. Я представлю их в порядке убывания предпочтения.

Первый вариант - развернуть двойной стек на тех сегментах вашей сети, между серверами и краем сети. Это хорошая практика, когда вы начинаете развертывание IPv6 по всей сети.

Второй вариант - развернуть туннели, ведущие от границы вашей сети к рассматриваемым серверам. Туннели могут передавать трафик ipv6 по сети IPv4 на серверы, которые затем могут обрабатывать его в исходном виде.

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