Teredo トンネリング
目的
最も一般的な IPv6 over IPv4 トンネリングプロトコルである6to4では、トンネルのエンドポイントがパブリックIPv4アドレスを持っている必要がある。 しかし現在、IPv4アドレス枯渇問題などのために、多くのホストが一つ以上のNAT機器越しにIPv4インターネットに接続しており、パブリックIPv4アドレスはNAT機器には付与されても個々のホストには付与されない。したがって、この環境で6to4プロトコルを使用するためにはNAT機器自体が6to4トンネルエンドポイントとなるよう実装する必要がある。しかし、現在稼働中のNAT機器に6to4を実装するアップグレードを提供することは、多くの場合で技術的もしくは経済的問題により困難である。
Teredo では、IPv6 データグラムをほとんどのNATで適切に処理される UDP/IPv4 データグラム内にカプセル化することによりこの問題を軽減する。したがって、NAT越しにインターネットに接続しておりパブリックIPv4アドレスを付与されていないとしても、内部的にはIPv6を利用できるホストであれば、Teredo トンネルのエンドポイントとして動作可能である。事実上、Teredo を実装されたホストはローカルネットワークに手を加えることなくIPv6接続が可能になる。
長期的には、全てのIPv6ホストがネイティブIPv6接続を使用すべきである。Teredo プロトコルは一時的な手段であり、将来的には sunset procedure, すなわちIPv6が成熟し接続可能になった暁には Teredo による接続をやめ、より安定したメカニズムで接続することが予定されている。IETF89開催時現在、マイクロソフトは自社の Windows クライアント向け Teredo サーバーを2014年前半までで停止し、かつ公開運用されている Teredo リレーに対し停止を促す計画である。
リレー
Teredo リレーは多大なネットワーク帯域を消費する可能性がある。また、他のIPv6ホストに対して Teredo IPv6プレフィクス (2001::/32) 向けのルートをエクスポート（アドバタイズ）する必要がある。これにより、Teredo リレーは他のIPv6ホストから Teredo クライアント宛のトラフィックを受けとることになり、UDP/IPv4越しに転送を行う。それとは逆に、Teredo クライアントからネイティブ IPv6 ホスト宛のデータグラムを UDP/IPv4 越しに受けとった場合は、IPv6 ネットワーク越しに転送を行う。
運用上、ネットワーク管理者は自社もしくはキャンパス内限定のプライベート Teredo リレーを設置することができる。この場合は、Teredo クライアントとIPv6ネットワークをそのまま結ぶことができる。対して、単一ネットワークを越えるスケールの Teredo リレーを設置するためには別の自律システム (AS) 向けにIPv6ルートをBGPによりエクスポートする能力が求められる。
接続の行きと帰りで違うリレーを使うことのできる6to4とは違い、ネイティブIPv6ホストと Teredo クライアントの通信は同じ Teredo リレー、実際上はネイティブIPv6ホストにネットワーク的に最も近いリレーが使われる。Teredo クライアントは自ら IPv6 データグラムを送信できないため、自分でリレーを指定することはできない。したがって、クライアントからネイティブIPv6ホスト宛の通信を開始したい場合は、Teredo サーバーにデータグラムを送信し、ネイティブIPv6ホスト宛にクライアントの Teredo IPv6 アドレスのついたデータグラムを送信してもらう必要がある。これを受けてネイティブIPv6ホストは通常通り Teredo IPv6アドレス宛に返信し、このデータグラムにより最終的には Teredo リレーへのルートが発見され、クライアントとの通信が開始される（NAT突破のために Teredo サーバーを使う場合もある）。こうして、Teredo クライアントとネイティブIPv6ホストは必要な期間だけリレーを使用して通信を行うことができる。この設計により、Teredo サーバーもクライアントも Teredo リレーのIPv4アドレスを知る必要がない。Teredo リレーはネットワーク 2001::/32 をアドバタイズしているため、グローバルIPv6ルーティングテーブル経由で自動的に適切なリレーが選ばれる。
2006年3月30日、イタリアのISP、ITGate はIPv6インターネットに向けて 2001::/32 宛のルートをアドバタイズした初の AS となり、RFC 4380準拠の Teredo 実装が完全に利用可能となった。2007年2月16日現在、これは既に機能していない。
2009年第1四半期、IPv6バックボーンの Hurricane Electric は14のエニーキャスト実装 Teredo リレーを稼動させ、2001::/32 をグローバルにアドバタイズした。リレーはシアトル、フレモント、ロサンゼルス、シカゴ、ダラス、トロント、ニューヨーク、アッシュバーン、マイアミ、ロンドン、パリ、フランクフルト、香港に設置された。
大規模ネットワーク管理者は Teredo リレーを維持することが期待されている。6to4と同様、インターネット上のホストの大部分がIPv4に加えて Teredo 経由でIPv6を使い始めたとき、Teredo サービスがスケールするかは不明瞭のままである。マイクロソフトは Windows XP で初めて Teredo 擬似トンネルをリリースして以来一群の Teredo サーバーを運用してきたが、IPv6インターネット全体向けの Teredo リレーを提供したことはない。
限界
Teredo は全てのNAT機器と互換性を持つわけではない。RFC 3489の用語を使うと、完全コーンNAT機器、制限NAT機器、ポート制限NAT機器をサポートするが、対称NATはサポートしない。Shipworm 仕様の初期ドラフト段階では最終的に対称NATもサポートされる予定だったが、セキュリティ上の懸念からキャンセルされた。
台湾の国立交通大学の研究者は後にオリジナルの Teredo プロトコルを拡張し対称NATをサポートした SymTeredo を提案し、マイクロソフトと Miredo の実装は標準に準拠しない拡張により対称NATサポートを向上させた。しかし、対称NAT越しのTeredo クライアントと、対称NATおよびポート制限NATとの間の接続は依然不可能なようである。
Teredo は二つのクライアントがカプセル化された IPv6 データグラムを交換する際は、Teredo サーバーとの通信に用いるものと同じマップされた外部UDPポート番号を用いることを想定している。この想定が成り立たないと、二つのクライアント間の直接通信を確立することができず、より通信コストのかかるリレーを挟んだ三角ルーティングを行う必要が出てくる。Teredo 実装はNATの種別を起動時に検知することを試み、NATが対称NATであれば動作を拒否する（この限界はNAT機器のポートフォワードルールを手動で設定することにより乗り越えることができる場合もあるが、機器への管理者アクセスが必要となる）。
Teredo はトンネルエンドポイントごとに単一のIPv6アドレスしか提供できない。したがって、6to4やいくつかのポイント・ツー・ポイントIPv6トンネルとは異なり、一つの Teredo トンネルを用いて複数ホストと接続することはできない。全ての Teredo クライアントが利用可能なIPv6インターネット向けの帯域幅は Teredo リレーの利用可能性により制限される。この点は6to4と変わらない。
代替手段
6to4はパブリックIPv4アドレスを必要とするが、各トンエルエンドポイント毎に大きな48ビットIPv6プレフィックスが提供され、カプセル化オーバーヘッドが比較的低い。ポイント・ツー・ポイント・トンネルは Teredo より信頼性も追跡性も高く、典型的にはトンネルエンドポイントのIPv4に依存しない永続的IPv6アドレスが提供される。いくつかのポイント・ツー・ポイント・トンネル事業者はNATトラバースのためのUDPカプセル化をサポートする（たとえばAYIYAプロトコルではこれが可能である）。一方で、ポイント・ツー・ポイント・トンネルの利用には通常、登録が必要である。ポイント・ツー・ポイント・トンネルの利用を簡便化するための自動化ツール（AICCUなど）もある。
露出
Teredo はインターネットから通常は到達できないNATの背後のネットワークホストに、ルーティング可能なIPv6アドレスを付与するので、IPv6を利用可能で外部にポートを開いているアプリケーションを露出させる可能性があり、攻撃対象領域を増加させる。Teredo トンネルのカプセル化によりパケット検査に対してIPv6データトラフィックがマスクされてしまい、IPv6 マルウェアや場合によっては IPv4 マルウェアの拡散の可能性が発生する。US CERT はIPv6トンネリングを利用するマルウェアのリスクについてのレポートを公開している。また、Teredo に不正に遠隔利用可能な脆弱性があると、IPv6スタックとトンネリングソフトウェアが攻撃者に対して露出してしまう。
マイクロソフトのIPv6スタックには「プロテクションレベル」ソケットオプションがある。これにより、アプリケーションが Teredo トンネル、Teredo トンネル以外の場所（デフォルト）、もしくはローカルイントラネットのみ、のいずれかからのトラフィックのみを許可することができる。
Teredo プロトコルはまた、トンネルのエンドポイントに関する詳細な情報をデータパケットにカプセル化している。
ファイアーウォール、フィルタリング、ブロック
Teredo 擬似トンネルを適切に運用するには、外向き UDP データグラムに加えて、それに対する返信データグラム（応答トラフィック）に対するフィルタリングも切る必要がある。これは、典型的なNATの設定とステートフルなファイヤーウォール機能に適合する。Teredo トンネリングソフトウェアは致命的エラーを検知すると外向き IPv4 UDP トラフィックをブロックする。また、UDP ポート 3544 への外向きトラフィックのブロックは Teredo の動作と干渉する。
ルーティングループ経由のDoS
近年、Teredo トンネルを用いたルーティングループ経由のDoS攻撃を行う方法が発見された。これを防ぐのは比較的容易である。
デフォルトで有効
マイクロソフト製OSの現行バージョンでは、Teredo を含むIPv6移行技術がデフォルトで有効になっている。これを無効化することはコマンドプロンプトおよびレジストリ編集により行うことができ、IPv6が実装されていなければ組織内ネットワークのグループポリシーで無効化することもできる。マイクロソフトによりデフォルトで有効化されているため、クリーンインストール直後のWindows OS においてIPv6を利用するマルウェアの脅威を増やさないためには、IPv6および関連する移行技術に関してはわかりづらい設定を行う必要が発生している。
名前の由来
Teredo トンネリングプロトコルの最初のニックネームは shipworm（フナクイムシ）だった。 プロトコルがNATに穴を空けるということから、フナクイムシが木にトンネルを穿つ様子を連想したものである。フナクイムシは非常に多くの木製船殻をダメにした元凶であるが、クリスチャン・ウイテマはオリジナルのドラフトに次のように書いている。「この動物は比較的清浄で汚染のない水にしか棲めない。彼らが北アメリカの港に近年戻ってきていることは、水が綺麗になっている証拠である。そのように、NATに穴を空けることによってこのサービスは新たなインターネットの透明性に寄与するだろう。」
クリスチャン・ウイテマは、コンピューターワームとの混同を避けるために名前を Teredo に変更した。もっとも一般的なフナクイムシ種の学名は Teredo navalis である。