View source for Teredo tunneling

{{Short description|Protocol transition technology in computer networking}}
{{IPv6 transition mechanisms}}

In [[computer network]]ing, '''Teredo''' is a [[Microsoft]] [[IPv6 transition mechanisms|transition technology]] that gives full [[IPv6]] connectivity for IPv6-capable hosts that are on the [[IPv4]] [[Internet]] but have no native connection to an IPv6 network. Unlike similar protocols such as [[6to4]], it can perform its function even from behind [[network address translation]] (NAT) devices such as home routers.

Teredo operates using a [[platform independent]] [[tunneling protocol]] that provides [[IPv6]] (Internet Protocol version 6) connectivity by [[encapsulation (networking)|encapsulating]] IPv6 [[datagram]] packets within IPv4 [[User Datagram Protocol]] (UDP) packets. Teredo routes these datagrams on the [[IPv4 Internet]] and through NAT devices. Teredo nodes elsewhere on the IPv6 network (called '''Teredo relays''') receive the packets, un-encapsulate them, and pass them on.

Teredo is a temporary measure. In the long term, all IPv6 hosts should use native IPv6 connectivity. Teredo should be disabled when native IPv6 connectivity becomes available.  [[Christian Huitema]] developed Teredo at [[Microsoft]], and the [[IETF]] standardized it as RFC 4380. The Teredo server listens on [[User Datagram Protocol|UDP]] port [[Well-known ports|3544]].

== Purpose ==
{{Unreferenced section|date=September 2021}}
For [[6to4]], the most common IPv6 over IPv4 tunneling protocol, requires that the tunnel endpoint have a public IPv4 address. However, many hosts currently attach to the IPv4 Internet through one or several NAT devices, usually because of [[IPv4 address exhaustion|IPv4 address shortage]]. In such a situation, the only available public IPv4 address is assigned to the NAT device, and the 6to4 tunnel endpoint must be implemented on the NAT device itself. The problem is that many NAT devices currently deployed cannot be upgraded to implement 6to4, for technical or economic reasons.

Teredo alleviates this problem by encapsulating IPv6 packets within UDP/IPv4 datagrams, which most NATs can forward properly. Thus, IPv6-aware hosts behind NATs can serve as Teredo tunnel endpoints even when they don't have a dedicated public IPv4 address. In effect, a host that implements Teredo can gain IPv6 connectivity with no cooperation from the local network environment.

In the long term, all IPv6 hosts should use native IPv6 connectivity. The temporary Teredo protocol includes provisions for a ''sunset procedure'': Teredo implementation should provide a way to stop using Teredo connectivity when IPv6 matures and connectivity becomes available using a less brittle mechanism. As of IETF89{{clarify|date=February 2020}}, Microsoft plans to deactivate their Teredo servers for Windows clients in the first half of 2014{{update inline|date=February 2020}} (exact date TBD), and encourage the deactivation of publicly operated Teredo relays.

== Overview ==
The Teredo protocol performs several functions:
# Diagnoses UDP over IPv4 (UDPv4) connectivity and discovers the kind of NAT present (using a simplified replacement to the [[STUN]] protocol)
# Assigns a globally routable unique IPv6 address to each host using it
# Encapsulates IPv6 packets inside UDPv4 datagrams for transmission over an IPv4 network (this includes [[NAT traversal]])
# Routes traffic between Teredo hosts and native (or otherwise non-Teredo) IPv6 hosts

=== Node types ===
Teredo defines several different kinds of nodes:<ref>{{Cite journal|last1=Sharma|first1=Vishal|last2=Kumar|first2=Rajesh|date=2017|title=Teredo tunneling-based secure transmission between UAVs and ground ad hoc networks|journal=International Journal of Communication Systems|language=en|volume=30|issue=7|article-number=e3144|doi=10.1002/dac.3144|s2cid=5263153 |issn=1099-1131}}</ref>

