世界を冷静に見ると、トランスポートネットワークは多数の「クランチ」で構成され、nat（すべての形式で）またはospfコストの仮想リンクなどの技術のみです。 EnIPのrfcドラフトを読んだ後、これが別の松葉杖であることに気付きました。 しかし、正直なところ、私はこのアイデアが好きでした。 さあ、始めましょう。
現在の難しさやIPv4アドレスの数は少ないとは言いませんが（誰もが聞いたことはありますが）、テクノロジーに直接行きます。
それで、EnIPとは正確に何ですか。 一見したところ、開発者は2つのIPv4アドレスを取得して1つにまとめ、192.0.0.1.10.0.0.1という形式の64ビットアドレスを受け取りました。 アドレススペースは40億以上増加したように見えます：2 ^ 32から2 ^ 64になり、プロバイダーはIPv6に切り替える必要がなくなり、IANAは再びパケットのアドレスを左右に分配できるようになりました。 しかし、実際にアドレス空間がどれだけ増加するかを考えてみましょう。 これを行うために、rfcからいくつかのフレーズを挙げます。
IPv4であるため、下位互換性を最大限に高めながら、アドレス空間を1790万倍に増やします。
これにより、/ 8ネットワーク内の未使用のアドレスブロックの小さなセグメントを、IPアドレスが慢性的に不足しているレジストリに再割り当てできます。
IPv4とEnIPの後方互換性を失わずに再配布できる3つの分散アドレスブロックがあります。これらはプライベート範囲10.0.0.0/8、172.16.0.0/12、192.168.0.0/16です。 複雑な計算（2 ^ 32 * 2 ^ 24）+（2 ^ 32 * 2 ^ 20）+（2 ^ 32 + 2 ^ 16）は行わず、インターネット上でルーティングされるアドレスの数が1790万倍に増加することを確認します。 もちろん、プライベートアドレススペース10.0.0.0/8,172.16.0.0/12および192.168.0.0/16からのプレフィックスに加えて、少なくとも1つのグローバルルーティングプレフィックスが必要です（または取得しないと、何も機能しません）。
注：プレフィックス240.0.0.0/4はまだありますが、まだ割り当てられておらず、RFCドラフトは再配布を参照しています。 たぶん、このrfcのドラフトが公式文書のステータスを取得すると、何かが変わるかもしれませんが、私は本当にそれを疑います。
それで、少し要約を要約します。 開発者は実際に何をしましたか。 彼らはプライベート範囲のアドレスを取得し、それらをすべてのグローバルにルーティングされるプレフィックスに付加することを提案しました。これにより、インターネット上のルーティングに使用できるアドレス（つまり白）の数が増えました。
しかし、良いアイデアが生まれます-IPv4ヘッダーのアドレスに64ビットが割り当てられているため、標準のIPv4ヘッダーをアップグレードせずに開発者のアイデアを実装する方法（ソースIPには32、宛先IPには32）：
タイトルを変更すると、IPv4は取得されず、新しく未知のものが取得されます。 この状況では、すぐにIPv6に切り替える方が簡単です。 しかし、開発者は、IPヘッダーの変更を必要としないことに加えて、プロバイダーからの大きな投資も必要としない方法を見つけました（ソフトウェアのアップグレードのみが必要です）。
IPv4ヘッダーにいくつかのオプションフィールドを追加できることを皆さんが知っていることを願っています。 EnIPでは、長さが12バイトのオプションフィールドがメインヘッダーの20バイトに追加されるため、長さが32バイトのこのようなヘッダーが取得されます。
図に示されているように、オプションフィールドには、アドレスの2つのフィールドが含まれます。これらは、拡張ソースアドレスと拡張宛先アドレスと呼ばれます。 あなたはすでに主要なアイデアを理解していると思います-アドレスは単一の64ビットアドレスとして提示されますが、実際にはそうではなく、ヘッダーのアドレスフィールドとオプションの拡張アドレスフィールドの2つのフィールドのヘッダーに配置されます。 この技術のメカニズムに直接進みます。
わかりやすくするために、次のトポロジを使用します。
ネットワークを2つのゾーンに分割することが条件的に可能です：プライベート範囲10.0.0.0/8からのプレフィックス（EIP1からN1、N2からEIP2）がルーティングに使用されるゾーンとグローバルに一意のプレフィックスが使用されるゾーン（N1からN2）。
次に、ノードからノードに転送するときにIPヘッダーのフィールドの値がどのように変化するかを見てみましょう。
EIP1ノードは、DNSサーバーから65.127.221.2.10.3.3.2という形式のEIP2ノードのアドレスを受け取ります。 （この技術におけるDNSの微妙な違いについては後述します）。 次に、EIP1ノードは、受信したアドレスを2つのアドレスに分割します。サイトアドレス（サイトアドレス）65.127.221.2（グローバルにルーティング可能である必要があります）とホストアドレス（ホストアドレス）10.3.3.2。 パケットを作成する場合、EIP1ノードは、ヘッダーの宛先アドレスフィールドのサイトアドレス（65.127.221.2）、オプションの拡張宛先アドレスフィールドのホストアドレス（10.3.3.2）、およびヘッダーのソースアドレスフィールドのアドレス（10.1.1.2）と干渉します）次の図に示すように：
図からわかるように、拡張ソースアドレスは指定されていません。 事実は、EIP1はこのアドレスを知らない（NATテクノロジーのように、ノードはグローバルな一意のアドレスを知らない）ため、RFCが規制するように、アドレスの代わりにすべてのユニット（255.255.255.255）を置き換えます。
EnIP送信元アドレスは現在存在しないため、EnIPヘッダーの拡張送信元アドレスはすべて1に設定されます。
また、オプションフィールドのESPおよびEDPフラグフィールドに注意する価値があります。 ESPで発生したフラグは拡張ソースアドレスを示し、EDPは拡張宛先アドレスを示します。
上記のヘッダーのオプションフィールドには、発信ノードの拡張アドレスがないため、ESPフラグは0に設定されています。
次に、上記のヘッダーを持つパケットはノードN1に送られます。 N1はヘッダーフィールドとオプションを分析し、ホストアドレス10.1.1.2をヘッダーからオプションに転送し、ソースアドレスの代わりに、グローバルにルーティング可能なIPv4アドレスをヘッダーに書き込み、両方の拡張アドレスが設定されているため、ESPフラグの値も1に変更します。 チェックサムを再計算し、適切なインターフェイスにパケットを送信します（変更されたフィールドは緑色で強調表示されます）。
発信アドレスを変更する必要があるのはなぜですか？ 実際、rfcによれば、オープンインターネット上でルーターがプライベートの発信アドレスまたはプライベートの宛先アドレスを持つパケットを受信した場合、このパケットを破棄する必要があります。 つまり、名前はプライベートアドレスであり、パッケージは単にグローバルネットワークに送信されません。 これは望ましくないため、ルーターはプライベートアドレスをグローバルにルーティング可能なアドレスに変更します
これで、パケットのヘッダーにはグローバルにルーティングされた宛先と送信元アドレスがヘッダーに含まれ、インターネット上で自由に送信できるようになり、オプションには最終ホストアドレスに関する情報が含まれます。
パケットを受信すると、ノードN2はヘッダーも分析します。 N2ノードはパケットが彼宛であることを確認したため、オプションの分析を開始し、ホストアドレス（10.3.3.2）をオプションからヘッダー宛先アドレスフィールドに移動し、オプションの拡張アドレスフィールドがリセットされます（このフィールドには意味がないため）。 ヘッダーが変更されたため、N2はヘッダーのチェックサムを再計算する必要があり、拡張宛先アドレスフィールドはアドレスではなくなったため、N2はEDPフラグもクリアする必要があります。
EIP2ノードは、パケットを受信すると、パケットがアドレス65.127.221.1.10.1.1.2（サイトアドレス65.127.221.1、ノード10.1.1.2のアドレス）から受信されたことを確認します。このアドレスを知っているEIP2は、EIP1ノードに応答メッセージを送信できます。
次に、EnIPテクノロジーの別の重要なリンクであるDNSサーバーに移りましょう。 説明されているテクノロジーを機能させるには、AAAAレコードを処理できるDNSサーバーが必要です。 基本的に、IPv6 DNSサーバーが必要です。
EIP1ホストは、mysite.ruなどのサイトのIPアドレスを決定する要求を行います。 このプロセスを以下に示します。
DNSサーバーは、データベースで要求されたサイトアドレスmysite.ruを見つけ、... IPv6アドレスの形式で情報を提供します。 なぜIPv6プレフィックスが必要なのですか?? 最初に、どのIPv6アドレスが予約されているかを覚えておく必要があります。 すべてを覚えているわけではありません。実験用に予約されていた2001：0101 ::プレフィックスが必要です。
DNSサーバーから受信した情報に戻ります。 リクエストに応えて、次のIPv6プレフィックスを受信しました：2001：0101：417F：DD02：0A03：0302 :: 0。 しかし、なぜそれが必要なのでしょうか？ 結果のプレフィックスを16進数システムから10進数に変換すると、この質問に答えることができます。
16進数システムから10進数への変換後、 417F：DD02：0A03：0302が65.127.221.2.10.3.3.2として表示されます 。 最初の2つのグループは予約済みプレフィックス2001：0101 ::であり、グループ7と8は常にゼロであるため、これらのプレフィックスグループが選択されています。
EIP1ノードは上記の操作を実行し、メッセージの送信に必要なアドレスを取得します。
これは、テクノロジーの簡単な概要で完了することができると思います。 質問があれば、尋ねてください、私はそれらに答えようとします。
記事の冒頭のリンクでRFCから取得した情報。 イラストは、参照によりプレゼンテーションから取得されます。