IPv6移行メカニズム

IPv6移行メカニズムは、1983 年以来使用されているインターネットプロトコルバージョン 4 (IPv4) インフラストラクチャから、後継のアドレス指定およびルーティングシステムであるインターネットプロトコルバージョン 6 (IPv6) への移行を容易にするテクノロジです。IPv4 ネットワークと IPv6 ネットワークは直接相互運用できないため、移行テクノロジは、どちらのネットワークタイプ上のホストも他のホストと通信できるように設計されています。

IPv6 が技術的基準を満たすには、現在の IPv4 からの簡単な移行計画が必要です。^[1]インターネット技術タスクフォース(IETF) は、IETFインターネットドラフトおよびコメント要求プロセスを通じてワーキンググループとディスカッションを実施し、その目標に向けた移行技術を開発しています。いくつかの基本的な IPv6 移行メカニズムは、RFC 4213 で定義されています。

ステートレス IP/ICMP 変換

ステートレス IP/ ICMP変換( SIIT ) は、 IPv6とIPv4のパケットヘッダー形式を変換します。^{[2] SIIT 方式では、}IPv4 変換アドレスと呼ばれる IPv6 アドレスのクラスが定義されています。^[3]これらはプレフィックス::ffff:0:0:0 / 96を持ち、 ::ffff:0:abcdと記述できます。この場合、 IPv4 形式のアドレスabcd はIPv6 対応ノードを参照します。プレフィックスは、トランスポートプロトコルヘッダーチェックサムの変更を回避するために、ゼロ値のチェックサムを生成するように選択されました。 ^{[4]このアルゴリズムは、永続的に割り当てられた IPv4 アドレスを持たない IPv6 ホストが IPv4 のみのホストと通信できるようにするソリューションで使用できます。アドレスの割り当てとルーティングの詳細は仕様では扱われていません。SIIT は、ステートレス}ネットワークアドレス変換の特殊なケースと見なすことができます。

この仕様は、NGTRANS IETFワーキンググループの成果物であり、2000年2月にサン・マイクロシステムズのE. Nordmark氏によって最初に起草されました。^[5] 2011年に改訂され、^[6] 2016年に現在の改訂版が公開されました。^[4]

トンネルブローカー

トンネルブローカーは、通常6in4を使用して、IPv6トラフィックをIPv4インターネットトランジットリンクにカプセル化することで、IPv6接続を提供します。これにより、IPv4インターネット内にIPv6トンネルが確立されます。トンネルは、トンネルセットアッププロトコル（TSP）^[7]またはAYIYA ^[8]を使用して管理できます。

6位

6rd は、Rémi Desprésによって開発されました。これは、インターネットサービスプロバイダー ( ISP )のIPv4インフラストラクチャ全体にIPv6サービスを迅速に導入するためのメカニズムです。IPv4 アドレスとIPv6アドレス間のステートレスアドレスマッピングを使用し、顧客ノード間でIPv4パケットと同じ最適化されたルートをたどる自動トンネルを介してIPv6パケットを送信します。

これは、2007年にネイティブアドレスを使用したIPv6サービスの初期の大規模展開に使用されました（RFC 5569 ^[9]）。プロトコルの標準仕様はRFC 5969にあります。^[10]

トランスポートリレー翻訳

RFC 3142はトランスポートリレー変換（TRT）方式を定義しています。TRTは2つのホスト間の中間デバイスとして機能します。トランスレータの機能は、IPV6アドレスをIPV4アドレスに変換することと、その逆を行うことです。TRTは、IPアドレスマッピングとカスタムIPアドレスを通じてこの変換を実現します。^[11]

たとえば、パケットがIPv6アドレス（fec0:0:0:1::/64）からIPv4アドレス（10.1.1.1）に送信されるとき、アドレスはfec0:0:0:1::10.1.1.1と表示されます。パケットは、まずIPv6/TCPプロトコルを介してトランスレータにルーティングされ、次にIPv4/TCPプロトコルを介してトランスレータからIPv4ホストにルーティングされます。^[12]

TRTは、RFC 2694で定義されているDNS-ALGと呼ばれるAAAAレコードとAレコード間のDNS変換と同様の操作を採用しています。^[13]

NAT64

