Teredo Tunnel Simulation

Virtual Machines

In order to simulate Teredo tunneling, one needs two IPv6 nodes and two routers with both IPv4 and IPv6 access. In total, there needs to be four virtual machines to be set up, thus I went for Void Linux, which is known for its low memory foot print thanks to using runit instead of systemd. To minimize resource usage and speed up the setup process, I chose the barebone live image which uses musl instead of glibc. At boot, the image uses only 40 MB of memory.

For virtualization, I used vert-manager, simply because it is available in Debian’s repository (my host OS). For some reason, on amd64, the kernel refuses to boot until I give it over 200 MB, but apparently that is still a really modest number. Networking is provided to the guest OSes via NAT with default configurations.

It is worth mentioning that through virtio, one may use SSH to log into the guests systems from the host OS. I find this especially convenient as it enables me to copy and paste not only commands but also IP addresses between host and guests as well as between guests.

For convenience, from now on, the outside nodes will be referred to as PC A and PC B, on the other hand the routers are named Router A and Router B. Upon boot, they were given an Ethernet interface eth0 with the following addresses.

Local IPv6 addresses were also given but we are not going to need them.

Teredo Tunnel Setup

First, I set up a IPv4 tunnel between the two routers:

# On Router A
ip tunnel add tunn mode sit remote 192.168.122.134 ttl 255
ip link set tunn up
# On Router B
ip tunnel add tunn mode sit remote 192.168.122.127 ttl 255
ip link set tunn up

For this tunnel to be able to act as a Teredo one, the two routers needs to have IPv6 addresses prefixed by 2001::/32.²

# On Router A
ip -6 addr add 2001:2::1/64 dev eth0
# On Router B
ip -6 addr add 2001:3::1/64 dev eth0

Finally, I fellback all IPv6 lookups to the tunnel and enabled IPv6 forwarding:

ip -6 route add default dev tunn
sysctl -w net.ipv6.conf.all.forwarding=1

Teredo Tunnel Usage

The IPv6 addresses of the PCs were set up as follows (0x8067 is PC in ASCII).

# On PC A
ip -6 address add 2001:2::8067/64 dev eth0
# On PC B
ip -6 address add 2001:3::8067/64 dev eth0

By giving both Router A and PC A addresses prefixed by 2001:2::/64 (similarly for Router B and PC B), I implied that they can find each other through the local IPv6 network, for example on PC B:

$ ip -6 route | head -n1
2001:3::/64 dev eth0 proto kernel metric 256 pref medium

To use the newly created tunnel, the PCs simple had to be routed directly to the routers:

# On PC A
ip -6 route add default via 2001:2::1
# On PC B
ip -6 route add default via 2001:3::1

The connection could then be verified by running on PC A:

$ traceroute 2001:3::8067
traceroute to 2001:3::8067 (2001:3::8067), 30 hops max, 80 byte packets
 1  2001:2::1 (2001:2::1)  0.572 ms  0.441 ms  0.328 ms
 2  2001:3::1 (2001:3::1)  0.906 ms  0.888 ms  1.049 ms
 3  2001:3::8067 (2001:3::8067)  1.325 ms  1.174 ms  1.091 ms

Packets Capturing

Fortunately for me³, all traffic of guests OSes were wired to an separate interface named virbr0. To capture going through the tunnel, I simply had to tell Wireshark to listen to the interface, while letting PC A ping PC B though IPv6: ping -c1 2001:3::8067. I then skimmed through the packets sent between the two nodes and looked for the IPv6-in-IPv4 ones.

Packet Contents

Catured IPv6-in-IPv4 looks exactly like how I would imagined it to be. The content of the ping request can be partially decoded as follows.