Teredo tunneling

Last updated

In computer networking, Teredo is a Microsoft 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.

Contents

Teredo operates using a platform independent tunneling protocol that provides IPv6 (Internet Protocol version 6) connectivity by 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 UDP port 3544.

Purpose

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 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[ clarification needed ], Microsoft plans to deactivate their Teredo servers for Windows clients in the first half of 2014[ needs update ] (exact date TBD), and encourage the deactivation of publicly operated Teredo relays.

Overview

The Teredo protocol performs several functions:

  1. Diagnoses UDP over IPv4 (UDPv4) connectivity and discovers the kind of NAT present (using a simplified replacement to the STUN protocol)
  2. Assigns a globally routable unique IPv6 address to each host using it
  3. Encapsulates IPv6 packets inside UDPv4 datagrams for transmission over an IPv4 network (this includes NAT traversal)
  4. Routes traffic between Teredo hosts and native (or otherwise non-Teredo) IPv6 hosts

Node types

Teredo defines several different kinds of nodes: [1]

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 (2001::/32). [2]
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 ] which means a single server can support many clients. Additionally, a Teredo server can be implemented in a fully 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 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):

Teredo IPv6 addressing table
Bits0 - 3132 - 6364 - 7980 - 9596 - 127
Length32 bits32 bits16 bits16 bits32 bits
DescriptionPrefixTeredo
server IPv4		FlagsObfuscated
UDP port		Obfuscated Client
public IPv4

As an example, the IPv6 address 2001:0000:4136:e378:8000:63bf:3fff:fdd2 refers to a Teredo client that:

Teredo IPv6 example table
Bits0 - 3132 - 6364 - 7980 - 9596 - 127
Length32 bits32 bits16 bits16 bits32 bits
DescriptionPrefixTeredo
server IPv4		FlagsObfuscated
UDP port		Obfuscated Client
public IPv4
Part2001:00004136:e378800063bf3fff:fdd2
Decoded65.54.227.120cone NAT40000192.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 — finally — 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:

Public Teredo servers:

Former public Teredo servers:

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 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 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 [4] 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 [5] in an anycast implementation and advertising 2001::/32 globally. The relays were located in Seattle, Fremont, Los Angeles, Chicago, Dallas, Toronto, New York, 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 NAT devices, but does not support symmetric NATs. The Shipworm specification [6] 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, [7] 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 ]

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

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 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 brokers also support UDP encapsulation to traverse NATs (for instance, the 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. [8] 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" 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. [9]

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. [10]

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 CLI command or Group Policy. [11]

Implementations

Several implementations of Teredo are currently available:

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." [15]

To avoid confusion with computer worms, [16] Huitema later changed the protocol's name from Shipworm to Teredo , after the genus name of the shipworm Teredo navalis . [16]

Related Research Articles

An Internet Protocol address is a numerical label such as 192.0.2.1 that is assigned to a device connected to a computer network that uses the Internet Protocol for communication. IP addresses serve two main functions: network interface identification, and location addressing.

<span class="mw-page-title-main">IPv4</span> Fourth version of the Internet Protocol

Internet Protocol version 4 (IPv4) is the first version of the Internet Protocol (IP) as a standalone specification. It is one of the core protocols of standards-based internetworking methods in the Internet and other packet-switched networks. IPv4 was the first version deployed for production on SATNET in 1982 and on the ARPANET in January 1983. It is still used to route most Internet traffic today, even with the ongoing deployment of Internet Protocol version 6 (IPv6), its successor.

<span class="mw-page-title-main">IPv6</span> Version 6 of the Internet Protocol

Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion, and was intended to replace IPv4. In December 1998, IPv6 became a Draft Standard for the IETF, which subsequently ratified it as an Internet Standard on 14 July 2017.

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

<span class="mw-page-title-main">Network address translation</span> Technique for making connections between IP address spaces

Network address translation (NAT) is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. The technique was originally used to bypass the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced, but could not route the network's address space. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.

SOCKS is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 optionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded. A SOCKS server accepts incoming client connection on TCP port 1080, as defined in RFC 1928.

In computer networking, Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs) or as part of the delivery of services by ISPs. It uses encryption ('hiding') only for its own control messages, and does not provide any encryption or confidentiality of content by itself. Rather, it provides a tunnel for Layer 2, and the tunnel itself may be passed over a Layer 3 encryption protocol such as IPsec.