NAT64 は、IPv6 ホストが IPv4 サーバーと通信できるようにするメカニズムです。NAT64 サーバーは、少なくとも 1 つの IPv4 アドレスと 32 ビットの IPv6 ネットワークセグメント (例: 64:ff9b:: / 96 ) のエンドポイントです。^[3] IPv6 クライアントは、これらのビットを使用して通信する IPv4 アドレスを埋め込み、その結果得られたアドレスにパケットを送信します。次に、NAT64 サーバーはIPv6 アドレスと IPv4 アドレスの間にNATマッピングを作成し、通信できるようにします。^[14]

DNS64

DNS64 は、ドメインのAAAA レコードを要求されたが A レコードしか見つからない場合に、A レコードから AAAA レコードを合成するDNS サーバーを記述します。合成された IPv6 アドレスの最初の部分は IPv6/IPv4 トランスレータを指し、2 番目の部分は A レコードから IPv4 アドレスを埋め込みます。問題のトランスレータは通常 NAT64 サーバーです。DNS64 の標準仕様は RFC 6147 にあります。^[15]

この移行メカニズムには、2 つの顕著な問題があります。

これは、DNS を使用してリモートホストアドレスを検索する場合にのみ機能します。IPv4 リテラルが使用されている場合、DNS64 サーバーは関与しません。
DNS64 サーバーはドメイン所有者によって指定されていないレコードを返す必要があるため、変換を実行する DNS サーバーがドメイン所有者のサーバーでない場合は、ルートに対するDNSSEC検証は失敗します。

# DNS リゾルバ 2606:4700:4700:64 は、
# ipv6test.google.com の AAAA レコードを NAT64 アドレス 64:ff9b::<original-ipv4> に合成します。 
$ nslookup ipv6test.google.com 2606:4700:4700::64

非権威回答: 
ipv6test.google.com正規名 = ipv6test.l.google.com。名前:	 ipv6test.l.google.comアドレス: 64:ff9b::8efa:c3e4

実装

dns64モジュール経由のアンバウンドDNSサーバー^[16]
バインドされていない opkg パッケージ経由のOpenWrt 。

イスアタップ

ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) は、IPv4 ネットワーク上のデュアルスタックノード間で IPv6 パケットを転送するための IPv6 移行メカニズムです。

6over4 (IPv4 マルチキャストを使用する古い類似プロトコル) とは異なり、ISATAP は IPv4 を仮想非ブロードキャストマルチアクセスネットワーク (NBMA) データリンク層として使用するため、マルチキャストをサポートするために基盤となる IPv4 ネットワークインフラストラクチャを必要としません。

464XLAT

464XLAT（RFC 6877）は、IPv6のみのネットワーク上のクライアントがSkypeなどのIPv4のみのインターネットサービスにアクセスすることを可能にします。^[17]^[18]

クライアントは SIIT トランスレータを使用してパケットを IPv4 から IPv6 に変換します。次に、これらのパケットは NAT64 トランスレータに送信され、NAT64トランスレータはパケットを IPv6 から IPv4 に再変換して IPv4 専用サーバーに送ります。クライアントトランスレータはクライアント自体または中間デバイスに実装され、CLAT (Customer-side transLATor) と呼ばれます。NAT64 トランスレータ、または PLAT (Provider-side transLATor) は、サーバーとクライアントの両方に (CLAT 経由で) 到達できる必要があります。NAT64 を使用すると、UDP、TCP、および ICMP を使用するクライアントサーバーモデルへの接続が制限されます。

実装

T-Mobile USは464XLATを使用してIPv6のみになりました。^[19]
Orange Polskaは2013年9月にIPv6のみ（CLAT/NAT64/DNS）のサービスを開始し、2015年1月までにすべてのADSL、VDSL、FTTHゲートウェイを移行しました。 ^[20]
テルストラは2020年2月に464XLATを使用したモバイルサービスでIPv6のみを採用した。^[21]
Androidには、 2013年にリリースされたJelly Bean 4.3以降、CLATのネイティブ実装が含まれています。^[22]
Windows 10には、2017 Creators Update以降、デスクトップとモバイル向けに464XLATのネイティブWWANのみの実装があります。^[23]
Windows 11 (23H2) は Windows 10 と同じ実装です。将来のバージョンでは、CLAT サポートが他のネットワークデバイス (現在は WWAN に限定) に拡張されます。実装では、RFC 7050 (ipv4only.arpa DNS クエリ)、RFC 8781 (PREF64)、および RFC 8925 (DHCP オプション 108) 標準が使用されます^[24]
macOSは2022年にリリースされるVenturaでネイティブCLATサポートを開始します。^[25]
iOSは2018年にリリースされたバージョン12.0以降、ネイティブCLAT実装を備えています。^{[26]さらに、Appleは}App Storeに提出されたすべてのアプリがIPv6ネットワークで動作することを要求しています。^[27]
clatdはLinux用のCLAT実装である。^[28]
ルーター用のOpenWRT Linux OSは、464xlatパッケージを介してclatのオプションサポートを備えています^[29]
FreeBSDはリリース12.1以降NAT64 CLATを実装している。^[30]

