PROFILPELAJAR.COM

コンピュータネットワークにおいて、Teredo とはIPv6移行技術の一つである。IPv4を用いてインターネットに接続可能であるが、通信経路のどこかに IPv6 を理解しない通信機器が存在するために IPv6 ネットワークと直接接続ができないホストに対し、完全な IPv6 接続を提供する。他の類似プロトコルとは異なり、家庭用ルーターなどのネットワークアドレス変換 (NAT) 機器を経由している環境でも機能する。

Teredo は IPv6 データグラムをIPv4 User Datagram Protocol (UDP) データグラム内にカプセル化することによりIPv6接続を提供するクロスプラットフォームトンネリングプロトコルである。Teredo はこれらのデータグラムをIPv4インターネット上で、NAT越しであろうとルーティングを行う。どこか別の、IPv6ネットワークに繋がっている Teredo ノード（Teredo リレーと呼ばれる）がデータグラムを受けとり、非カプセル化して渡す。

Teredo はマイクロソフトのクリスチャン・ウイテマ（英語版）により開発され、IETFによりRFC 4380として標準化された。Teredo サーバーは UDP ポート 3544 番への接続を待ち受ける。

目的

最も一般的な 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 リレーに対し停止を促す計画である^[1]。

概要

Teredo プロトコルはいくつかの機能を実行する。

UDP over IPv4 (UDPv4) 接続が利用可能であるか診断し、（簡略化されたSTUNプロトコルの代替を用いて）NAT機器の存在を検知する。
グローバルにルーティング可能なユニークIPv6アドレスを各ホストに割り当てる
IPv6データグラムをUDPv4データグラム内にカプセル化し、IPv4ネットワーク越しに送信する（NAT traversal も行う）。
Teredo ホスト同士およびネイティブ（もしくは Teredo 以外のトンネリングプロトコルを利用している）IPv6ホストとのルーティングを行う。

ノード種別

Teredo では、いくつかのノード種別が定義されている。

Teredo クライアント: NAT越しにIPv4インターネットに接続しており、Teredo トンネリングプロトコルを用いてIPv6インターネットに接続するホスト。Teredo クライアントには Teredo プレフィクス (2001::/32) から始まるIPv6アドレスが付与される^[2]。

Teredo サーバー: Teredo トンネルの初期設定に用いられる公知のホスト。Teredo サーバーはクライアントに対するトラフィックの転送を（IPv6 ping を除いて）一切行わない。そのため、多大な帯域幅を求められることはなく（最大で1クライアントあたり数百bps程度）^[要出典] 一つのサーバーにより多数のクライアントを処理できる。加えて、Teredo サーバーは完全にステートレスに実装することができ、したがってどんなに多くのクライアントをサポートする場合にもメモリー消費量は変わらない。

Teredo リレー: Teredo トンネルのリモートエンドポイントである。Teredo リレーは、Teredo クライアントのために全てのデータを転送する。ただし、Teredo クライアント同士の直接データ交換は除く。したがって、リレーは多大な帯域幅を要求され、同時には限られた数のクライアントしか処理することができない。各 Teredo リレーは一定の範囲のIPv6ホスト（例えば単一のキャンパスまたは会社、ISP、事業者ネットワーク全体またはIPv6インターネット全体の場合もある）を処理し、全ての Teredo クライアントとこの範囲のホストとのトラフィックを全て転送する。

Teredo ホスト限定リレー: それ自身への転送のみを担う Teredo リレーである。したがって、特に帯域幅やルーティングの必要はない。ホスト限定リレーは Teredo クライアントとの通信には Teredo を使用するが、他のIPv6インターネットとの通信にはメインのIPv6接続プロバイダを用いる。

IPv6アドレス付与

各 Teredo クライアントには、下記のルールに従って構築されるパブリックIPv6アドレスが付与される。