; Teredo client: A host that has IPv4 connectivity to the Internet from behind a NAT and uses the Teredo tunneling protocol to access the IPv6 Internet. Teredo clients are assigned an IPv6 address that starts with the Teredo prefix (<code>2001::/32</code>).<ref>{{cite web|title=Teredo Addresses (Windows)|url=http://msdn.microsoft.com/en-us/library/windows/desktop/cc136764(v=vs.85).aspx|website=msdn.microsoft.com|language=en|access-date=2014-12-02|archive-date=2016-12-23|archive-url=https://web.archive.org/web/20161223065016/https://msdn.microsoft.com/en-us/library/windows/desktop/cc136764(v=vs.85).aspx|url-status=live}}</ref>

; Teredo server: A well-known host used for initial configuration of a Teredo tunnel. A Teredo server never forwards any traffic for the client (apart from IPv6 pings), and has therefore  modest bandwidth requirements (a few hundred bits per second per client at most),{{Citation needed|date=March 2009}} which means a single server can support many clients. Additionally, a Teredo server can be implemented in a fully [[stateless protocol|stateless]] manner, thus using the same amount of memory regardless of how many clients it supports.

; Teredo relay: The remote end of a Teredo tunnel. A Teredo relay must forward all of the data on behalf of the Teredo clients it serves, with the exception of direct Teredo client to Teredo client exchanges. Therefore, a relay requires a lot of bandwidth and can only support a limited number of simultaneous clients. Each Teredo relay serves a range of IPv6 hosts (e.g. a single campus or company, an [[Internet service provider|ISP]] or a whole operator network, or even the whole [[IPv6 Internet]]); it forwards traffic between any Teredo clients and any host within said range.

; Teredo host-specific relay: A Teredo relay whose range of service is limited to the very host it runs on. As such, it has no particular bandwidth or routing requirements. A computer with a host-specific relay uses Teredo to communicate with Teredo clients, but sticks to its main IPv6 connectivity provider to reach the rest of the IPv6 Internet.

=== IPv6 addressing ===
Each Teredo client is assigned a public [[IPv6 address]], which is constructed as follows (the higher order bit is numbered 0):
* Bits 0 to 31 hold the Teredo prefix (2001::/32).
* Bits 32 to 63 embed the primary IPv4 address of the Teredo server that is used.
* Bits 64 to 79 hold some flags and other bits; the format for these 16 bits, MSB first, is "CRAAAAUG AAAAAAAA".  The "C" bit was set to 1 if the Teredo client is located behind a [[Network address translation#Methods of translation|cone NAT]], 0 otherwise, but RFC 5991 changed it to always be 0 to avoid revealing this fact to strangers. The "R" bit is currently unassigned and should be sent as 0.  The "U" and "G" bits are set to 0 to emulate the "Universal/local" and "Group/individual" bits in [[MAC address]]es.  The 12 "A" bits were 0 in the original RFC 4380 specification, but were changed to random bits chosen by the Teredo client in RFC 5991 to provide the Teredo node with additional protection against IPv6-based scanning attacks.
* Bits 80 to 95 contain the ''obfuscated'' UDP port number. This is the port number that the NAT maps to the Teredo client, with all bits inverted.
* Bits 96 to 127 contain the ''obfuscated'' IPv4 address. This is the public IPv4 address of the NAT with all bits inverted.

{{center|''Teredo IPv6 addressing table''}}
{| class="wikitable" style="margin-right:auto; margin-left:auto;"
|-
! Bits || 0 - 31 || 32 - 63 || 64 - 79 || 80 - 95 || 96 - 127
|-
| Length || 32 bits || 32 bits || 16 bits || 16 bits || 32 bits
|-
| Description || Prefix || Teredo<br />server IPv4 || Flags || Obfuscated<br />UDP port || Obfuscated Client<br />public IPv4
|}

As an example, the IPv6 address 2001:0000:4136:e378:8000:63bf:3fff:fdd2 refers to a Teredo client that:
* Uses Teredo server at address 65.54.227.120 (4136e378 in [[hexadecimal]])
* Is behind a cone NAT and client is not fully compliant with RFC 5991 (bit 64 is set)
* Is probably (99.98%) not compliant with RFC 5991 (the 12 random bits are all 0, which happens less than 0.025% of the time)
* Uses UDP mapped port 40000 on its NAT (in hexadecimal [[Bitwise NOT|not]] 63bf equals 9c40, or decimal number 40000)
* Has a NAT public IPv4 address of 192.0.2.45 (not 3ffffdd2 equals c000022d, which is to say, 192.0.2.45)

{{center|''Teredo IPv6 example table''}}
{| class="wikitable" style="margin-right:auto; margin-left:auto;"
|-
! Bits || 0 - 31 || 32 - 63 || 64 - 79 || 80 - 95 || 96 - 127
|-
| Length || 32 bits || 32 bits || 16 bits || 16 bits || 32 bits
|-
| Description || Prefix || Teredo<br />server IPv4 || Flags || Obfuscated<br />UDP port || Obfuscated Client<br />public IPv4
|-
| Part || 2001:0000 || 4136:e378 || 8000 || 63bf || 3fff:fdd2
|-
| Decoded || || 65.54.227.120 || cone NAT || 40000 || 192.0.2.45
|}

=== Servers ===
Teredo clients use Teredo servers to autodetect the kind of NAT they are behind (if any), through a simplified STUN-like ''qualification procedure''. Teredo clients also maintain a binding on their NAT toward their Teredo server by sending a UDP packet at regular intervals. That ensures that the server can always contact any of its clients—which is required for [[NAT hole punching]] to work properly.

If a Teredo relay (or another Teredo client) must send an IPv6 packet to a Teredo client, it first sends a ''Teredo bubble'' packet to the client's Teredo server, whose IP address it infers 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 do hole punching toward the Teredo relay.

Teredo servers can also transmit ICMPv6 packet from Teredo clients toward the IPv6 Internet. In practice, when a Teredo client wants to contact a native IPv6 node, it must locate the corresponding Teredo relay, ''i.e.'', to which public IPv4 and UDP port number to send encapsulated IPv6 packets. To do that, the client crafts an ICMPv6 Echo Request (''ping'') toward the IPv6 node, and sends it through its configured Teredo server. The Teredo server de-capsulates the ping onto the IPv6 Internet, so that the ping should eventually reach the IPv6 node. The IPv6 node should then reply with an ICMPv6 Echo Reply, as mandated by RFC 2460. This reply packet is routed to the ''closest'' Teredo relay, which&nbsp;— finally&nbsp;— tries to contact the Teredo client.

Maintaining a Teredo server requires little bandwidth, because they are not involved in actual transmission and reception of IPv6 traffic packets. Also, it does not involve any access to the Internet routing protocols. The only requirements for a Teredo server are:
* The ability to emit ICMPv6 packets with a source address belonging to the Teredo prefix
* Two distinct public IPv4 addresses.  Though not written down in the official specification, Microsoft Windows clients expect both addresses to be consecutive&nbsp;— the second IPv4 address is for NAT detection

Public Teredo servers:
* win10.ipv6.microsoft.com
* win1910.ipv6.microsoft.com
* teredo.ginzado.ne.jp

Former public Teredo servers:
* teredo.remlab.net / teredo-debian.remlab.net (Germany), terminated since 2021.<ref>{{cite web | title=Miredo: Teredo for Linux and BSD | url=https://www.remlab.net/miredo/ }}</ref> 
* teredo.trex.fi (Finland), terminated since 2022.<ref>{{cite web | title=Public Service: Teredo Server | url=https://www.trex.fi/service/teredo.html }}</ref>

=== Relays ===
A Teredo relay potentially requires much network bandwidth. Also, it must export (''advertise'') a route toward the Teredo IPv6 prefix (2001::/32) to other IPv6 hosts. That way, the Teredo relay receives traffic from the IPv6 hosts addressed to any Teredo client, and forwards it over UDP/IPv4. Symmetrically, it receives packets from Teredo clients addressed to native IPv6 hosts over UDP/IPv4 and injects those into the native IPv6 network.

In practice, network administrators can set up a private Teredo relay for their company or campus. This provides a short path between their IPv6 network and any Teredo client. However, setting up a Teredo relay on a scale beyond that of a single network requires the ability to export [[BGP]] IPv6 routes to the other [[autonomous system (Internet)|autonomous systems]] (AS's).

Unlike [[6to4]], where the two halves of a connection can use different relays, traffic between a native IPv6 host and a Teredo client uses the same Teredo relay, namely the one closest to the native IPv6 host network-wise. The Teredo client cannot localize a relay by itself (since it cannot send IPv6 packets by itself). If it needs to initiate a connection to a native IPv6 host, it sends the first packet through the Teredo server, which sends a packet to the native IPv6 host using the client's Teredo IPv6 address. The native IPv6 host then responds as usual to the client's Teredo IPv6 address, which eventually causes the packet to find a Teredo relay, which initiates a connection to the client (possibly using the Teredo server for [[NAT traversal|NAT piercing]]). The Teredo Client and native IPv6 host then use the relay for communication as long as they need to. This design means that neither the Teredo server nor client needs to know the IPv4 address of any Teredo relays. They find a suitable one automatically via the global IPv6 [[routing table]], since all Teredo relays advertise the network 2001::/32.

On March 30, 2006, Italian ISP ITGate<ref>{{cite web |url=https://www.itgate.it/index.php/en/ |title=IT.Gate &#124; Technology Services - IT.Gate |website=itgate.it |access-date=September 22, 2019 |archive-date=June 14, 2021 |archive-url=https://web.archive.org/web/20210614043955/https://www.itgate.it/index.php/en/ |url-status=live }}</ref> was the first AS to start advertising a route toward 2001::/32 on the IPv6 Internet, so that RFC 4380-compliant Teredo implementations would be fully usable. As of 16 February 2007, it is no longer functional.

In Q1 2009, IPv6 backbone [[Hurricane Electric]] enabled 14 Teredo relays<ref>{{cite web | url=http://lacnic.net/documentos/lacnicxii/presentaciones/flip6/08_Martin_Levy.pdf | title=Hurricane Electric's experience in deploying Teredo and 6to4 relays | author=Levy, Martin | date=May 28, 2009 | publisher=LACNIC-XII/FLIP6 2009 Conference, Panama City, Panama | access-date=December 29, 2012 | archive-date=April 11, 2015 | archive-url=https://web.archive.org/web/20150411153631/http://lacnic.net/documentos/lacnicxii/presentaciones/flip6/08_Martin_Levy.pdf | url-status=live }}</ref> in an [[anycast]] implementation and advertising 2001::/32 globally. The relays were located in [[Seattle]], [[Fremont, California|Fremont]], [[Los Angeles]], [[Chicago]], [[Dallas]], [[Toronto]], [[New York City|New York]], [[Ashburn, Virginia|Ashburn]], [[Miami]], [[London]], [[Paris]], [[Amsterdam]], [[Frankfurt]], and [[Hong Kong]].

It is expected that large network operators will maintain Teredo relays. As with 6to4, it remains unclear how well the Teredo service will scale up if a large proportion of Internet hosts start using IPv6 through Teredo in addition to IPv4. While Microsoft has operated a set of Teredo servers since they released the first Teredo pseudo-tunnel for Windows XP, they have never provided a Teredo relay service for the IPv6 Internet as a whole.

===Clients===
Officially, this mechanism was created for Microsoft Windows XP and onwards PCs to provide IPv6 connectivity to IPv4 clients by connecting to '''ipv6.microsoft.com''' and works in conjunction with '''IP Helper''' service and '''Teredo Tunneling Adapter Interface''' driver. The service also opens a [[UPNP]] port on the router for relaying.

== Limitations ==

Teredo is not compatible with all NAT devices. Using the terminology of RFC 3489, it supports full cone, restricted, and port-restricted [[network address translation#PORT-TRANSLATION|NAT]] devices, but does not support [[network address translation#Type of NAT and NAT traversal, role of port preservation for TCP|symmetric NATs]]. The Shipworm specification<ref>{{cite IETF |url=https://www.ietf.org/proceedings/51/I-D/draft-huitema-shipworm-00.txt |title=Shipworm: Tunneling IPv6 over UDP through NATs |date=July 12, 2001 |first=Christian |last=Huitema }} {{Webarchive|url=https://web.archive.org/web/20210104150155/https://www.ietf.org/proceedings/51/I-D/draft-huitema-shipworm-00.txt |date=January 4, 2021 }}</ref> original that led to the final Teredo protocol also supported symmetric NATs, but dropped that due to security concerns.

People at the [[National Chiao Tung University]] in Taiwan later proposed SymTeredo,<ref>{{Cite journal |last1=Huang |first1=Shiang-Ming |last2=Wu |first2=Quincy |last3=Lin |first3=Yi-Bing |date=May 2006 |title=Enhancing teredo IPv6 tunneling to traverse the symmetric NAT |journal=IEEE Communications Letters |language=en |volume=10 |issue=5 |pages=408–410 |doi=10.1109/LCOMM.2006.1633339 |bibcode=2006IComL..10..408H |issn=1089-7798 }}</ref> which enhanced the original Teredo protocol to support symmetric NATs, and the Microsoft and Miredo implementations implement certain unspecified non-standard extensions to improve support for symmetric NATs. However, connectivity between a Teredo client behind a symmetric NAT, and a Teredo client behind a port-restricted or symmetric NAT remains seemingly impossible.{{Citation needed|date=April 2009}}

Indeed, Teredo assumes that when two clients exchange encapsulated IPv6 packets, the mapped/external UDP port numbers used will be the same as those that were used to contact the Teredo server (and building the Teredo IPv6 address). Without this assumption, it would not be possible to establish a direct communication between the two clients, and a costly relay would have to be used to perform [[triangle routing]]. A Teredo implementation tries to detect the type of NAT at startup, and will refuse to operate if the NAT appears to be symmetric. (This limitation can sometimes be worked around by manually configuring a [[port forwarding]] rule on the NAT box, which requires administrative access to the device).

Teredo can only provide a single IPv6 address per tunnel endpoint. As such, it is not possible to use a single Teredo tunnel to connect multiple hosts, unlike 6to4 and some point-to-point IPv6 tunnels. The bandwidth available to all Teredo clients toward the IPv6 Internet is limited by the availability of Teredo relays, which are no different than 6to4 relays in that respect.

== Alternatives ==
{{Main|IPv6 transition mechanism}}

[[6to4]] requires a public IPv4 address, but provides a large 48-bit IPv6 prefix for each tunnel endpoint, and has a lower encapsulation [[overhead (computing)|overhead]]. [[Network topology#Point-to-point|Point-to-point]] tunnels can be more reliable and are more accountable than Teredo, and typically provide permanent IPv6 addresses that do not depend on the IPv4 address of the tunnel endpoint. Some point-to-point [[tunnel broker]]s also support UDP encapsulation to traverse NATs (for instance, the [[Anything In Anything|AYIYA]] protocol can do this). On the other hand, point-to-point tunnels normally require registration. Automated tools (for instance [[AICCU]]) make it easy to use Point-to-Point tunnels.

== Security considerations ==

=== Exposure ===
Teredo increases the ''[[attack surface]]'' by assigning globally routable IPv6 addresses to network hosts behind NAT devices, which would otherwise be unreachable from the Internet. By doing so, Teredo potentially exposes any IPv6-enabled application with an open port to the outside. Teredo tunnel encapsulation can also cause the contents of the IPv6 data traffic to become invisible to packet inspection software, facilitating the spread of malware.<ref name="auto">{{cite web |url=https://us-cert.cisa.gov/security-publications/malware-tunneling-ipv6 |title=Malware Tunneling in IPv6 |website=[[US-CERT.gov]] |date=June 22, 2012 |access-date=2016-09-05 |archive-date=2020-08-10 |archive-url=https://web.archive.org/web/20200810024845/https://us-cert.cisa.gov/security-publications/malware-tunneling-ipv6 |url-status=live }}</ref> Finally, Teredo exposes the IPv6 stack and the tunneling software to attacks should they have any remotely exploitable vulnerability.

In order to reduce the attack surface, the Microsoft IPv6 stack has a "protection level" [[Berkeley sockets|socket]] option. This allows applications to specify from which sources they are willing to accept IPv6 traffic: from the Teredo tunnel, from anywhere except Teredo (the default), or only from the local [[intranet]].

The Teredo protocol also encapsulates detailed information about the tunnel's endpoint in its data packets. This information can help potential attackers by increasing the feasibility of an attack, and/or by reducing the effort required.<ref>{{Cite web|url=http://blog.trendmicro.com/trendlabs-security-intelligence/ipv6-tunneling-protocols-good-for-adoption-not-so-hot-for-security/|title=IPv6 Tunneling Protocols: Good for Adoption, Not So Hot for Security - TrendLabs Security Intelligence Blog|date=2009-10-26|language=en-US|access-date=2016-09-05|archive-date=2016-10-08|archive-url=https://web.archive.org/web/20161008142827/http://blog.trendmicro.com/trendlabs-security-intelligence/ipv6-tunneling-protocols-good-for-adoption-not-so-hot-for-security/|url-status=live}}</ref>

=== Firewalling, filtering, and blocking ===

For a Teredo pseudo-tunnel to operate properly, outgoing UDP packets to port 3544 must be unfiltered. Moreover, replies to these packets (i.e., "solicited traffic") must also be unfiltered. This corresponds to the typical setup of a NAT and its [[stateful firewall]] functionality. Teredo tunneling software reports a fatal error and stops if outgoing IPv4 UDP traffic is blocked.

=== DoS via routing loops ===
In 2010, new methods to create denial of service attacks via routing loops that use Teredo tunnels were uncovered. They are relatively easy to prevent.<ref>{{cite news |url=https://datatracker.ietf.org/doc/html/draft-gont-6man-teredo-loops-00#ref-USENIX-WOOT |title=Internet-Draft - Teredo routing loops - Mitigating Teredo Rooting Loop Attacks |date=September 8, 2010 |first=Fernando |last=Gont |newspaper=Ietf Datatracker |publisher=ietf.org |page=2 |access-date=August 9, 2021 |archive-date=December 7, 2021 |archive-url=https://web.archive.org/web/20211207130346/https://datatracker.ietf.org/doc/html/draft-gont-6man-teredo-loops-00#ref-USENIX-WOOT |url-status=live }}</ref>

=== Default use in MS-Windows ===

[[Microsoft Windows]] as of Windows 10, version 1803 and later disable Teredo by default. If needed, this transitional technology can be enabled via a [[command-line interface|CLI]] command or [[Group Policy]].<ref name=":0">{{cite web |date=2020-12-07 |title=DirectAccess clients that use Teredo tunneling cannot connect after upgrade to Windows 10 |url=https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/directaccess-clients-teredo-tunneling-not-connect-after-upgrade |website=[[Microsoft Docs]] |access-date=2021-01-12 |url-status=live |archive-date=2021-01-14 |archive-url=https://web.archive.org/web/20210114083743/https://docs.microsoft.com/en-us/troubleshoot/windows-client/networking/directaccess-clients-teredo-tunneling-not-connect-after-upgrade }}</ref>

== Implementations ==
Several implementations of Teredo are currently available:

* [[Windows XP#Service Pack 2|Windows XP SP2]] includes a client and ''host-specific'' relay (also in the Advanced Networking Pack for Service Pack 1).
* [[Windows Server 2003]] has a relay and server provided under the [[Microsoft]] Beta program.
* [[Windows Vista]] and [[Windows 7]] have built-in support for Teredo with an unspecified extension for symmetric NAT traversal. However, if only a link-local and Teredo address are present, these operating systems don't try to resolve IPv6 DNS AAAA records if a DNS A record is present, in which case they use IPv4. Therefore, only literal IPv6 URLs typically use Teredo.<ref>{{cite web |url=https://www.potaroo.net/ispcol/2011-04/teredo.html |title=ISP Column - May 2011 |website=potaroo.net |access-date=September 22, 2019 |archive-date=November 1, 2019 |archive-url=https://web.archive.org/web/20191101153121/http://www.potaroo.net/ispcol/2011-04/teredo.html |url-status=live }}</ref> This behavior can be modified in the [[Windows Registry|registry]].
* [[Windows 10]] version 1803 and later disable Teredo by default. If needed, this transitional technology can be enabled via a [[command-line interface|CLI]] command or [[Group Policy]].<ref name=":0" />
* [[Miredo]] is a client, relay, and server for [[Linux]], [[*BSD]], and [[Mac OS X]],
* ng_teredo is a relay and server based on [[netgraph]] for [[FreeBSD]] from the [[Laboratoire d'Informatique de Paris 6|LIP6]] University and 6WIND.<ref>Kabassanov, Konstantin; Jardin, Vincent. (October 22, 2003). [http://www-rp.lip6.fr/teredo/ Teredo for FreeBSD] {{Webarchive|url=https://web.archive.org/web/20050306022628/http://www-rp.lip6.fr/teredo/ |date=2005-03-06 }} www-rp.lip6.fr.</ref>{{citation needed|date=February 2011}}<!-- also needs 3rd party citation -->
* NICI-Teredo is a relay for the [[Linux kernel]] and a userland Teredo server, developed at the National Chiao Tung University.<ref>"Solomon, Aaron". (November 29, 2004). [https://sourceforge.net/projects/nici-teredo/ NICI-Teredo] {{Webarchive|url=https://web.archive.org/web/20210829175338/https://sourceforge.net/projects/nici-teredo/ |date=2021-08-29 }}. Sourceforge.</ref>{{citation needed|date=February 2011}}<!-- also needs 3rd party citation -->

== Choice of the name ==

The initial nickname of the Teredo tunneling protocol was ''Shipworm''. The idea was that the protocol would pierce through NAT devices, much as the [[shipworm]] (a kind of marine wood-boring clam) bores tunnels through wood. Shipworms have been responsible for the loss of many wooden hulls. Christian Huitema, in the original draft, noted that the shipworm "only survives in relatively clean and unpolluted water; its recent comeback in several Northern American harbors is a testimony to their newly retrieved cleanliness. The Shipworm service should, in turn, contributes {{sic}} to a newly retrieved transparency of the Internet."<ref>{{cite news |author=Huitema |first=Christian |date=2001-08-25 |title=Shipworm: Tunneling IPv6 over UDP through NATs (draft 00 of 08) |newspaper=Ietf Datatracker |url=https://datatracker.ietf.org/doc/html/draft-ietf-ngtrans-shipworm-00 |publisher=[[Internet Engineering Task Force]] (IETF) |access-date=2021-08-09 |archive-date=2021-08-29 |archive-url=https://web.archive.org/web/20210829030554/https://datatracker.ietf.org/doc/html/draft-ietf-ngtrans-shipworm-00 |url-status=live }}</ref>

To avoid confusion with [[computer worm]]s,<ref name="mail">{{cite web |author=Huitema |first=Christian |date=2001-12-19 |title=Renaming Shipworm as Teredo? |url=ftp://ftp.ietf.org/ietf-mail-archive/ngtrans/2001-12.mail |website=IETF NGTrans mailing list |archive-url=https://web.archive.org/web/20180108111233/ftp://ftp.ietf.org/ietf-mail-archive/ngtrans/2001-12.mail |archive-date=2018-01-08 |publisher=[[Internet Engineering Task Force]] (IETF)}}</ref> Huitema later changed the protocol's name from ''Shipworm'' to ''[[Teredo (bivalve)|Teredo]]'', after the [[genus]] name of the shipworm ''[[Teredo navalis]]''.<ref name="mail"/>

== References ==
{{Reflist}}
{{Refbegin}}
{{Refend}}

== External links ==
* [https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-xp/bb457011(v=technet.10) Teredo Overview] on Microsoft TechNet
* [https://stat.ripe.net/widget/prefix-routing-consistency#w.resource=2001%3A%3A%2F32 Current anycast Teredo BGP routes]
* ''Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)''. RFC 4380, C. Huitema. February 2006.<!-- was a non-specific reference - move back when cited. -->
* [https://www.wyae.de/docs/ipv6calc/ JavaScript Teredo-IP address calculator]

[[Category:Internet architecture]]
[[Category:IPv6 transition technologies]]
[[Category:Tunneling protocols]]