Доступ к IPv6
Преимущества
С 09.08.2018 по 19.04.2020 год услуга «Доступ к IPv6» включалась в первоначальный пакет услуг.
С 20.04.2020 года доступ в сеть Интернет по протоколам IPv6 предоставляется автоматически.
В связи с этим опция «Доступ к IPv6» закрыта для подключения.
Подробности
Что такое IPv6
IPv6 — протокол передачи данных, который позволяет присвоить каждому устройству, имеющему доступ в интернет, уникальный IPv6-адрес.
IPv4v6 (Dual-Stack) — технология, которая предоставляет доступ в интернет по протоколам IPv4 и IPv6.
Как настроить
Доступ в интернет предоставляется в режиме Dual-Stack IPv4/IPv6 при использовании APN internet.mts.ru. Дополнительно к IPv4 предоставляется блок публичных IPv6-адресов размерностью /64. В режиме модема каждому подключаемому устройству выделяется свой IPv6-адрес.
Чтобы вручную настроить доступ к IPv6:
1. Укажите в настройках устройства:
• Точка доступа — internet.mts.ru
• Протокол APN — IPv4/IPv6.
2. Подключите услугу «Доступ к IPv6».
3. Включите и отключите авиарежим или перезагрузите устройство.
Сколько стоит
Стоимость подключения и абонентская плата — 0 руб.
Безопасность
В целях повышения уровня безопасности опция «Доступ к IPv6» ограничивает входящие соединения из сети на системные TCP/UDP-порты (0-1023). Для дополнительной защиты устройств рекомендуется использовать Firewall и Антивирус.
Зона действия
Адресация IPv6 действует на территории России и в международном роуминге при наличии технической возможности на сети роуминг-партнера.
IPv6 для домашних сетей
В этой статье мы постараемся описать текущее состояние поддержки и варианты внедрения IPv6 в домашних сетях. Статья написана осенью 2012 года, вполне возможно, что уже через год она будет совершенно неактуальной, но всё-таки мы опишем статус IPv6 на сегодняшний день. Информация ориентирована в первую очередь на провайдеров домашних сетей, соответственно, под определение «провайдер» в данной статье магистралы не подпадают.
Не так давно закончилась свободная раздача IPv4 адресов, поэтому вопросов по IPv6 с каждым днём становится всё больше. Но сами вопросы чаще всего показывают разрыв между понятием IPv6 в головах вопрошающих и реальным положением вещей.
Из наиболее частых вопросов можно выделить: «А ваш биллинг поддерживает IPv6 адреса?». При этом ответ: «А всё ваше оборудование готово к его внедрению?» вызывает удивление: «А что там готовить надо?».
Не хочется заниматься переписыванием основ IPv6 из rfc (http://tools.ietf.org/html/rfc2460) или википедии (http://ru.wikipedia.org/wiki/Ipv6), поэтому на этот фундаментальный вопрос ответим двумя предложениями. IPv4 и IPv6 — это два разных протокола, совсем разных. Как, например, AppleTalk или IPX — совсем разные. Поэтому IPv6 — это не просто «другие адреса», это совершенно другой протокол.
Вышесказанное необходимо осознавать в первую очередь украинским провайдерам: никакого UA-IX в IPv6 сетях нет, протоколом заложены элементы маршрутизации уже в заголовке IPv6 пакета (http://tools.ietf.org/html/rfc3587), сети аггрегируются по умолчанию, IPv6 full-view не может превышать 8К префиксов. Соответственно, провайдерам прийдётся отвечать на волну вопросов абонентов: «А почему у меня нет 100М на UA-IX?».
Также, в настоящее время ни одна биллинговая система не поддерживает полноценное управление IPv6. Некоторые системы заявили о поддержке IPv6, но на практике эта «поддержка» представляет собой лишь модифицированное поле IP адреса. А по стандарту, конечному пользователю адрес не выделяется, конечному пользователю должна выделяться сеть, по старым рекомендациям — /48 сеть (http://tools.ietf.org/html/rfc6177), по новым рекомендациям RIPE — уже /56 сеть, т.е. 256 сетей по 18446744073709551616 адресов. Повторим — каждому абоненту. Ни один из известных биллингов в настоящее время не поддерживает данные стандарты.
Тем не менее, невозможность получить IPv4 адреса и неуклонное подорожание их аренды заставляет задумываться об использовании IPv6 протокола.
Мы рассмотрим два варианта внедрения IPv6: в Dual-Stack, и «чистого» IPv6.
Использование IPv6 в Dual-Stack
Dual-Stack — это параллельное использование IPv6 и IPv4. Пользователь получает оба варианта адресов. Очевидно, что выдавать реальный IPv4 адрес при этом никто не собирается, т.к. тогда смысла в IPv6 для провайдера нет, задача стоит экономить IPv4 адреса.
В настоящее время всё клиентское оборудование хорошо и качественно поддерживает получение адресов и маршрутов для обоих протоколов, со стороны пользователей Dual-Stack проблем не вызывает. Однако, со стороны провайдера всё несколько грустнее.
Начнём с коммутаторов доступа. Прекрасно показавшая себя связка dhcp snooping + opt82 имеется «из коробки» в IPv6 протоколе, только называется она opt37 (http://tools.ietf.org/html/rfc4649), но при этом сам коммутатор должен поддерживать IPv6 протокол, как минимум, уметь блокировать «чужие» RA, фильтровать ND, пр. Иначе ситуация будет подобна сети с DHCP на «тупых» свичах, где адреса раздаёт любой клиентский роутерчик.
На сегодняшний день подобная поддержка IPv6 известна только у последних D-Link, начиная с DES-3200, и более экстремальных вариантах типа коммутаторов SNR от уважаемого nag.ru, приобретая которые провайдер за собственные деньги подписывается в вечные бета-тестеры глюков прошивок. Но, надо отдать должное DCN (http://www.dcnglobal.com): а это и SNR, и Edge-Core, и многие другие торговые марки, — покупая коммутаторы D-Link, тоже немало времени будет потрачено администраторами на бета-тестирование и отлов багов.
Также, нельзя не отметить, что тестирование работы необходимого IPv6 функционала под реальной нагрузкой особо не проводилось, у подавляющего большинства провайдеров IPv6 существует только в тестовом виде, так что рискнувший на внедрение IPv6 в эксплуатацию, вполне может стать первопроходцем на этом поле.
Использование же VPN (PPTP, PPPoE) для выдачи адресов, несомненно, уменьшает запросы к коммутаторам доступа, однако увеличивает объём негатива среди абонентов.
Итого: в настоящее время поддержка необходимых функций защиты IPv6 сети имеется лишь у незначительного количества новых моделей коммутаторов «нестабильных» производителей.
Не лучше обстоят дела в центре сети. Мы не будем тщательно рассматривать вариант, где центром сети является сервер под FreeBSD/Linux, подобные сети обычно невелики, и имеющихся у них /22 или даже /23 IPv4 адресов с головой и надолго хватит на всех пользователей. Напомним только, что для FreeBSD dummynet пока ещё не научился использовать несколько ядер.
Но самая главная проблема заключается в том, что пользователей необходимо NAT-ить под реальный IPv4. В условиях «средней» сети это совсем непростая задача. Необходимость прогонять пару гигабит через сервера приведёт к низкому качеству трафика, высоким задержкам, жалобам и оттоку абонентов.
Получается, что при объёме трафика в несколько гигабит возвращаться к «софтовым» шейперам на базе FreeBSD/Linux/Mikrotik уже невозможно, а приобретать оборудование уровня Cisco ASR1000 — нереально дорого.
Да и что делать с самим IPv6 трафиком, тоже вопрос. Отдавать аплинку? Почти все аплинки отдельно тарифицируют транзит IPv6 трафика. Заворачивать у себя IPv6 to IPv4? Тогда использование IPv6 вообще не имеет смысла. Поднять туннельный пиринг с кем-либо типа Hurricane Electric (http://www.tunnelbroker.net/new_tunnel.php?type=bgp)? Во-первых, трафик пойдёт через «мир» (у кого есть подобное разделение), во-вторых, при достижении определённых лимитов, Hurricane Electric тоже начнёт брать деньги за транзит. Получается, что кроме увеличения накладных расходов, внедрение IPv6 ничего положительного не даст. Если уж всё равно использовать NAT, то можно просто NAT-ить серые IPv4 адреса, и всё. Пользователи не заметят разницы.
Итого: типичное для «среднего» провайдера оборудование либо совсем невозможно использовать для работы пользователей в Dual-Stack, либо же оно будет нагружено сильнее в несколько раз (отдельная маршрутизация плюс NAT).
Использование «чистого» IPv6
С учётом нецелесообразности развёртывания Dual-Stack в домашних сетях, у провайдеров возникает вполне логичный вопрос: «А что, если мы только один сегмент сети переведём на «чистый» IPv6, а остальные пусть работают, как раньше?». В теории подобная схема выглядит неплохо: поставить отдельную железку под IPv6, раздать пользователям IPv6 адреса, докупить у аплинков IPv6 транзит — и пусть себе работают. Рассмотрим подробнее, как обстоят дела с поддержкой «чистого» IPv6 в настоящее время.
В этот раз опустим анализ коммутаторов доступа — всё аналогично описанному в разделе про Dual-Stack, разве что необходимо отметить, что коммутаторы D-Link при получении IPv6 по автоконфигурации не видят предлагаемых роутов, так что надо быть готовым к тому, что default gateway необходимо будет прописывать вручную.
В качестве примера «центра» сети мы опять использовали оборудование Cisco, IOS версии 15.1. К «настоящей» cisco претензий нет никаких: IPv6 адреса и маршруты как по автоконфигурации, так и по DHCPv6 получает корректно; сама в роли роутера выступает корректно; вариантов работы с RA, ND и пр. множество, всё функционирует согласно документации; адреса раздаёт как по автоконфигурации, так и по DHCPv6 тоже корректно. Тут провайдеры домашних сетей могут только позавидовать магистралам, у которых проблем с запуском IPv6 особо и нет.
Перейдём к клиентскому оборудованию. Об этом писалось много раз, например, самим IETF (http://tools.ietf.org/html/rfc6586), однако надежда на то, что поддержка IPv6 активно развивается производителями, заставила пробежаться по основным вариантам пользовательских подключений. А именно, мы проверили работоспособность «чистого» IPv6 подключения для Wi-Fi роутера Cisco (Linksys), а также компьютеров под управлением Debian/Ubuntu, Mac OS X, Windows 7. Всё вышеперечисленное имело последние версии ПО/обновлений/патчей/прошивок.
Да и заявленная работоспособность, например, youtube, тоже относительна: сам ресурс полностью поддерживает IPv6, однако для его использования нужен Adobe Flash Player, который скачать и установить невозможно, т.к. все ресурсы Adobe недоступны по IPv6.
Выходом остаётся всё тот же NAT, только уже в другом направлении, а единственным известным софтверным решением является TAYGA, NAT64 for Linux (http://www.litech.org/tayga), последние изменения в котором датированы 10.06.2011, и который не входит в состав ни одного распространённого дистрибутива. Да и очевидно, что более 90% клиентского трафика будет уходить в IPv4 сеть, а вопросы необходимых мощностей для Dual-Stack рассматривались выше.
Итоги
UPD: Приношу извинения andrewsh, что не заметили собранного им пакета tayga для Debian Wheezy.
IPv4/IPv6 Dual Stack на коммутаторах SNR
Введение
Описание стенда Dual Stack
На тестовом стенде мы разберем настройки коммутаторов SNR для авторизации IPv6-абонентов с использованием опций 37 (remote-id), 38 (subscriber-id), безопасность и конфигурацию DHCP-сервера для выдачи IPv6-адресов.
Еще раз отметим, что все управляемые коммутаторы доступа SNR, от FastEthernet-моделей, таких как SNR-S2962-24T, до гигабитных коммутаторов с 10G-аплинками (SNR-S2989G-24TX), поддерживают одинаковый функционал и имеют одинаковые настройки в части IPv6.
Рассмотрим стенд Dual Stack. Коммутатор доступа SNR-S2985G-24TС будет использоваться для подключения абонентов, как через домашний Wi-Fi-маршрутизатор, методом Prefix Delegation, так и напрямую. Для выделения IPv6-префикса и IPv6-адресов будут использоваться опции 37 (remote-id) и 38 (subscriber-id). Для выделения IPv4-адресов будем использовать классическую опцию 82.
Для защиты от нелегитимных DHCP-серверов и подмены IP-адреса, в случае с IPv4 будет использоваться DHCP snooping binding. Коммутаторы SNR имеют несколько механизмов защиты протокола IPv6. Например, Security RA блокирует RA-сообщения от недоверенных портов. ND Security позволяет влиять на автоматическое изучение ND-записей (аналог ARP Security). В нашем примере будет использоваться SAVI (Source Address Validation Improvement), который включает в себя ND Snooping, DHCPv6 Snooping и RA Snooping. Мы будем защищаться от нелегитимных DHCP-серверов и источников RA-сообщений с помощью trust-портов. Выдаваемые IPv6-адреса и префиксы будут привязываться к binding-таблице. Мы также будем задавать максимальное количество адресов на порт.
Коммутатор агрегации SNR-2995G-24FX, в качестве IPv6-роутера, будет рассылать RA-сообщения с M-флагом в своем сегменте сети, чтобы клиенты могли знать, каким образом формировать их IPv6-адрес. Также, на SNR-2995G-24FX будут присутствовать L3-интерфейсы в клиентских VLAN, с которых он будет осуществлять релей в VLAN DHCP-сервера.
Сервер ISC-DHCP будет выделять адреса и префиксы согласно классам.
Настройка и проверка стенда
Далее будут приведены минимально необходимые конфигурации с пояснениями некоторых настроек. Некоторые из них были описаны в прошлой статье.
ip dhcp snooping enable
ip dhcp snooping vlan 100;200
ip dhcp snooping binding enable
!
ip dhcp snooping information enable
ip dhcp snooping information option subscriber-id format hex
!
savi enable
savi ipv6 dhcp-slaac enable
savi check binding probe mode
!
ipv6 dhcp snooping vlan 100;200
ipv6 dhcp snooping remote-id option #включаем добавление опции 37
ipv6 dhcp snooping subscriber-id option #включаем добавление опции 38
ipv6 dhcp snooping mode relay #задаем отправку опций в RELAY-FORWARD сообщениях
!
vlan 1;100;200
!
Interface Ethernet1/0/1
switchport access vlan 100
ip dhcp snooping binding user-control
ip dhcp snooping binding user-control max-user 10
savi ipv6 check source ip-address mac-address #включаем проверку IP и MAC адресов
savi ipv6 binding num 10
!
Interface Ethernet1/0/2
switchport access vlan 200
ip dhcp snooping binding user-control
ip dhcp snooping binding user-control max-user 10
savi ipv6 check source ip-address mac-address
savi ipv6 binding num 10
!
Interface Ethernet1/0/24
switchport mode trunk
switchport trunk allowed vlan 100;200
ip dhcp snooping trust
ipv6 dhcp snooping trust #назначаем trust-порт для DHCPv6 пакетов
ipv6 nd snooping trust #назначаем trust-порт для ND-RA пакетов
service dhcp
!
ip forward-protocol udp bootps
!
service dhcpv6
!
vlan 1;10;100;200
!
Interface Ethernet1/0/1
switchport mode trunk
switchport trunk allowed vlan 100;200
!
Interface Ethernet1/0/12
switchport mode trunk
switchport trunk allowed vlan 10
!
interface Vlan10
ipv6 address 2001:db8:10:1::1/64
ip address 192.168.10.1 255.255.255.0
!
interface Vlan100
ipv6 address 2001:db8:100:1::1/64
no ipv6 nd suppress-ra #разрешаем рассылать RA-сообщения с этого L3-интерфейса
ipv6 nd min-ra-interval 60 #задаем минимальный интервал рассылки RA
ipv6 nd max-ra-interval 120 #задаем максимальный интервал рассылки RA
ipv6 nd managed-config-flag #задаем M-флаг
ipv6 nd prefix 2001:db8:100:1::/64 2592000 604800 no-autoconfig #отключаем A-флаг в RA-сообщениях
ip address 192.168.100.1 255.255.255.0
ip helper-address 192.168.10.3
ipv6 dhcp relay destination 2001:db8:10:1::3
!
interface Vlan200
ipv6 address 2001:db8:200:1::1/64
no ipv6 nd suppress-ra
ipv6 nd min-ra-interval 60
ipv6 nd max-ra-interval 120
ipv6 nd managed-config-flag
ipv6 nd prefix 2001:db8:200:1::/64 2592000 604800 no-autoconfig
ip address 192.168.200.1 255.255.255.0
ip helper-address 192.168.10.3
ipv6 dhcp relay destination 2001:db8:10:1::3
Приступим к конфигурационному файлу для DHCPv6, здесь уже появляются новые элементы, требующие пояснений.
default-lease-time 120;
max-lease-time 240;
#Делаем наглядный разделитель с перечислением распознанных опций, например:
#Remote-ID: f8-f0-82-78-05-ba | Subscriber-ID: vlan200+Ethernet1/0/2
log(info, (concat(
«Remote-ID: «, (substring(v6relay(1, option dhcp6.remote-id), 4, 17)),
» | Subscriber-ID: «, v6relay(1, option dhcp6.subscriber-id)
)));
#Создаем класс «sw1-1», который сверяет DHCPv6-RELAY опции 37 и 38.
class «sw1-1» <
match if(
(substring (v6relay(1, option dhcp6.remote-id), 4, 17) = «f8-f0-82-78-05-ba») and
(v6relay(1, option dhcp6.subscriber-id) = «vlan100+Ethernet1/0/1»)
);
>
class «sw1-2» <
match if(
(substring (v6relay(1, option dhcp6.remote-id), 4, 17) = «f8-f0-82-78-05-ba») and
(v6relay(1, option dhcp6.subscriber-id) = «vlan200+Ethernet1/0/2»)
);
>
subnet6 2001:db8:100:1::/64 <
pool6 <
#Задаем диапазон префиксов, выдаваемых CPE.
prefix6 2001:db8:80:: 2001:db8:90:: /56;
range6 2001:db8:100:1::100 2001:db8:100:1::130;
option dhcp6.name-servers 2001:db8:10:1::88;
option dhcp6.domain-search «domain.example»;
allow members of «sw1-1»;
>
>
subnet6 2001:db8:200:1::/64 <
pool6 <
range6 2001:db8:200:1::100 2001:db8:200:1::130;
option dhcp6.name-servers 2001:db8:10:1::88;
option dhcp6.domain-search «domain.example»;
allow members of «sw1-2»;
>
>
subnet6 2001:db8:10:1::/64 <>
Для каждого протокола будем запускать отдельный экземпляр ISC-DHCP с соответствующим файлом конфигурации:
Проверим, корректно ли отрабатывают технологии DHCP Snooping и SAVI на одном коммутаторе доступа одновременно:
ip dhcp snooping static binding count:0, dynamic binding count:2
MAC IP address Interface Vlan ID Flag
—————————————————————————-
6c-3b-6b-da-5a-d8 192.168.100.100 Ethernet1/0/1 100 DOL
f0-de-f1-19-d5-eb 192.168.100.101 Ethernet1/0/2 200 DOL
—————————————————————————-
SNR-S2985G-24T-UPS#sh savi ipv6 check source binding
Static binding count: 0
Dynamic binding count: 4
Binding count: 2
MAC IP VLAN Port Type State Expires
—————————————————————————————————————
6c-3b-6b-da-5a-d8 fe80::6e3b:6bff:feda:5ad8 100 Ethernet1/0/1 slaac BOUND 14008
6c-3b-6b-da-5a-d8 2001:db8:90::/56 100 Ethernet1/0/1 dhcp BOUND 83
f0-de-f1-19-d5-eb fe80::f2de:f1ff:fe19:d5eb 200 Ethernet1/0/2 slaac BOUND 5
f0-de-f1-19-d5-eb 2001:db8:100:1::130 200 Ethernet1/0/2 dhcp BOUND 94
—————————————————————————————————————
Посмотрим как выглядят полученные сетевые реквизиты на одном из клиентов:
]$ ip add show enp3s0
2: enp3s0:
mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether f0:de:f1:19:d5:eb brd ff:ff:ff:ff:ff:ff
inet 192.168.200.101/24 brd 192.168.200.255 scope global dynamic noprefixroute enp3s0
valid_lft 170sec preferred_lft 170sec
inet6 2001:db8:200:1::130/128 scope global dynamic noprefixroute
valid_lft 76sec preferred_lft 31sec
inet6 fe80::f2de:f1ff:fe19:d5eb/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Проверим информацию о маршрутах:
Как и было описано в первой статье, шлюзом по умолчанию для IPv6-хоста является link-local адрес маршрутизатора, от которого было получено RA-сообщение.
Заключение
Подведем итог. Мы рассмотрели один из сценариев настройки Dual Stack на коммутаторах SNR, делается это довольно просто. На тестовом стенде проверили работоспособность одновременного использования IPv4, IPv6 и связанных с ними технологий. Если статья вызовет достаточный интерес, то можно будет ожидать третью часть про настройку IPv6-маршрутизации на коммутаторах агрегации и ядра SNR.
По всем вопросам, в том числе предоставления скидок, вы можете обратиться к вашему менеджеру. Напоминаем, что у нас есть Telegram-канал, а также обновленная база знаний.
Как добиться сосуществования IPv4 и IPv6: dual stack или MPLS tunnel
Charlene
В настоящее время, когда доступные адреса IPv4 (Internet Protocol Version 4) почти исчерпаны, отсутствие IP-адресов стало насущной проблемой во всем мире. Хотя IPv6 (Internet Protocol Version 6) с более длинным заголовком появился несколько лет назад, он позволяет использовать больше IP-адресов для будущего использования, но его применение и продвижение не легки, и может пройти долгий путь. Можно ли использовать IPv4 и IPv6 одновременно? Чтобы ответить на эти вопросы, мы представим некоторые методы сосуществования IPv4 и IPv6, а именно dual stack и MPLS (Multi-Protocol Label Switching) tunnel.
Зачем нужны сосуществование IPv4 и IPv6?
Обычно основной причиной использования IPv4 и IPv6 является совместимость. Фактически, IPv4 и IPv6 несовместимы друг с другом, а это означает, что устройства не могут взаимодействовать напрямую. Сегодня IPv4 по-прежнему доминирует в IP-сети, в то время как IPv6 имеет лишь небольшой диапазон развертывания и коммерческого использования. Таким образом, отсутствие реальной обратной совместимости с IPv4 может быть критическим отказом для широкого применения IPv6, и полное преобразование в IPv6 является путь прочь. Internet Service Providers (ISP, поставщик интернет-услуг) должны предоставлять своим клиентам услуги IPv4 и IPv6, что также создает проблемы для пользователей.
Как добиться сосуществования IPv4 и IPv6?
Сосуществование IPv4-IPv6 может быть достигнуто с помощью трех технологий. Одним из них является стек с двумя протоколами, где ваше сетевое оборудование работает как по IPv4, так и по IPv6. Вторым является tunnel, что означает, что пакеты IPv6 инкапсулированы в пакеты IPv4. Последний метод называется преобразованием сетевых адресов (NAT), и устройство использует этот метод для преобразования пакетов IPv6 в пакеты IPv4 и наоборот. Поскольку NAT в основном используется ISPs, здесь представлены первые две технологии.
Сосуществование IPv4 и IPv6 через dual stack
Рисунок 1. Сосуществование IPv4 и IPv6 через dual stack.
Преимущества & недостатки dual stack
Сосуществование IPv4 и IPv6 через MPLS tunnel
Tunnel также является типичным механизмом, часто используемым при переходе IPv4/IPv6, что означает инкапсуляцию одного типа трафика протокола в пакеты другого протокола для передачи. Существует множество методов tunnel, в том числе 6to4 (IPv6 over IPv4 Tunnel), ISATAP (Intra Sita Automatic Tunnel Addressing Protocol), Teredo, 6PE (IPv6 Provider Edge), 6VPE (IPv6 VPN Provider Edge) и MPLS. MPLS используется поставщиками услуг в своих сетях IPv4 для увеличения скорости пересылки. По сравнению с традиционным методом IP-маршрутизации MPLS анализирует только заголовки IP-пакетов на границе сети, а не на каждом прыжке при пересылке данных, что экономит время обработки. MPLS Tunnel подключается к сети IPv6 через тракт переключения меток (LSP) в сети IPv4. По сравнению с другими методами tunnel. он обеспечивает лучшую производительность и оптимизированную маршрутизацию по сравнению с другими методами tunnel. MPLS tunnel может быть реализованы многими способами, среди которых 6PE на MPLS является распространенным способом. 6PE позволяет IPv6 работать на ядре MPLS, которое использует только IPv4, на котором мы используем PE-маршрутизаторы dual stack.
Рисунок 2: Сосуществование IPv4 и IPv6 через MPLS tunnel.
Преимущества & недостатки MPLS tunnel
Советы по сосуществованию IPv4 и IPv6
Даже если существует множество стратегий сосуществования IPv4 и IPv6, вы всегда должны помнить, что это сосуществование является лишь переходом в определенный период времени, и развертывание IPv6 может быть долгосрочной стратегией. С другой стороны, IPv4 в настоящее время доминирует в IP-сетях, что может продолжаться долго из-за трудностей в продвижении IPv6. Поэтому лучше всего выбрать подходящий метод, который будет легче решать проблемы совместимости, что поможет упростить настройку сети и сэкономить средства.
Заключение
Dual stack является прямым способом достижения высокой производительности, но стоимость может быть высокой. Хотя MPLS tunnel может в полной мере использовать исходную сеть, он также приносит вычислительную сложность. Мы советуем выбрать стратегию сосуществования IPv4 и IPv6, которая соответствует характеристикам вашей сети в зависимости от таких факторов, как масштабируемость, безопасность, производительность сети, стоимость, технические трудности и простота развертывания.
