Конечно, я осознаю необходимость перехода на IPv6 в открытом Интернете, поскольку у нас заканчиваются адреса, но я действительно не понимаю, почему есть необходимость использовать его во внутренней сети. Я ничего не сделал с IPv6, поэтому мне также интересно: не будут ли современные брандмауэры выполнять NAT между внутренними адресами IPv4 и внешними адресами IPv6?
Мне просто было интересно, так как я видел, как так много людей борются с вопросами IPv6 здесь, и задаюсь вопросом, зачем беспокоиться?
Для IPv6 нет NAT (как вы все равно думаете о NAT). NAT был $ EXPLETIVE временным решением проблемы исчерпания адресов IPv4 (проблема, которая на самом деле не существовала и была решена до того, как NAT вообще понадобился, но история 20/20). Это не добавляет ничего, кроме сложности, и мало что даст, кроме как вызвать головную боль в IPv6 (у нас так много IPv6-адресов, что мы беззастенчиво тратим их). NAT66 действительно существует и предназначен для уменьшения количества адресов IPv6, используемых каждым хостом (для хостов IPv6 нормально иметь несколько адресов, IPv6 несколько отличается от IPv4 во многих отношениях, это один).
Предполагалось, что Интернет будет иметь сквозную маршрутизацию, что является одной из причин, по которым был изобретен IPv4 и почему он получил признание. Это не означает, что все адреса в Интернете должны были быть доступны. NAT ломает оба. Брандмауэры добавляют уровни безопасности, нарушая достижимость, но обычно это происходит за счет возможности маршрутизации.
Вам понадобится IPv6 в ваших сетях, поскольку нет возможности указать конечную точку IPv6 с адресом IPv4. Работает и другой способ, который позволяет сетям только для IPv6, использующим DNS64 и NAT64, по-прежнему получать доступ к Интернету IPv4. На самом деле сегодня возможно полностью отказаться от IPv4, хотя настроить его немного хлопотно. Можно было бы прокси с внутренних адресов IPv4 на серверы IPv6. Добавление и настройка прокси-сервера увеличивает затраты на конфигурацию, оборудование и обслуживание сети; обычно гораздо больше, чем просто включение IPv6.
NAT тоже вызывает свои проблемы. Маршрутизатор должен уметь координировать каждое проходящее через него соединение, отслеживать конечные точки, порты, таймауты и многое другое. Весь этот трафик обычно направляется через эту единственную точку. Хотя можно создать резервные маршрутизаторы NAT, эта технология чрезвычайно сложна и, как правило, дорога. Простые резервные маршрутизаторы просты и дешевы (относительно). Кроме того, чтобы восстановить некоторую возможность маршрутизации, в системе NAT должны быть установлены правила пересылки и трансляции. Это по-прежнему нарушает протоколы, в которые встроены IP-адреса, такие как SIP. UPNP, STUN и другие протоколы были изобретены, чтобы помочь с этой проблемой - больше сложности, больше обслуживания, больше того может пойти не так.
Отсутствие внутренних (rfc1918) адресов ipv4 также может быть очень веской причиной для перехода на ipv6.
Comcast объяснил на Nanog37 почему они использовали ipv6 для своих адресов управления.
20 Million video customer
x 2.5 STB/customer
x 2 ip addresses/STB
--------------------
= 100 Millions IP addresses
И это только для видеоа не данные / модемы.
Они исчерпали пулы RFC1918 в 2005 году. Затем они использовали пулы общедоступных адресов (поскольку nat не подходит для управления) и пошел ipv6, чтобы решить свои потребности.
Пара причин:
IPv6 не поддерживает трансляцию. Он заменен многоадресной рассылкой. Широковещательная передача позволяет одному узлу отправлять трафик всем узлам в подсети. Управление широковещательными доменами является серьезной проблемой для обеспечения быстрой и бесперебойной работы больших сетей IPv4. Многоадресная рассылка требует, чтобы узлы, которые хотят получать "широковещательную рассылку", фактически "подписывались" на нее, чтобы сеть не была затоплена трафиком, который достигает всех узлов.
IPv6 изначально поддерживает шифрование в стиле IPsec.
IPv6 поддерживает автоконфигурацию. Хосты за маршрутизатором могут настраиваться без использования DHCP, хотя вам все равно понадобится DHCP-сервер для передачи таких параметров DHCP, как DNS-сервер, TFTP-сервер и т. Д.
На моей старой работе в большом университете я использовал внутреннее выделение IPv6. Раньше им был назначен IPv4 / 16, и даже сегодня они раздают адреса IPv4 почти каждому внутреннему клиенту. Сети RFC1918 были ограничены только телекоммуникационной сетью и некоторыми специализированными применениями (стандарты PCI требовали использования RFC1918 до октября 2010 года).
Из-за этого они активно планировали использовать IPv6 и внутри компании. Осталось решить некоторые проблемы с оборудованием, граничные коммутаторы недостаточно хорошо поддерживали v6, но ядро было готово. Идея заключалась в том, чтобы получить поддержку v6 в публично видимой части (хорошо, публично отзывчивый end) сети потребует 70% работы по ее развертыванию для всех, может также сделать дополнительные 30% и пройти ее от начала до конца.
Так долго живя с публичным выделением IP-адресов, наши люди хорошо знали поговорку: «То, что он публичный, не означает, что он доступен». Как сказал Крис С., маршрутизируемость не подразумевает достижимости.
Вот почему по крайней мере один класс организаций будет развертывать IPv6 внутри: потому что они уже используют IPv4, отличное от RFC1918.
Работая в небольшой компании, я могу только думать о причинах НЕ использовать IPv6.
Для такой компании, как наша, просто не имеет смысла вносить изменения, поскольку это потребует значительных затрат и усилий, и от этого ничего не получится.
Откровенно говоря, мне нравится NAT и преимущества, которые мы получаем от работы с локальными адресами. Если это когда-нибудь станет нужно (вместо того, чтобы быть любителями компьютерных игр), чтобы мы могли взаимодействовать с IPv6 в Интернете, мы будем делать это на шлюзе.
Я не ожидаю, что нынешняя мода на IPv6 станет необходимостью для подавляющего большинства мира, по крайней мере, внутри страны, в течение десятилетия или более. Поскольку я ожидаю, что к тому времени выйду на пенсию, у меня лично нет большого стимула тратить на это время и силы.
Редактировать:
Я получаю отрицательные голоса, но ни одного логичного и разумного противоположного мнения. Это заставляет меня думать, что это просто кучка фанатиков, которые хотят следовать тенденции, не задумываясь об этом. Для такого радикального изменения сети должна быть ПРИЧИНА, а у меня ее нет. Кроме того, я сильно подозреваю, что он есть только у очень немногих пользователей SF.
IPv6 действительно предлагает некоторые потенциальные улучшения в реальном мире по сравнению с IPv4, такие как более простой механизм автоматической настройки и автоматического обнаружения, он также более безопасен в том смысле, что становится невозможным для вредоносных программ реплицировать по сети путем сканирования портов диапазона IP-адресов. - слишком много IP-адресов. Но эти улучшения не особо значительны и, конечно, не стоят затрат на переход.
Но учтите, что это не либо / либо После принятия решения вы можете запускать обе программы параллельно, а если вы разрабатываете программное обеспечение, вам, вероятно, следует, как многие люди упомянули, использовать его в целях тестирования. Нет надежного способа сделать программу совместимой с IPv6 без наличия внутренней инфраструктуры IPv6 для тестирования. Большинство современных операционных систем автоматически создают внутреннюю сеть IPv6 между собой - это просто вопрос ее использования.
10 лет назад я разработал программное обеспечение, которое клиенты-работодатели используют для получения обновлений программ. При создании сетевого компонента мне пришлось выбирать между созданием совместимости с IPv6 или просто предположением, что все IP-адреса будут иметь размер 4 байта. Я решил пойти по простому пути, сэкономив около 4 часов работы, и сделал приложение только для IPv4. Я подумал, что его все равно заменит через несколько лет. Они все еще используют его сегодня и поэтому заблокированы на некоторых более мелких рынках.
Здесь мы говорим о двух вещах - о запуске внутренней сети на чистом IPv6 или использовании двойного стека IPv4 / IPv6. Я думаю, что пока рано говорить о запуске чистого IPv6 - во многих операционных системах даже невозможно использовать IPv6 без IPv4. Однако вы можете рассмотреть возможность использования двойного стека по следующим причинам (а), если вы разрабатываете программное обеспечение (б), чтобы подготовить свою сеть к неизбежному переходу на IPv6. Если у вас ситуация A, то вы должны действовать сейчас, если это B, то, по моей оценке, у вас есть около 1-2 лет, чтобы подумать об этом (но чем раньше вы начнете, тем более подготовленным вы будете).
Моя ситуация - А, и мы работаем с двойным стеком уже 6 месяцев. За это время мы выявили и решили некоторые проблемы с нашим общедоступным / частным DNS, распределением адресов, DHCP, маршрутизацией, брандмауэром, и мы даже не могли предвидеть многие из этих проблем, не попробовав. Теперь мы полностью готовы к IPv6 и даже имеем публичный доступ к IPv6 через туннелирование. Исходя из своего опыта, я могу с уверенностью сказать, что IPv6 - гораздо более простое и элегантное решение по сравнению с устаревшим IPv4, поэтому я буду очень рад, когда придет время перейти на IPv6, но до того, как это произойдет, - двойной стек - это способ идти.
Помимо большого адресного пространства, отсутствия широковещательной рассылки, IPSec и более простой автоконфигурации, IPv6 имеет некоторые «не столь известные» преимущества:
Большее адресное пространство означает, что в адресе больше битов, которые можно использовать в качестве хранилища данных. Например, количество переходов между двумя узлами может быть функцией их адресов IPv6, например:
IPv6-адрес может быть в формате PREFIX:Country&Region:DC&Line:Rack&Unit:VM&ID поэтому более близкие узлы будут иметь больше самых значимых битов. Это всего лишь пример, конечно, метрики «близости» могут храниться во внешней базе данных, такой как DNS. TXT|SRV записи.
Существует несколько методов использования адресного пространства IPv6 для криптографических целей, таких как адреса, сгенерированные криптографически (CGA) и отправить (SEcure Neighbor Discovery)
Когда IPv6 включен, все узлы в сети имеют IPv6-адрес локального канала (если не настроено иначе). Так что есть шанс получить доступ даже к неправильно настроенному узлу.
Вы можете получить MAC-адреса узлов напрямую с локального адреса IPv6 (если Расширения конфиденциальности IPv6 не настроены)
Невозможно использовать IPv4 в подсетях с тысячами узлов - ваша сеть будет перегружена широковещательным трафиком (например, ARP).
Вы можете запросить узел для дополнительной информации, используя информация об узле, например в BSD вы можете запрашивать у хоста адреса узлов информации об узлах ICMPv6:
$ ping6 -a Aacgsl ::1
PING6(72=40+8+24 bytes) ::1 --> ::1
136 bytes from ::1:
fe80::beae:c5ff:fe43:44a(TTL=infty)
fe80::beae:c5ff:fe43:212(TTL=infty)
::1(TTL=infty)
fe80::1(TTL=infty)
2a02::9222(TTL=infty)
Я могу придумать две причины использовать IPv6 для внутреннего хоста.
В будущем вы можете обнаружить, что этот хост теперь должен быть доступен извне, по крайней мере, на определенных портах.
Вы можете обнаружить, что этому хосту необходимо подключиться к другому хосту, который также выбрал тот же внутренний адрес. Например, вам нужно подключиться к 10.0.0.5 в корпорации Acme, и ваш собственный адрес в корпорации Emca также 10.0.0.5. Я помню, как это происходило на предыдущей работе, мы оба использовали одни и те же внутренние адреса.
Я бы сказал, что в современном мире большинство компьютеров не на 100% внутреннее. Большинство настольных компьютеров могут иметь некоторые ограниченные подключения к внешнему миру или наоборот.
Единственная веская причина для внутреннего перехода на IPv6 - это быть готовым, когда мир перейдет на IPv6, и я думаю, что это довольно плохая причина, учитывая скорость его принятия. Поскольку большинство внутренних IP-адресов не будут доступны извне, перевод остальных не составит большого труда.
Моя корпорация, вероятно, никогда не перейдет на IPv6 внутри компании. Это потребует фундаментального сдвига в политике, настолько масштабного, что я не могу честно представить, как это могло произойти. Придется убить множество людей, и придется принять множество необъяснимых решений. Аналогичным образом, любая попытка отдельных бизнес-единиц перейти на IPv6 в своих локальных сетях будет подавлена с предубеждением со стороны корпоративных сетевых властителей, основанных на соображениях совместимости и удобства обслуживания (мы допускаем большую свободу действий на местном уровне, но не который много.)
По сути, если бы переход на IPv6 был безболезненным, мы бы сделали это много лет назад.
IPv4 предназначался для того, чтобы каждое устройство находилось непосредственно в Интернете ... пока у нас не закончилось адресное пространство. Затем мы потратили последние 20 лет на блокировку всего этого. Теперь IPv6 по своей задумке снова хочет разместить каждое устройство непосредственно в Интернете ... результат будет таким же. Я полностью согласен с тем, что NAT - это один из уровней безопасности, от которого нельзя отказываться без столь же эффективной или лучшей замены.
К сожалению, в подавляющем большинстве этих ответов и комментариев содержится много неверной информации. Так грустно видеть, как слепые так плодотворно ведут слепых.
NAT никуда не денется, и люди, которые говорят вам: «О, этот NAT, какая это ужасная вещь» ... «О, этот NAT, это была всего лишь работа» ... ad nasueum Если они начнут использовать язык вроде что, переходите к настоящему профессиональному сетевому архитектору за советом, а не к сетевику на выходных.
Вам нужно балансировать нагрузку трафика на внутренние серверы из Интернета? Угадайте, что, с IPv6 вы не можете сделать это так, как вы это делали ... если вы не используете NAT!
Да, это правда. Некоторые скажут, что вы просто используете балансировку нагрузки DSR / Direct server return. Но они забывают сказать вам, что вы должны отказаться 1) Вставка файлов cookie 2) Ускорение приложений 3) Трансляция адресов портов
Итак, если вы хотите, чтобы ваши внутренние серверы работали на порту 8080, а ваши внешние - на порте 80 ... О, как жаль, с IPv6 ничего не поделаешь ... если только вы не используете хороший старый NAT! Даже с DSR.
Затем добавьте к этому «хвастовство», что люди говорят: «О, да, все предложения IPv6 NAT провалились ... слава богу» (и империя умирает под звуки аплодисментов). Знаете, что это значит? NAT будет ужасным, если он вообще будет работать с IPv6, потому что все фанатики IPv6 по своей сути отрицают необходимость NAT / PAT, а люди, делающие это, делают это неохотно. Так грустно, так плохо управляем
Итак, что вы будете делать сейчас, когда правда освободила вас, и вы можете подняться над толпой леммингов, пытающихся использовать тактику запугивания, чтобы заставить вас уступить?
Вы покупаете или продолжаете использовать балансировщик нагрузки или брандмауэр, который действует как публичный / частный брокер вашей сети. На публичных интерфейсах размещаются те же виртуальные IP-адреса, которые у вас уже есть, но с дополнительным IPv6-адресом, если он вам нужен. Все, что находится к северу от уровня Loadbalancer / Firewall, также является двойным стеком IPv4 / IPv6. На внутренних интерфейсах балансировщика нагрузки / брандмауэра все они - IPv4, а вся ваша внутренняя сеть - IPv4, и он остается таким, пока вы хотите. Это только твое дело. Loadbalancer выполняет NAT / PAT между внешним и внутренним окружением ... потому что он уже есть и необходим для полнофункциональной балансировки нагрузки, а также потому, что теперь он также решает вашу проблему с внешним IPv6.
Да и саркастичному человеку, который спросил: "Какую единственную цель безопасности выполняет NAT?"
Безопасность - это доступность на самом фундаментальном уровне. Подумайте об этом, прежде чем отбросить это.
Балансировщики нагрузки обеспечивают эту доступность / безопасность, и вы ДОЛЖНЫ использовать NAT / PAT, чтобы сделать это правильно, независимо от версии IP, которую вы используете.
Цитата относительно сбоя DSR: https://devcentral.f5.com/articles/the-disadvantages-of-dsr-direct-server-return
k thnx
Использование IPv6 во внутренней сети - не лучшая идея, поскольку многие устаревшие устройства не смогут обмениваться данными. Старые копировальные аппараты / многофункциональные принтеры, медицинское оборудование, старые печатные машины, старые серверы и сетевые устройства. Схема IPv4 имо намного проще в управлении.
Принятый ответ вводит в заблуждение
Концепции Chris S о NAT ошибочны; БЕЗОПАСНОСТЬ - одна из лучших особенностей NAT, помимо искусственного расширения схемы IPv4. NAT - это уровень, который скрывает реальный IP-адрес хоста, который при прямом подключении к Интернету может стать целью всех мыслимых атак. К счастью, разговоры об избавлении от NAT без поощрения дополнительных мер безопасности - это просто игнорирование этой темы.