Как организация, мы только что запросили первое выделение IPv6. В настоящее время мы являемся полностью организацией IPv4 с глобальным распределением адресов IPv4, настроенным на нашем граничном маршрутизаторе и используемым (преимущественно) для NAT через пограничный брандмауэр для внутренних веб-серверов с частными адресами IPv4.
Я понимаю, что один из способов сделать наши внешние сервисы доступными для Интернета IPv6 - это реализовать двойной стек IPv6 во внутренней сети и напрямую назначать этим серверам глобально доступные адреса IPv6 (в дополнение к их существующим адресам IPv4).
Однако даже после прочтения множества сообщений и статей о технологиях перехода IPv6, а также о плюсах и минусах NAT в мире IPv6 я все еще не совсем уверен, можем ли мы по существу воспроизвести нашу существующую настройку, но с адресами IPv6, то есть можем ли мы настроить глобально маршрутизируемый интерфейс IPv6 на нашем граничном маршрутизаторе со связанным «внешним» интерфейсом IPv6 на нашем брандмауэре и просто 1: 1 NAT, глобально обращающимся с IPv6-адресов на IPv4-адрес?
Это, очевидно, основано на том принципе, что у нас есть пиринговая связь IPv6 BGP с нашим интернет-провайдером и что наши внутренние потребности в адресации удовлетворяются RFC1918, но мы хотели бы сделать некоторые внешние службы IPv6 доступными.
Как сказано в первом комментарии, я также настоятельно рекомендую перейти на двойной стек, поскольку в долгосрочной перспективе это дешевле, чем реализация решений NAT. (Вам все равно придется это сделать, так почему бы не сейчас?)
Но все же для вашей проблемы есть два возможных решения/ обходные пути:
Да.
Вам понадобится реализация NAT64 с отслеживанием состояния. Обычно они используются для предоставления локальным клиентам IPv6 доступа к ресурсам в общедоступном Интернете IPv4, но ничто не мешает вам использовать его, чтобы позволить клиентам IPv6 в общедоступном Интернете получать доступ к локальным ресурсам IPv4. Брандмауэры могут использоваться для ограничения доступа к хостам через шлюз NAT64.
В общем, я бы сказал нет.
Ключевая проблема этого подхода заключается в том, что вы потеряете информацию об исходном IP-адресе трафика. Просто невозможно втиснуть 128-битный IP-адрес источника в 32-битное поле. Поэтому будет сложно отследить злоупотребления и сообщить о них.
Есть серверал. Я представлю их в порядке убывания предпочтения.
Первый вариант - развернуть двойной стек на тех сегментах вашей сети, между серверами и краем сети. Это хорошая практика, когда вы начинаете развертывать IPv6 в своей сети.
Второй вариант - развернуть туннели, ведущие от границы вашей сети к рассматриваемым серверам. Туннели могут передавать трафик ipv6 по сети IPv4 на серверы, которые затем могут обрабатывать его в исходном виде.
Третий вариант - обратный прокси. Поскольку он работает на уровне приложения, он может кодировать информацию внешнего IP-адреса в заголовок уровня приложения. Чтобы воспользоваться этой информацией, могут потребоваться изменения на стороне приложения, но многие приложения уже поддерживают ее, поскольку установка обратного прокси-сервера довольно распространена в крупных развертываниях по другим причинам.
Такой способ предоставления услуг IPv4 через IPv6 довольно распространен. Вам нужен брандмауэр, который может выполнять статические сопоставления NAT64. Я сам сделал это, используя ящики Juniper SSG.
Однако я заметил некоторые проблемы с фрагментацией. Поскольку заголовок IPv6 больше заголовка IPv4, при преобразовании размер пакета будет немного больше. Это может привести к фрагментации пакета IPv6, и я видел устройства, которые игнорируют весь фрагментированный трафик. Чтобы избежать проблем с пользователями, у которых есть такое сломанное устройство, лучше немного уменьшить MTU на стороне IPv4 (1480 или 1400 - обычные значения), чтобы даже после преобразования размер пакета был меньше 1500 байт.
Ага, Мем совершенно права. Двойной стек и только на общедоступной стороне сети - это обязательный первый шаг ... это настоящая задержка. То есть ТАКЖЕ быть готовым отказаться от 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 и подключаются к вашему позвоночнику. / leaf или ваши маршрутизаторы и коммутаторы служб / доступа уровня 2, которые также все остаются IPv4, если они даже уровня 3.
Так вы держите NAT. Вы поддерживаете жесткую границу публичного IP / частного IP NAT с такими устройствами, как F5 BIGIP и межсетевые экраны, которые легко обрабатывают IPv6 в IPv4 NAT. Они соединяют ваш публичный уровень дистрибутива с вашим приватным уровнем сервиса / доступа.
Теперь все, что вы выбираете для сохранения NAT (что, вероятно, уже есть), остается IPv4, и все это дерьмовое программное обеспечение хоста IPv6 может быть безнаказанно удалено, потому что только ваше высокопроизводительное сетевое оборудование, работающее на общедоступном краю сети yoru, должно беспокоиться об IPv6.
Серьезно, будь мудрым. IPv6 никоим образом не обгоняет IPv4 в нашей жизни. При нынешних темпах внедрения он не будет соответствовать размерам таблиц IPv4 BGP в течение следующих 200 лет.