التحذير الذي وصل إلى الخادم الخطأ: تاريخ اكتشاف MTU المسار

الخلاصة

• جعل RFC 1191 مصدر IPv4 يضبط Don't Fragment، وجعل router الذي يواجه وصلة أصغر يعيد next-hop MTU في رسالة ICMP. كان المسار يلاحظ القيد، بينما يحتفظ endpoint بالتقدير ويقرر كيف يصغّر الحزمة.
• وثّق RFC 2923 حالة PMTUD black hole: قد ينجح TCP handshake والحزم الصغيرة، ثم تتوقف الجلسة عند ظهور segment أكبر إذا اختفت رسالة ICMP. أما MSS فليس قياساً كاملاً للمسار.
• في واقعة Cloudflare عام 2015 استُخدم hash مختلف لـTCP وICMP، فوصل دليل التحكم إلى شبكة المشغل لكنه أخطأ backend الذي يحمل حالة الاتصال.
• أعاد PLPMTUD وDPLPMTUD قدراً من القرار إلى endpoint عبر probes وتأكيد التسليم. لكن تقليل الاعتماد على ICMP نقل إليه كلفة traffic وstate والتمييز بين حد MTU وأسباب الفقد الأخرى.

وصلت الرسالة إلى المؤسسة وفقدت صاحبها

كانت Cloudflare قد وسّعت استخدام Equal-Cost Multi-Path routing داخل شبكتها. بالنسبة إلى TCP، يحسب router hash من عناوين ومنافذ المصدر والوجهة، فتعود packets التابعة للاتصال نفسه إلى backend نفسه.

تقول رواية المشغل إن ICMP كان يُوزّع باستخدام عنواني المصدر والوجهة فقط. لذلك كان Packet Too Big قد يصل إلى خادم آخر فيما يبقى TCP flow في مكانه الصحيح. وكتبت Cloudflare أن هذا بالضبط ما حدث في حالتها.

ذكر postmortem عدداً قليلاً من مستخدمي IPv6 tunnels. لا يكفي ذلك لقياس انتشار عالمي أو لإثبات ضرر أو ذنب طرف ثالث. لكنه يثبت آلية محددة: قد تتلقى المؤسسة control evidence من المسار من دون أن يصل إلى state الذي يمنحه معنى عملياً.

خفضت الشركة مؤقتاً IPv6 MTU إلى 1280، وفعّلت probing الموصوف في RFC 4821 لـIPv4. ثم أنشأت daemon يلتقط IPv4 fragmentation-needed وIPv6 Packet Too Big، ويبثهما عبر Ethernet إلى جميع backends.

حدد repository افتراضياً packet واحداً في الثانية من source واحد، وعشرة packets في الثانية على interface واحد. نشر الدليل عالج تعارض ملكية state، لكنه خلق سطحاً جديداً للتحقق والسعة وسوء الاستخدام. كان حلاً لبنية Cloudflare، لا وصفة عامة لكل شبكة.

قبل الاكتشاف كان الاختيار بين الصغر والتجزئة

عرّف RFC 1191 في 1990 Path MTU بأنه أصغر MTU بين hops من source إلى destination. القيمة تخص مساراً مقدّراً، وليست صفة دائمة لعنوان أو prefix. يمكن لتغيير route أو إضافة tunnel أن يغير الحد من دون تغيير الطرفين.

كانت ممارسة أقدم تختار الأصغر بين 576 octets وMTU أول hop. هذا حذر مع المسار المجهول، لكنه يرسل packets أصغر من اللازم في المسارات الأوسع. وإذا ظهرت وصلة أضيق لاحقاً، بقي IPv4 router مضطراً إلى fragmentation.

تنقل fragmentation العمل إلى داخل الشبكة. يقسم router الـdatagram، ويعيد destination جمع fragments؛ وفقد جزء واحد قد يبطل الأصل كله. أضاف RFC 8900 لاحقاً مشكلات stateful middleboxes وfilters وtunnels والمسارات غير المتساوية.

لم يكن قرار 1990 بين تقنية مثالية وأخرى غير منطقية. كانت الخيارات هي الإرسال الصغير دائماً، أو السماح للـrouters بالتجزئة، أو طلب إشارة صريحة من المسار، أو المزج بينها. اختار RFC 1191 feedback كي يقترب من السعة الفعلية من دون جعل fragmentation الروتينية هي الافتراض.

