الخلاصة

  • غطى مجموع IPv4 الاختباري الرأس وحده. يتحقق الموجّه من النسخة الواردة، ويخفض TTL أو يعدّل الحقول المسموح بها، ثم ينتج قيمة جديدة للرأس المعدّل من دون أن يضمن الحمولة.
  • أدخل TCP وUDP رأس النقل وبياناته ورأساً زائفاً يحوي حقائق IP مختارة في الحساب. ساعد ذلك على كشف بعض التسليم الخاطئ، لكنه لم يوثّق المرسل أو ملكية العنوان أو شرعية الطريق.
  • للحساب بالمتمم الأحادي صفر موجب وآخر سالب. أمكن لطريقة RFC 1141 أن تنتج 0xFFFF حين تعطي إعادة الحساب الكاملة 0x0000؛ فصحح RFC 1624 الحد. وأزال IPv6 المجموع من رأسه الأساسي من دون إسقاط مسؤولية الطبقات العليا.

رأس يتغير وهو يسافر

لا يبقى رأس IPv4 ثابتاً. تنقص قيمة Time to Live عند كل نقطة معالجة بمقدار واحد على الأقل. وقد يغير التجزؤ الطول والأعلام والإزاحة، كما تستطيع بعض الخيارات تعديل الرأس.

عرّف RFC 791 Header Checksum بوصفه المتمم الأحادي لمجموع كلمات الرأس ذات 16 بت بالمتمم الأحادي، مع اعتبار حقل المجموع صفراً أثناء الحساب. والتغطية للرأس وحده.

يفحص الموجّه الحالة الواصلة، ويرمي الرزمة إن فشل الفحص، وينفذ تعديله المشروع، ثم يكتب قيمة تلائم الرأس الجديد. ليست القيمة ختماً دائماً وضعه المصدر، بل قولاً محلياً عن نسخة بعينها بين نقطتي معالجة.

ويحدد RFC ما لا يقدمه IP: لا تحكم في أخطاء البيانات، ولا إقرارات ولا إعادة إرسال. نجاح رأس IPv4 لا يقول إن الحمولة سليمة. تحمي العملية المعلومات التي تحتاجها طبقة الإنترنت للعمل فقط.

حدود متعددة داخل الرزمة

يجمع IPv4 رأسه. ويجعل RFC 768 UDP يجمع رأس UDP والبيانات ورأساً زائفاً. ويغطي RFC 793 رأس TCP ونصه مع رأس زائف طوله 96 بتاً.

يفصل ذلك الحقول المتغيرة في الطريق عن حساب النقل بين الطرفين. يحدّث الموجّه IPv4، ويبقى TCP أو UDP من مسؤولية الطرفين. وقد تضيف طبقة الوصلة فحصاً لإطار واحد لا يتجاوز صلاحيته ذلك الجوار.

لا تتحول نجاحات متعددة إلى شهادة شاملة. لكل نتيجة مادة مشمولة ومنتج وعمر. ولا تستنتج أي منها وحدها هوية مؤسسة أو سياسة طريق أو تاريخ الرزمة الكامل.

رأس زائف لا يرسل

يدخل UDP عنوان المصدر والوجهة والبروتوكول وطول UDP في الحساب. ويفعل TCP الشيء نفسه مع طوله. لا يظهر هذا الرأس ككتلة مستقلة على السلك؛ يعيد المستقبِل بناءه من IP.

يقول RFC 768 وRFC 793 إن الغرض حماية من الرزم أو القطع الموجهة خطأ. فلا ينبغي لبايتات TCP السليمة أن تمر بسهولة إذا وصلت تحت وجهة أو بروتوكول مختلف.

لكن الربط ليس مصادقة. من ينشئ الرزمة يستطيع حساب القيمة، ومن يغيّر الحقول عمداً يستطيع إعادة حسابها. لا يثبت الرأس الزائف صاحب العنوان، أو دقة سجل، أو صلاحية مسار، أو غياب الاعتراض.

تستعير طبقة النقل الحقائق التي تعتمد عليها من دون أن تكتسب سلطة على التوجيه أو الملكية.

لماذا احتاج UDP إلى صفرين

في المتمم الأحادي يمثل 0x0000 الصفر الموجب، ويمثل 0xFFFF الصفر السالب. منح RFC 768 النمطين معنيين مختلفين. إذا أعطى حساب UDP صفراً، يرسل الحقل كله آحاداً. أما الحقل المرسل كله أصفاراً فيعني أن المرسل لم يولّد مجموعاً اختبارياً.

إذن قد يكون 0xFFFF نتيجة تحقق صحيحة، فيما يشير 0x0000 في عقد UDP على IPv4 إلى حذف الفحص. يفصل البروتوكول بين «حُسب وكانت النتيجة صفراً» و«لم يُحسب».

ضيّق RFC 8200 الباب في IPv6. صار مجموع UDP إلزامياً افتراضياً؛ يتحول الصفر إلى 0xFFFF، وعلى المستقبِل رمي الحقل الصفري. توجد حالة استثنائية محدودة لبعض أنفاق UDP بشروط إضافية، لا إعفاء عام.

