IPv4残留導入

IPv4 Residual Deployment（4rd ）は、インターネットサービスプロバイダーが顧客へのIPv4サービスを維持しながら、インターネットプロトコルバージョン6 （IPv6）を導入するためのIPv6移行メカニズムです。プロトコルとサンプルアプリケーションはRFC 7600で規定されています

特徴

IPv4 Residual Deploymentには、3つの主な特徴があります。

  • メッシュトポロジ：2つのエンドポイント間で、IPv4パケットはIPv6パケットと同じ直接経路をたどります。[ 1 ]
  • 共有 IPv4 アドレス: 避けられない IPv4 アドレス不足に対処するために、複数の顧客に共通の IPv4 アドレスを割り当て、各顧客に個別の TCP/UDP ポート セットを割り当てることができます (RFC 6346 の一般的なA+Pモデルの応用)。
  • ステートレス操作: ドメイン入口での IPv4 パケットから IPv6 パケットへの変換、およびドメイン出口でのその逆の変換はステートレスです (つまり、ドメイン エッジ ノードで顧客ごとの状態は必要ありません)。

同じ主な機能を持つ他のIETF指定のメカニズム、つまり MAP-E (RFC 7597、RFC 7598、RFC 2473) や MAP-T (RFC 7599、RFC 7598、RFC 6145) と比較すると、その際立った特性は、次のものを同時にサポートすることです。

  • IPv4フラグメンテーションの完全な透過性：この機能により、 RFC 6349で推奨されているRFC 4821のパスMTU検出のサポート が維持されます。この機能がなければ、ファイアウォールがICMPパケットをフィルタリングする場合、RFC 4821 [ 2 ]をサポートするエンドシステムは、大きなパケットをサポートするパスを利用できなくなります。
  • IPv6パケット検査のIPv4への適用性：IPv6専用ドメインを通過する場合、変換されたIPv4パケットは通常のIPv6パケットとなり、その内容は変更されず、IPv6でも有効です。[ 3 ]したがって、IPv6専用ドメイン内で実行されるIPv6フィルタ（アクセス制御リスト、Webキャッシュ、ディープパケットインスペクションなど）は、暗黙的かつ自動的に、ドメインを通過するIPv4パケットに対して有効になります。

MAP-E は前者のみをサポートし、MAP-T は後者のみをサポートします。

ISP がIPv6 専用ドメイン全体で残余 IPv4 サービスを提供したい場合、このドメインのすべての顧客に顧客構内機器を提供するときは、MAP-E、MAP-T、4rd のいずれかを選択できます。ただし、MAP-E と MAP-T は標準化過程の RFC で指定されているのに対し、4rd は少なくともこれまでのところ、実験過程の RFC で指定されていることに留意してください (以下の「履歴」セクションを参照)。選択されたメカニズムは、各ドメイン内部のみに限定されます。

原則

IPv4フラグメンテーション透過性とIPv6ディープパケットインスペクションを単一の設計で組み合わせることを可能にする鍵は、ドメイン入口と出口で可逆的なパケット変換を使用することです。 [ 3 ] これは、必要に応じてフラグメントヘッダーが適切に補完されたIPv6パケットヘッダーが、RFC 7600で詳述されているアドホックな方法で、すべての有用なIPv4ヘッダー情報をエンコードするのに十分な大きさであるため可能です。（これは、IPv4のみのドメイン間でのIPv6のトンネリングメカニズムである6rdでは不可能でした。IPv4ヘッダーは小さすぎてすべてのIPv6ヘッダー情報を含めることができないためです。）

IPv4のIP層オプションは4rdではサポートされていないが、エンドシステムは既にセキュリティ上の理由からIPv4のIP層オプションが多くのルータによってフィルタリングされているという事実に適応しているため、実際的な影響はない。[ 4 ]

4rd仕様がMAP-EやMAP-Tの仕様を凌駕するもう一つの問題は、断片化されたIPv4データグラムに関するものです。MAP-EとMAP-T仕様では、転送前のドメインエントリ時にデータグラムを再構成する動作のみが詳細に記述されています。[ 5 ] [ 6 ] ユーザーが体感するパフォーマンスの向上、ドメインエントリ処理の削減、そして攻撃機会の低減を目的として、4rd仕様には、受信した大きなデータグラムの断片を一つずつオンザフライで転送するアルゴリズムが含まれています。[ 7 ]

歴史

最初の「4rd」仕様は、現在のRFC 7600とは異なり、IPv6パケットでIPv4カプセル化を使用していました。これは、IPv6のみのドメイン全体で完全なIPv4の保持を保証するために、当時唯一知られていたトンネリング手法でした。これは、ステートレスアドレスマッピング、メッシュトポロジ、およびA+Pを組み合わせた最初の提案でした。[ 8 ] [ 9 ]

次に提案されたのは、dIVIと呼ばれる別のステートレスメッシュA+Pアプローチである。 [ 10 ]このアプローチでは、カプセル化の代わりに、RFC 2765の既存のSIIT一方向変換に基づいて、2つの連続した変換（IPv4からIPv6へ、そしてその逆）が使用された。カプセル化と比較して、このアプローチには、変換されたUDPおよびTCP IPv4パケットにIPv6パケット検査を適用できるという利点があったが、SIITの制限により、IPv4フラグメンテーションとの完全な互換性がなかった（その結果、前述のように、 RFC 6349で推奨されているパスMTU検出との互換性もなかった ）。