ビット 0〜31: Teredo プレフィクス (2001::/32)。
ビット 32〜63: 使用する Teredo サーバーの主IPv4アドレスが埋め込まれる。
ビット 64〜79: フラグその他のビットを保持する。これらの16ビットのフォーマットはMSBを先頭として "CRAAAAUG AAAAAAAA" の通りである。"C" ビットは Teredo クライアントが cone NAT 越しであれば1、そうでなければ0となる。しかし、RFC 5991 では他人にその情報を知られることを防ぐために常に0と変更された。"R" ビットは、現在は不使用で常に0が送られる。"U" および "G" ビットは、MACアドレスの "Universal/local" ビットと "Group/individual" ビットをエミュレートするために0とされる。12個の "A" ビットは元々の RFC 4380 仕様では0だったが、RFC 5991 ではTeredo クライアントが生成する乱数に変更された。これは、IPv6ベースのスキャニング攻撃を避けるためである。
ビット 80〜95: 「難読化」されたUDP ポート番号。これはNATが Teredo クライアント向けにマッピングしているポート番号の全てのビットを反転させたものである。
ビット 96〜127: 「難読化」されたIPv4アドレス。これはNATのパブリックIPv4アドレスの全ビットを反転させたものである。

*Teredo IPv6 アドレス構築テーブル*
ビット	0 - 31	32 - 63	64 - 79	80 - 95	96 - 127
長さ	32ビット	32ビット	16ビット	16ビット	32ビット
説明	プレフィクス	Teredo サーバーIPv4アドレス	フラグ	難読化UDPポート	難読化クライアントIPv4パブリックアドレス

例えば、IPv6 アドレス 2001:0000:4136:e378:8000:63bf:3fff:fdd2 は、次のような Teredo クライアントを指す。

アドレス 65.54.227.120 (16進表現で 4136e378) の Teredo サーバーを使用している
RFC 5991 に完全には準拠しておらず、 cone NAT 越しであることを示している（ビット64が1である）
おそらく (99.98%の確率で) RFC 5991 に準拠していない（12個のランダムビットが全て0となる確率は 0.025% である）
NAT上のUDPポート40000をマッピングして用いる（16進表現 63bf のNOTは 9c40、すなわち10進表現で40000である）
NATのパブリックIPv4アドレスは192.0.2.45である（3ffffdd2 のNOTは c000022d、すなわち 192.0.2.45 である）

*Teredo IPv6 アドレス例*
ビット	0 - 31	32 - 63	64 - 79	80 - 95	96 - 127
長さ	32ビット	32ビット	16ビット	16ビット	32ビット
説明	プレフィクス	Teredo サーバーのIPvアドレス	フラグ	難読化UDPポート	難読化クライアントのパブリックIPv4アドレス
例	2001:0000	4136:e378	8000	63bf	3fff:fdd2
意味		65.54.227.120	cone NAT	40000	192.0.2.45

サーバー

Teredo クライアントは Teredo サーバーを用いてNATが（あれば）どの種類であるかをSTUN類似の「認定手続」により自動検知する。また、Teredo クライアントはサーバー宛の UDP データグラムをNATに向けて一定間隔で送信することによりサーバーとの接続を維持する。これによりサーバーが各クライアントにいつでもコンタクトできる状態が維持され、UDPホールパンチングが適切に利用できる状態が保たれる。

Teredo リレー（もしくは別の Teredo クライアント）が Teredo クライアント宛の IPv6 データグラムを送信する際、まず Teredo bubble を、そのクライアントが利用している Teredo サーバーに送信する。サーバーのアドレスは宛先クライアントの Teredo IPv6アドレスに埋め込まれているので取得できる。サーバーは bubble をクライアントに転送し、これによりクライアントはリレーに向けてホールパンチングを行うことができる。

