в чем заключается роль протокола nat64 в ipv6
Адресация в IP-сетях
7.6. Протокол ICMPv6
Для передачи некоторых видов служебной информации в сетях IPv6 используется протокол ICMPv6, принцип работы которого аналогичен протоколу ICMPv4. Наиболее известными сообщениями ICMPv6 являются:
При возникновении новых маршрутов с лучшей метрикой к адресату назначения протоколы ICMP посылают сообщение переадресации маршрута источнику передаваемой информации.
Помимо вышеперечисленных сообщений протокол ICMPv6 предусматривает новые виды сообщений:
Выше было показано, что на «Запрос маршрутизатораIPv6«, рассылаемый устройством в многоадресном режиме всем маршрутизаторам IPv6,в режиме SLAAC может быть получена адресная информация ( значение префикса, его длина и адрес шлюза по умолчанию), рассылаемая в «Объявлениях маршрутизатора IPv6«.
Сообщения «Запрос соседнего узла» и «Объявление соседнего узла» используются для определения (разрешения) МАС-адреса назначения по известному IPv6-адресу. Действие сообщений » Запрос соседнего узла» и «Объявление соседнего узла» похоже на функционирование протокола ARP в сети IPv4. Узел отправляет в локальную сеть запрос с групповым адресом запрашиваемого узла, в котором объединяется префикс группового адреса FF02:0:0:0:0:1:FF00::/104 и младшие 24 бита глобального индивидуального адреса IPv6. В ответ на запрос получает от запрашиваемого узла «Объявление соседнего узла» его МАС-адресом.
Пара сообщений » Запрос соседнего узла» и «Объявление соседнего узла» используется также для обнаружения адресов дубликатов. Для этого узел направляет в локальную сеть » Запрос соседнего узла» со своим IPv6-адресом. Если в сети есть узел с таким же IPv6-адресом, то он отправляет «Объявление соседнего узла», которое уведомляет, что запрошенный адрес уже используется. Если ответ не приходит в течение заданного таймером времени, то запрошенный IPv6- адрес может быть использован на запрашивающем узле.
7.7. Методы сетевой миграции
На период перехода от IPv4 к IPv6 разработан механизм двойного стека, когда маршрутизаторы, коммутаторы и конечные узлы конфигурируются, чтобы поддерживать оба протокола, причем, IPv6, является привилегированным. То есть, на интерфейсах устройств конфигурируется два стека протоколов.
При туннелировании пакеты IPv6 инкапсулируются в пакеты IPv4, при этом, пакеты IPv6 воспринимаются как обычные передаваемые данные. Это позволяет передавать пакеты IPv6 через сети IPv4.
Технологии для миграции на IPv6
В настоящее время общее количество возможных к использованию IP-адресов версии четыре подошло к концу. Последние блоки официально распроданы, какие-то запасы еще остаются у тех, кто успел закупить себе достаточное количество адресного пространства. Всем уже давно известно, что в скором будущем придется переходить к другой технологии, известной как IP-адресация шестой версии. Некоторые организации уже начинают осуществлять данный переход на своих сетях.
В данном обзоре хотелось бы привлечь внимание читателя к тому, что сейчас уже существуют решения проблем при переходе на технологию IPv6, причем эти решения уже применяются на сетях связи различных компаний. Перечислить основные плюсы и минусы каждого решения, что позволит каждому выбрать то, что больше подходит для него лично.
Давайте рассмотрим все более детально.
Double NAT (aka NAT444)
Технология позволяющая «отсрочить» тот момент, когда адресное пространство IPv4 подойдет к концу. Смысл в том, что технология трансляции применяется два раза. Первый раз приватный адрес подсети клиента транслируется в другой приватный адрес, например это может сделать домашний маршрутизатор, или небольшой корпоративный файрвол. После чего устройство на операторской сети, транслирует адрес, полученный в результате первого преобразования, в глобальный адрес сети Интернет. Это позволяет увеличить число устройств подключенных по технологии IPv4.
Данная технология позволит «отсрочить» конец IPv4 адресного пространства, но не поможет нам перейти на технологию IPv6.
Основным преимуществом Double NAT является то, что нет необходимости менять клиентские устройства, а так же менять их функционал для работы в IPv6-сети. Это один из самых дешевых вариантов «временного» решения проблемы нехватки IPv4-адресов.
NAT-PT
Технология трансляции адресов IPv4 в адреса IPv6. Данная технология не получила широкого применения из-за значительных ограничений масштабируемости и проблем в работе приложений и безопасности (подробно можно узнать: RFC 4966).
NAT 64
Технология трансляции IPv6-адресов в адреса IPv4. Данная технология требует дополнительного функционала DNS 64. NAT 64 пришел на смену NAT-PT, и работает только, если IPv6-устройство инициирует соединение. Это позволяет оборудованию IPv6-адресации думать, что оно работает в сети IPv6, несмотря на то, что оно работает с оборудованием IPv4, и наоборот.
Данная технология требует наличия на сети специальных CGNAT-устройств, способных осуществлять преобразование NAT64. Технология NAT64 позволяет решить проблему предоставления сервисов IPv6 на сети провайдера, а так же проблему нехватки IPv4-адресов.
DS-Lite
Данная технология использует соединения IPv6 между провайдером услуг и его клиентами. Если клиент посылает IPv4-пакет во внешнюю сеть, то его граничное устройство инкапсулирует этот пакет в IPv6-пакеты, и отправляет в ядро сети оператора связи, где пакет деинкапсулируется и отправляется во внешний мир. Таким образом, все приложения и устройства, использующие IPv4 в клиентской сети, могут работать через IPv6-сеть провайдера без особенных проблем. Используя данную технологию, провайдер услуг может перейти на полное использование IPv6, но при этом поддерживать IPv4-сервисы в своей сети.
Таким образом, провайдеру необходимо использовать клиентские устройства поддерживающие технологию DS-lite., а также специальные устройства CGN/AFTR, способные осуществлять деинкапсуляцию пакетов.
В этом случае, технология NAT применяется один раз, на устройстве CGN, а не на конечном устройстве пользователя.
DS-lite A+P
Основными недостатками данной технологии считается необходимость использования поддержки технологии на CPE клиента, а также сложность работы приложений, использующих определенные порты, таких как FTP и WEB сервера.
Технология пропуска IPv6-трафика через IPv4-сеть позволяет IPv6-клиентским устройствам и приложениям получать услуги доступа к IPv6-хостам, через IPv4-сеть провайдера услуг.
Пожалуй, самый простой способ получения связности между IPv6-хостами через IPv4-сеть. Для этого от провайдера услуг не требуется делать ничего дополнительного на сети. Единственным условием для работы технологии является наличие у клиента статического публичного IPv4-адреса.
Технология использует специальные устройства, которые называются 6to4 relay. Эти устройства деинкапсулируют клиентские IPv6-пакеты из IPv4, и передают их далее по сети до требуемого IPv6-назначения. Они могут располагаться где угодно на просторах Интернет. Данный функционал может использоваться как отдельным устройством, так и сразу в подсети из нескольких устройств.
Технология не позволяет осуществлять коммуникации между «чистым» IPv4 и IPv6-устройством, как это делает NAT64, а также не решает проблемы окончания IPv4-адресного пространства. Это просто механизм общения IPv6-устройств через IPv4-сеть.
IPv6 rapid deployment
Данная технология необходима тем, кто хочет предоставлять услуги IPv6 через сеть, основанную на IPv4. Технология 6rd использует принцип туннелирования IPv6-пакетов через IPv4, а также позволяет обойти некоторые ограничения 6to4.
Необходимо отметить, что данная технология не решает проблему нехватки IPv4-адресов, а только позволяет использовать услуги IPv6 через IPv4-сеть.
6PE/6VPE
Эта технология не решает проблему перехода к IPv6-адресации, а позволяет IPv6-хостам общаться через IPv4 mpls-сеть.
Для реализации любого из выше предложенных методов, необходимо либо использовать дополнительное оборудование, которое может выполнять функции преобразования адресов или туннелирования, например A10 Thunder, или модернизировать существующие устройства на сети, добавив специальные сервисные модули в маршрутизаторы известных брендов Cisco, Juniper, Ericsson.
Выбор решения, прежде всего, зависит от экономической составляющей, и конечной цели.
Самым идеальным случаем можно считать dual stack на сети.
Если вам необходимо продлить жизнь вашей сети на основе IPv4, можно воспользоваться недорогими и простыми устройствами способными осуществлять преобразование NAT, вплоть до решений, основанных на серверах и свободном ПО. Все зависит от требуемой производительности решения.
Если же хочется начать предоставлять услуги на базе IPv6, на максимально удобных для вас условиях, стоит воспользоваться 6to4 или 6rd. 6to4 не потребует от вас в принципе никаких модернизаций, а 6rd позволит осуществлять более плотный контроль за работой ваших клиентов, и предоставлять сервис более высокого класса.
Остальные рассмотренные технологии применяются в зависимости от частной конкретной ситуации.
NAT (Network Address Translation) для новичков
Приветствую всех читателей данной статьи!
Данная статья будет полезна как новичкам в IT сфере, так и неопытным системным администраторам/ сетевым инженерам. Здесь затрагиваются понятия и принцип работы технологии NAT, ее значение в наше время, виды и создание с конфигурированием в программе-симуляторе Cisco Packet Tracer.
Введение
С задачей объединения устройств в единую сеть помогают различные компании, занимающиеся разработкой и внедрением сетевого оборудования.На сей момент на рынке сетевого оборудования доминируют компании Cisco Systems и Huawei. В данной статье будем вести работу с оборудованием Cisco.
В операционной системе IOS представлен специфичный интерфейс командой строки CLI (Command Line Interface). В этом интерфейсе возможно использовать некоторое количество команд. Количество зависит от выбранного режима и от уровня привилегий пользователя (пользовательский, привилегированный, глобальной конфигурации и специфической конфигурации).
Нехватка IP адресов. Технология NAT
В 80х годах ХХ века заложили основу IPv4, позволяющую создавать
4.3 млрд. адресов, но никто не предполагал, что этот запас так быстро иссякнет. С каждым годом появлялось все больше и больше пользователей и с 25 ноября 2019г. в России и в Европе официально закончились IP адреса. Лимит исчерпан.
Для решения этой проблемы было придумано несколько способов:
Первый способ заключается в усилении контроля за IP адресами.
Пусть существует некоторый сайт N с IPv4 xxx.xxx.xxx.xxx, и его хост решил прекратить его поддержание данного сайта. Сайт заброшен, а IP продолжает числиться как занятый и таких случаев может быть очень много. То бишь необходимо провести «инвентаризацию» IP адресов и изъять неиспользуемые/заброшенные.
Протокол IPv6 разработан как преемник протокола IPv4. Основные преимущества IPv6 над IPv4 заключаются в увеличенном адресном пространстве (IPv4 имел 32 бита, что равнялось 2 32 адресам, а IPv6 имел 128 бит, что равнялось 2 128 адресам), 6 версия протокола стала безопаснее (т.к. в v4 не предусматривались многие аспекты безопасности, ибо расчет был на сторонние ПО, а в v6 появились контрольные суммы и шифрование пакетов), однако это далеко не все преимущества IPv6 над IPv4.
Проблема, казалось бы, решена, однако перейти с протокола IPv4 на IPv6 вызывает трудности, потому что эти протоколы несовместимы. И изюминкой причины тяжелого перехода на 6 версию протокола является денежная стоимость. Многие кампании не готовы вложить достаточное кол-во средств для перехода, хоть и стоит отметить, что процесс перехода с 4 на 6 версию постепенно идет.
Cогласно документу RFC 1918, IANA зарезервировала 3 блока адресов для частных IP (серых) (рис 1), остальные же IP адреса носят название публичных адресов (белых).
рис.1
Маршрутизатор подменяет обратный IP-адрес пакета на свой внешний (видимый из интернета) IP-адрес и меняет номер порта (чтобы различать ответные пакеты, адресованные разным локальным компьютерам). Комбинацию, нужную для обратной подстановки, маршрутизатор сохраняет у себя во временной таблице. Через некоторое время после того, как клиент и сервер закончат обмениваться пакетами, маршрутизатор сотрет у себя в таблице запись об n-ом порте за сроком давности.
Существует множество типов технологии NAT, однако основными принято считать: Статический NAT (Static Network Address Translation), Динамический NAT (Dynamic Network Address Translation) и Перегруженный NAT (Network Address Translation Overload).
Статический NAT применяют для отображения незарегистрированного IP-адреса на зарегистрированный IP-адрес на основании один к одному. Особенно полезно, когда устройство должно быть доступным снаружи сети.
рис 2
Статический NAT используется чаще всего в корпоративных сетях, когда необходимо, чтобы какой-либо IP адрес всегда был доступен из глобальной сети. Зачастую статическим IP наделяют сервера и помещают их в DМZ (рис 2).
Подготовка компьютерной сети
Логическая схема топологии сети будет выглядеть как показано на изображении (рис 3)
рис 4
рис 5
Теперь нужно настроить непосредственно маршрутизатор. Технология sub-interface позволяет объединять несколько виртуальных интерфейсов в один и подключить их к физическому интерфейсу (на маршрутизаторе выбран физический интерфейс fa0/0). Необходимо дать для каждого VLAN’а свой под-интерфейс (показано красным на рис 5) и выдать им IP адрес (показано зеленым на рис 5).
Таким образом, в будущем мы будем NAT’ить трафик.
Дадим серверу статичный IP 192.168.3.2, а остальных оставим для динамического распределения адресов.
После настройки DHCP, нужно прописать на каждом саб-интерфейсе в R0 команду «ip helper-address 192.168.3.2», тем самым указывая, куда стоит обращаться для получения IP адреса.
После данной команды, устройства получат запрашиваемые IP адреса.
рис 6
Пингуем с рандомного ПК сам сервер (1 пинг) и шлюзы маршрутизатора (2- 3 пинг) (рис 6).
Дальше для удобства будем эмулировать подключение к провайдеру, путем создания в программе-симуляторе РС провайдера, сервера Serv2 с IP 213.234.60.2 (эмулирующий остальную сеть интернет) и роутера R3.
Настройка NAT
Ну и наконец-то мы дошли до самой настройки NAT.
Для внедрения NAT нужно определиться какие порты будут внешними(outside), а какие внутренними(inside).
рис 7
рис 8 рис 9
А теперь, на финал, внедрим NAT Overload на R0.
Для этого создадим ACL и пропишем там сети, которые должны «натиться» (показано синим на рис 9) и, показав что нужно «натить», активируем лист (показано красным на рис 9).
Таким образом, реализовав статическую и динамическую (типа PAT) настройку NAT, мы смогли защитить небольшую сеть от подключения извне.
Надеюсь вам понравилась данная статья.
Спасибо за ее чтение, всем хорошего настроения 🙂
Клиент IPv6 встраивает IPv4-адрес, с которым он хочет связываться, используя часть хоста сетевого сегмента IPv6, что приводит к встроенным IPv4-адресам (отсюда и 32-битное адресное пространство в сетевом сегменте IPv6), и отправляет пакеты на полученный адрес. Шлюз NAT64 создает сопоставление между адресами IPv6 и IPv4, которое может быть настроено вручную или определено автоматически.
Принцип действия
Простая установка NAT64 может состоять из шлюза с двумя интерфейсами, подключенными к сети IPv4 и сети IPv6 соответственно. Трафик из сети IPv6 направляется через шлюз, который выполняет все необходимые преобразования для передачи пакетов между двумя сетями. Однако преобразование не является симметричным, поскольку адресное пространство IPv6 намного больше адресного пространства IPv4 ; таким образом, однозначное отображение адресов невозможно. Шлюз поддерживает преобразование адресов IPv6 в IPv4, которое может быть установлено с помощью автоматического алгоритма (сопоставление без сохранения состояния) или с помощью специальных и ручных преобразований (сопоставление с отслеживанием состояния), когда первый пакет из сети IPv6 достигает шлюза NAT64.
Трансляция без сохранения состояния подходит, когда транслятор NAT64 используется перед серверами только для IPv4, чтобы позволить им быть доступными для удаленных клиентов, работающих только с IPv6. Преобразование с отслеживанием состояния подходит для развертывания на стороне клиента или у поставщика услуг, позволяя клиентским узлам, поддерживающим только IPv6, достигать удаленных узлов, поддерживающих только IPv4.
Как правило, NAT64 предназначен для использования, когда связь инициируется хостами IPv6. Некоторые механизмы, в том числе статическое сопоставление адресов, позволяют реализовать обратный сценарий.
Networking Overview
Supporting IPv6 DNS64/NAT64 Networks
With IPv4 address pool exhaustion imminent, enterprise and cellular providers are increasingly deploying IPv6 DNS64 and NAT64 networks. A DNS64/NAT64 network is an IPv6-only network that continues to provide access to IPv4 content through translation. Depending on the nature of your app, the transition has different implications:
If you’re writing a client-side app using high-level networking APIs such as NSURLSession and the CFNetwork frameworks and you connect by name, you should not need to change anything for your app to work with IPv6 addresses. If you aren’t connecting by name, you probably should be. See Avoid Resolving DNS Names Before Connecting to a Host to learn how. For information on CFNetwork, see CFNetwork Framework Reference.
What’s Driving IPv6 Adoption
Major network service providers, including major cellular carriers in the the United States, are actively promoting and deploying IPv6. This is due to a variety of factors.
IPv4 Address Depletion
IPv6 More Efficient than IPv4
Aside from solving for the IPv4 depletion problem, IPv6 is more efficient than IPv4. For example, IPv6:
Avoids the need for network address translation (NAT)
Provides faster routing through the network by using simplified headers
Prevents network fragmentation
Avoids broadcasting for neighbor address resolution
4G Deployment
The fourth generation of mobile telecommunication technology (4G) is based on packet switching only. Due to the limited supply of IPv4 addresses, IPv6 support is required in order for 4G deployment to be scalable.
Multimedia Service Compatibility
IP Multimedia Core Network Subsystem (IMS) allows services such as multimedia SMS messaging and Voice over LTE (VoLTE) to be delivered over IP. The IMS used by some service providers is compatible with IPv6 only.
Service providers incur additional operational and administrative costs by continuing to support the legacy IPv4 network while the industry continues migrating to IPv6.
DNS64/NAT64 Transitional Workflow
To help slow the depletion of IPv4 addresses, NAT was implemented in many IPv4 networks. Although this solution worked temporarily, it proved costly and fragile. Today, as more clients are using IPv6, providers must now support both IPv4 and IPv6. This is a costly endeavor.
Figure 10-1 A cellular network that provides separate IPv4 and IPv6 connectivity 
Ideally, providers want to drop support for the IPv4 network. However, doing so prevents clients from accessing IPv4 servers, which represent a significant portion of the Internet. To solve this problem, most major network providers are implementing a DNS64/NAT64 transitional workflow. This is an IPv6-only network that continues to provide access to IPv4 content through translation.
Figure 10-2 A cellular network that deploys an IPv6 network with DNS64 and NAT64 
Figure 10-3 DNS64 IPv4 to IPv6 translation process 
Figure 10-4 Workflow of a DNS64/NAT64 transitional solution 
IPv6 and App Store Requirements
Compatibility with IPv6 DNS64/NAT64 networks will be an App Store submission requirement, so it is essential that apps ensure compatibility. The good news is that the majority of apps are already IPv6-compatible. For these apps, it’s still important to regularly test your app to watch for regressions. Apps that aren’t IPv6-compatible may encounter problems when operating on DNS64/NAT64 networks. Fortunately, it’s usually fairly simple to resolve these issues, as discussed throughout this chapter.
Common Barriers to Supporting IPv6
Several situations can prevent an app from supporting IPv6. The sections that follow describe how to resolve these problems.
Ensuring IPv6 DNS64/NAT64 Compatibility
Adhere to the following guidelines to ensure IPv6 DNS64/NAT64 compatibility in your app.
Use High-Level Networking Frameworks
Apps requiring networking can be built upon high-level networking frameworks or low-level POSIX socket APIs. In most cases, the high-level frameworks are sufficient. They are capable, easy to use, and less prone to common pitfalls than the low-level APIs.
Figure 10-5 Networking frameworks and API layers 
WebKit. This framework provides a set of classes for displaying web content in windows, and implements browser features such as following links, managing a back-forward list, and managing a history of pages recently visited. WebKit simplifies the complicated process of loading webpages—that is, asynchronously requesting web content from an HTTP server where the response may arrive incrementally, in random order, or partially due to network errors. For more information, see WebKit Framework Reference.
CFNetwork. This Core Services framework provides a library of abstractions for network protocols, which makes it easy to perform a variety of network tasks such as working with BSD sockets, resolving DNS hosts, and working with HTTP/HTTPS. To target a host without an explicit IP address, call the CFHostCreateWithName method. To open a pair of TCP sockets to the host, call the CFStreamCreatePairWithSocketToCFHost method. For more information, see CFNetwork Concepts in CFNetwork Programming Guide.
Note: Getting Started with Networking, Internet, and Web and Networking Overview provide detailed information on networking frameworks and APIs.
Don’t Use IP Address Literals
Note: In iOS 9 and OS X 10.11 and later, NSURLSession and CFNetwork automatically synthesize IPv6 addresses from IPv4 literals locally on devices operating on DNS64/NAT64 networks. However, you should still work to rid your code of IP address literals.
Connect Without Preflight
Use Appropriately Sized Storage Containers
Check Source Code for IPv6 DNS64/NAT64 Incompatibilities
Check for and eliminate IPv4-specific APIs, such as:
If your code handles IPv4 types, make sure the IPv6 equivalents are handled too.
Use System APIs to Synthesize IPv6 Addresses
If your app needs to connect to an IPv4-only server without a DNS hostname, use getaddrinfo to resolve the IPv4 address literal. If the current network interface doesn’t support IPv4, but supports IPv6, NAT64, and DNS64, performing this task will result in a synthesized IPv6 address.
Listing 10-1 Using getaddrinfo to resolve an IPv4 address literal
Test for IPv6 DNS64/NAT64 Compatibility Regularly
To set up a local IPv6 Wi-Fi network using your Mac
Make sure your Mac is connected to the Internet, but not through Wi-Fi.
Launch System Preferences from your Dock, LaunchPad, or the Apple menu.
Press the Option key and click Sharing. Don’t release the Option key yet.
Figure 10-7 Opening Sharing preferences 
Select Internet Sharing in the list of sharing services.
Figure 10-8 Configuring Internet sharing 
Release the Option key.
Select the Create NAT64 Network checkbox.
Figure 10-9 Enabling a local IPv6 NAT64 network 
Choose the network interface that provides your Internet connection, such as Thunderbolt Ethernet.
Figure 10-10 Choosing a network interface to share 
Select the Wi-Fi checkbox.
Figure 10-11 Enabling sharing over Wi-Fi 
Click Wi-Fi Options, and configure the network name and security options for your network.
Select the Internet Sharing checkbox to enable your local network.
Figure 10-14 Enabling Internet sharing 
When prompted to confirm you want to begin sharing, click Start.
Figure 10-15 Starting Internet sharing 
Once sharing is active, you should see a green status light and a label that says Internet Sharing: On. In the Wi-Fi menu, you will also see a small, faint arrow pointing up, indicating that Internet Sharing is enabled. You now have an IPv6 NAT64 network and can connect to it from other devices in order to test your app.
Figure 10-16 Internet sharing indicator 
Important: To ensure that testing takes place strictly on the local IPv6 network, make sure your test devices don’t have other active network interfaces. For example, if you are testing with an iOS device, make sure cellular service is disabled so you are only testing over Wi-Fi.
Limitations of Local Testing
A Mac-based IPv6 DNS64/NAT64 network is a useful tool for testing your app in an IPv6 environment. However, because it always generates synthesized IPv6 addresses and transmits data on the WAN side using IPv4, it’s not an exact replica of the networks supplied by service providers. These networks (as well as the one used during App Review) do allow for direct IPv6-to-IPv6 connectivity. If your server is misconfigured, this might result in your app behaving differently in regular use or during review than it does in your local testing. It might even result in an App Review failure that is hard to reproduce in your own environment.
In particular, you may run into trouble if your server claims to support IPv6, but in practice does not. In this case, during your initial testing, your app appears to be communicating with your server via an IPv6 path, and thus behaves properly. However, your test network is actually translating the IPv6 traffic that your app generates to IPv4 traffic on the WAN. Therefore, you’re actually exercising your server’s IPv4 data path. Later, during App Review (or in the real world), the app operates identically, but the network makes a direct IPv6 connection to the server. If your server fails to respond properly to IPv6 traffic, your app fails to operate as expected, and might fail App Review.
To avoid this, in addition to using a Mac-based IPv6 DNS64/NAT64 test network to validate your app, independently verify that your server is working properly as an IPv6 server. For example, make sure that the server:
Has the correct DNS information. In addition to examining the server itself, you can use the command line tool dig(1) from your Mac to see how server reports its AAAA record.
Is actually listening on IPv6. Use a tool like ipv6-test.com to test a web server (HTTP or HTTPS). For other protocols, you’ll need to verify this from a native IPv6 network.
Responds properly to IPv6 requests. If you have access, look at the server logs to verify that IPv6 traffic is being handled properly. If not, you’ll need to test from a native IPv6 network.
Resources
For more information on implementing networking, see: