اتفق الطرفان، لكن جسور Ethernet لم تشارك في الاتفاق

الخلاصة

• إعلان الطرفين دعمهما لحمولة PPP أكبر لا يتضمن تصريحاً من كل جسر Ethernet في الوسط بأنه يستطيع تمريرها.
• حد PPPoE التقليدي، وهو 1492 بايتاً، نتج من طرح ستة بايتات لترويسته وبايتين لمعرّف بروتوكول PPP من حمولة Ethernet البالغة 1500.
• فصل امتداد عام 2006 بين إعلان الإمكانية والتفاوض على الحجم واختبار تشغيلي قد يقيّد الإرسال إلى 1492 طوال الجلسة المعنية، إذا فشل الطلب الكبير ونجح الأصغر.

من غاب عن التفاوض؟

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

قد تكون جسور Ethernet بين الطرفين قد مررت رسائل التحكم الصغيرة من دون أن تتمكن من تمرير الإطارات الأكبر. هي ليست أطرافاً في تفاوض PPP. نجاح الرسائل التي مرت عبرها لا يحولها إلى جهات أعلنت قدرتها على حمل أحجام لم تختبرها تلك الرسائل.

هذه المسافة بين اتفاق النهايات وقدرة الوسط هي محور RFC 4638، المنشور في سبتمبر 2006. فالوثيقة لم تكتفِ بالسماح برقم أكبر، بل وضعت إعلان الدعم قبل تفاوض LCP، وأبقت مجالاً لاختبار الحجم بعد فتح الجلسة.

وهكذا صار من الممكن أن يكون التفاوض صحيحاً، وأن تبقى النتيجة التشغيلية أضيق منه. ليس في ذلك تناقض: كل خطوة تجيب عن سؤال مختلف، ولها أدلة لا توفرها الخطوة السابقة.

حساب لم يلغِه الامتداد

بدأت قاعدة الحجم في RFC 2516، الصادر في فبراير 1999. حمولة Ethernet القصوى البالغة 1500 بايت تستوعب ترويسة PPPoE من ستة بايتات ومعرّف بروتوكول PPP من بايتين. يتبقى 1492 بايتاً لحمولة PPP.

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

امتداد 2006 لم يحذف الترويسة ولا معرّف البروتوكول. لكي يحمل PPP مقدار 1500 بايت ضمن حساب الستة زائد اثنين، يجب أن تتسع حمولة Ethernet إلى 1508 بايتات. الحل يعتمد على أجهزة تستطيع حمل مساحة أكبر، لا على اتفاق يجعل المساحة القديمة أوسع.

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

البوابة ورثت ما كان الحاسوب يراه

لم يظهر الاحتياج إلى الامتداد من رغبة مجردة في تكبير الحزم. يصف RFC 4638 انتقالاً في موضع نهاية PPPoE. في الترتيب السابق الذي تناقشه الوثيقة، كان الحاسوب يبدأ الجلسة بنفسه عبر تجهيزات الوصول، وكان حد 1492 مقبولاً عادة في هذا النموذج.

عندما تولت البوابة المنزلية المهمة، صارت تستقبل IP عبر Ethernet من الشبكة المحلية، ثم تبدأ PPPoE باتجاه جهة الوصول عريض النطاق. يمكن أن تصل إليها من الداخل حزمة IP بطول 1500 بايت، بينما يسمح المقطع التقليدي التالي بحمولة PPP قدرها 1492.

لم تتغير كلفة التغليف، بل تغير من يواجه الفرق. منتج الحزمة داخل المنزل لم يعد المشارك المباشر في تفاوض PPP الذي يحدد حجم ذلك المقطع. انتقلت معالجة الحد إلى جهاز وسيط بين توقعين مختلفين.

تتناول الوثيقة أيضاً الانتقال من PPPoA إلى PPPoE، وتذكر تجهيزات عميل PPPoA كانت منشورة آنذاك ولا تستطيع دعم 1492. هذه شهادة عن سياق 2006، وليست إحصاء للأجهزة المستخدمة اليوم أو حكماً على جميع تطبيقات PPPoA.

ولم يكن ATM خالياً من قيود الحجم. فقد اشترط RFC 2364، في يوليو 1998، ألا تتجاوز MRU في PPP فوق AAL5 الحد الأقصى لـCPCS-SDU في عقد حركة الاتصال الافتراضي للاتجاه المعني. الهجرة بدلت القيد السفلي؛ لم تنقل PPP من عالم بلا حدود إلى عالم مقيد للمرة الأولى.

العثور على النظير ليس نهاية الإعداد

يقسم PPPoE العمل إلى اكتشاف ثم جلسة PPP. يرسل العميل PADI بالبث، ويتلقى عروض PADO، ثم يختار مركز الوصول ويرسل PADR، وتأتي PADS لتأكيد الجلسة. تسمح عناوين Ethernet ومعرّف الجلسة بربط التبادل اللاحق بالمشاركين المناسبين.

لكن انتهاء الاكتشاف لا يعني اكتمال كل مراحل PPP، ولا المصادقة عند الحاجة، ولا جاهزية خدمة IP. ولا يثبت أن أكبر حزمة متوقعة مرت بنجاح. رسائل التأسيس تؤسس السياق؛ لا تستوعب كل شروط تشغيله.

يضيف PPP-Max-Payload إعلاناً محدداً إلى هذه المرحلة. العميل الذي يريد تجاوز 1492 ملزم بإدراج الوسم في PADI وPADR معاً. والخادم القادر على دعم الامتداد، إذا تلقى الوسم، يعيده في PADO وPADS.