Teredo サーバーは Teredo クライアントからの ICMPv6 データグラムをIPv6インターネットに向けて転送することもできる。実運用上、Teredo クライアントがネイティブIPv6ノードとコンタクトしたい場合、対応する Teredo リレー、すなわちクライアントの使用するパブリックIPv4アドレスおよびUDPポート番号に対して IPv6 データグラムを転送してくれるリレーを用意する必要がある。このために、クライアントは ICMPv6 Echo Request (ping) データグラムを作成し、設定済み Teredo サーバー向けに送信する。Teredo サーバーはこれを非カプセル化して IPv6 インターネットに ping を転送し、やがて ping は IPv6 ノードに到達する。そのノードは ICMPv6 Echo Reply をRFC 2460で必須とされている通り返信する。この返信データグラムは「最近傍」Teredo リレー経由でルーティングされ、リレーはクライアントにこれを転送を試みる。

Teredo サーバを維持するためにはほとんど帯域幅は必要ない。なぜなら、実際のIPv6トラフィックデータグラムの送受信には関与しないからである。また、インターネットルーティングプロトコルへアクセスすることもない。Teredo サーバーに要求されるのは以下の二点のみである。

Teredo プレフィクスのついたソースアドレスを持つ ICMPv6 データグラムを送信する能力
二つの異なるパブリックIPv4アドレス。これは公式の仕様には書かれていないが、Microsoft Windows クライアントは二つのアドレスが連続していることを予期している。二つ目のIPv4アドレスはNAT検知用である。

公開 Teredo サーバーの一覧

teredo.remlab.net / teredo-debian.remlab.net（ドイツ）
teredo.ngix.ne.kr（韓国）
teredo.managemydedi.com（アメリカ、シカゴ）
teredo.trex.fi（フィンランド）
win8.ipv6.microsoft.com (The Teredo server hidden in Windows RT 8.1) of which Windows 7 has no knowledge.

リレー

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 リレー^[3]を稼動させ、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 マルウェアの拡散の可能性が発生する^[4]。US CERT はIPv6トンネリングを利用するマルウェアのリスクについてのレポートを公開している。また、Teredo に不正に遠隔利用可能な脆弱性があると、IPv6スタックとトンネリングソフトウェアが攻撃者に対して露出してしまう。

マイクロソフトのIPv6スタックには「プロテクションレベル」ソケットオプションがある。これにより、アプリケーションが Teredo トンネル、Teredo トンネル以外の場所（デフォルト）、もしくはローカルイントラネットのみ、のいずれかからのトラフィックのみを許可することができる。

Teredo プロトコルはまた、トンネルのエンドポイントに関する詳細な情報をデータパケットにカプセル化している^[5]。

ファイアーウォール、フィルタリング、ブロック

Teredo 擬似トンネルを適切に運用するには、外向き UDP データグラムに加えて、それに対する返信データグラム（応答トラフィック）に対するフィルタリングも切る必要がある。これは、典型的なNATの設定とステートフルなファイヤーウォール機能に適合する。Teredo トンネリングソフトウェアは致命的エラーを検知すると外向き IPv4 UDP トラフィックをブロックする。また、UDP ポート 3544 への外向きトラフィックのブロックは Teredo の動作と干渉する。

ルーティングループ経由のDoS

近年、Teredo トンネルを用いたルーティングループ経由のDoS攻撃を行う方法が発見された。これを防ぐのは比較的容易である^[6]。

デフォルトで有効

マイクロソフト製OSの現行バージョンでは、Teredo を含むIPv6移行技術がデフォルトで有効になっている。これを無効化することはコマンドプロンプトおよびレジストリ編集により行うことができ、IPv6が実装されていなければ組織内ネットワークのグループポリシーで無効化することもできる。マイクロソフトによりデフォルトで有効化されているため、クリーンインストール直後のWindows OS においてIPv6を利用するマルウェアの脅威を増やさないためには、IPv6および関連する移行技術に関してはわかりづらい設定を行う必要が発生している^[7]。

実装

Teredo の実装としては、複数のものが存在する。

