الخلاصة

  • يسمح RFC 8950 بإعلان قابلية وصول IPv4 وVPN-IPv4 بواسطة next hop من IPv6. ولا يثبت capability code 5 إلا دعماً لثلاثية محددة من NLRI AFI وNLRI SAFI وnext-hop AFI؛ فلا يفعّل عائلة العناوين ولا يثبت أن next hop قابل للوصول.
  • يستنتج المستقبِل نوع next hop من الطول المشفّر. ويجب على route reflector إبقاء encoding كما استلمه، ولا يجوز له توزيع NLRI على client لم يعلن القدرة على فهمه.
  • يحتاج الترحيل الموثوق إلى إثبات متسلسل: رسالتا OPEN، وMP_REACH_NLRI الدقيق، ونتيجة import policy، وحل IPv6 recursion، والطريق المختارة، وFIB، والـadjacency أو tunnel، ثم حزم IPv4 حقيقية. لون الجلسة الأخضر ليس إلا الدرجة الأولى.

عند الساعة 01:40 ينقل موقع تجميع قلب النقل إلى underlay واحد من IPv6. تبقى خدمات العملاء وبادئاتها IPv4. المطلوب تقليل ازدواج العناوين وحالة IGP في القلب، لا تحويل المنتج الذي يستهلكه العميل.

يدعم route reflector اثنان ومعظم clients هذا التصميم. يعلن جهاز جديد IPv4 unicast وExtended Next Hop Encoding في OPEN. أما جهاز أقدم فيعلن العائلة فقط. تصل الجلستان إلى Established.

يتلقى الجهاز الجديد طرق IPv4 ويختارها، لكن resolver يبحث عن next hop من IPv6 في management VRF فينتهي إلى interface لا تحمل الخدمة. ولا يتلقى الجهاز القديم تلك الطرق، لأن reflector لا يملك تحويل IPv6 next hop إلى IPv4 كي يلائم عجزه.

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

الوجهة وnext hop يجيبان عن سؤالين مختلفين

تصف NLRI الوجهات القابلة للوصول. ويحدد next hop العنوان الذي ينبغي للمستقبِل أن يحله ويوجه نحوه كي يستخدم تلك القابلية. وكثرة تطابق عائلتيهما جعلت بعض الأدوات تتعامل مع ذلك كأنه هوية واحدة، مع أنه مجرد نمط شائع.

يكشف MP-BGP الفصل. يحمل MP_REACH_NLRI قيم AFI وSAFI وطول next hop وبايتاته وNLRI. عرّف RFC 4760 الحاوية، بينما افترضت تعريفات IPv4 وVPN-IPv4 القديمة next hop من هيئة IPv4، فلم تستطع التعبير بصورة عامة عن خدمة IPv4 فوق قلب IPv6.

يوسع RFC 8950 التركيب المسموح. تظل AFI 1 دالة على NLRI من IPv4، ويمكن أن تكون AFI الخاصة بـnext hop هي 2 في SAFI المحددة. لا يتحول عنوان العميل، ولا تزول مسؤولية IPv4؛ إنما تنتقل نقطة الارتكاز في طبقة النقل إلى عائلة أخرى.

يبقى التبني محلياً. يستطيع operator تفعيل الآلية داخل domain واحد أو بين peers مختارين أو لعائلة خدمة بعينها. ومن لا يتبناها يبقى في compatibility set أخرى ولا يصبح طرفاً «غير صالح». يحدد المعيار قاعدة wire صغيرة، ولا ينشئ سلطة مركزية للترحيل.

ويجب ضبط عبارة «IPv6-only core» بالطريقة نفسها. قد يقلل underlay موحد حالة التشغيل المكررة، لكنه لا يمحو عملاء IPv4 أو العقود أو قيمة موارد العناوين أو الدعم أو المخاطر. اسم طبقة النقل ليس وصفاً للمنتج كله.

Capability 5 يعد بثلاثية دقيقة فقط

رقم Extended Next Hop Encoding هو 5. وتتكون قيمته من ثلاثيات طول كل منها ستة octets: اثنان لـNLRI AFI واثنان لـNLRI SAFI واثنان لـnext-hop AFI. يسمح RFC 8950 بـAFI 1، وSAFI 1 أو 2 أو 4 أو 128 أو 129، وnext-hop AFI 2.

دعم IPv4 unicast لا يثبت دعم labeled unicast أو multicast أو VPN-IPv4. وقد تختلف التغطية بين release وplatform وline card. لذلك يمحو حقل عام مثل extended-nexthop=true موضوع التفاوض الحقيقي.

