RFC 6864 - IPv4 IDフィールドの更新仕様
- ステータス: Proposed Standard
- 発行日: February 2013
- ストリーム: IETF
- 更新: RFC791, RFC1122, RFC2003
- エラッタ: エラッタなし
このメモのステータス
これはインターネット標準トラック文書です。
この文書はInternet Engineering Task Force (IETF)の成果物です。IETFコミュニティのコンセンサスを表しています。公開レビューを受け、Internet Engineering Steering Group (IESG)によって公開が承認されました。インターネット標準に関する詳細情報は、RFC 5741のセクション2で入手できます。
この文書の現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6864 で入手できます。
著作権表示
Copyright (c) 2013 IETF Trustおよび文書著者として特定された者。すべての権利を保有します。
この文書は、BCP 78およびIETF文書に関するIETF Trustの法的規定(http://trustee.ietf.org/license-info)の対象となり、この文書の公開日に有効です。この文書に関するあなたの権利と制限を説明しているため、これらの文書を注意深く確認してください。
概要
IPv4識別(ID)フィールドは、フラグメンテーションと再構成を可能にし、現在の仕様では、同じ送信元アドレス/宛先アドレス/プロトコルタプルを持つすべてのデータグラムに対して、最大生存時間内で一意である必要があります。しかし、現在の実装はこの仕様に従っておらず、IDフィールドを各データグラムの一意の値として扱っており、高速デバイスでIDフィールドの枯渇を引き起こす可能性があります。この文書は、RFC 791、RFC 1122、およびRFC 2003のIPv4 IDフィールドの仕様を更新して、現在の実践により近づけ、これらの変更がデータグラム設計者に与える影響について議論します。
目次
1. はじめに
2. IPv4 IDフィールド
3. IPv4 ID仕様の更新
4. 提案された変更の影響
5. 既存標準の更新
6. セキュリティに関する考慮事項
7. 参考文献
付録A. 重複検出可能性
付録B. 謝辞
公式ソース: IETF RFC 6864
1. はじめに
IPv4では、識別(ID)フィールドはデータグラムのフラグメンテーションと再構成をサポートするための16ビット値です。現在の仕様によると、IDフィールドは、同じ送信元アドレス、宛先アドレス、プロトコルを持つデータグラムに対して、最大セグメント生存時間(MSL)内で一意である必要があります。しかし、現在の実装はこの仕様に厳密に従っておらず、データグラムがフラグメント化されるかどうかに関係なく、各データグラムの一意の識別子としてIDフィールドを扱っています。
IPv4では、トランスポート層およびそれ以上のプロトコルは、TCPシーケンス番号やUDPチェックサムなど、通常16ビットまたは32ビットのフィールドを使用して重複データグラムを検出します。しかし、IPv4のIDフィールドは16ビットしかないため、高速ネットワーク環境では、IDフィールドが短時間で枯渇し、新しいデータグラムに一意のID値を割り当てることができなくなる可能性があります。
IPv6では、フラグメンテーションはソースノードによってのみ実行され、フラグメントヘッダーには32ビットの識別フィールドが含まれています。IPv6仕様では、この識別フィールドは、データグラムがフラグメント化される場合にのみ一意である必要があることが明確に述べられています。対照的に、IPv4のIDフィールドは、フラグメント化されているかどうかに関係なく、すべてのデータグラムに存在します。
本文書は、RFC 791、RFC 1122、およびRFC 2003のIPv4 IDフィールドの仕様を更新し、現在の実践に近づけ、IPv6の処理方法と一致させます。具体的には、本文書は以下の点を明確にします：
-
アトミックデータグラム: DFフラグ(Don't Fragment)が設定されているデータグラムの場合、IDフィールドは任意の値に設定でき、受信者はフィールドの値を無視する必要があります。
-
非アトミックデータグラム: DFフラグが設定されていないデータグラムの場合、IDフィールドは再構成タイムアウト期間中に一意である必要があり、フラグメントの正しい再構成を保証します。
-
互換性: 本文書は、これらの変更が既存のデバイスとプロトコルに与える影響について議論し、移行期間の推奨事項を提供します。
ナビゲーション:
2. IPv4 IDフィールド
IPv4識別(ID)フィールドは、元々データグラムのフラグメンテーションと再構成をサポートするために設計されました。RFC 791によると、IDフィールドは、同じ送信元アドレス、宛先アドレス、プロトコルを持つデータグラムに対して、最大セグメント生存時間(MSL)内で一意である必要があります。
2.1 フラグメンテーション用のIPv4 ID
IPv4 IDフィールドは、主にデータグラムのフラグメンテーションと再構成をサポートするために使用されます。高速ネットワーク環境では、16ビットのIDフィールドは急速に枯渇する可能性があります。
2.2 重複検出用のIPv4 ID
フラグメンテーションに加えて、IDフィールドは重複データグラムの検出にも使用できます。しかし、高速ネットワーク環境では、IDフィールドは急速に再利用される可能性があります。
2.3 IPv4 ID再構成問題の背景
高速ネットワーク環境では、16ビットの制限により、IDフィールドの枯渇、再構成エラー、パフォーマンスの低下が発生する可能性があります。
ナビゲーション:
3. IPv4 ID仕様の更新
この章では、高速ネットワーク環境でのID枯渇問題を解決するためのIPv4 IDフィールド仕様の更新について説明します。
3.1 アトミックデータグラムのIPv4 ID
アトミックデータグラム(DF=1)の場合、送信者はIDフィールドを任意の値に設定できます(MAY)、受信者はIDフィールドを無視しなければなりません(MUST)。
3.2 非アトミックデータグラムのIPv4 ID
非アトミックデータグラム(DF=0)の場合、送信者は再構成タイムアウト期間中にIDフィールドが一意であることを保証しなければなりません(MUST)。
ナビゲーション:
4. 提案された変更の影響
この章では、IPv4 IDフィールドの更新が既存のデバイス、データグラム生成、ヘッダー圧縮スキームに与える影響を分析します。
4.1 レガシーインターネットデバイスへの影響
レガシーデバイスは変更なしで動作を続けることができ、後方互換性が保証されます。
4.2 データグラム生成への影響
新しい送信者は、アトミックデータグラムに対して簡略化されたID生成アルゴリズムを使用でき、パフォーマンスが向上します。
4.3 ヘッダー圧縮スキームへの影響
ヘッダー圧縮スキームは、新しい仕様に適応するために調整が必要な場合があります。
ナビゲーション:
5. 既存標準の更新
この章では、RFC 791、RFC 1122、RFC 2003の具体的な更新について説明します。
5.1 RFC 791の更新
RFC 791は基本的なIPv4仕様です。このドキュメントは、アトミックデータグラムと非アトミックデータグラムを区別するためにIDフィールド仕様を更新します。
5.2 RFC 1122の更新
RFC 1122はインターネットホストの要件を定義します。更新には、アトミックデータグラムと非アトミックデータグラムの新しい動作が含まれます。
5.3 RFC 2003の更新
RFC 2003はIP-in-IPカプセル化を定義します。更新には、外部ヘッダーと内部ヘッダーのルールが含まれます。
ナビゲーション:
6. セキュリティに関する考慮事項
この章では、IPv4 IDフィールド更新のセキュリティへの影響について説明します。
6.1 プライバシーへの影響
IDフィールド生成戦略は送信者に関する情報を漏洩する可能性があります。対策には、ランダム値の使用とフローごとのカウンターが含まれます。
6.2 フラグメンテーション攻撃
IPv4フラグメンテーションは、さまざまな攻撃に悪用される可能性があります。対策には、アトミックデータグラムの使用とPath MTU Discoveryが含まれます。
6.3 ID衝突攻撃
攻撃者は限られたID容量を悪用しようとする可能性があります。対策には、ランダム化されたID生成とIPsecが含まれます。
6.4 サービス拒否攻撃
IPv4 IDフィールド処理はDoS攻撃の標的になる可能性があります。対策には、レート制限とリソース管理が含まれます。
ナビゲーション:
付録 A. 重複検出機能
この付録では、IPv4 IDフィールドが重複データグラムの検出において果たす役割と、更新が重複検出機能に与える影響について説明します。
A.1 重複検出の背景
重複データグラムは、リンク層再送信、ルーティングループ、負荷分散、悪意のある攻撃など、さまざまな理由で発生する可能性があります。
A.2 IPv4 IDの制限
16ビットのIDフィールドは、高速ネットワーク環境での重複検出メカニズムとして制限があります。
A.3 RFC 6864更新の影響
アトミックデータグラムの場合、IPv4 IDフィールドは重複検出機能を提供しなくなりました。
A.4 推奨されるメカニズム
推奨されるメカニズムには、TCPシーケンス番号、アプリケーション層メカニズム、IPsecが含まれます。
ナビゲーション:
付録 B. 謝辞
このドキュメントの著者は、貢献とサポートを提供してくれた以下の個人および組織に感謝します。
B.1 貢献者
このドキュメントの開発は、Fred Baker、Brian Carpenter、Wesley Eddy、Fernando Gontなど、IETFコミュニティの多くのメンバーの貢献から恩恵を受けました。
B.2 ワーキンググループの貢献
このドキュメントは、IETF INTAREA(Internet Area)ワーキンググループで広範囲に議論およびレビューされました。
B.3 実装経験
開発は、オペレーティングシステム(Linux、FreeBSD、Windows)、ネットワークデバイス、アプリケーションの実装経験を考慮しました。
B.4 歴史的背景
開発は、RFC 791(1981)、RFC 1122(1989)、RFC 4963(2007)などの歴史的ドキュメントに触発されました。
B.5 著者アドレス
Joe Touch
USC/ISI
4676 Admiralty Way
Marina del Rey, CA 90292
U.S.A.
ナビゲーション: