Web開発者はIPv4の終わりまでに心配する必要がありますか?それとも、これは厳密にホスティングレベルの懸念ですか?
平均的なPHP/JavaScript / Ajaxなどの開発者は、切り替えの影響を軽減するために何ができますか?
議論!
(これが謝罪する前に出てきたが、私の検索では何も明らかにならなかった場合)
Web開発者はIPv4の終わりまでに心配する必要がありますか?それとも、これは厳密にホスティングレベルの懸念ですか?
平均的なPHP/JavaScript / Ajaxなどの開発者は、切り替えの影響を軽減するために何ができますか?
議論!
(これが謝罪する前に出てきたが、私の検索では何も明らかにならなかった場合)
サーバー側では、リモートIPアドレスの形式について推測していないことを確認してください。ポスターのIPアドレスを単一の32ビットデータベースフィールドにパックするようなハッキングはお勧めできません。禁止などにサブネットマスクを使用している場合は、それも変更する必要があります。
また、IPアドレスのフィールドを検証するときは、両方の形式(152.115.4.70および2001:db8:1f70 :: 999:de8:7648:6e8)を考慮することを忘れないでください。
IP アドレスを扱う場所はどこでも、IPv6 がクリーンかどうかを確認するために監査する必要があります。単純な Web アプリケーションは IP アドレスを保存する必要はありませんが、多くの場合、悪用の追跡/制御のために保存されます。IPv6 アドレスは ipv4 アドレスより大きく、テキスト表現は異なる記号を使用します。
状況によっては、IPv4 接続を IPv6 ソケットで処理できます。この場合、保存/比較する前に通常の IPv4 アドレスに戻す必要がある「IPv4 マップ アドレス」が表示されることがあります (Web サーバーなどの下位レベルのプロセスがこの変換を処理する場合と処理しない場合があります)。
虐待者への対処には、ある程度の考慮が必要な場合があります。単一のアドレスを禁止することはおそらく無駄です。効果的な禁止のために、さまざまな異なるプレフィックス長に基づいて禁止する機能が必要になります。乱用者の使用パターンをブロックにマッピングする機能も必要になる場合があります。同様の問題が、ユーザーごとの接続数の制限にも当てはまります。
IPv4 の危機が深刻化するにつれて、v6 のみのオリジン サーバー間で限定されたパブリック IPv4 アドレスのプールを共有するリバース プロキシ設定の使用が増える可能性があります。したがって、リバース プロキシを使用できるようにソフトウェアを準備することは賢明な選択です。これは通常、x-forwarded-for ヘッダーを受け入れる信頼できるリバース プロキシのリストを持つことを意味します。
実際、IPv4 が終了することはないと思います。私の意見です。Netorking アプリは、IPv4/6 と互換性があるように作成する必要があります。一部の API は、これを非常に簡単にします。