ولا يمنح code 5 الإذن باستخدام AFI/SAFI. تحدد Multiprotocol capability بصورة مستقلة ما إذا كان يمكن تبادل العائلة أصلاً. ويقول Extended Next Hop Encoding فقط إن peer يفهم هيئة next hop معينة لعائلة مسموحة من قبل.

لهذا يحتاج دليل OPEN إلى عمودين: هل جرى التفاوض على عائلة MP-BGP؟ وهل أعلن المستقبِل الثلاثية الدقيقة؟ قد تكون الجلسة Established رغم غياب أحدهما. ولا يجوز للsender إرسال IPv4 NLRI مع IPv6 next hop إلا بعد إثبات الثاني.

هذه صورة عملية لمبدأ Minimum Initial Specification لدى Heng Lu: code ثابت، وقاعدة حتمية، وقرار محلي. إذا غابت الثلاثية يمتنع هذا الطرف عن استخدام encoding مع ذلك peer؛ ولا توجد جهة تعلن أن الشبكة كلها «هاجرت».

يجب أن يحتفظ inventory بالدقة نفسها: BGP instance، وpeer، والإصدارات، وsession epoch، وكل AFI/SAFI وثلاثية مرسلة أو مستقبلة. عبارة «المنتج يدعم RFC 8950» معلومة شراء، وليست حقيقة عن الجلسة الجارية.

الطول جزء من النوع

مع AFI 1 وSAFI 1 أو 2 أو 4، يكون IPv6 next hop بطول 16 أو 32 octets. يحمل 16 عنواناً واحداً، وقد يحمل 32 عنواناً global يتبعه link-local وفق RFC 2545.

أما VPN-IPv4 مع SAFI 128 أو 129 فيستخدم 24 أو 48 octets، ويتضمن Route Distinguisher من ثمانية octets مضبوطاً على الصفر. عدّل RFC 8950 encoding الخاص بـVPN في RFC 5549 كي يطابق implementations المنشورة والمتوافقة، ويعالج erratum معروفاً.

يجب على receiver استنتاج بروتوكول next hop من الطول المسموح به في AFI/SAFI. ليس الطول تفصيلاً للعرض. وإذا حولت telemetry كل شيء إلى string بلا type، فلن يبقى ما يثبت أن parser أو policy engine فهم الرسالة صحيحة.

وللعنوانين global وlink-local سلطتان مختلفتان. يمكن حل global في routing table، أما link-local فلا يصبح فريداً إلا مع interface والرابط. لا يكفي تسجيل fe80::1 بلا peer وinterface وVRF.

في eBGP unnumbered قد تكون session وcapability صحيحتين بينما يفتقر FIB إلى adjacency مرتبطة بالواجهة. ويمكن لإعادة التشغيل أو استبدال منفذ أن تحفظ نص العنوان وتغير السياق الذي جعله صالحاً.

وفي VPN لا يلغي RD الصفري في حقل next hop قيمة service RD أو route targets داخل الطريق. هوية VPN وتمثيل next hop كائنان مختلفان.

الـreflector ليس مترجماً

إذا مرر route reflector قيمة next hop بلا تغيير، فعليه إبقاء encoding كما هو. وإذا عجز client عن فهمه، فلا يجوز توزيع NLRI عليه. استبدال IPv6 بعنوان IPv4 ليس تنسيقاً، بل قرار routing جديد ينقل recursion ومسؤولية forwarding إلى نقطة أخرى.

لذلك تصبح compatibility خاصية في topology. فإذا ولّد client encoding تحتاج بقية clients إلى استقباله عبر reflector مشترك، وجب أن تدعمه الأطراف المعنية. قد تكشف ترقية جهاز واحد عجز جهاز أقدم من غير أن يكون reflector معطلاً.

الغياب الناتج خادع. يبقى client القديم Established ويتلقى طرق IPv4 أخرى، ويحتفظ reflector بالطريق المتأثرة. يظهر count اختلافاً ولا يشرح أن إعلان capability لدى client منع التوزيع.

يصل الدليل، داخل epoch واحد، بين UPDATE المصدر والطريق المقبولة في reflector وOPEN الهدف وAdj-RIB-Out نحوه. ويجب تسمية السبب encoding غير مدعوم لدى client، لا عبارة عامة مثل «prefix مفقودة».

تغير next-hop-self وroute server وconfederation الحد، ويجب اختبارها منفصلة. قد يكون rewrite مشروعاً، لكنه يصبح فعلاً محلياً له owner ودليل، لا انعكاساً شفافاً.