عرف router حقيقة محلية واحتفظ endpoint بقرار الاستجابة

في IPv4 PMTUD الكلاسيكي يضبط source علامة Don't Fragment. إذا عجز router عن تمرير datagram على next hop من دون fragmentation، يتخلص منه ويرسل ICMP Destination Unreachable مع code الخاص بـfragmentation needed.

يشترط RFC 1191 أن تحمل الرسالة next-hop MTU. يخفض host تقديره، ويمكنه إرسال packets أصغر أو إيقاف DF. لا تمنح الرسالة router سلطة اختيار transport policy نيابة عن الطرف.

هنا ظهرت التبعية المؤسسية. لدى router ملاحظة مباشرة لواجهة واحدة. ولدى endpoint خوارزمية packetization. لا يملك أي منهما control surface الآخر؛ لذلك كانت ICMP الجسر بين evidence وcorrective power.

أما زيادة الحجم فلا تأتي من رسالة ICMP تدّعي قيمة أكبر. يجب على endpoint أن يختبر لاحقاً بنفسه. أوصى RFC 1191 بالانتظار خمس دقائق على الأقل بعد الخفض، وفضّل عشر دقائق، قبل probe إلى أعلى.

هذه إرشادات تاريخية وليست قياساً لكل stacks الحالية. لكنها ترسم حدود الدليل: routes تتغير، والرسائل قد تكون قديمة أو مزورة، والملاحظة المحلية لا تصبح إذناً دائماً.

أزال IPv6 تجزئة routers ولم يلغِ الحاجة إلى التعلم

تفرض مواصفة IPv6 الأساسية الحالية أن تحمل كل link مقدار 1280 octets أو توفر fragmentation وreassembly تحت IP. لا تقوم IPv6 routers بتجزئة packet أثناء العبور؛ وحده source يستطيع إضافة Fragment header.

يوصي RFC 8200 بقوة باستخدام PMTUD لاستعمال أحجام فوق 1280. ويمكن لـminimal implementation ألا ترسل أكثر من 1280. هذا خروج مشروع من full discovery، لكنه يضحّي بالكفاءة في المسارات الأوسع ولا يثبت أن MTU كل مسار يساوي 1280.

وفق RFC 8201 يرسل router المقيِّد ICMPv6 Packet Too Big. على endpoint التحقق من أن packet المقتبس ينتمي فعلاً إلى traffic أرسله. تخفض الرسالة الصالحة التقدير، ولكن ليس تحت الحد الأدنى 1280.

لا يجوز أن ترفع PTB التقدير. بعد الخفض يمكن لـsource أن probe إلى أعلى على فترات لا تقل عن خمس دقائق، والأفضل عشر. يبلغ router قيداً محلياً؛ ويتحقق endpoint من context ويحتفظ بالقرار.

يصنف RFC 4890 Packet Too Big ضمن رسائل ICMPv6 التي يجب ألا يسقطها firewall لأن الاتصال قد يُمنع أو يتضرر بشدة. هذه توصية تشغيلية واضحة، وليست دليلاً على الامتثال الشامل أو أمراً بتمرير كل ICMP بلا تحقق.

أخفى black hole التفسير ولم يزل القيد

وصف RFC 2923 في عام 2000 مشكلة قديمة. كان router أو kernel fault أو configuration أو firewall يمنع ICMP error من العودة، فيستمر source في إرسال حجم لا يستطيع المسار حمله.

جعل TCP العطل يبدو نجاحاً جزئياً. يمكن أن يمر handshake الصغير، ثم تمر البيانات الأولى. وعندما يظهر segment أكبر يسقط، وتعيد retransmissions الحجم نفسه. في مثال FTP يعمل control connection صغير وتتوقف bulk transfer.

هذا pattern سبب للتحقيق، لا حكم نهائي. congestion أو corruption أو asymmetric policy قد تنتج فقداً شبيهاً. يحتاج الإثبات إلى packet size وIP family وDF أو Fragment وسجل retransmission ومحتوى أي ICMP مقتبس.