デュアルスタックライト (DS-Lite)

Dual-Stack Liteテクノロジーでは、インターネットアクセスを提供するために顧客構内設備(CPE) に IPv4 アドレスを割り当てる必要がありません。^[31] CPE は、ローカルエリアネットワークのネットワーク要件に従って、LAN クライアントにプライベート IPv4 アドレスを配布します。CPE は、IPv4 パケットを IPv6 パケット内にカプセル化します。CPE は、グローバル IPv6 接続を使用して、グローバル IPv4 アドレスを持つ ISP のキャリアグレード NAT (CGN) にパケットを配信します。元の IPv4 パケットが復元され、IPv4 パケットに対して NAT が実行され、パブリック IPv4 インターネットにルーティングされます。CGN は、CPE パブリック IPv6 アドレス、プライベート IPv4 アドレス、および TCP または UDP ポート番号をセッションとして記録することにより、トラフィックフローを一意に識別します。

軽量4over6は、 NAT機能をISP側からCPEに移動することでDS-Liteを拡張し、キャリアグレードのNATを実装する必要がなくなります。^[32]これは、共有IPv4アドレスのポート範囲を各CPEに割り当てることで実現されます。NAT機能をCPEに移動すると、ISPは各加入者に対して追跡する状態の量を減らすことができ、変換インフラストラクチャのスケーラビリティが向上します。

V4-V6 ルーティング

V4-via-v6ルーティングは、エンドホストにのみ IPv4 アドレスが割り当てられ、中間ルータには IPv6 アドレスのみが割り当てられる手法です。IPv4 ルートは通常どおり伝播され、パケット変換やカプセル化は行われず、IPv6 ネクストホップが使用されます。V4-via-v6 では、コアネットワークに IPv6 アドレスのみを割り当てる必要があるため、必要な管理量が削減されますが、コアネットワークが IPv4 パケットを転送できることは依然として必要です。

V4-via-v6は、ボーダーゲートウェイプロトコル（BGP）^[33]とBabelルーティングプロトコル[ ^34]用に定義されています。これは、 Birdインターネットルーティングデーモン^[35]とbabeld^[36]に実装されています。

地図

アドレスとポートのマッピング（MAP）は、A+Pポートアドレス変換とISPプロバイダーの内部IPv6ネットワークを介したIPv4パケットのトンネリングを組み合わせたシスコの IPv6移行提案です。 ^[37] MAP-T ^[38]とMAP-E ^[39]は2015年7月に標準化の軌道に入り、Sky Italiaは2021年にはインターネットサービスにMAP-Tを導入しています。^[40]

提案案

以下のメカニズムは、IETF によってまだ議論中であるか、または放棄されています。

4位

IPv4 Residual Deployment（4rd）は、 IPv6ネットワーク上でのIPv4サービスの残余展開を容易にするための実験的なメカニズム^[41]です。6rdと同様に、 IPv6とIPv4間のステートレスなアドレスマッピングを使用します。トランスポート層ポートに基づくIPv4アドレスの拡張をサポートします。これはA+Pモデルのステートレスな変種です。

非推奨のメカニズム

以下のメカニズムは IETF によって非推奨となっています。

NAT-PT

ネットワークアドレス変換/プロトコル変換( NAT-PT ) は RFC 2766 で定義されていますが、多くの問題があるため、RFC 4966 によって廃止され、非推奨となり、歴史的ステータスになりました。通常、 DNS アプリケーションレベルゲートウェイ(DNS-ALG) 実装と組み合わせて使用されます。

NAPT-PT

NAT-PT とほぼ同じですが、 RFC 2766 でも説明されているネットワークアドレスポート変換 + プロトコル変換では、アドレスだけでなくポートの変換も追加されます。これは主に、メカニズムの片側にある 2 つのホストがメカニズムのもう一方の側にある同じ公開ポートを使用することを回避するために行われます。これにより、アプリケーションの不安定性やセキュリティ上の欠陥が発生する可能性があります。このメカニズムは、RFC 4966 で非推奨になっています。

