IPv6 Tunneling with Teredo

| Friday, February 26th, 2010 | 2 Comments »

For those that do not have native IPv6 support from their ISP, will have to use some tunneling protocols in order to experience IPv6. These tunneling protocols (Teredo, 6to4, ISATAP) are considered transition technology because they are only meant for temporary use while the world balances serving up IPv4 and IPv6 simultaneously(Dual Stack). In this article I dive into the Teredo protocol and discuss its operation on an IPv4 network, either way, it’s important to know that neither of these protocols will give you true native IPv6 experience. So don’t get too used to any one of them!

Teredo by Microsoft

Teredo (the tunnel of last resort)

The Teredo protocol is used when all other tunneling methods are unavailable, developed by Microsoft, it embeds itself into IPv4 UDP datagrams in order to give you unicast IPv6 access across the IPv4 Internet. It is a NAT traversal transition technology allowing Teredo clients to cross one or multiple NAT’s. Think of this as carpooling. So you’re driving an old clunky car on a pretty bad congested highway. You bring along with you the “new” guy.  He belongs on the IPv6 highway, but can’t get access to it, so he’s hitching a ride with you. He can outdo you in all aspects of the IP protocol. You’re the 800 Series Terminator, and he’s the T-1000.

Don’t get me wrong, he does appreciate your kindness in giving him a lift, but let’s face it, he’s the next version (IPng), and you’re getting old. But don’t be so down, you still have some pretty good tricks up your sleeve like NAT’s, Subnetting, CIDR etc….

So what’s the nitty gritty on Teredo? The way this protocol works is first you need to have an operating system that is IPv6 aware. All recent Microsoft Windows OS’s support IPv6. And by default, these OS’s even prefer IPv6 and only fallback to IPv4 when it doesn’t detect that you have IPv6 access.

  • Windows Vista
  • Windows 7
  • Windows Server 2008 R2

Older versions of Windows do support IPv6 but may not be enabled by default.

  • Windows XP SP2
  • Windows 2003 SP1

You also run the risk of using an outdated version of IPv6. So if you are using Windows XP SP3, make sure you have all the patches installed. You can always check Microsoft’s knowledgebase.

*Note –  A little history, Microsoft was allocated this prefix which it used on early versions of XP and 2003 Server. (3ffe:831F::/32). But now with the RFC officially declaring that 2001::/32 is the official Teredo prefix, this is the one all OS’s will standardize on. Updated patches from Microsoft will fix this.

I say Teredo, you say Miredo!

As always, the Linux/BSD world has their own implemention of the Teredo protocol called Miredo. These distributions don’t include a package but you can find out more info here:

http://www.remlab.net/miredo/

I would also assume that other recent linux-based OS’s also support IPv6 as well as Mac OS. But this isn’t an article on OS’s so check your OS vendor to see if they support IPv6, I’m pretty sure they do.

Now, Teredo communicates from one IPv6 aware host to another IPv6 aware host through IPv4 NATed routers over the IPv4 Internet. This method makes the most economical sense for those looking to experience IPv6 as you do not need to purchase any extra equipment to access the IPv6 Internet. Unlike 6to4 technology which is created with edge routers, this works behind the NATed routers utilizing port 3544.

Teredo is made up of these parts: clients, servers, relays and host-specific relays.

Clients

Teredo clients can connect to other Teredo clients or nodes on the IPv6 Internet. Clients obtain addressing from Teredo servers. The addressing prefix is: 2001::/32. These addresses are defined in RFC 4380. The Teredo server embeds its own IPv4 address that is given out to the client. In order for clients to communicate with other clients, they would have to query the current address of their peer.

So how do clients connect with native IPv6 nodes? They must utilize a Teredo relay. The relaying server has connectivity with both IPv4 and native IPv6 access. It announces the Teredo prefix route out its IPv6 interface.

Servers