لا يحل TCP MSS المشكلة. فهو يعلن أكبر TCP payload يقبله receiver، ولا يرى كل tunnel في المسار الأمامي، ولا يثبت أن مسار العودة متماثل.

فضّل RFC 2923 إصلاح ICMP black hole. ويمكن لاكتشاف محلي أن يصغّر packet بعد timeouts. قد يعيد ذلك session، لكنه يضيف ثواني ويخفي path defect ما زال يؤثر في flows أخرى.

سلطة filter المحلية لا تصادق على قدرة المسار

قد يملك operator سلطة مشروعة لوضع firewall policy في شبكته. لا تسمح المصادر باتهام actor بعينه بالشر أو عدم المشروعية أو دافع خاص غير مثبت.

الحد القابل للتحقق مختلف. إسقاط Packet Too Big لا يجعل packet الأصلية قابلة للتمرير. إنه يزيل evidence ويبقي constraint. يملك filter عملياً veto على adaptation، لكنه لا يكتسب معرفة router أو مسؤولية endpoint.

تضيف tunnels headers بعد أن يختار endpoint الحجم. وقد يفصل ECMP أو anycast بين instance التي تستقبل data وتلك التي تستقبل error. رقم MTU بلا time وdirection وflow وencapsulation ليس خاصية دائمة لـaddress block.

هذا مهم لحامل number resources. يخصص RIR العناوين، لكنه لا يصادق على end-to-end MTU لكل route إلى الحامل. يمكن أن يبقى ASN وprefix وservice IP كما هو، فيما يكسر تغيير تشغيلي packets الكبيرة فقط.

حوّل PLPMTUD الصمت إلى تجربة

عرّف RFC 4821 في 2007 Packetization Layer PMTUD. ترسل الطبقة التي تصنع packets probes بأحجام متزايدة، وتتعلم من delivery أو loss، من دون اشتراط وصول ICMP.

يستعيد endpoint مخرجاً، لا يقيناً. قد يشير فقد probe كبيرة منفردة إلى تجاوز الحد. وإذا فقدت packets أخرى قريبة، تجعل congestion أو أسباب أخرى النتيجة غير حاسمة. لذلك يلزم search state وtimers وإعادة اختبار حذرة.

سجلت charter الخاصة بـIETF PMTUD Working Group ضعف الطريقة السابقة بوصفه عائقاً مزمناً أمام links وtunnels جديدة. وكان اتجاه العمل البدء صغيراً ثم probe إلى أعلى بلا اعتماد على ICMP. تثبت charter scope مؤسسياً، لا consensus أو deployment عالمياً.

وسع RFC 8899 المبدأ إلى Datagram Packetization Layers. يختبر DPLPMTUD أحجاماً، ويرفع confirmed value بعد delivery confirmation، ويخفضه عند اكتشاف black hole. يمكن الاستفادة من PTB متحقق منها، لكن لا الاعتماد عليها وحدها ولا استخدامها للرفع.

لا يوفر UDP acknowledgement بنفسه. يجب على application أو packetization layer تأكيد probe. مع انتقال القرار إلى endpoint تنتقل أيضاً كلفة traffic وstate وتفسير loss.

النتيجة الحديثة تعايش وليست إحلالاً كاملاً

توصي مواصفة TCP الحالية بقوة بـPMTUD، وتوصي كذلك بـPLPMTUD. تبقى fallback sizes الصغيرة، بينما يحذر RFC 9293 من كلفتها على performance. لم يلغِ probing إشارة router، بل أضاف مخرجاً عند غيابها.

تعرض Linux documentation الحالية خيارات واضحة. tcp_mtu_probing=0 يعطل probing؛ mode 1 يفعله بعد اكتشاف ICMP black hole؛ وmode 2 يبقيه مفعلاً انطلاقاً من base MSS. القيمة الافتراضية الموثقة لفاصل probe هي عشر دقائق.

هذه product controls وليست إحصاءً عالمياً. يشكل وجود firewalls وtunnels وkernels وtransports وapplications من أجيال مختلفة آلية lock-in.

لذلك لم يعلن RFC 8900 إلغاء fragmentation. وثق هشاشتها وطلب من upper layers تقليل الاعتماد. بقي مزيج من explicit signal وvalidation وendpoint probing وconservative fallback.