Есть ли способ всегда использовать один и тот же адрес Teredo IPv6?

Teredo IP addresses depend on a few things as per Wikipedia.

First of all, it depends on the IPv4 address of the router. If that is subject to change, you have a problem.

Second, it depends on the source port used by Teredo, which may be translated and changed by the NAT device. If your NAT device does preserve the source port used by applications on the inside, you may be able to get this to be unchanging. If you're on Windows, the "clientport" option for Teredo might be useful. See this technet article.

Short answer: You may be able to get it to be the same most of the time, but your mileage may vary considerably. Likely, you won't be able to get this reliable because the NAT device may mangle your source port. You may be able to stop that by setting up port forwards on your firewall... but you already can't do that... so...

A better option might be to set up a dynamic DNS client, assuming you can find one that will publish an IPv6 address of a teredo interface.

По-видимому, начиная с RFC 5991, некоторые части адреса IPv6 всегда случайны, чтобы сделать его непредсказуемым.

Таким образом, самым простым решением для меня было использование службы динамического DNS, поддерживающей IPv6, например dynv6.com.

Да, это можно сделать с помощью протокола Teredo. Но для этого требуется модифицированный код как на клиенте Teredo, так и на сервере Teredo.

Чтобы объяснить, почему он может считаться одним и тем же протоколом после того, как клиент и сервер были изменены, я сначала должен объяснить, каковы другие компоненты, участвующие в обмене данными.

Основы Teredo

Четыре критических сетевых узла в коммуникации, использующей протокол Teredo:

• Клиент Teredo
• Сервер Teredo (выбирается клиентом)
• Реле Teredo (выбирается собственным узлом IPv6)
• Собственный узел IPv6

В конечном счете, именно клиент Teredo и собственный узел IPv6 хотят обмениваться пакетами IPv6. Серверы Teredo и реле Teredo существуют для облегчения этого трафика.

Сервер Teredo участвует только в начальной настройке соединения. Как только соединение установлено, трафик между клиентом Teredo и собственным узлом IPv6 проходит через ретранслятор, и сервер Teredo не видит какой-либо трафик.

Поскольку клиент не влияет на выбор реле Teredo, любое решение, которое потребовало бы изменений в реле, не будет работать. К счастью, это не требуется. Соединение между клиентом и ретранслятором, по которому отправляется основная часть трафика, все равно будет полностью стандартным трафиком Teredo.

Поскольку клиент и ретранслятор по-прежнему обмениваются данными с использованием стандартного Teredo и поскольку у клиента все еще есть IPv6-адрес в 2001::/32префиксе, это все еще квалифицируется как Teredo.

Нужны изменения

12 бит в адресе Teredo выбираются случайным образом клиентом Teredo. На стороне клиента требуется модификация, чтобы они не были случайными.

48 битов в адресе Teredo - это адрес IPv4 и номер порта UDP клиента Teredo, видимый сервером Teredo.

Здесь очень важно, чтобы эти 48 бит были адресом порта, видимым сервером. Из-за NAT клиент и ретранслятор могут думать, что порт UDP имеет совершенно другой адрес. Но то, что видит IPv4-адрес и номер порта клиент и ретранслятор, не влияет на конечный IPv6-адрес.

Обычно единственный задействованный NAT расположен рядом с клиентом Teredo. Но если вы хотите повлиять на конечный IPv6-адрес, NAT может быть установлен на той же машине, что и сервер Teredo. Можно даже встроить NAT непосредственно в сервер Teredo, если вы склонны к этому.

Существует ли какая-либо реализация этого?

Возможно нет.

Ранее я реализовал большую часть сервера Teredo, делая это. Но клиент может выбрать только адрес IPv4, а не номер порта UDP. Мне нужен был номер порта UDP, чтобы различать клиентов.

Серверу Teredo с поддержкой сохранения статичности IPv4-адреса и UDP-порта для конкретного пользователя потребуется определенный способ распознавания пользователя. В протоколе есть поля, которые потенциально могут быть использованы для этого. Но я не знаю ни одной реализации с поддержкой идентификации клиентов Teredo по отношению к серверам Teredo.

Кроме того, Teredo страдает от значительной проблемы с надежностью. Эта проблема надежности связана с той частью протокола Teredo, которая не затронута никакими модификациями, которые я описал здесь.

Проблема с Тередо

Проблема в том, как собственный узел IPv6 выбирает, какой ретранслятор Teredo использовать. В идеале администратор сети, в которой расположен собственный узел IPv6, должен настроить ретранслятор Teredo для этой сети (и найти его вне NAT, если NAT используется для IPv4).

Но многие администраторы предпочитают не развертывать реле Teredo. Обычно полагая, что, поскольку Teredo настолько ненадежен, им не нужно его поддерживать (никогда не понимая, что это рассуждение делает Teredo ненадежным самоисполняющимся пророчеством).

Вместо этого происходит то, что трафик от нативного узла IPv6 будет отправляться по маршруту по умолчанию вышестоящему провайдеру, который, в свою очередь, может отправлять его своему вышестоящему провайдеру, и в конечном итоге трафик может оказаться на общедоступном стороннем ретрансляторе в AS, который имеет решил объявить 2001::/32.

Использование сторонней ретрансляции означает более длинный сетевой путь, что, в свою очередь, означает увеличение задержки. Это также означает, что SLA отсутствует, и ретранслятор Teredo может не обладать достаточной пропускной способностью для передаваемого ему трафика.

В большинстве случаев, когда требуется статический IP-адрес, также требуется некоторая надежность. И так как вы редко контролируете все удаленные узлы, с которыми вы будете связываться, вы также не можете контролировать, какие реле Teredo будут использоваться.

Это делает Teredo со статическим IP-адресом нишевым продуктом для тех немногих, кто желает установить модифицированный клиент Teredo, чтобы получить статический IP-адрес без каких-либо гарантий надежности.

You may be better off with a 6in4 tunnel. This uses protocol 41 does not require additional NAT rules. There are brokers who provide free tunnels. As long as you are the only one on your network using the tunnel broker IP, there should be no issues.

If your router's IP address is not static, you will need to do additional configuration to reconfigure the network when the IP address changes. This is similar to what you would need to do with DDNS.

Do firewall your connection as you will not have a NAT protecting you from unwanted traffic.

Support for both 6in4 and 6to4 is built into Linux. I originally started with 6to4 which worked but was not as stable as I liked. With 6in4 I have had stable connectivity. I have been using it for NTP connectivity, and get stable time sources over IPv6.