One of my computers is on an IPv4-only ISP so I am using miredo in order to have an IPv6 address. Now I need to access this computer remotely with IPv6. (I can't use IPv4 here because it is behind a NAT I and can't add new port forwardings.) The problem is I can't add an AAAA DNS record because some part of the IP address changes randomly each time the computer connects to the network.
So my question is: is there a way to always use the same IP address with Teredo?
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.
Yes, it is possible to do that with the Teredo protocol. But it requires modified code on both Teredo client and Teredo server.
In order to explain why it can still be considered the same protocol once both client and server has been modified, I first have to explain what the other components involved in the communication are.
Teredo basics
The four critical network nodes in a communication using the Teredo protocol are:
Ultimately it is the Teredo client and the native IPv6 node who want to exchange IPv6 packets. The Teredo servers and Teredo relays exist to facilitate that traffic.
The Teredo server is only involved in the initial connection setup. Once the connection is established traffic between Teredo client and native IPv6 node goes through the relay without the Teredo server seeing any of the traffic.
Since the client has no influence on the choice of Teredo relay, any solution which would require changes on the relay would not work. Luckily that is not required. The connection between client and relay where the bulk of the traffic is send will still be completely standard Teredo traffic.
Because client and relay still communicate using standard Teredo and because the client still has an IPv6 address in the 2001::/32 prefix, this still qualifies as Teredo.
Changes needed
12 of the bits in the Teredo address are chosen at random by the Teredo client. A modification is needed on the client side to make those not be random.
48 of the bits in the Teredo address is the IPv4 address and UDP port number of the Teredo client as seen by the Teredo server.
Here it is very important that those 48 bits are the port address as seen by the server. Due to NAT the client and relay may think the UDP port has a completely different address. But what IPv4 address and port number client and relay sees have no influence on the final IPv6 address.
Normally the only NAT involved is located close to the Teredo client. But if you want to influence the final IPv6 address a NAT could be put on the same machine as the Teredo server. It is even possible to build NAT directly into the Teredo server if you are so inclined.
Does any implementation of this exist?
Probably not.
I have previously implemented most of a Teredo server doing this. But the client would only get to choose the IPv4 address and not the UDP port number. I needed the UDP port number to distinguish clients.
A Teredo server with support for keeping both IPv4 address and UDP port static for a specific user would need some way of recognizing the user. There are fields in the protocol, which could potentially be used for that. But I don't know of any implementation with support for identifying Teredo clients towards Teredo servers.
Moreover Teredo suffers from a significant reliability problem. This reliability problem is related to the part of the Teredo protocol, which is not touched by any modifications I have described here.
The problem with Teredo
The problem is how the native IPv6 node choose which Teredo relay to use. Ideally the administrator of the network on which the native IPv6 node is located would configure a Teredo relay for that network (and locate it outside of the NAT if NAT is being used for IPv4).
But many administrators choose not to deploy a Teredo relay. Usually reasoning that since Teredo is so unreliable, they don't need to support it (never realizing that this reasoning makes Teredo unreliability a self-fulfilling prophecy).
What happens instead is that traffic from the native IPv6 node will be sent through the default route to the upstream provider who in turn may send it to their upstream provider and eventually the traffic may end up on a public third party relay on an AS which has decided to announce 2001::/32.
Using a third party relay means a longer network path which in turn means increased latency. It also means there is no SLA, and the Teredo relay may not have sufficient capacity for the traffic being sent to it.
Most of the cases where a static IP address is desired, some reliability is also desired. And since you rarely have control over all of the remote nodes you will be communicating with, you also have no control over which Teredo relays will be used.
This makes Teredo with static IP address a niche product for those few who are willing to install a modified Teredo client in order to get a static IP address with no guarantees about reliability.
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.
