インターネットで最大の安全なUDPパケットサイズ

UDPパケットサイズに関する多くの記事を読みましたが、何が正しいかについて結論を出すことができませんでした。

多くのサービスは、最大のUDPパケットを512バイト（dnsなど）に制限します

インターネット上の最小MTUが576で、IPv4ヘッダーのサイズが20バイト、UDPヘッダーが8バイトであるとします。これにより、ユーザーデータ用に548バイトが使用可能になります

パケットを断片化せずに548サイズまでのパケットを使用できますか？または、DNSの作成者が知っていた何かがあり、それが彼らが512バイトに制限した理由です。

安全に548バイトを超えることもできますか？

典型的な IPv4ヘッダーが20バイトであり、UDPヘッダーが8バイトであることは事実です。ただし、IPヘッダーのサイズを60バイトまで増やすことができるIPオプションを含めることは可能です。さらに、パケットを宛先にルーティングするために、中間ノードがIPsec（VPNなどに使用される）などの別のプロトコルの内部でデータグラムをカプセル化する必要がある場合があります。そのため、特定のネットワークパスのMTUがわからない場合は、予想外の可能性がある他のヘッダー情報に妥当なマージンを残すことをお勧めします。512バイトのUDPペイロードは、それを行うと一般的に考えられていますが、それでも最大サイズのIPヘッダーに十分なスペースは残されません。

UDPパケットの最大サイズの理論上の制限（Windowsの場合）は65507バイトです。これはここに文書化されています：

正しい最大UDPメッセージサイズは65507で、次の式で決定されます。0xffff-（sizeof（IPヘッダー）+ sizeof（UDPヘッダー））= 65535-（20 + 8）= 65507

そうは言っても、ほとんどのプロトコルははるかに小さいサイズ（通常512または時々8192）に制限されます。信頼できるネットワーク上にある場合は、安全に548を超えることができますが、インターネット全体でブロードキャストしている場合、大きい行くほど、パケット伝送の問題と損失に遭遇する可能性が高くなります。

安全な最大UDPペイロードは508バイトです。これは576のパケットサイズから、最大60バイトのIPヘッダーと8バイトのUDPヘッダーを差し引いたものです。このサイズ以下のUDPペイロードは、IP経由での配信が保証されています（配信は保証されていません）。それより大きなものは、何らかの理由でルーターによって完全にドロップされることが許可されます。IPv6のみのルートを除き、最大ペイロードは1,212バイトです。他の人が述べたように、状況によっては追加のプロトコルヘッダーを追加できます。代わりに、約300〜400バイトのより保守的な値が推奨されます。

UDPパケットはフラグメント化される可能性があります。ただし、フラグメントを失うことは、フラグメント化されていないパケットを失うことと同じ効果があるため、これはそれほど重要ではありません。パケット全体がドロップされます。UDPでは、これはどちらの方法でも発生します。

興味深いことに、理論上の最大パケットサイズは約30 MB（1,500イーサネットMTU-60 IPヘッダーx 65,536フラグメントの最大数）ですが、通過する可能性はごくわずかです。

出典：RFC 791、RFC 2460

576は、最小再構成バッファーサイズの最小値です。つまり、各実装は、少なくともそのサイズのパケットを再構成できる必要があります。詳細については、IETF RFC 1122を参照してください。

この記事では、最大伝送ユニット（MTU）http://en.wikipedia.org/wiki/Maximum_transmission_unitについて説明します。IPホストはIPパケットに対して576バイトを処理できる必要があると述べています。ただし、最小値は68であると記載されています。RFC 791：「すべてのインターネットモジュールは、さらに断片化せずに68オクテットのデータグラムを転送できる必要があります。これは、インターネットヘッダーが最大60オクテットで、最小フラ​​グメントが8オクテットであるためです。 」

したがって、安全なパケットサイズ508 = 576-60（IPヘッダー）-8（udpヘッダー）が妥当です。

user607811で言及されているように、他のネットワーク層による断片化は再構成する必要があります。 https://tools.ietf.org/html/rfc1122#page-56 3.3.2再構成IP層は、IPデータグラムの再構成を実装する必要があります。EMTU_R（「受信する有効なMTU」）で再構成できる最大のデータグラムサイズを指定します。これは、「再構成バッファーサイズ」と呼ばれることもあります。EMTU_Rは576以上である必要があります

IPv4の最小再構成バッファーサイズは576、IPv6は1500です。ここからヘッダーサイズを差し引きます。参照してください。UNIXネットワークW.リチャードスティーヴンスによってプログラミング :)