Teredo servers have access to both IPv4 and IPv6 networks and provides IPv6 addresses in the form of the Teredo prefix 2001::/32 to prospective clients. These clients can then connect to other IPv6 Teredo clients or directly to IPv6 only nodes. Because Teredo runs on port 3544, it is only natural that the server listens on this port. They can determine if your NAT is compatible with Teredo (restricted/cone). These servers generally do not act as relays and don’t pass data packets. Their job is only to pass information to Teredo clients that will help them get access to IPv6 network/peers.

Relays

Teredo relays are routers that are connected to both the IPv4 and IPv6 Internet. Its job is to forward packets from Teredo clients on IPv4 to IPv6 only nodes on the IPv6 Internet. The relays also listen on port 3544 and occasionally will communicate with Teredo servers to help Teredo clients communicate effectively. Native IPv6 packets are encapsulated for transmission to the IPv4 Internet, while IPv4 traffic is decapsulated for the IPv6 Internet.

Host-specific relays

Pretty much the same as a relay, except that this is an IPv6 host and IPv4 host connected to both IPv6 and IPv4 Internet. In this situation, the Teredo client is better off communicating with this host, rather than going to a Teredo Relay and adding unnecessary hops. This servers serves requests from local hosts only.

Restricted NATs VS Cone NATs

I am going to briefly describe the difference between Restricted and Cone NATs so that you’ll understand the Teredo Addressing Structure further below.

  • Restricted NAT – A NAT that accepts external packets for an internal host if the internal host has sent out a packet to THAT external (destination) host with IP and Port. The NAT will allow the destination host to send packets based on it’s IP address and any port as long as the internal host has communicated with that destination host. The cone flag in the Teredo address structure would be set to 0 indicating that the Teredo client is behind a restricted NAT. (this will be explained below)
  • Cone NAT – Pays more attention to the IP address and port. So external hosts would use the SAME port that was initially used by the internal host in order to communicate back. The cone flag in the Teredo address structure would be set to 1 indicating that the Teredo client is behind a cone NAT. (this will be explained below)
  • Symmetric NAT – Teredo typically does not work behind these kinds of NATs.

Teredo Addressing Structure

Teredo Address Structure

The packet structure consists of five fields:

  • Teredo Prefix (32 bits) – This is the Teredo prefix defined by RFC 4380.  2001::/32
  • Teredo Server IPv4 Address (32 bits) – Remember that Teredo Servers embed their own IPv4 address when configuring Teredo client addresses. This is where the address is placed.
  • Flags (16 bits) – This 16-bit field supports 5 flag types. C, R, A, U and G. The order of these bits are as follows: CRAAAAUG AAAAAAAA
    • A – This flag contains 12 bits of a randomly generated number. Making it extremely hard for any malicious user who has already figured out other parts of this packet, to guess this number as well. (2^12) gives you 4,096 possible numbers. So go ahead, spoof away!
      • Example: 011001100110
    • C – The C bit is simply to state the cone flag. It’s a high order bit that’s set when the Teredo client is behind a NAT and is determined through during initial configuration.
      • Restricted NAT set to 0.
      • Cone NAT set to 1.
    • R – The R bit is reserved for future use.
    • U – By default set to 0. This is the Universal/Local flag.
    • G – By default set to 0. This is the Individual/Group flag.
  • Obscured External Port (16 bits) – External UDP port corresponding to all Teredo traffic for a Teredo client.
    • Let’s break down how this port is created.
      • Most of us understand how NATs work. Most NATs have a routing table that maps internal IPs to its outside IP with a unique external port. This allows traffic on the outside to know how to get back to that particular private host by specifying the same information in the header that it received when communicating back to the host through the NAT. When a Teredo client connects to a Teredo server, the NAT takes its internal UDP port from the client and maps it to an external UDP port.
      • This external port is obscured by XORing the external port with 0xFFFF.
  • Obscured External Address (32 bits) – External IPv4 address corresponding to all Teredo traffic for a Teredo client.
    • Let’s break down how this address is created.
      • This works just about the same way as the Obscured External Port. The NAT device maps the source IPv4 address of the Teredo client to its external IPv4 address. The external address uses the same XOR methods as with the Obscured External Port, but this time with 0xFFFFFFFF.

