8. ホスト断片化

パケット化層は、断片化を必要とするメッセージの送信を避けるべきです(SHOULD)[Kent87] [frag-errors]。しかし、断片化を完全に防ぐことは常に可能ではありません。カーネル外のUDPアプリケーションなどの一部のパケット化層は、送信するメッセージのサイズを変更できない場合があり、パスMTUを超えるデータグラムサイズになる可能性があります。

IPv4では、このようなアプリケーションがDFビットを設定せずにパケットを送信することを許可していました。DFビットが設定されていない超過サイズのパケットは、パケットよりも小さいMTUのリンクに遭遇したときに、ネットワークまたは送信ホストで断片化されます。場合によっては、段階的に小さいMTUのカスケードリンクがある場合、パケットが複数回断片化される可能性があります。このアプローチは推奨されません(NOT RECOMMENDED)。

IPv4実装は、IPv6機能を模倣する戦略を使用することが推奨されます(RECOMMENDED)。アプリケーションが有効パスMTUより大きいデータグラムを送信する場合、最初のリンクのMTUより小さい場合でも、ホストに直接接続された最初のリンクよりも、ホストIP層でパスMTUに断片化されるべきです(SHOULD)。DFビットは断片に設定されるべきであり(SHOULD)、ネットワークで再び断片化されません。この技術は、アプリケーションがIPv6で実装できない方法でIPv4断片化に依存する可能性を最小限に抑えます。少なくとも1つの主要なオペレーティングシステムがすでにこの戦略を使用しています。セクション9では、アプリケーションがプローブまたは診断目的で超過サイズのパケットを送信している場合のこの規則の例外について説明します。

PLPMTUDを実装していないプロトコルは、ICMPブラックホールによる問題の影響を受けるため、これらのプロトコルを任意のパスで機能する可能性が高い「安全な」MTU(例えば、1280バイト)に制限することが望ましい場合があります。PLPMTUDを実装する任意のプロトコルが、下位層でサポートされる完全な範囲で動作できるようにします。

IP断片化はデータをパケットに分割するため、最小限のパケット化層です。ただし、失われたパケットを検出するメカニズムがないため、PLPMTUDのネイティブ実装をサポートできません。断片化ベースのPLPMTUDには、セクション10.3で説明されているように補助プロトコルが必要です。