実装

stone (ソフトウェア)、Windows および Unix ベースのシステム用のポートトランスレータ。
faithd、 KAME プロジェクトによる BSD ベースの静的 TRT 実装
CLATD、Linux 用の CLAT / SIIT-DC エッジリレー実装
Linux 用の NAT64 実装である WrapSix
TAYGA、Linux 用のステートレス NAT64 実装
Jool、Linux 用の SIIT およびステートフル NAT64 実装
naptd、ユーザーレベル NAT-PT
NAT64ゲートウェイであるEcdysisにはDNS64が含まれています
アドレスファミリトランジションルータ (AFTR)、DS-Lite 実装
IPv6ネットワーク経由でIPv4ユニキャストトラフィックの送信を可能にするniit Linuxカーネルデバイス
IVI IPv4/IPv6 パケット変換実装 (Linux カーネル (2.6 のみ) パッチ)
Microsoft Forefront Unified Access Gateway は、DNS64 と NAT64 を実装するリバースプロキシおよび VPN ソリューションです。
BIND、バークレーインターネットネームドメイン DNS サーバー、バージョン 9.8 以降で DNS64 を実装
PF（ファイアウォール）、OpenBSDパケットフィルタはバージョン5.1以降IPバージョン変換をサポートし、NAT64を含む

参照

参考文献