*It’s important to note that ONLY Teredo Clients receive a Teredo address. Neither Teredo servers, relays or host-specific relays are assigned one.

As you see in the above diagram. Client A is behind a restricted NAT while Client B is behind a cone NAT. I’ve color coded parts of the diagram to relate to where they would be allocated to the Teredo address. Visually, it should be easier to remember their locations. Let’s go over how these two clients obtain their Teredo addresses.

Client A (restricted NAT)

  • This client is behind a restricted NAT with a public IPv4 address of 12.31.56.7
  • UDP port is 8500
  • Because we know it’s behind a restricted NAT, the C bit is set to 0. (zero)

Determining client A address of 2001::c937:370a:CE7:DECB:F3E0:C7F8

There are five main segments to this address, we know that it is a 128 bit address.

  • The first segment is the prefix which is allocated to 2001::
  • The second segment is the Teredo server IP address: 201.55.55.10
    • converted to hexadecimal format is c937:37oa
  • The third segment is the flag. In this example, this is what our flag looks like: 00001100 11100111
    • converted to hexadecimal and we get CE7
  • The fourth segment is the obscured port. We know the port is 8500.
    • converted to hexadecimal is 2134. Here’s the calculation:
      • 0x2134 XOR 0xFFFF = DECB
  • The fifth segment is the obscured external IP address which is: 12.31.56.7
    • converted to hexadecimal format is 0c1f:3807
      • 0x0c1f3807 XOR 0xFFFFFFFF = F3E0:C7F8

Client B (cone NAT)

  • This client is behind a cone NAT with a public IPv4 address of 162.33.44.5
  • UDP port is 6200
  • Because we know it’s behind a cone NAT, the C bit is set to 1. (one)

Determining client B address of 2001::c937:370a:B0B7:E7C7:5DDE:D3FA

There are five main segments to this address, we know that it is a 128 bit address.

  • The first segment is the prefix which is allocated to 2001::
  • The second segment is the Teredo server IP address; 201.55.55.10
    • converted to hexadecimal format is  c937:370a
  • The third segment is the flag. In this example, this is what our flag looks like:  10110000 10110011
    • converted to hexadecimal and we get B0B3
  • The fourth segment is the obscured port. We know the port is 6200.
    • converted to hexadecimal and we get 1838. Here’s the calculation:
      • 0x1838 XOR 0xFFFF = E7C7
  • The fifth segment is the obscured external address. We know the IP address is: 162.33.44.5
    • converted to hexadecimal and we get a221:2c05
      • 0xa2212c05 XOR 0xFFFFFFFF = 5DDE:D3FA

Teredo Packet Formats

  • Teredo data packet format
  • Teredo bubble packets
  • Teredo indicators

The Teredo Data Packet Format

Teredo’s data packet format consists of 4 fields.

  • IPv4 Header – Contains the source and destination IPv4 addresses that corresponds to the automatic tunnel endpoints. This field can be translated by NAT.
  • UDP Header – Contains the source and destination UDP ports and can be translated by NAT.
  • IPv6 Header – Contains the source and destination IPv6 addresses.
  • IPv6 Payload – Contains zero or more IPv6 extensions headers and upper layer PDU’s of the encapsulated IPv6 packet.

The Teredo Bubble Packets

The purpose of these packets is to maintain the NAT table state. These packets do not contain a payload, and is configured with a “Next Header” set to 59, indicating that there is no next header. It allows outside IPv6 nodes to communicate with the internal Teredo client. In order to avoid flooding, bubble packets cannot be sent if one was just sent in the last 2 seconds, or if four were sent in the past 5 minutes without receiving a response. The default refresh interval is 30 seconds. Think of this as a keepalive-type function.

