10. セキュリティに関する考慮事項

割り当てられたインターネットプロトコル番号 [IANA-PN]
ONC RPC ネットワーク識別子（netids）[IANA-NI]
関連するネットワーク層プロトコル識別子（NLPID）[IANA-NL]
プロトコルレジストリ [IANA-PR]

IANA は、これらの参照先が本書を指すよう更新した。

IPv6 は、パケットの基本形式および送信の観点から、IPv4 と類似したセキュリティ特性を持つ。これらのセキュリティ問題には、次が含まれる。

盗聴: 経路上の要素が、各 IPv6 データグラムの内容とメタデータを含むパケット全体を観測できる。
リプレイ: 攻撃者が通信路上のパケット列を記録し、元の受信者に再送する。
パケット挿入: 攻撃者が選択した属性を持つパケットを偽造してネットワークに注入する。
パケット削除: 攻撃者が通信路からパケットを削除する。
パケット変更: 攻撃者が通信路からパケットを取り除き、変更してからネットワークに再注入する。
中間者攻撃（MITM）: 攻撃者が通信ストリームを乗っ取り、受信者に対しては送信者として、送信者に対しては受信者として振る舞う。
サービス拒否攻撃（DoS）: 攻撃者が大量の正当なトラフィックを宛先に送信して過負荷にする。

IPv6 パケットは、「Security Architecture for the Internet Protocol」[RFC4301] を使用することで、盗聴、リプレイ、パケット挿入、パケット変更、および MITM 攻撃から保護できる。加えて、Transport Layer Security（TLS）や Secure Shell（SSH）などの上位層プロトコルを使用して、IPv6 上で動作するアプリケーション層トラフィックを保護できる。

DoS 攻撃から保護する機構は存在しない。この種の攻撃への防御は本仕様の範囲外である。

IPv6 アドレスは IPv4 アドレスより大幅に大きいため、インターネット全体や単一のネットワークリンク、たとえばローカルエリアネットワークにおいても、アドレス空間のスキャンは格段に困難になる。詳細は [RFC7707] を参照。

アドレス変換技術の使用が減るため、ノードの IPv6 アドレスは IPv4 と比べてインターネット上でより可視化されることが予想される。これにより、エンドポイントをより容易に区別できるなど、追加のプライバシー問題が生じる。詳細は [RFC7721] を参照。

IPv6 拡張ヘッダアーキテクチャの設計は大きな柔軟性をもたらす一方で、新たなセキュリティ上の課題も生む。後述のとおり、Fragment 拡張ヘッダに関する問題は解決された。しかし将来設計される新しい拡張ヘッダについては、セキュリティへの影響を徹底的に検討する必要があり、新しい拡張ヘッダが既存の拡張ヘッダとどのように動作するかも含めなければならない。詳細は [RFC7045] を参照。

この版の IPv6 仕様は、IPv6 仕様の旧版 [RFC2460] で見つかった多数のセキュリティ問題を解決する。これには次が含まれる。

フラグメントがデータグラム全体である場合、すなわち Fragment Offset フィールドと M フラグがともにゼロである場合を扱うよう、本文を改訂した。これを受信した場合、再構成済みパケットとして処理するべきである。これ以外に一致するフラグメントは個別に処理するべきである。フラグメント生成の処理は、データグラム全体を表すフラグメント（Fragment Offset フィールドと M フラグがともにゼロ）を生成しないよう変更された。詳細は [RFC6946] および [RFC8021] を参照。
Next-Hop MTU が 1280 未満であることを報告する ICMP Packet Too Big メッセージを受け取った場合に、送信パケットへ Fragment ヘッダを含めることを要求していた 5 節の段落を削除した。詳細は [RFC6946] を参照。
IPv6 ノードが重複するフラグメントを作成してはならないことを要求するよう、本文を変更した。また、IPv6 データグラムの再構成時に、その構成フラグメントの 1 つ以上が重複フラグメントであると判定された場合、データグラム全体とすべての構成フラグメントを黙って破棄しなければならない。重複フラグメントを受信した場合は ICMP エラーメッセージを送信しないことも明確化した。詳細は [RFC5722] を参照。
最初の上位層ヘッダまでのすべてのヘッダが最初のフラグメント内に存在することを要求するよう、本文を改訂した。詳細は [RFC7112] を参照。
[RFC5095] および [RFC5871] の更新を取り込み、Routing Header type 0（RH0）の説明を削除し、Routing Header の割り当て指針が RFC 5871 で規定されることを示し、必須拡張ヘッダの一覧から RH0 を削除した。

アドレッシング、ICMPv6、Path MTU Discovery など、IPv6 の他の部分に関するセキュリティ問題は、それぞれの仕様で扱われる。