^ Partridge, C.; Kastenholz, F. (1994 年 12 月). IP The Next Generation (IPng) を選択するための技術基準. doi : 10.17487/RFC1726 . RFC 1726.
^ F. Baker、X. Li、C. Bao、K. Yin (2011 年 4 月)。 IPv4/IPv6 変換フレームワーク。インターネット技術タスクフォース( IETF )。doi : 10.17487 / RFC6144。ISSN 2070-1721。RFC 6144 。 情報提供。
^ ab C. Bao; C. Huitema ; M. Bagnulo; M. Boucadair; X. Li (2010 年 10 月). IPv4 /IPv6 トランスレータの IPv6 アドレス指定。インターネット技術タスクフォース(IETF)。doi : 10.17487 / RFC6052。ISSN 2070-1721。RFC 6052 。 提案された標準。RFC 4291 を更新します。
^ ab C. Bao; X. Li; F. Baker ; T. Anderson; F. Gont (2016 年 6 月). ステートレス IP/ICMP 変換アルゴリズム. doi : 10.17487/RFC7915 . RFC 7915.
^ E. Nordmark (2000 年 2 月). ステートレス IP/ICMP 変換アルゴリズム (SIIT). ネットワークワーキンググループ. doi : 10.17487/RFC2765 . RFC 2765. 廃止。RFC 6145 により廃止されました。
^ X. Li; C. Bao; F. Baker (2011 年 4 月). IP/ICMP 変換アルゴリズム.インターネット技術タスクフォース(IETF). doi : 10.17487/RFC6145 . ISSN 2070-1721. RFC 6145. 廃止。RFC 7915 により廃止。RFC 6791 および 7757 により更新。
^ M. Blanchet、F. Parent (2010 年 2 月)。トンネルセットアッププロトコル (TSP) を使用した IPv6 トンネルブローカー。doi : 10.17487 / RFC5572。ISSN 2070-1721。RFC 5572 。 実験的。
^ A. Durand、P. Fasano、I. Guardini、D. Lento (2001 年 1 月)。IPv6 トンネルブローカー。ネットワークワーキンググループ。doi : 10.17487 / RFC3053。RFC 3053 。 情報提供。
^ Despres, R. (2010年1月). IPv4インフラストラクチャへのIPv6の迅速な導入 (第6回). doi : 10.17487/RFC5569 . RFC 5569.
^ Troan, O. (2010年8月). IPv4インフラストラクチャへのIPv6の迅速な導入（6回目） - プロトコル仕様. doi : 10.17487/RFC5969 . RFC 5969.
^ Hagino, J.; Yamamoto, K. (2001 年 6 月). 「An IPv6-to-IPv4 Transport Relay Translator」. rfc-editor.org . Request for Comments Editor . 2024 年6 月 28 日閲覧。
^ Shanmugaraja, P. 「トランスポートリレートランスレータの設計と実装、およびそのセキュリティ緩和策」。researchgate.net。Research Gate。2024年6月28日閲覧。
^ Heffernan, Andy; Tsirtsis, George; Srisuresh, Pyda; Akkiraju, Praveen (1999年9月). 「DNS extensions to Network Address Translators (DNS_ALG)」. rfc-editor.org . 2024年6月28日閲覧。
^ M. Bagnulo、P. Matthews、I. van Beijnum (2011 年 4 月)。ステートフル NAT64: IPv6 クライアント からIPv4 サーバーへのネットワークアドレスおよびプロトコル変換。インターネット技術タスクフォース(IETF)。doi : 10.17487 / RFC6146。ISSN 2070-1721。RFC 6146 。 提案された標準。
^ Bagnulo, M.; Sullivan, A.; Matthews, P.; van Beijnum, I. (2011 年 4 月). DNS64: IPv6 クライアントから IPv4 サーバーへのネットワークアドレス変換のための DNS 拡張。doi : 10.17487 / RFC6147。RFC 6147 。
^ “README.DNS64”. GitHub . 2024-04-07にオリジナルからアーカイブ。2024-04-07に取得。
^ Žorž, Jan (2013年4月3日). 「ビデオ: パリで開催された世界IPv6会議での464XLATライブデモ」.インターネット協会. 2017年9月13日時点のオリジナルよりアーカイブ。 2013年8月5日閲覧。
^ 「464XLAT – IPv6専用ネットワーク上でIPv4サービスを提供するソリューション」T-Mobile USA。2020年11月12日時点のオリジナルよりアーカイブ。2013年8月5日閲覧。
^ 「ケーススタディ：T-Mobile US、464XLATを使用してIPv6のみに移行」。インターネット協会。2014年6月13日。2024年2月4日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。
^ Twardowska, Marta (2015年1月6日). 「Orange PolskaがSoftAtHomeで世界初の革新的なIPv6ソリューションを開始」. Business Wire . 2023年1月15日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。
^ 「Telstra IPv6 Wireless Enablement – IPv6 Single Stack」。2020年2月6日。2023年6月12日時点のオリジナルよりアーカイブ。 2023年6月12日閲覧。
^ Drown, Dan. 「What is Android CLAT?」. Dan's Notes . 2022年12月17日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。
^ Havey, Daniel; Balasubramanian, Praveen (2019 年 2 月 14 日). 「Windows 10 の Creators Update のコアネットワークスタック機能」. Microsoft Networking ブログ. 2023 年 2 月 1 日時点のオリジナルよりアーカイブ。2023年1 月 15 日閲覧。
^ 「Windows 11 が CLAT サポートを拡張する予定」。Microsoft Networking ブログ。2024 年 3 月 8 日時点のオリジナルよりアーカイブ。2024年3 月 7 日閲覧。
^ “Twitter” . 2022年6月27日閲覧。
^ 「[v6ops] iOS12 IPv6のみ」。2018年11月5日閲覧。
^ van Beijnum, Iljitsch (2015-06-16). 「Apple to iOS devs: IPv6-only cell service is coming soon, get your apps ready」Ars Technica。2016-06-28時点のオリジナルよりアーカイブ。 2016年7月2日閲覧。
^ Anderson, Tore (2019年5月20日). 「clatd」. GitHub . 2022年12月17日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。
^ 「OpenWrt Wiki パッケージ: 464xlat」。OpenWrt 。 2024年4月1日閲覧。
^ Baoi, Danilo G. (2021年6月19日). 「FreeBSD 12.1-RELEASE リリースノート」. FreeBSD . 2023年1月15日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。
^ A. Durand、R. Droms、J. Woodyatt、Y. Lee (2011 年 8 月)。 IPv4 枯渇後のデュアルスタックライトブロードバンド展開。インターネットエンジニアリングタスクフォース。doi : 10.17487/RFC6333。ISSN 2070-1721。RFC 6333。 提案された標準。
^ Y. Cui、Q. Sun、M. Boucadair、T . Tsou、Y. Lee、I. Farrer (2015 年 7 月)。「 Lightweight 4over6 : デュアルスタック Lite アーキテクチャの拡張」。インターネットエンジニアリングタスクフォース。doi : 10.17487/RFC7596。ISSN 2070-1721。RFC 7596 。 提案された標準。
^ Le Faucheur, François; Rosen, Eric (2009 年 5 月). IPv6 ネクストホップによる IPv4 ネットワーク層到達可能性情報の広告。doi : 10.17487 / RFC5549。RFC 5549 。
^ Chroboczek, Juliusz (2022年5月). BabelルーティングプロトコルにおけるIPv6ネクストホップを使用したPv4ルート。doi : 10.17487/ RFC9229。RFC 9229 。
^ Rammhold, Andreas (2020年12月15日). 「[RFC] Babel: v4viav6 サポートの追加」. BIRD インターネットルーティングデーモン. 2022年12月29日時点のオリジナルよりアーカイブ。2023年1月15日閲覧。
^ Chroboczek, Juliusz (2022年5月5日). 「[Babel-users] ANNOUNCE: babeld-1.12」. Debian Alioth リスト. 2022年12月29日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。
^ Mark Townsley (2012 年 9 月 24 日)。「アドレス + ポートのマッピング」(PDF)。Cisco。2022年 12 月 29 日時点のオリジナルからアーカイブ(PDF) 。2012 年 9 月 25 日閲覧。
^ X. Li; C. Bao; O. Troan; S. Matsushima; T. Murakami (2015 年 7 月). W. Dec (編). 変換を使用したアドレスとポートのマッピング (MAP-T).インターネット技術タスクフォース(IETF). doi : 10.17487/RFC7599 . ISSN 2070-1721. RFC 7599. 提案された標準。
^ W. Dec; X. Li; C. Bao; S. Matsushima; T. Murakami (2015 年 7 月). O. Troan; T. Taylor (編). カプセル化によるアドレスとポートのマッピング (MAP-E).インターネット技術タスクフォース(IETF). doi : 10.17487/RFC7597 . ISSN 2070-1721. RFC 7597. 提案された標準。
^ Patterson, Richard (2021年5月). 「IPv6-Only with MAP-T」. RIPE NCC Open House . 2023年2月21日時点のオリジナルよりアーカイブ。 2023年8月1日閲覧。
^ R. Despres、R. Penno、Y. Lee、G. Chen、M. Chen (2015 年 7 月)。S. Jiang (編)。IPv6 による IPv4 残余展開 - ステートレスソリューション (第 4 版)。インターネット技術タスクフォース(IETF)。doi : 10.17487 / RFC7600。ISSN 2070-1721。RFC 7600 。 実験的。

