Приложение Java PHP рассчитать или получить IPv6 из IPv4, если доступно
я придумал решение создать сеть «как p2p» в Java.
Я использую веб-сервер в качестве моста для соединений. у каждого клиента есть java-сервер и java-клиент, которые могут общаться через мою ip-базу данных на моем php-сервере. Моя проблема в том, что он работает только с IPv6, и я знаю, что не все пользователи имеют адрес IPv6. Можно ли рассчитать IPv6-адрес из v4 и сохранить его в моей базе данных для подключения к нему других клиентов, даже если они подключаются из-за маршрутизатора NAT?
после долгого исследования я теперь могу обрабатывать IPv6-адреса, но я понял, что мой IPv6-адрес меняется каждый раз, когда я подключаюсь к маршрутизатору ?! первые 4 блока всегда одинаковы, но последние 4 блока моего ipv6 чейнгируют. Я думаю, что я ищу правильный путь, или это невозможно? если это невозможно (я так не думаю) как http://ipv6.whatismyv6.com/ Это?
Решение
Вашему вопросу не хватает контекста. Так что не понятно, что именно вы просите. Однако у меня есть три предложения в зависимости от того, как я интерпретирую ваш вопрос.
У вас есть сервер, доступный через IPv4 и IPv6, к которым подключаются клиенты. Вы хотите рассказать клиентам об IPv6-адресах друг друга. Но для клиента, который подключен через IPv4, есть вероятность, что у клиента нет адреса IPv6. Ожидается, что те, которые имеют как IPv4, так и IPv6, будут использовать IPv6 для подключения к вашему серверу.
В этой ситуации, если протокол позволяет передавать только IPv6-адрес, но единственный IP-адрес, который вы должны сообщить о одноранговом узле, — это IPv4-адрес, тогда вы можете просто использовать ::ffff:0:0/96 префикс. Если IPv4-адрес клиента был 192.0.2.3 тогда вы можете сказать другому клиенту, что адрес был ::ffff:192.0.2.3, Когда другой клиент пытается подключиться к ::ffff:192.0.2.3фактически он установит соединение IPv4 с этим IP-адресом.
Это, конечно, все еще не решает проблемы, представленные NAT.
Возможно, клиент, подключившийся к вашему серверу по протоколу IPv4, сделал это, потому что у него не было собственного адреса IPv6, но он все еще мог иметь автоматический туннель. Например, некоторые системы автоматически назначают адрес 6to4, если у них есть общедоступный адрес IPv4, но нет адреса IPv6. Если адрес IPv4 был 192.0.2.3 общий подход к генерации адреса 6to4 будет выглядеть примерно так 2002:192.0.2.3::192.0.2.3 (это не совсем допустимая нотация, поскольку встраивание IPv4-адреса в нотацию IPv6-адреса разрешено только для последних 32 бит. Действительной нотацией будет 2002:c000:203::192.0.2.3).
Но этот способ получения адреса IPv6 для хоста из адреса IPv4 будет работать только для хоста с публичным адресом IPv4. И не все хосты будут автоматически настраивать 6to4, поэтому он не будет работать в большинстве ситуаций.
Если у вас есть приложение только для IPv6, и вы хотите добавить поддержку клиентов без собственного IPv6-адреса путем встраивания туннелирования непосредственно в приложение, то я думаю, что Teredo является наиболее подходящим протоколом. Преимущество Teredo заключается в том, что он работает путем туннелирования IPv6 поверх UDP, и поэтому его можно встраивать в приложение без специальных привилегий. Большинство ОС разрешают любому приложению открывать порт UDP.
Если ваше приложение обычно отправляет UDP-пакеты по IPv6 между клиентами, то создание пакета Teredo путем встраивания этого UDPv6-пакета в пакет Teredo довольно просто. Вам просто нужно поставить префикс двух заголовков фиксированного размера и вычислить контрольную сумму. Если ваш клиент обычно общается с использованием TCP через IPv6, то такой подход становится намного сложнее. Связавшись с портом UDP и используя свою собственную реализацию Teredo, вы не будете использовать реализацию TCP в ОС, поэтому ваше приложение должно будет содержать свою собственную реализацию TCP. Я бы порекомендовал стремиться к дизайну, в котором это не станет необходимым.
Предполагая, что ваше приложение привязано к порту UDP, и если отправитель и получатель имеют собственный IPv6, вы просто отправляете пакеты UDP между ними, что будет означать этот подход для других случаев?
Ваше приложение должно работать в одном из трех разных режимов:
- Только IPv6. Используется экземплярами, которые имеют собственный адрес IPv6 и не имеют общедоступного адреса IPv4. Предполагается, что весь мир — это IPv6, и для связи с клиентами, у которых нет IPv6-адреса, используются сторонние реле Teredo.
- Режим реле Teredo. Используется экземплярами, которые имеют собственный адрес IPv6 и общедоступный адрес IPv4. Поскольку эти экземпляры имеют общедоступный IPv4-адрес, их UDP-порт может быть доступен тем клиентам, у которых нет собственного IPv6. Это позволяет избежать зависимости от сторонних реле Teredo.
- Режим клиента Teredo. Используется экземплярами, которые не имеют собственного адреса IPv6.
Любая прямая связь между двумя узлами, использующими только IPv4, за отдельными шлюзами NAT, должна полагаться на пробой NAT. Teredo позволяет использовать много различных видов пробивки NAT, поэтому если вам понадобится пробивать NAT в вашем приложении, вы также можете использовать протокол Teredo, так как он одновременно предоставляет немного механизма перехода IPv6.
Я хотел бы просто указать на библиотеку, выполняющую все вышеперечисленное, но, к сожалению, я ее не знаю.
Другие решения
Других решений пока нет …