このような状況下では、規格の統一が一般的に望まれていたにもかかわらず、2つの設計のうちのいずれかを単一の規格として承認することは不可能と思われました。そこで、2つの異なる方向性が検討されました。

  • ある提案では、4番目のカプセル化ソリューションをMAP-Eと改名し、二重SIIT変換をMAP-Tと改名し、これらを統合した MAPという仕様にまとめるというものでした。[ 11 ]この考え方は、標準の単一性という目標を満たすために、2つのバリエーション（IPv6専用ドメインごとに選択する必要がある）を持つ仕様は、単一の標準と同等とみなされる可能性があるというものでした。しかし、この解釈については合意に至りませんでした。[ 12 ]
  • もう1つは、前述のように、MAP-TのようにIPv6パケット検査のIPv4への適用性と、MAP-EのようにIPv4フラグメンテーションとの完全な互換性を兼ね備えた、アップグレードされたIPv4-IPv6二重変換アルゴリズムが実現可能であるという発見に基づいていました。カプセル化ソリューションに「4rd」という頭字語が使用されなくなったため、このソリューションは4rdと名付けられました。このアプローチを独自の標準に採用するという提案がなされました。[ 13 ]しかし、実装におけるその原理の検証にもかかわらず、[ 14 ] MAP-EおよびMAP-Tの支持者からの関心は高まりませんでした。[ 12 ]

長い議論の末、ソフトワイヤーワーキンググループ[ 15 ]は2012年8月にMAP-Eのみを標準化し、4rdとMAP-Tの両方の作業は実験的なものとして継続することを決定した。[ 12 ]

最終的に、2014年12月にSoftwireワーキンググループ[ 15 ]は以前の決定を変更し、MAP-TをMAP-Eと並行して標準化過程に載せることを決定しました。ただし、MAP-T RFCにRFC 4821のパスMTU検出との非互換性を示す注記を含めることを条件としました 。 [ 16 ]

これにより、実験的カテゴリでは4 位だけが残りました (ただし、 ISP は機能上の利点により、顧客宅内機器を全顧客に 提供するドメインでこれを導入する可能性があります)。

実世界での導入

フランスのISP Freeは、 2015年12月から「低密度地域」でのFTTH実験のために4rdを導入したとされています。A +Pモデルの実装は、IPv4アドレスごとに4つの連続したポート範囲を異なる顧客に割り当てることを意味します。Freeは6rdの最初の実装者としても知られています。[ 17 ]

参考文献

  1. ^ Wu, J.; Cui, Y.; Metz, C.; Rosen, E. (2009). 「IPv4-over-IPv6 メッシュシナリオ」 . doi : 10.17487/ RFC5565{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  2. ^ 「Linux には Windows PMTU ブラックホール ルーター検出と同等の機能がありますか?」。
  3. ^ a b Despres, R.; Penno, R.; Lee, Y.; Chen, G.; Chen, M.; Chen, M. (2015). Jiang, S. (ed.). 「ドメイン入口および出口における可逆パケット変換」 . doi : 10.17487/RFC7600 .{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  4. ^デュガル、D.;ピニャタロ、C.ダン、R. (2011)。「設計のトレードオフ - RFC 6192」。土井: 10.17487/RFC6192。{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  5. ^ Dec, W.; Li, X.; Bao, C.; Matsushima, S.; Murakami, T.; Murakami, T.; Taylor, T. (2015). Troan, O.; Taylor, T. (編). 「MAPドメイン境界でのIPv4フラグメントの受信（MAP-Eのケース）」 . doi : 10.17487/RFC7597 .{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  6. ^ Li, X.; Bao, C.; Troan, O.; Matsushima, S.; Murakami, T.; Murakami, T. (2015). Dec, W. (ed.). 「MAPドメイン境界でのIPv4フラグメントの受信（MAP-Tの場合）」 . doi : 10.17487/RFC7599 .{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  7. ^ Despres, R.; Penno, R.; Lee, Y.; Chen, G.; Chen, M.; Chen, M. (2015). Jiang, S. (編). 「共有アドレスCE宛のフラグメントポート（4番目のケース）」 . CiteSeerX 10.1.1.697.6541 . doi : 10.17487/RFC7600 . {{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）が必要です
  8. ^ 「IPv6専用ドメインにおけるパブリックIPv4アドレスとIPv4Eプレフィックス 4rd」 IETFデータトラッカー。
  9. ^ 「IPv6サービスネットワークにおけるIPv4残余展開（第4回）ISP-NATがオプションに」 IETFデータトラッカー。
  10. ^ "draft-xli-behave-divi-02" . Ietf Datatracker .
  11. ^ "draft-ietf-softwire-map-00" . Ietfデータトラッカー.
  12. ^ a b c「IETF-84 - Softwire WG - 会議議事録」。
  13. ^ "draft-ietf-softwire-map-00" .
  14. ^ 「第4回実施報告書」。
  15. ^ a b「IETF Softwires (softwire) ワーキンググループ」。
  16. ^ 「[Softwires] MAP-T から標準化の道へ」。
  17. ^ギョーム、シャンポー (2016 年 2 月 15 日)。「IP à plusieurs abonnés のアドレス属性を無料で取得」。ヌメラマ（フランス語）。2016 年2 月 29 日に取得。
「 https://en.wikipedia.org/w/index.php?title=IPv4_Residual_Deployment&oldid=1292388269」から取得