外部リンク

IPv6 in Practice、Benedikt Stockebrand (2006)、ISBN 3-540-24524-3
RFC 2767、バンプ・イン・ザ・スタック
RFC 3089、Socks ベースのゲートウェイ
RFC 3338、API のバンプ
RFC 6144、IPv4/IPv6 変換フレームワーク
RFC 6219、中国教育研究ネットワーク (CERNET) IVI 変換設計と IPv4/IPv6 共存および移行のための展開
DJ バーンスタイン – IPv6 の混乱
クリスチャンとティナ・ストラウフ – 輸送リレー翻訳者の使い方
ネットワークワールド– デュアルスタックライトの理解 2011-10-20 にWayback Machineでアーカイブ
IETE 技術レビュー– プロトコル変換を使用せずに異種 (IPv4/IPv6) ネットワーク間の相互運用性を保証する
インターネットおよび情報システムにおける KSII トランザクション -ホストを自動検出 (IPv6、IPv6-in-IPv4、または IPv4) ネットワーク接続用に構成する

[RFC1726-1] Partridge, C.; Kastenholz, F. (1994 年 12 月). IP The Next Generation (IPng) を選択するための技術基準. doi : 10.17487/RFC1726 . RFC 1726.

[rfc6144-2] F. Baker、X. Li、C. Bao、K. Yin (2011 年 4 月)。 IPv4/IPv6 変換フレームワーク。インターネット技術タスクフォース( IETF )。doi : 10.17487 / RFC6144。ISSN 2070-1721。RFC 6144 。 情報提供。

[rfc6052-3] C. Bao; C. Huitema ; M. Bagnulo; M. Boucadair; X. Li (2010 年 10 月). IPv4 /IPv6 トランスレータの IPv6 アドレス指定。インターネット技術タスクフォース(IETF)。doi : 10.17487 / RFC6052。ISSN 2070-1721。RFC 6052 。 提案された標準。RFC 4291 を更新します。

[rfc7915-4] C. Bao; X. Li; F. Baker ; T. Anderson; F. Gont (2016 年 6 月). ステートレス IP/ICMP 変換アルゴリズム. doi : 10.17487/RFC7915 . RFC 7915.