حرية التنفيذ مع جواب واحد

جمع RFC 1071 خصائص تسمح بتسريع الحساب. إذا حُفظ ترتيب البايتات الزوجي والفردي، يكون الجمع تبديلياً وترابطياً؛ يمكن تقسيم الذاكرة وجمع النتائج الجزئية. ويجوز الحساب بأي ترتيب للبايتات، وبمراكم أوسع أو حلقات مفكوكة أو عمل متواز. وإذا بقي بايت منفرد يضاف صفر للحساب ولا يرسل.

يثبت البروتوكول مجال التغطية والبتات النهائية، لا برنامجاً واحداً لكل آلة. تنتهي حرية التنفيذ عندما يتغير ازدواج البايتات أو الالتفاف بالحمل أو البايت الأخير فينتج جواب مختلف.

كلفة بحجم التعديل

عندما يخفض الموجّه TTL فهو يعرف الكلمة التي تغيرت. يشرح RFC 1141 إزالة مساهمة القيمة القديمة وإضافة الجديدة بدلاً من جمع الرأس كاملاً. ويعني خفض TTL واحداً إضافة 1 أو 256 إلى الحقل المخزن بحسب موضع البايت، بجمع المتمم الأحادي.

يذكر RFC 1624 أيضاً التجزؤ وتعديل source route. يناسب العمل حجم التغيير، لكن صحته تتطلب التطابق مع إعادة حساب الرأس كله في كل حالة.

معادلة عبرت إلى الصفر الخطأ

وثق RFC 1624 أن صيغة RFC 1141 افترضت ضمنياً خاصية توزيع لا تصح عندما تكون النتيجة صفراً. في مثاله تتغير كلمة من 0x5555 إلى 0x3285، ومجموع بقية الرأس 0xCD7A. تعطي إعادة الحساب 0x0000، وتعطي الطريقة القديمة 0xFFFF.

لا يتبادل النمطان بحرية في رأس IPv4. يوجد في الرأس حقل غير صفري واحد على الأقل. يستطيع جمع مدخلات غير صفرية بالمتمم الأحادي إنتاج الصفر السالب لا الموجب؛ وبعد أخذ المتمم النهائي يمكن للحقل أن يكون 0x0000، ولا يكون 0xFFFF نتيجة معيارية.

الصيغة المصححة هي HC' = ~(~HC + ~m + m') مع إجراء كل جمع بالمتمم الأحادي. تتجنب خطوة التوزيع غير الصالحة وتساوي المرجع الكامل.

أخفى بعض المستقبلات الفرق. فمن أضاف الحقل الوارد إلى المجموع وقارنه بالصفر السالب وفق RFC 1071 أمكنه قبول الشكلين في المثال. وأعادت تطبيقات أخرى الحساب وقارنت القيمة مباشرة. كشفت اختبارات منتج الحالة، وثبتها التحليل والمحاكاة.

لا تجعل سماحة مستقبِل معين خرجاً غير معياري صحيحاً. يجب على المنتج إرسال التمثيل الذي تعرفه جميع طرق التحقق.

نقل IPv6 موضع المسؤولية

لا يحتوي رأس IPv6 الأساسي في RFC 8200 على مجموع اختباري لطبقة الإنترنت. لكن TCP وUDP وICMPv6 تستخدم رأساً زائفاً يضم عنواني IPv6 بطول 128 بتاً، وطول الطبقة العليا، وقيمة Next Header.

يوضح RFC أن ICMPv6 يضم هذه الحقائق لأن حقول IPv6 التي يعتمد عليها لا يغطيها مجموع طبقة الإنترنت كما في IPv4. لم تختف المسؤولية؛ انتقلت إلى البروتوكول الذي يستهلك الحقول.

ألزم IPv4 كل موجّه بفحص قول صغير وتجديده، غالباً إلى جانب فحوص الوصلة والنقل. أزال IPv6 التكرار من الرأس الثابت، وأبقى فحوص الطرفين، وأغلق حذف UDP افتراضياً.

المصادر وحدود المعرفة

يؤسس RFC 768 لـUDP والصفرين؛ وRFC 791 لـIPv4؛ وRFC 793 لـTCP؛ وRFC 1071 لخصائص التنفيذ؛ وRFC 1141 للتحديث؛ وRFC 1624 للإصلاح؛ وRFC 8200 لحد IPv6.

لا تثبت هذه النصوص مخترعاً وحيداً أو تنفيذاً موحداً أو انتشار offload اليوم أو نسبة محددة للأخطاء غير المكتشفة. النجاح لا يستبعد تعديلاً مقصوداً أعقبه حساب جديد، والفشل لا يحدد وحده جهازاً أو شخصاً.

الثابت أضيق: حين حددت الإنترنت البايتات والمنتج ونهاية الصلاحية، جعلت تناقضات كثيرة مرئية بثمن قليل من دون أن تمنح المجموع سلطة عامة.