Windows XP SP2 （と Advanced Networking Pack for Service Pack 1）にはクライアントとホスト限定リレーが実装されている。
Windows Server 2003 向けにはマイクロソフトベータプログラムによりリレーおよびサーバーが提供された。
Windows Vista と Windows 7 には規格外の対称NATトラバーサル拡張をサポートする Teredo 実装が組み込まれている。しかし、リンクローカルおよび Teredo アドレスのみが利用可能な場合、これらのOSは IPv6 DNS AAAA レコードを解決しようとしないため、IPv4 が使用される。したがって、Teredo 使用時はIPv6アドレスをURLに直打ちする必要があった。
Miredo（英語版）は Linux, *BSD, Mac OS X 向けのクライアント・リレー・サーバー実装である。
ng_teredo はパリ第6大学の研究所、LIP6（英語版）とネットワークソフトウェアベンダの6WINDが開発した、FreeBSD 向けの netgraph（英語版）ベースのリレー・サーバー実装である^[8]^[要出典]。
NICI-Teredo は国立交通大学が開発した、Linux カーネル向けのリレーおよびユーザーランド Teredo サーバーである^[9]^[要出典]。

名前の由来

Teredo トンネリングプロトコルの最初のニックネームは shipworm（フナクイムシ）だった。プロトコルがNATに穴を空けるということから、フナクイムシが木にトンネルを穿つ様子を連想したものである。フナクイムシは非常に多くの木製船殻をダメにした元凶であるが、クリスチャン・ウイテマはオリジナルのドラフトに次のように書いている。「この動物は比較的清浄で汚染のない水にしか棲めない。彼らが北アメリカの港に近年戻ってきていることは、水が綺麗になっている証拠である。そのように、NATに穴を空けることによってこのサービスは新たなインターネットの透明性に寄与するだろう。」

クリスチャン・ウイテマは、コンピューターワームとの混同を避けるために名前を Teredo に変更した^[10]。もっとも一般的なフナクイムシ種の学名は Teredo navalis である。

脚注

^ 川島正伸 (2014年3月). “IPv6関連WG報告〜6man WG、v6ops WGについて〜”. JPNIC. 2022年3月25日閲覧。 “なお、今回のv6ops WGで最初に行われたプレゼンでは、Microsoft社のChris Palmer氏から、Microsoft社のTeredoサービスとXbox Oneに関するプレゼンが行われ、Windows向けのTeredoサービスに関しては、2014年の前半にはサービスを終息する予定であるとの報告がありました。”
^ "Teredo Addresses (Windows)". msdn.microsoft.com (英語). {{cite web}}: Cite webテンプレートでは|access-date=引数が必須です。 (説明)
^ Levy, Martin (28 May 2009). "Hurricane Electric's experience in deploying Teredo and 6to4 relays" (PDF). LACNIC-XII/FLIP6 2009 Conference, Panama City, Panama. {{cite web}}: Cite webテンプレートでは|access-date=引数が必須です。 (説明)
^ “Malware Tunneling in IPv6 | US-CERT”. www.us-cert.gov. 2016年9月5日閲覧。
^ “IPv6 Tunneling Protocols: Good for Adoption, Not So Hot for Security - TrendLabs Security Intelligence Blog” (英語) (2009年10月26日). 2016年9月5日閲覧。
^ Gont, Fernando (8 September 2010). "Internet-Draft - Teredo routing loops - Mitigating Teredo Rooting Loop Attacks". ietf.org. p. 2. {{cite web}}: Cite webテンプレートでは|access-date=引数が必須です。 (説明)
^ Perschke, Susan. “Hackers target IPv6”. 2016年9月5日閲覧。
^ Kabassanov, Konstantin; Jardin, Vincent.
^ "Solomon, Aaron".
^ Huitema, Christian (19 December 2001). "(ngtrans) Renaming Shipworm as Teredo?". IETF ngtrans wg mailing list. {{cite web}}: Cite webテンプレートでは|access-date=引数が必須です。 (説明)