[rfc2765-5] E. Nordmark (2000 年 2 月). ステートレス IP/ICMP 変換アルゴリズム (SIIT). ネットワークワーキンググループ. doi : 10.17487/RFC2765 . RFC 2765. 廃止。RFC 6145 により廃止されました。

[rfc6145-6] X. Li; C. Bao; F. Baker (2011 年 4 月). IP/ICMP 変換アルゴリズム.インターネット技術タスクフォース(IETF). doi : 10.17487/RFC6145 . ISSN 2070-1721. RFC 6145. 廃止。RFC 7915 により廃止。RFC 6791 および 7757 により更新。

[rfc5572-7] M. Blanchet、F. Parent (2010 年 2 月)。トンネルセットアッププロトコル (TSP) を使用した IPv6 トンネルブローカー。doi : 10.17487 / RFC5572。ISSN 2070-1721。RFC 5572 。 実験的。

[rfc3053-8] A. Durand、P. Fasano、I. Guardini、D. Lento (2001 年 1 月)。IPv6 トンネルブローカー。ネットワークワーキンググループ。doi : 10.17487 / RFC3053。RFC 3053 。 情報提供。

[RFC5569-9] Despres, R. (2010年1月). IPv4インフラストラクチャへのIPv6の迅速な導入 (第6回). doi : 10.17487/RFC5569 . RFC 5569.

[RFC5969-10] Troan, O. (2010年8月). IPv4インフラストラクチャへのIPv6の迅速な導入（6回目） - プロトコル仕様. doi : 10.17487/RFC5969 . RFC 5969.

[11] Hagino, J.; Yamamoto, K. (2001 年 6 月). 「An IPv6-to-IPv4 Transport Relay Translator」. rfc-editor.org . Request for Comments Editor . 2024 年6 月 28 日閲覧。

[12] Shanmugaraja, P. 「トランスポートリレートランスレータの設計と実装、およびそのセキュリティ緩和策」。researchgate.net。Research Gate。2024年6月28日閲覧。

[13] Heffernan, Andy; Tsirtsis, George; Srisuresh, Pyda; Akkiraju, Praveen (1999年9月). 「DNS extensions to Network Address Translators (DNS_ALG)」. rfc-editor.org . 2024年6月28日閲覧。

[rfc6146-14] ^ M. Bagnulo、P. Matthews、I. van Beijnum (2011 年 4 月)。ステートフル NAT64: IPv6 クライアント からIPv4 サーバーへのネットワークアドレスおよびプロトコル変換。インターネット技術タスクフォース(IETF)。doi : 10.17487 / RFC6146。ISSN 2070-1721。RFC 6146 。 提案された標準。

[RFC6147-15] Bagnulo, M.; Sullivan, A.; Matthews, P.; van Beijnum, I. (2011 年 4 月). DNS64: IPv6 クライアントから IPv4 サーバーへのネットワークアドレス変換のための DNS 拡張。doi : 10.17487 / RFC6147。RFC 6147 。

[16] “README.DNS64”. GitHub . 2024-04-07にオリジナルからアーカイブ。2024-04-07に取得。

[17] Žorž, Jan (2013年4月3日). 「ビデオ: パリで開催された世界IPv6会議での464XLATライブデモ」.インターネット協会. 2017年9月13日時点のオリジナルよりアーカイブ。 2013年8月5日閲覧。

[18] 「464XLAT – IPv6専用ネットワーク上でIPv4サービスを提供するソリューション」T-Mobile USA。2020年11月12日時点のオリジナルよりアーカイブ。2013年8月5日閲覧。

[19] 「ケーススタディ：T-Mobile US、464XLATを使用してIPv6のみに移行」。インターネット協会。2014年6月13日。2024年2月4日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。

[20] Twardowska, Marta (2015年1月6日). 「Orange PolskaがSoftAtHomeで世界初の革新的なIPv6ソリューションを開始」. Business Wire . 2023年1月15日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。

[21] 「Telstra IPv6 Wireless Enablement – IPv6 Single Stack」。2020年2月6日。2023年6月12日時点のオリジナルよりアーカイブ。 2023年6月12日閲覧。

[22] Drown, Dan. 「What is Android CLAT?」. Dan's Notes . 2022年12月17日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。

[23] Havey, Daniel; Balasubramanian, Praveen (2019 年 2 月 14 日). 「Windows 10 の Creators Update のコアネットワークスタック機能」. Microsoft Networking ブログ. 2023 年 2 月 1 日時点のオリジナルよりアーカイブ。2023年1 月 15 日閲覧。

