In computer networks, Teredo is a transitional technology that provides full IPv6 connectivity for IPv6-enabled hosts on the IPv4 Internet but does not have native connections to the IPv6 network. Unlike similar protocols, it can perform its functionality even from network address translation devices (NAT) such as home routers.
Teredo operates using an independent tunneling protocol platform that provides IPv6 (Internet Protocol version 6) connectivity by encapsulating IPv6 datagram packets in IPv4 User Datagram Protocol (UDP) packets. Teredo directs this datagram on the Internet IPv4 and via NAT devices. Teredo nodes elsewhere on the IPv6 network (called Teredo relay ) receive packets, un-encapsulate them, and forward them.
Teredo is a temporary measure. In the long run, all IPv6 hosts must use native IPv6 connectivity. Teredo must be disabled when native IPv6 connectivity is available. Christian Huitema developed Teredo at Microsoft, and the IETF standardized it as RFC 4380. Teredo server listened to port UDP 3544.
Video Teredo tunneling
Destination
6to4, the most common IPv6 protocol over the IPv4 tunneling protocol, requires that tunnel endpoints have public IPv4 addresses. However, many hosts currently attach to the IPv4 Internet through one or more NAT devices, usually due to a lack of IPv4 addresses. In such situations, the only publicly available IPv4 addresses are assigned to NAT devices, and 6to4 tunnel endpoints must be implemented on the NAT device itself. Many NAT devices currently in use, however, can not be upgraded to implement 6to4, for technical or economic reasons.
Teredo reduces this problem by encapsulating IPv6 packets in UDP/IPv4 datagrams, most of which NAT can be forwarded correctly. Thus, IPv6-aware hosts behind NAT can serve as Teredo tunnel endpoints even when they do not have a dedicated public IPv4 address. As a result, hosts that implement Teredo can obtain IPv6 connectivity without the cooperation of the local network environment.
In the long run, all IPv6 hosts must use native IPv6 connectivity. The Teredo Protocol temporarily includes provisions for the sunset procedure: The Teredo application must provide a means to stop using Teredo connectivity when it matures and IPv6 connectivity becomes available using a less fragile mechanism. At IETF89, Microsoft plans to disable their Teredo servers for Windows clients in the first half of 2014 (the exact date of TBD), and encourage the disabling of publicly operated Teredo relays.
Maps Teredo tunneling
Overview
- For a full explanation, see the Teredo Overview on External links.
The Teredo protocol performs several functions:
- Diagnose UDP over IPv4 (UDPv4) connectivity and find the current NAT type (using a simplified replacement to the STUN protocol)
- Specifies a unique IPv6 address that can be redirected globally to any host that uses it
- Encapsulating IPv6 packets in UDPv4 datagrams for transmission over an IPv4 network (this includes NAT traversal)
- Traffic route between Teredo host and native IPv6 host (or otherwise non-Teredo)
Node type
Teredo defines several types of nodes:
- Teredo Client
- A host that has IPv4 connectivity to the Internet from behind NAT and uses the Teredo tunneling protocol to access the IPv6 Internet. The Teredo client is assigned an IPv6 address starting with the Teredo prefix (
2001 ::/32).
- Teredo Server
- A well known host used for the initial configuration of the Teredo tunnel. The Teredo server never forwards any traffic to the client (other than IPv6 ping), and therefore has a simple bandwidth requirement (several hundred bits per second per client at most), meaning one server can support multiple clients. In addition, Teredo servers can be implemented in a completely stateless manner, so use the same amount of memory regardless of how many clients it supports.
- Teredo relay
- The remote end of the Teredo tunnel. A Teredo relay must forward all data on behalf of the Teredo client it serves, with the exception of Teredo's clients directly to the Teredo client exchange. Therefore, relays require a lot of bandwidth and can only support a number of simultaneous clients. Each Teredo relay serves various IPv6 hosts (eg single campus/enterprise, ISP or carrier network as a whole, or even entire IPv6 Internet); forward traffic between Teredo's clients and any hosts within that range.
- Teredo hosted special relay
- Teredo Relay whose service range is limited to the host it uses. Thus, it has no bandwidth or specific routing requirements. Hosted host-specific computers use Teredo to communicate with Teredo clients, but still use IPv6 connectivity providers primarily to reach the entire IPv6 Internet.
IPv6 addressing
Each Teredo client is assigned a public IPv6 address, which is constructed as follows (higher order bit is numbered 0):
- Bits 0 through 31 hold the Teredo prefix (2001 ::/32).
- Bits 32 to 63 embed the primary IPv4 address of the Teredo server in use.
- Bits 64 to 79 hold several flags and other bits; The format for this 16 bit, MSB first, is "CRAAAUGAAAAAAAA". The "C" bit is set to 1 if the Teredo client is located behind a NAT cone, 0 otherwise, but RFC 5991 converts it to 0 to avoid revealing this fact to a stranger. The "R" bit is not currently specified and must be sent as 0. The "U" and "G" bits are set to 0 to mimic the "Universal/local" and "Group/individual" bits in the MAC Address. The 12 "A" bit is 0 in the original RFC 4380 specification, but converted into random bits selected by the Teredo client in RFC 5991 to provide Teredo nodes with additional protection against IPv6-based scanning attacks.
- Bits 80 through 95 contain obfuscated port number UDP. This is the port number that NAT maps to the Teredo client, with all bits reversed.
- Bits 96 to 127 contains an IPv4 obfuscated address. This is a public IPv4 NAT address with all the bits being reversed.
Teredo IPv6 addressing table
For example, the IPv6 address 2001: 0000: 4136: e378: 8000: 63bf: 3fff: fdd2 refers to the Teredo client that:
- Using Teredo server at address 65.54.227.120 (4136e378 in hexadecimal)
- Behind the cone NAT and client does not fully comply with RFC 5991 (64 bit is set)
- Maybe (99.98%) is not compliant with RFC 5991 (12 random bits are all 0, which occurs less than 0.025% of the time)
- UDP maps port 40000 to its NAT (in hexadecimal instead of 63bf equal to 9c40, or decimal number 40000)
- Have public IPv4 public NAT address 192.0.2.45 (not 3ffffdd2 equals c000022d, that is, 192.0.2.45)
Example Teredo IPv6 table
Server
- For a list of available Teredo servers, see the list on the External link.
Teredo clients use Teredo servers to automatically detect their NAT types behind (if any), via a simplified STUN-like qualification procedure . Teredo clients also maintain their NAT binding to their Teredo servers by sending UDP packets periodically. It ensures that the server can always contact one of its clients - required to punch the NAT hole in order to function properly.
If the Teredo relay (or any other Teredo client) has to send an IPv6 packet to a Teredo client, it first sends the Teredo bubble pack to the Teredo client server, whose IP address goes from the Teredo IPv6 address of the Teredo client. The server then forwards the bubble to the client, so the Teredo client software knows it must perform a punch in the direction of the Teredo relay.
The Teredo server can also send ICMPv6 packets from Teredo clients to the IPv6 Internet. In practice, when a Teredo client wants to contact a native IPv6 node, it must locate a corresponding Teredo relay, i.e , to which the public IPv4 and UDP port numbers are to send packaged IPv6 packets. To do that, the client creates an ICMPv6 ( ping ) Echo Request to the IPv6 node, and sends it via a configured Teredo server. The Teredo server outlines the ping to the IPv6 Internet, so the ping must eventually reach the IPv6 node. The IPv6 node should then respond with Echo ICMPv6 Reply, as mandated by RFC 2460. This reply packet is routed to the nearest relay Teredo, which - finally - attempts to contact the Teredo client.
Maintaining Teredo servers requires less bandwidth, as they are not involved in actual transmission and receipt of IPv6 traffic packets. Also, it does not involve access to Internet routing protocols. The only requirements for Teredo servers are:
- The ability to transmit ICMPv6 packets with source addresses belongs to Teredo prefix
- Two different public IPv4 addresses. Although not written in official specifications, Microsoft Windows clients expect both addresses to be consecutive - the second IPv4 address is for NAT detection
Server publik Teredo:
- teredo.remlab.net/teredo-debian.remlab.net (Jerman)
- teredo.ngix.ne.kr (Korea Selatan)
- teredo.managemydedi.com (AS, Chicago)
- teredo.trex.fi (Finlandia)
Relays
Teredo relay potentially requires a lot of network bandwidth. Also, must export ( advertise ) routes to the Teredo prefix IPv6 (2001 ::/32) to other IPv6 hosts. That way, the Teredo relay receives traffic from an IPv6 host addressed to each Teredo client, and passes it via UDP/IPv4. Symmetrically, it receives a packet from a Teredo client addressed to the original host IPv6 via UDP/IPv4 and injects it into the original IPv6 network.
In practice, network administrators can set Teredo personal relays for their companies or colleges. It provides a short path between their IPv6 network and each Teredo client. However, setting Teredo relays on a scale outside a single network requires the ability to export IPv6 BGP routes to other autonomous systems (AS).
Unlike 6to4, where two connection sections can use different relays, traffic between the original IPv6 host and Teredo client uses the same Teredo relay, which is closest to the host-hosted IPv6 host network. The Teredo client can not localize the relay by itself (because it can not send IPv6 packets by itself). If it is necessary to initiate a connection to the original IPv6 host, it sends the first packet through the Teredo server, which sends the packet to the original host IPv6 using the IPv6 Teredo client address. The original IPv6 host then responds as usual to the Teredo IPv6 client address, which eventually causes the packet to locate the Teredo relay, which initiates the connection to the client (possibly using the Teredo server for NAT piercing). The Teredo client and the original host IPv6 then use the relay for communication as long as necessary. This design means both Teredo servers and clients do not need to know the IPv4 address of any Teredo relay. They find that match automatically via the global IPv6 routing table, as all Teredo relays advertise the 2001 ::/32 network.
- For near real-time information on Teredo and BGP, see External links.
On 30 March 2006, ITGate ISP Italia was the first US to start advertising routes to 2001 ::/32 on IPv6 Internet, so that the implementation of Teredo RFC 4380 will be fully usable. On February 16, 2007, it no longer works.
In Q1 2009, Hurricane Electric's IPv6 backbone enabled 14 Teredo relays in anycast and ad implementation 2001 ::/32 globally. The relays are located in Seattle, Fremont, Los Angeles, Chicago, Dallas, Toronto, New York, Ashburn, Miami, London, Paris, Amsterdam, Frankfurt, and Hong Kong.
It is expected that major network operators will maintain Teredo relays. As with 6to4, it remains unclear how well Teredo service will increase if a large number of Internet hosts start using IPv6 via Teredo other than IPv4. While Microsoft has operated a set of Teredo servers since they released the first Teredo pseudo tunnel for Windows XP, they never provided Teredo relay service for the IPv6 Internet as a whole.
Limitations
Teredo is not compatible with all NAT devices. Using RFC 3489 terminology, it supports cone-filled, restricted, and port-limited NAT devices, but does not support symmetric NAT. The original Shipworm specification that caused the final Teredo protocol also supports symmetric NAT, but dropped it due to security issues.
People at National Chiao Tung University in Taiwan then proposed SymTeredo, which enhanced the original Teredo protocol to support symmetric NAT, and the implementation of Microsoft and Miredo implements certain unspecified non-standard extensions to increase support for symmetric NATs. However, the connectivity between the Teredo clients behind the NAT is symmetrical, and the Teredo client behind the port-restricted or symmetric NAT still seems impossible.
Teredo assumes that when two clients exchange encapsulated IPv6 packets, the mapped/external UDP port numbers they use are the same ones used to contact the Teredo server (and build the Teredo IPv6 address). Without this assumption, it is impossible to establish a direct communication between two clients, and an expensive relay should do triangular routing. The Teredo implementation tries to detect the NAT type at startup, and refuses to operate if NAT looks symmetric. (This limitation can sometimes be done by manually configuring port forwarding rules on the NAT box, which requires administrative access to the device).
Teredo can only provide one IPv6 address per tunnel endpoint. Thus, it is not possible to use a single Teredo tunnel to connect multiple hosts, unlike 6to4 and some IPv6 point-to-point tunnels. The bandwidth available to all Teredo clients to the IPv6 Internet is limited by the availability of the Teredo relay, which is no different from the 6to4 relay in that case.
Alternative
6to4 requires a public IPv4 address, but provides a large 48-bit IPv6 prefix for each tunnel endpoint, and has a lower encapsulation overhead. Point-to-point tunnels can be more reliable and more accountable than Teredo, and usually provide a permanent IPv6 address that does not rely on IPv4 addresses from tunnel endpoints. Some point-to-point tunnel brokers also support UDP encapsulation to traverse NAT (for example, the AYIYA protocol can do this). On the other hand, point-to-point tunnels usually require registration. Automated tools (such as AICCU) make it easy to use Point-to-Point tunnels.
Security considerations
Exposure
Teredo increases the attack surface by assigning a globally redirected IPv6 address to the network host behind the NAT device, which would otherwise be accessible from the Internet. By doing so, Teredo potentially exposes applications that support IPv6 with an open port to the outside. Teredo tunnel encapsulation may also cause the contents of IPv6 data traffic to be invisible to packet inspection software, facilitating the spread of malware. Finally, Teredo exposes IPv6 stacks and tunneling software to attack if they have vulnerabilities that can be exploited remotely.
To reduce the attack surface, the Microsoft IPv6 stack has a "protection level" socket option. This allows apps to determine from which source they are willing to receive IPv6 traffic: from Teredo tunnel, from anywhere except Teredo (default), or just from a local Intranet.
The Teredo protocol also summarizes detailed information about the tunnel endpoints in its data packets. This information can assist potential attackers by improving attack feasibility, and/or by reducing the effort required.
Firewalling, filtering and blocking
For Teredo pseudo-tunnel to operate properly, outgoing UDP packets to port 3544 should not be filtered. Additionally, replies to these packages (i.e., "requested traffic") should also be unfiltered. This corresponds to typical NAT settings and stateful firewall functions. Teredo tunnel software reports a fatal error and stops if blocked UDP IPv4 traffic.
DoS via a routing loop
In 2010, a new method to create denial of service attacks through a routing loop using Teredo tunnels was not found. They are relatively easy to prevent.
The default usage in MS-Windows
Current versions of Microsoft Windows enable IPv6 transition technology, including Teredo, by default, exposing new installations to malware that supports IPv6. If not required, this transition technology can be disabled using CLI commands, edit the registry or use group policy.
Implementations
Some Teredo implementations are currently available:
- Windows XP SP2 includes both client relays and host-specific (also in Advanced Network Packages for Service Pack 1).
- Windows Server 2003 has relays and servers provided under the Microsoft Beta program.
- Windows Vista and Windows 7 have built-in support for Teredo with unspecified extensions for symmetric NAT traversal. However, if only existing link-local and Teredo addresses, this operating system does not attempt to resolve AAAA DNS IPv6 records if there is a DNS A record, in which case they are using IPv4. Therefore, only literal IPv6 URLs typically use Teredo [1]. This behavior can be modified in the registry.
- Miredo is a client, relay, and server for Linux, * BSD and Mac OS X,
- ng_teredo is a netgraph-based relay and server for FreeBSD from LIP6 University and 6WIND.
- NICI-Teredo is a relay for the Linux kernel and Teredo user server, developed at Chiao Tung National University.
Choice name
The initial nickname of the Teredo tunneling protocol is Shipworm . The idea is that protocols will penetrate NAT devices, just as hookworms (a kind of wood-boring seashell) bore tunnels through wood. The shipworm is responsible for the loss of many wooden hulls. Christian Huitema, in the original draft, notes that shipworms "only survive in relatively clean and uncontaminated water; recent comebacks in several North American ports are a testimony to their newly taken cleanliness." The Shipworm service should, in turn, contributions [ sic ] to the newly retrieved Internet transparency. "
To avoid confusion with computer worms, Huitema then changed the protocol name from Shipworm to Teredo , after the genus of the worm vessel Teredo navalis .
References
External links
- Teredo Review on Microsoft TechNet
- Anycast Terror BGP current route
- Teredo: Tunneling IPv6 through UDP via Network Address Translations (NATs) . RFC 4380, C. Huitema. February 2006.
- JavaScript Teredo-IP address calculator
Source of the article : Wikipedia
0 Comments