512が最善の策です。それは他の場所で使用されており、素晴らしい偶数です（1024の半分）。

IPV6のサイズが1500であることを考えると、キャリアはIPV4とIPV6（どちらも異なるタイプのIP）に個別のパスを提供せず、それらを古い、冗長で、維持するのにコストがかかるipv4の機器に強制することを主張します信頼性が低くなります。それは意味がありません。その上、そうすることは、一部のトラフィックに優先的な扱いを提供することと容易に見なされる可能性があります-ノーノールールの下では、彼らはおそらくあまり気にしません（キャッチされない限り）。

したがって、1472は外部使用に対して安全である必要があります（これは、DNSのようなアプリがEDNSを認識しないことを受け入れるという意味ではありません）。内部ネットについて話している場合は、ネットワークレイアウトを知っている可能性が高くなります。ジャンボパケットサイズは、断片化されていないパケットに適用されるため、4096〜4068バイト、および9014バイトバッファを備えたインテルのカードの場合、パッケージサイズは...待機... 8086バイトで、最大...一致しますか？ スニッカー

****更新****

さまざまな回答は、1つのSWベンダーが許可する最大値、またはカプセル化を想定したさまざまな回答を提供します。ユーザーは、可能な最小値（安全なUDPサイズの「0」など）を要求するのではなく、最大の安全なパケットサイズを要求しました。

さまざまなレイヤーのカプセル化値を複数回含めることができます。いったんストリームをカプセル化したら-たとえば、その下のVPNレイヤーとその上のカプセル化レイヤーの完全な複製を禁止するものは何もありません。

質問は最大安全値に関するものだったので、受信可能なUDPパケットの最大安全値について話していると思います。UDPパケットは保証されていないため、UDPパケットを受信した場合、安全な最大サイズはIPv4上の1パケットまたは1472バイトになります。

注-IPv6を使用している場合、IPv6のヘッダーサイズは40バイトであるのに対し、IPv4の20バイトサイズと比較して、最大サイズは1452バイトです（UDPヘッダーには8バイトを許可する必要があります）。

ここでいくつかの良い答えを読みました。ただし、いくつかの小さな間違いがあります。UDPヘッダーのメッセージ長フィールドは最大65535（0xFFFF）であると回答した人もいます。これは技術的には真実です。実際の最大値は（65535-IPHL-UDPHL = 65507）であると回答した人もいます。間違いは、UDPヘッダーのメッセージ長フィールドに、すべてのペイロード（レイヤー5〜7）とUDPヘッダーの長さ（8バイト）が含まれていることです。つまり、メッセージ長フィールドが200バイト（0x00C8）の場合、ペイロードは実際には192バイト（0x00C0）になります。

難しくて速いのは、IPデータグラムの最大サイズが65535バイトであることです。この数は、L3およびL4ヘッダーとレイヤー5〜7ペイロードの合計に到達します。IPヘッダー+ UDPヘッダー+レイヤー5〜7 = 65535（最大）。

UDPデータグラムにはUDPヘッダーが含まれているため、UDPデータガムの最大サイズは65515バイト（0xFFEB）です。UDPペイロードにはUDPヘッダーが含まれていないため、UDPペイロードの最大サイズは65507バイトです。

私は混乱した反応を招くのではないかと心配していますが、それでも、私が間違っているかどうか、この質問を見て答えに興味があるかどうかを明確にするために：

https://tools.ietf.org/html/rfc1122についての私の理解ステータスが「公式仕様」、この質問で使用されている用語のリファレンスであり、別のRFCに取って代わられておらず、エラッタにも矛盾していません。以下：

理論的には、すなわち。記述された仕様に基づいて、https：//tools.ietf.org/html/rfc1122#section-4で指定されたUDP には「パケットサイズ」がありません。したがって、答えは「不明確」である可能性があります

実際には、これがこの質問で求められる可能性が高い（そして現在の技術に応じて更新できる）ので、これは異なる可能性があり、私にはわかりません。

私が動揺した場合、私は謝罪します。https://tools.ietf.org/html/rfc1122#page-8「インターネットプロトコルスイート」と「アーキテクチャの前提条件」では、聞いたことに基づいて、私が従った「前提条件」が明確にわかりません。層が分離されています。つまり。UDPが含まれているレイヤーは、IPが含まれているレイヤーに関係する必要はありません（IPレイヤーには、Reassembly、EMTU_R、Fragmentation、MMS_R（https://tools.ietf.org/html/rfc1122#page- 56））