IPv4とIPv6は本質的に互換性がないことを理解しています。IPv4クライアントはIPv6を使用してWebサイトにアクセスできますか?また、IPv6クライアントはIPv4 Webサイトにアクセスできますか?
ある種の移行メカニズムがないと、ipv4のみのクライアントはipv6のみのサーバーと通信できません。その逆も同様です。
元々のアイデアは、全世界が「シングルスタックipv4」から「デュアルスタック」に移行するというものでした。次に、全員がデュアルスタックになったら、IPv4をオフにして、「シングルスタックipv6」に移行し始めることができます。
しかし、それは実現しませんでした。ネットワークオペレーターは、IPv6とIANAを展開するというプレッシャーをほとんど感じておらず、ほとんどのRIRはIPv4アドレスを使い果たしています。そのため、IPv4が豊富にある時代は終わりましたが、v4のみのクライアントとサーバーはまだたくさんあるという状況に陥りました。
さまざまな移行メカニズムが出現しました。含む:
- 6to4やteredoのような「自動トンネリング」と、固定エンドポイントへの構成済みトンネルの両方のトンネリングメカニズム。これらにより、v4専用ネットワーク上のv6対応ホストがv6専用サービスに接続できるようになります。ただし、他の人のネットワーク上のマシンで有効になっているかどうかを制御できないため、あまり役に立ちません。
- NAT64、ステートレス(1:1)とステートフル(1:many)の両方。これにより、管理者はv6のみのネットワークを実行し、インターネット上のv4のみのマシンと対話することができます。これはクライアントにとっては合理的なソリューションですが、サーバーの場合は、サーバーごとに専用のipv4アドレスが必要であるため、アドレス枯渇の問題は実際には解決されません。
- リバースプロキシ。これらはアプリケーションレベルのデータを参照できるため、上位レベルのプロトコルがホスト名を示す場合(たとえば、ホストヘッダーを使用したHTTP、SNIを使用したTLS)、プロキシは単一のパブリックIPv4アドレスと直接要求をリッスンできます。複数の内部サーバーに。
それらのどれもがすべての問題を解決するわけではなく、それらのいくつかは独自の問題を作成しますが、それらを組み合わせて使用すると、他の世界と通信するための比較的少数のIPv4アドレスのみでv6のみの内部ネットワークを実行できます。
Spring MVC Webサイトの訪問者のIPアドレスを次のように確認します。....これまでのところ、これは常にabcd形式のIPv4アドレスを返しています。IPv6を使用するクライアントが私のWebサイトに接続すると、これは変更されますか?または、Webサイトの設定によっては、さまざまなトンネリング技術によってIPv6クライアントがIPv4クライアントになりすますことがありますか?
サーバーがipv6接続を直接受け入れる場合、明らかにipv6アドレスが表示されます。
サーバーが「::」のソケットを使用してipv4接続とipv6接続の両方をリッスンする場合(Linuxはデフォルトでこれを有効にし、Windowsはそれを有効にするために特定のソケットオプションを必要とします)、ipv4アドレスはソケットを「」として使用してアプリケーションに渡されます。 ipv4マップアドレス」。あなたが使用するライブラリは、これをあなたから隠すかもしれないし、しないかもしれません(私は春のMVCが何をするのかよく知りません)。
nat64またはプロキシからの接続を受け入れる場合は、明らかにnat/proxyのアドレスが表示されます。プロキシの場合、プロキシから送信された情報からクライアントの実際のIPアドレスを判別できる場合があります。
IPアドレスの取得と処理に関して、私が直面する可能性のある他のIPv6の問題はありますか?
IPv4アドレスを32ビット整数または長さ制限の短い文字列として格納/送信する場所では、手直しが必要になる可能性があります。
テストネットワークを設定して、このようなものを試してみることを強くお勧めします。