The Teredo Indicators

Two types of indicators are used by Teredo, authentication and origin.

  • Authentication Indicator
    • This indicator is used to protect Router Solicitation (RS) and Advertisements (RA) between the Teredo client and server. A secret key is shared between the client and server. There are 7 fields that make up the Authentication indicator.
      • Indicator Type – two byte field, set to 1.
      • Client ID Length – one byte field indicating the length of the Client Identification field.
      • Authentication Data Length – one byte field indicating the length of the Authentication Value field.
      • Client Identification – Variable length containing an identification string for the Teredo client.
      • Authentication Value – Variable length field contains authentication value for current packet calculated by shared secret key.
      • Nonce – Eight byte field contains random number to provide proof of real live exchange. Tries to prevent packet relay attacks.
      • Confirmation – one byte field contains a value on whether or not the Teredo client is using the correct shared secret key.
        • In the Router Solicitation message, this field is set to 0(zero).
        • In the Router Advertisement message is set to 0(zero) if shared key is correct, non-zero if incorrect.
  • Origin Indicator
    • This header/indicator is used indicate a public IPv4 address and UDP port of a Teredo client, relay, or host-specific relay. There are only 3 fields in this indicator.
      • Indicator Type – two byte field specifies the indicator type.  Set to 0.
      • Obscured Origin Port – two byte field contains obscured external port of either the Teredo client, relay or host-specific relay.
      • Obscured Origin Address – four byte field obscured external IPv4 address of either the Teredo client, relay or host-specific relay.

Router Advertisements and Solicitations

Now that we have a general idea of the Teredo topology, I’ll go into the process of how a client obtains an IP address from a Teredo server or relay. For the sake of brevity, I won’t go into a full fledged diagram. We’ll assume the Teredo client has access to a Teredo server.

  1. The client sends out a router solicitation message the server from a link-local address. It sets the cone flag bit.
  2. The server now responds with a router advertisement message. The response comes from an alternate IPv4 address, this will help to determine what kind of NAT the client
    is behind. If the client receives the response, then it is behind a cone NAT.
  3. The second attempt only occurs if the client does not receive a response. It will then send another RS but this time with no cone flag bit set.
  4. The server, this time will see that the cone flag is not set. Therefore it attempts to send an RA back to the client using the source IPv4 address that corresponds to the destination IPv4 address of the RS. If the client receives a response, it is behind a restricted NAT.
  5. To determine if the client is behind a symmetric NAT, it sends out an RS to server #2.
  6. The server responds with a RA. The client now compares the mapped addresses and UDP ports in the Origin indicators of the RA received by both servers. If they are different, the NAT is mapping the internal address and port number to different external addresses and port numbers.

Maximum Transmission Unit

The size of the MTU should be kept minimal. Because the IPv6 packet is embedded in a UDP datagram, in theory, the size can be 65507 bytes. But a payload of this size could cause fragmentation and reassembly. The minimum should at least be 1280 bytes.

Conclusion

In conclusion, the Teredo protocol can be used to successfully allow those stuck behind NATs to experience the IPv6 Internet. If this protocol becomes widely used, it will be interesting to see how long it would take for IPv4 to be officially deprecated. It could indirectly extend the shelf life of IPv4 as ISP’s may ask their customers to use the Teredo protocol instead of providing native IPv6 support. It could allow ISP’s and commercial networks more time in delaying the process of jumping over to IPv6. It is not meant to be a long term solution, and I hope that it won’t be used that way. People want the advantages of IPv6, and as long as IPv6 traffic is carried by IPv4, those great features will never be truly realized. In any event, it’s a good middle ground technology that can be used to ease the transition.  IPv6 will make Internet life much easier, and the Teredo protocol will help us get there faster.

Share