نوع الوسم هو 0x0120، أي 288 بالنظام العشري. قيمته الثنائية من بايتين، وتمثل أكبر حمولة PPP يدعمها العميل في الإرسال والاستقبال كليهما. الرقم 288 يحدد نوع المعلومة، ولا يعني أن الحمولة المسموحة 288 بايتاً. كما أن بايتي القيمة لا يصبحان ترويسة إضافية متكررة لكل حزمة في الجلسة.

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

ثلاث قيم لا ينبغي دمجها

الخادم يعيد وسم العميل، وليس مطلوباً منه أن يستبدل قيمته فوراً بأقصى حجم محلي يستطيع استخدامه. يظهر القيد المحلي لاحقاً عند تحديد مجال تفاوض MRU.

يبدأ الإجراء في RFC 4638 بسقف 1492. إذا وجد الوسم وكانت قيمته أعلى، يصبح السقف القابل للتفاوض هو الأصغر بين القيمة المعلنة وMTU الواجهة مطروحاً منها ثمانية. ثم يجري تفاوض LCP المعتاد داخل هذا المجال.

لهذا قد يرى المراقب قيمة مرتفعة معادة في PADO ثم قيمة أقل في نتيجة LCP. ليست الأولى وعداً نهائياً نقضته الثانية؛ الأولى تؤكد فهم الامتداد، والثانية تعكس ما تسمح به الشروط المحلية.

يعرّف RFC 1661، الصادر في يوليو 1994، MRU بوصفها أقصى وحدة استقبال لجزأي Information وPadding، من دون حقل البروتوكول والتأطير الخارجي. إعلانها لا يلزم الطرف الآخر بملء كل حزمة إلى الحد الأقصى.

القيمة الافتراضية في PPP العادي هي 1500، لكنها لا تمحو قيد PPPoE الخاص. وحتى إذا أعلن الوسم أكثر من 1500 في تبادل صالح للامتداد، فإن عدم التفاوض على MRU أكبر يترك القيمة الافتراضية العادية كما هي. القدرة المعلنة والسقف المحلي والاختيار الفعلي ليست اسماً واحداً لرقم واحد.

المقارنة التي تقيد الجلسة

بعد فتح الجلسة والتفاوض على MRU أعلى من 1492، ينبغي أن تتاح للمرسل إمكانية إرسال طلب LCP Echo أو أكثر بحجم MRU. إذا لم تصل ردود، يمكنه تكرار المحاولة بحجم 1492. وإذا تلقت الطلبات الأصغر ردوداً، فلا يجوز له الإرسال بأحجام تتجاوز 1492 في هذه الجلسة.

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

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

يشترط RFC 1661 حالة LCP Opened لتبادل Echo، ويربط الرد بالطلب عبر Identifier. لكنه لا يبرر الزعم بأن الرد دائماً مساوٍ للطلب في الحجم. لذلك لا تمنح جولة واحدة ناجحة شهادة دائمة بقدرة قصوى متناظرة في الاتجاهين. يجب الاحتفاظ بأحجام الرسائل الفعلية واتجاهاتها، لا بعلامة نجاح مجردة.

ما بعد جلسة الوصول

تبقى هناك مسألة أخرى: حجم المسار الموجه عبر Internet إلى الوجهة البعيدة. تناول RFC 1191، في نوفمبر 1990، اكتشاف MTU لمسار IPv4 باستخدام بت منع التجزئة ورسائل ICMP التي تفيد بأن الموجّه لا يستطيع تمرير الحزمة من دون تجزئتها.

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

اختبار PPPoE يخص الجلسة ومعالجة Ethernet في الوسط؛ لا يحل محل اكتشاف القيود في بقية طريق Internet. قد يحمل الوصول الحجم المطلوب بينما يظهر حد أصغر بعده. قيمة الاختبار المحلي تأتي من دقة نطاقه، لا من ادعاء أنه يصف كل طريق محتمل.

السجل ينسق المعنى ولا يغير العتاد

صدر RFC 4638 بوصفه وثيقة Informational، لا Internet Standard. والتحذير الذي أضافته IESG يرتبط بواقع المعايير في عام 2006 بشأن أحجام Ethernet التي تتجاوز 1500. لا يجوز عرضه كأنه وصف لحالة المعايير في 2026.

في يونيو 2007 نظم RFC 4937 تسجيل أنواع وسوم PPPoE ذات 16 بت لدى IANA، وأدرج PPP-Max-Payload تحت 288. ويحافظ سجل معاملات PPPoE لدى IANA الذي جرى الاطلاع عليه على هذه العلاقة.

يوحد الرمز طريقة قراءة الحقل بين تطبيقات مستقلة. لا يثبت أن شبكة محددة أصبحت تحمل إطارات أكبر، ولا يقدم تاريخاً لاعتماد شامل. تغليف 1999 وامتداد 2006 وترتيب التسجيل في 2007 أحداث مختلفة، لا لحظة ترقية واحدة.

بقيت ثمانية البايتات محتاجة إلى حيز حقيقي. ما تحسن هو توزيع الإثبات: الاكتشاف يدل على الفهم المشترك، وLCP يختار تحت قيود محلية، والملاحظة التشغيلية قد تضيق استخدام الجلسة. لم تشارك الجسور في الاتفاق، ولذلك لم يكن من حق الاتفاق أن يتكلم باسمها.