A Martian packet is an IP packet seen on the public Internet that contains a source or destination address that is reserved for special use by the Internet Assigned Numbers Authority (IANA) as defined in RFC 1812, Appendix B Glossary. On the public Internet, such a packet either has a spoofed source address, and it cannot actually originate as claimed, or the packet cannot be delivered. The requirement to filter these packets is found in RFC 1812, Section 5.3.7.

6to4 is an Internet transition mechanism for migrating from Internet Protocol version 4 (IPv4) to version 6 (IPv6) and a system that allows IPv6 packets to be transmitted over an IPv4 network without the need to configure explicit tunnels. Special relay servers are also in place that allow 6to4 networks to communicate with native IPv6 networks.

UDP hole punching is a commonly used technique employed in network address translation (NAT) applications for maintaining User Datagram Protocol (UDP) packet streams that traverse the NAT. NAT traversal techniques are typically required for client-to-client networking applications on the Internet involving hosts connected in private networks, especially in peer-to-peer, Direct Client-to-Client (DCC) and Voice over Internet Protocol (VoIP) deployments.

Network address translation traversal is a computer networking technique of establishing and maintaining Internet Protocol connections across gateways that implement network address translation (NAT).

In the context of computer networking, a tunnel broker is a service which provides a network tunnel. These tunnels can provide encapsulated connectivity over existing infrastructure to another infrastructure.

Anything In Anything (AYIYA) is a computer networking protocol for managing IP tunneling protocols in use between separated Internet Protocol networks. It is most often used to provide IPv6 transit over an IPv4 network link when network address translation masquerades a private network with a single IP address that may change frequently because of DHCP provisioning by Internet service providers.

Traversal Using Relays around NAT (TURN) is a protocol that assists in traversal of network address translators (NAT) or firewalls for multimedia applications. It may be used with the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It is most useful for clients on networks masqueraded by symmetric NAT devices. TURN does not aid in running servers on well known ports in the private network through a NAT; it supports the connection of a user behind a NAT to only a single peer, as in telephony, for example.

In computer networking, the Tunnel Setup Protocol (TSP) is an experimental networking control protocol used to negotiate IP tunnel setup parameters between a tunnel client host and a tunnel broker server, the tunnel end-points. A major use of TSP is in IPv6 transition mechanisms.

An IPv6 transition mechanism is a technology that facilitates the transitioning of the Internet from the Internet Protocol version 4 (IPv4) infrastructure in use since 1983 to the successor addressing and routing system of Internet Protocol Version 6 (IPv6). As IPv4 and IPv6 networks are not directly interoperable, transition technologies are designed to permit hosts on either network type to communicate with any other host.

DirectAccess, also known as Unified Remote Access, is a VPN technology that provides intranet connectivity to client computers when they are connected to the Internet. Unlike many traditional VPN connections, which must be initiated and terminated by explicit user action, DirectAccess connections are designed to connect automatically as soon as the computer connects to the Internet. DirectAccess was introduced in Windows Server 2008 R2, providing this service to Windows 7 and Windows 8 "Enterprise" edition clients. In 2010, Microsoft Forefront Unified Access Gateway (UAG) was released, which simplifies the deployment of DirectAccess for Windows 2008 R2, and includes additional components that make it easier to integrate without the need to deploy IPv6 on the network, and with a dedicated user interface for the configuration and monitoring. Some requirements and limitations that were part of the design of DirectAccess with Windows Server 2008 R2 and UAG have been changed. While DirectAccess is based on Microsoft technology, third-party solutions exist for accessing internal UNIX and Linux servers through DirectAccess. With Windows Server 2012, DirectAccess is fully integrated into the operating system, providing a user interface to configure and native IPv6 and IPv4 support.

<span class="mw-page-title-main">IPv6 address</span> Label to identify a network interface of a computer or other network node

An Internet Protocol version 6 address is a numeric label that is used to identify and locate a network interface of a computer or a network node participating in a computer network using IPv6. IP addresses are included in the packet header to indicate the source and the destination of each packet. The IP address of the destination is used to make decisions about routing IP packets to other networks.

NAT64 is an IPv6 transition mechanism that facilitates communication between IPv6 and IPv4 hosts by using a form of network address translation (NAT). The NAT64 gateway is a translator between IPv4 and IPv6 protocols, for which function it needs at least one IPv4 address and an IPv6 network segment comprising a 32-bit address space. The "well-known prefix" reserved for this service is 64:ff9b::/96.