في recursion تتحول الصياغة إلى تشغيل

بعد قبول UPDATE يحل المستقبل IPv6 next hop: يختار table أو VRF، ويجد طريق underlay، ويتابع recursion، ويربط adjacency أو tunnel، ثم يمرر النتيجة إلى FIB.

يمكن أن تفشل كل مرحلة منفردة: غياب العنوان من IGP، وجوده في global table بينما العملية تستعمل VRF، انقطاع سلسلة recursion، فشل Neighbor Discovery، فقدان label أو SID، صغر MTU بعد encapsulation، أو تأخر line card.

يتكون سلم الإثبات من:

  1. إعلان عائلة MP-BGP؛
  2. إعلان ثلاثية extended-next-hop الدقيقة؛
  3. ظهور MP_REACH_NLRI المتوقع على wire؛
  4. تفسير type صحيحاً؛
  5. قبول import policy؛
  6. اختيار الطريق؛
  7. حل next hop في السياق المقصود؛
  8. برمجة وجهة IPv4 في FIB؛
  9. ذهاب حزم IPv4 وعودتها.

لا تثبت درجة ما بعدها. عبارة «الطريق موجودة في BGP» واسعة أكثر من اللازم. يمكن للdashboard جمع المراحل، لكن لا يجوز له محو مصدر كل انتقال.

ويتطلب rollback الدقة نفسها. قد تستلزم العودة إلى IPv4 next hop إعادة underlay سابق وnext-hop-self وcapabilities وتسلسل الإعلانات. إطفاء code 5 بلا استعادة resolver القديم ليس رجوعاً.

يكتسب الأمن سطحاً من IPv6

لا يصادق RFC 8950 على الطرق. وقد تحمل session محمية إعلاناً غير مخول. يفحص RPKI origin validation سلطة origin AS للبادئة IPv4، ولا يثبت سلامة IPv6 next hop أو الوصول إليه.

الأدوات التي تفترض أن كل طريق IPv4 تحمل next hop من IPv4 ستفقد الكائن الجديد. ويحذر RFC 8950 من أن IPv6 next hop قد يتيح تحويل traffic عبر بنية IPv6 وسيطة، بما في ذلك hijacking أو denial of service. كما ينبغي التعامل بحذر مع الحالة غير المعتادة لعنوان IPv4-mapped IPv6.

ليس الحل رفض كل route عابرة للعائلات. بل تعريف peers المسموحين، وعائلات الخدمة، وIPv6 scopes، والجداول، والـtunnels، وخدمات IPv4 التي يجوز أن تعتمد عليها.

تبقى transport authentication وGTSM وprefix policy وRPKI وnext-hop authorization وأمن underlay واختبار الحزم controls منفصلة. الربط بينها مفيد، ودمج معانيها يصنع يقيناً زائفاً.

يجب أن يعبر canary العائلتين

قبل التفعيل اختر prefix IPv4 محدودة وIPv6 next hop متوقعاً. احتفظ بالطريق وFIB ومسار الحزم وpeer وسياق resolver والثلاثيات المتوقعة عند كل speaker.

في session epoch جديد التقط OPEN من الطرفين وافحص Multiprotocol وcode 5 منفصلين. ثم افحص UPDATE: ‏AFI 1، وSAFI المطلوبة، وطول 16/32 أو 24/48، والبايتات IPv6، وNLRI.

مع reflector أثبت حفظ next hop ودعم كل client. وفي كل receiver احتفظ بـpre-policy وpost-policy والطريق المختارة وrecursive lookup والجدول وadjacency/tunnel وFIB.

أرسل traffic IPv4 تمثيلياً مع source وdestination والاتجاه ومسار العودة والحجم وepoch. لا يكفي ping لاختبار encapsulation وMTU. اسحب canary بعدها وأثبت التنظيف في Adj-RIB-Out وRIB وrecursion وFIB.

وجود config قديم في Git ليس دليلاً على rollback. يجب أن يعود المسار السابق إلى حمل الحزم في الظروف الحالية.

يحدد RFC لغة مشتركة، وينفذها vendors، ويختار operators، وتحسم running network النتيجة. لا تصبح الوجهة IPv6 لأنها تعبر core من IPv6. ولا تتحول capability إلى سلطة forwarding لأن الرقم نفسه ظهر في OPEN. لا تصدق الطريق إلا حين يتفق type وpolicy وrecursion وhardware والحزم.