[24] 「Windows 11 が CLAT サポートを拡張する予定」。Microsoft Networking ブログ。2024 年 3 月 8 日時点のオリジナルよりアーカイブ。2024年3 月 7 日閲覧。

[25] “Twitter” . 2022年6月27日閲覧。

[26] 「[v6ops] iOS12 IPv6のみ」。2018年11月5日閲覧。

[27] van Beijnum, Iljitsch (2015-06-16). 「Apple to iOS devs: IPv6-only cell service is coming soon, get your apps ready」Ars Technica。2016-06-28時点のオリジナルよりアーカイブ。 2016年7月2日閲覧。

[28] Anderson, Tore (2019年5月20日). 「clatd」. GitHub . 2022年12月17日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。

[29] 「OpenWrt Wiki パッケージ: 464xlat」。OpenWrt 。 2024年4月1日閲覧。

[30] Baoi, Danilo G. (2021年6月19日). 「FreeBSD 12.1-RELEASE リリースノート」. FreeBSD . 2023年1月15日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。

[rfc6333-31] A. Durand、R. Droms、J. Woodyatt、Y. Lee (2011 年 8 月)。 IPv4 枯渇後のデュアルスタックライトブロードバンド展開。インターネットエンジニアリングタスクフォース。doi : 10.17487/RFC6333。ISSN 2070-1721。RFC 6333。 提案された標準。

[rfc7596-32] ^ Y. Cui、Q. Sun、M. Boucadair、T . Tsou、Y. Lee、I. Farrer (2015 年 7 月)。「 Lightweight 4over6 : デュアルスタック Lite アーキテクチャの拡張」。インターネットエンジニアリングタスクフォース。doi : 10.17487/RFC7596。ISSN 2070-1721。RFC 7596 。 提案された標準。

[33] Le Faucheur, François; Rosen, Eric (2009 年 5 月). IPv6 ネクストホップによる IPv4 ネットワーク層到達可能性情報の広告。doi : 10.17487 / RFC5549。RFC 5549 。

[34] ^ Chroboczek, Juliusz (2022年5月). BabelルーティングプロトコルにおけるIPv6ネクストホップを使用したPv4ルート。doi : 10.17487/ RFC9229。RFC 9229 。

[35] Rammhold, Andreas (2020年12月15日). 「[RFC] Babel: v4viav6 サポートの追加」. BIRD インターネットルーティングデーモン. 2022年12月29日時点のオリジナルよりアーカイブ。2023年1月15日閲覧。

[36] Chroboczek, Juliusz (2022年5月5日). 「[Babel-users] ANNOUNCE: babeld-1.12」. Debian Alioth リスト. 2022年12月29日時点のオリジナルよりアーカイブ。 2023年1月15日閲覧。

[37] Mark Townsley (2012 年 9 月 24 日)。「アドレス + ポートのマッピング」(PDF)。Cisco。2022年 12 月 29 日時点のオリジナルからアーカイブ(PDF) 。2012 年 9 月 25 日閲覧。

[rfc7599-38] X. Li; C. Bao; O. Troan; S. Matsushima; T. Murakami (2015 年 7 月). W. Dec (編). 変換を使用したアドレスとポートのマッピング (MAP-T).インターネット技術タスクフォース(IETF). doi : 10.17487/RFC7599 . ISSN 2070-1721. RFC 7599. 提案された標準。

[rfc7597-39] W. Dec; X. Li; C. Bao; S. Matsushima; T. Murakami (2015 年 7 月). O. Troan; T. Taylor (編). カプセル化によるアドレスとポートのマッピング (MAP-E).インターネット技術タスクフォース(IETF). doi : 10.17487/RFC7597 . ISSN 2070-1721. RFC 7597. 提案された標準。

[40] Patterson, Richard (2021年5月). 「IPv6-Only with MAP-T」. RIPE NCC Open House . 2023年2月21日時点のオリジナルよりアーカイブ。 2023年8月1日閲覧。

[rfc7600-41] R. Despres、R. Penno、Y. Lee、G. Chen、M. Chen (2015 年 7 月)。S. Jiang (編)。IPv6 による IPv4 残余展開 - ステートレスソリューション (第 4 版)。インターネット技術タスクフォース(IETF)。doi : 10.17487 / RFC7600。ISSN 2070-1721。RFC 7600 。 実験的。