Port Control Protocol (PCP) is a computer networking protocol that allows hosts on IPv4 or IPv6 networks to control how the incoming IPv4 or IPv6 packets are translated and forwarded by an upstream router that performs network address translation (NAT) or packet filtering. By allowing hosts to create explicit port forwarding rules, handling of the network traffic can be easily configured to make hosts placed behind NATs or firewalls reachable from the rest of the Internet, which is a requirement for many applications.

References

  1. ↑ Sharma, Vishal; Kumar, Rajesh (2017). "Teredo tunneling-based secure transmission between UAVs and ground ad hoc networks". International Journal of Communication Systems. 30 (7): e3144. doi:10.1002/dac.3144. ISSN   1099-1131. S2CID   5263153.
  2. ↑ "Teredo Addresses (Windows)". msdn.microsoft.com. Archived from the original on 2016-12-23. Retrieved 2014-12-02.
  3. ↑ Rémi Denis-Courmont (5 June 2021). "Miredo : News". Archived from the original on 2022-07-17. Retrieved 2022-07-17. For the time being, teredo.remlab.net will alias the public Teredo server provided by the TREX regional exchange in the Finnish city of Tampere.
  4. ↑ "IT.Gate | Technology Services - IT.Gate". itgate.it. Archived from the original on June 14, 2021. Retrieved September 22, 2019.
  5. ↑ Levy, Martin (May 28, 2009). "Hurricane Electric's experience in deploying Teredo and 6to4 relays" (PDF). LACNIC-XII/FLIP6 2009 Conference, Panama City, Panama. Archived (PDF) from the original on April 11, 2015. Retrieved December 29, 2012.
  6. ↑ Huitema, Christian (July 12, 2001). Shipworm: Tunneling IPv6 over UDP through NATs. Archived January 4, 2021, at the Wayback Machine
  7. ↑ Huang, Shiang-Ming; Wu, Quincy; Lin, Yi-Bing (May 2006). "Enhancing teredo IPv6 tunneling to traverse the symmetric NAT". IEEE Communications Letters. 10 (5): 408–410. doi:10.1109/LCOMM.2006.1633339. ISSN   1089-7798. Archived from the original on 2022-05-01. Retrieved 2022-05-01.
  8. ↑ "Malware Tunneling in IPv6". US-CERT.gov . June 22, 2012. Archived from the original on 2020-08-10. Retrieved 2016-09-05.
  9. ↑ "IPv6 Tunneling Protocols: Good for Adoption, Not So Hot for Security - TrendLabs Security Intelligence Blog". 2009-10-26. Archived from the original on 2016-10-08. Retrieved 2016-09-05.
  10. ↑ Gont, Fernando (September 8, 2010). "Internet-Draft - Teredo routing loops - Mitigating Teredo Rooting Loop Attacks". Ietf Datatracker. ietf.org. p. 2. Archived from the original on December 7, 2021. Retrieved August 9, 2021.
  11. 1 2 "DirectAccess clients that use Teredo tunneling cannot connect after upgrade to Windows 10". Microsoft Docs . 2020-12-07. Archived from the original on 2021-01-14. Retrieved 2021-01-12.
  12. ↑ "ISP Column - May 2011". potaroo.net. Archived from the original on November 1, 2019. Retrieved September 22, 2019.
  13. ↑ Kabassanov, Konstantin; Jardin, Vincent. (October 22, 2003). Teredo for FreeBSD Archived 2005-03-06 at the Wayback Machine www-rp.lip6.fr.
  14. ↑ "Solomon, Aaron". (November 29, 2004). NICI-Teredo Archived 2021-08-29 at the Wayback Machine . Sourceforge.
  15. ↑ Huitema, Christian (2001-08-25). "Shipworm: Tunneling IPv6 over UDP through NATs (draft 00 of 08)". Ietf Datatracker. Internet Engineering Task Force (IETF). Archived from the original on 2021-08-29. Retrieved 2021-08-09.
  16. 1 2 Huitema, Christian (2001-12-19). "Renaming Shipworm as Teredo?". IETF NGTrans mailing list. Internet Engineering Task Force (IETF). Archived from the original on January 8, 2018.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.