أخبار تكنلوجيا

الدافعُ وراء تحديد إصدارٍ جديد من بروتوكول IP بسيط هو التعامل مع استنفاد حيّز عناوين IP. ساعد التوجيه بين النطاقات عديم التصنيف Classless Interdomain Routing أو اختصارًا CIDR بصورة كبيرة في احتواء المعدل الذي يُستهلك حيز عناوين الإنترنت فيه، وساعد أيضًا في التحكم في نمو معلومات جدول التوجيه المطلوبة في الموجّهات على الإنترنت، ولكن هذه التقنيات لم تعد كافية. يكاد يكون من المستحيل تحقيق كفاءة استخدام العناوين بنسبة 100%، لذلك اُستهلك حيز العناوين قبل اتصال المضيف الذي رقمه 4 مليارات بالإنترنت. حتى لو تمكنّا من استخدام جميع العناوين التي عددها 4 مليارات، فمن الواضح الآن أن عناوين IP تحتاج إلى إسنادها لأكثر من حاسوبٍ تقليدي فقط، بما في ذلك الهواتف الذكية وأجهزة التلفاز والأجهزة المنزلية والطائرات دون طيار. إن حيّز العناوين ذات 32 بت صغيرٌ جدًا.

بدأت منظمة IETF في النظر في مشكلة توسيع حيز عناوين IP في عام 1991، واُقترحت العديد من البدائل. إن زيادة حجم العنوان يفرض تغييرًا في ترويسة الرزمة نظرًا لأن عنوان IP يُحمَل في ترويسة كل رزمة IP، وهذا يعني إصدارًا جديدًا من بروتوكول الإنترنت. ونتيجة لذلك هناك حاجة إلى برنامج جديد لكل مضيفٍ وموجّه في الإنترنت. من الواضح أن القيام بذلك ليس بمسألة بسيطة، فهي تغييرٌ كبير يجب التفكير فيه بعناية فائقة.

كانت الجهود المبذولة لتحديد إصدارٍ جديد من IP يُعرف في الأصل باسم IP Next Generation أو IPng. أُسند رقم إصدار IP رسمي مع تقدّم العمل، لذلك أصبح IPng يُعرَف باسم IPv6. لاحظ أن إصدار IP الذي نوقِش حتى الآن في هذا الفصل هو الإصدار 4 (IPv4). الانقطاع الظاهر في ترقيم الإصدارات هو نتيجة استخدام الإصدار رقم 5 لبروتوكولٍ تجريبي منذ عدة سنوات.

تسببت أهمية التغيير إلى إصدار جديد من بروتوكول IP في إحداث تأثيرٍ تراكمي. كان الشعور العام بين مصممي الشبكات أنه إذا كنت ستجري تغييرًا بهذا الحجم، فيمكنك أيضًا إصلاح العديد من الأشياء الأخرى في بروتوكول IP في نفس الوقت. وبالتالي طلبت منظمة IETF من أي شخص مُهتم أن يدخل معلوماتٍ حول الميّزات التي قد تكون مطلوبة في إصدارٍ جديد من بروتوكول IP. تضمنت بعض عناصر قائمة الرغبات الأخرى لإصدار IPng، إضافةً إلى الحاجة إلى استيعاب التوجيه القابل للتوسّع والعنونة، ما يلي:

• دعم خدمات الوقت الحقيقي.
• دعم الأمن.
• الضبط التلقائي Autoconfiguration: أي قدرة المضيفين على ضبط أنفسهم تلقائيًا بمعلومات مثل عنوان IP الخاص بهم واسم النطاق.
• وظيفة توجيه محسَّنة، بما في ذلك دعم المضيفين المتنقلين.

من المثير للاهتمام ملاحظة أنه في حين غياب العديد من هذه الميزات عن الإصدار IPv4 في الوقت الذي صُمِّم فيه الإصدار IPv6، فقد شق دعم جميع هذه الميزات طريقه إلى الإصدار IPv4 في السنوات الأخيرة، ويستخدم غالبًا تقنيات مماثلة في كلا البروتوكولين. يمكن القول بأن حرية التفكير في الإصدار IPv6 كصفحة بيضاء سهّلت تصميم قدراتٍ جديدة لبروتوكول IP والتي عُدِّلت بعد ذلك في الإصدار IPv4.

كانت إحدى الميزات غير القابلة للتفاوض على الإطلاق للإصدار IPv6، بالإضافة إلى قائمة الرغبات، هي أنه يجب أن تكون هناك خطة تحوُّل للانتقال من الإصدار الحالي من IP (الإصدار 4) إلى الإصدار الجديد. سيكون من المستحيل تمامًا وجود يومٍ يغلق فيه الجميع مضيفهم والموجّهات الخاصة بهم ثم يثبّتون إصدارًا جديدًا من بروتوكول IP نظرًا لأن الإنترنت كبير جدًا ولعدم وجود تحكم مركزي. توقع المهندسون فترة انتقالية طويلة يشغّل فيها بعض المضيفين والموجهات إصدار IPv4 فقط، والبعض الآخر سيعمل على الإصدارين IPv4 و IPv6، والبعض الآخر سيعمل على الإصدار IPv6 فقط، وتوقعوا اقتراب الفترة الانتقالية من الذكرى الثلاثين لتأسيسها.

أولاً وقبل كل شيء، يوفر الإصدار IPv6 حيز عناوين بطول 128 بت، بدلًا من 32 بت في الإصدار 4. وبالتالي يمكن للإصدار IPv6 معالجة 3.4 × 1038 عقدة بافتراض كفاءة 100%، في حين أن الإصدار 4 يمكن أن يعالج 4 مليارات عقدة إذا وصلت كفاءة إسناد العناوين إلى 100%. كما رأينا وعلى الرغم من ذلك، فإن الكفاءة بنسبة 100% في إسناد العناوين أمرٌ غير محتمل. أظهرت بعضُ التحليلات لمخططات العنونة الأخرى، مثل تلك الخاصة بشبكات الهاتف الفرنسية والأمريكية وكذلك تحليلات الإصدار IPv4، بعضَ الأرقام التجريبية لكفاءة إسناد العناوين. من المتوقع أن يوفر حيز عناوين IPv6، استنادًا إلى أكثر تقديرات الكفاءة تشاؤمًا المستمدة من هذه الدراسة، أكثر من 1500 عنوان لكل قدم مربع من سطح الأرض، وهذا بالتأكيد سيخدمنا جيدًا حتى عندما يكون للأجهزة على كوكب الزهرة عناوين IP.

إن عناوين IPv6 عديمةُ التصنيف classless أيضًا بالاعتماد على فعالية توجيه CIDR في IPv4، لكن حيز العناوين لا يزال مقسمًا بطرق مختلفة بناءً على البتات البادئة. تحدّد البتات البادئة استخدامات مختلفة لعناوين IPv6 بدلًا من تحديد أصناف عناوين مختلفة. يوضح الجدول التالي الإسناد الحالي للبادئات في الإصدار IPv6:

يستدعي هذا التخصيص لحيز العناوين القليلَ من المناقشة. أولًا، تُضمَّن الوظيفة الكاملة لأصناف عناوين IPv4 الرئيسية الثلاثة (A و B و C) داخل نطاق "كل شيء آخر". تشبه عناوين البث الأحادي العالمية Global Unicast، كما سنرى قريبًا، إلى حدٍ كبير عناوين IPv4 عديمة التصنيف، ولكنها أطول من ذلك بكثير. هذه هي أهم الأمور المهمة في هذه المرحلة، حيث يتوفر أكثر من 99% من إجمالي حيز عناوين IPv6 لهذا الشكل من العناوين. (تُخصَّص عناوين IPv6 أحادية البث من الكتلة التي تبدأ بـ 001 في وقت كتابة هذا الكتاب، بينما يُحجز حيز العناوين المتبقي، الذي يمثل حوالي 87%، للاستخدام في المستقبل).

من الواضح أن حيز عناوين البث المتعدد multicast مخصصة للبث المتعدد. وبالتالي تخدم نفس دور عناوين الصنف D في IPv4. لاحظ أنه من السهل تمييز عناوين البث المتعدد، فهي تبدأ ببايتٍ مكوَّن من واحدات. سنرى كيفية استخدام هذه العناوين في لاحقًا.

تكمن الفكرة وراء عناوين استخدام الروابط المحلية في تمكين المضيف من إنشاء عنوان يعمل على الشبكة التي يتصل بها دون القلق بشأن الطابع الفريد عالميًا للعنوان. قد يكون هذا مفيدًا للضبط التلقائي، كما سنرى أدناه. وبالمثل، فإن عناوين استخدام الموقع المحلية site-local use تهدف إلى السماح بإنشاء عناوين صالحة على موقع (شبكة شركة خاصة مثلًا) غير متصلٍ بشبكة الإنترنت الأكبر، فلا يجب أن يكون التفرد العالمي مشكلةً.

توجد بعض أنواع العناوين الخاصة المهمة داخل حيز العناوين أحادية البث العالمية. يمكن إسناد عنوان IPv6 متوافق مع IPv4 للعقدة من خلال توسيع عنوان IPv4 المؤلَّف من 32 بتًا إلى 128 بت من خلال إضافة أصفار zero-extending. يمكن إسناد عنوان IPv6 المربوط مع عنوان IPv4 للعقدة القادرة فقط على فهم عناوين IPv4 عن طريق بدء prefixing عنوان IPv4 المؤلَّف من 32 بتًا بـ 2 بايت مؤلفة من واحدات ثم توسيع النتيجة من خلال إضافة أصفار zero-extending إلى 128 بت. يُستخدم هذان النوعان الخاصان من العناوين في الانتقال من IPv4 إلى IPv6.

هناك بعض الرموز الخاصة لصيغة عناوين IPv6 تمامًا كما هو الحال مع عناوين IPv4. التمثيل القياسي هو x: x: x: x: x: x: x: x، حيث يمثّل كلx تمثيلًا ست عشريًا لقطعةٍ مؤلفةٍ من 16 بتًا من العنوان. سيكون على سبيل المثال كما يلي:

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

يمكن كتابته بالشكل:

من الواضح أن هذا النوع من الاختزال لا يمكن استخدامه إلا لمجموعة واحدة من الأصفار المتجاورة في العنوان لتجنب الالتباس.

يوجد نوعان من عناوين IPv6، يحويان على عنوان IPv4 مضمَّن، لهما صيغةٌ خاصة بهما، مما يجعل استخراج عنوان IPv4 أسهل. يمكن كتابة عنوان IPv6 المربوط mapped مع IPv4 لمضيفٍ عنوان IPv4 الخاص به هو 128.96.33.81 على سبيل المثال بالشكل التالي:

أي أن آخر 32 بتًا مكتوبة بصيغة IPv4، بدلًا من كتابة زوجٍ من الأرقام الست عشرية المفصولة بنقطتين. لاحظ أن النقطتين المزدوجتين في المقدمة تشير إلى الأصفار البادئة leading.

إن أهم نوعٍ من العناوين التي يجب أن يوفرها IPv6 هو عنونة البث الأحادي القديم البسيط. يجب أن يحدث ذلك بطريقة تدعم المعدل السريع لإضافة مضيفِين جددٍ إلى الإنترنت وتسمح بإجراء التوجيه بطريقة قابلة للتوسع مع نمو عدد الشبكات الفيزيائية في الإنترنت. وبالتالي توجد خطةٌ في صميم IPv6 لتخصيص عنوان البث الأحادي التي تحدد كيفية إسناد عناوين البث الأحادي لمزودي الخدمة والأنظمة المستقلة والشبكات والمضيفين والموجهات.

تشبه خطة تخصيص العناوين المقترحة لعناوين بث IPv6 الأحادي إلى حدٍ بعيد تلك التي تُنشَر مع توجيه CIDR في الإصدار IPv4. يجب تحديد بعض المصطلحات الجديدة لفهم كيفية عملها وكيف توفر قابلية التوسع. يمكننا التفكير بالنظام المستقل الذي ليس نظامًا مستقلًا عابرًا nontransit (أي نظام مستقل جذري Stub AS، أو متعدد طرق الاتصال Multihomed AS) مثل مشترك subscribe، وقد نفكر في النظام المستقل العابر كمزوّد provider. وقد نقسّم مزودي الخدمة إلى قسمين مباشر direct وغير مباشر indirect. النوع الأول متصل مباشرةً بالمشتركين. ويربط النوع الثاني بين مزودين آخرين ولا يرتبط مباشرة بالمشتركين، وغالبًا ما يُعرف باسم الشبكات الأساسية backbone networks*.

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

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

يكمن العيب في ذلك أنه في حال قرّر موقعٌ ما تغيير مزوّدي الخدمة، فلا بُدّ له من الحصول على بادئة عنوان جديدة وإعادة ترقيم جميع العقد في الموقع. قد تكون هذه المهمةً ضخمة بما يكفي لثني معظم الناس عن تغيير مزودي الخدمة باستمرار. لذلك هناك بحثٌ مستمر حول مخططات العنونة الأخرى، مثل العنونة الجغرافية geographic addressing، حيث يكون عنوان الموقع تابعٌ لمكانه وليس للمزود الذي يرتبط به. ومع ذلك فإن العنونة حاليًا المعتمدة على المزود ضروريةٌ لجعل التوجيه يعمل بكفاءة. نلاحظ بالرغم من أن إسناد عناوين IPv6 يكافئ بصورة أساسية الطريقة التي جرى بها إسناد العناوين في الإصدار IPv4 منذ استخدام توجيه CIDR، فإن IPv6 يتمتع بميزة كبيرة تتمثل في عدم وجود قاعدة كبيرة مثبَّتة من العناوين المسنَدة لتناسب خططها.

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

قد يكون المكان الذي يتم فيه التجميع منطقيًا هو على المستوى الوطني أو القاري. تشكل الحدود القارية تقسيمات طبيعية في مخطَّط الإنترنت. إذا احتوت جميع العناوين في أوروبا مثلًا على بادئةٍ مشتركة، يمكن إجراء قدرٍ كبير من التجميع، عندها ستحتاج معظم الموجّهات في القارات الأخرى فقط إلى مدخلةِ جدول توجيه واحد لجميع الشبكات ذات البادئة الأوروبية Europe prefix. كما سيختار جميع مزودي الخدمة في أوروبا البادئات الخاصة بهم التي تبدأ بالبادئة الأوروبية. ويوضح الشكل الآتي عنوان IPv6 باستخدام هذا المخطط. فقد يكون معرّف المسجل RegistryID وهو معرّف يُسنَد لمسجل عناوينٍ أوروبي، مع معرّفاتٍ مختلفة مُسنَدة لقاراتٍ أو دول أخرى. لاحظ أن البادئات ستكون ذات أطوالٍ مختلفة في ظل هذا السيناريو، فقد يكون لدى مزود الخدمة الذي لديه عدد قليل من العملاء بادئة أطول (وبالتالي حيز عناوين أقل توفّرًا) من مزود به العديد من العملاء على سبيل المثال.

قد يحدث موقفٌ صعب عندما يكون المشترك متصلًا بأكثر من مزود. فما هي البادئة التي يجب على المشترك استخدامها لموقعه؟ لا يوجد حل مثالي لهذه المشكلة. افترض، على سبيل المثال، أن أحد المشتركين متصلٌ بمزودَي خدمة هما X وY. إذا أخذ المشترك بادِئته من المزود X، فيجب على المزود Y الإعلان عن بادئة ليس لها علاقة بمشتركيه الآخرين وبالتالي لا يمكن تجميعهم. وإذا كان جزءٌ من أرقام المشترك في النظام المستقل الخاص به مع بادئة المزود X والجزء الآخر مع بادئة المزود Y، فإنه يخاطر بأن يصبح نصف موقعه غير قابل للوصول إذا تعطل الاتصال بمزود. أحد الحلول التي تعمل جيدًا إلى حد ما إذا كان هناك الكثير من المشتركين بين المزودَين X وY، هو أن يكون بينهما ثلاث بادئات: بادئة لمشتركي المزود X فقط، وبادئة لمشتركي المزود Y فقط، وبادئة للمواقع المشتركة في كل من المزودَين X وY.

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

تبدأ هذه الترويسة بحقل الإصدار Version كما هو الحال مع العديد من العناوين، والذي ضُبِط على القيمة 6 للإصدار IPv6. يوجد حقل الإصدار في نفس المكان بالنسبة إلى بداية العنوان مثل حقل الإصدار الخاص بالإصدار IPv4 بحيث يمكن لبرنامج معالجة الترويسة أن يقرر على الفور صيغة العنوان الذي يجب البحث عنه. يرتبط كلا الحقلين TrafficClass وFlowLabel بجودة الخدمة.

يعطي حقل PayloadLen طول الرزمة، بدون ترويسة IPv6، مُقاسًا بالبايت. يستبدل الحقل NextHeader بذكاء كلًا من خيارات IP وحقل البروتوكول Protocol من الإصدار IPv4. إذا كانت الخيارات مطلوبة، فستُحمَل في ترويسة خاصة واحدة أو أكثر تتبع ترويسة IP، ويشار إلى ذلك بقيمة الحقل NextHeader. إذا لم تكن هناك ترويسات خاصة، سيكون الحقل NextHeader مفتاح فك تجميع demux، الذي يحدّد بروتوكول المستوى الأعلى الذي يعمل عبر بروتوكول IP (بروتوكول TCP أو بروتوكول UDP مثلًا)، أي أنه يخدّم نفس هدف حقل البروتوكول Protocol في الإصدار IPv4. تُعالَج التجزئةfragmentation الآن كترويسة اختيارية، مما يعني أن الحقول المتعلقة بالتجزئة في IPv4 غير مضمَّنة في ترويسة IPv6. حقل HopLimit هو ببساطة حقل TTL وهو العُمر time to live للإصدار IPv4، وأُعيدت تسميته ليعكس طريقة استخدامه بالفعل.

أخيرًا، الجزء الأكبر من الترويسة هو عناوين المصدر والوجهة، حيث يبلغ طول كلٍّ منهما 16 بايتًا (أو 128 بت). وبالتالي يبلغ طول ترويسة IPv6 دائمًا 40 بايتًا. بالنظر إلى أن عناوين IPv6 أطول أربع مرات من عناوين IPv4، فإن هذا يوازَن جيدًا بترويسة IPv4، والتي يبلغ طولها 20 بايتًا في حالة عدم وجود خيارات options.

تحسنت الطريقة التي يتعامل بها الإصدار IPv6 مع الخيارات كثيرًا عن الإصدار IPv4. حيث يتعين على كل موجهٍ في IPv4، في حالة وجود أية خيارات، تحليل حقل الخيارات بالكامل لمعرفة ما إذا كان أي من هذه الخيارات ذو صلة. حيث أن جميع الخيارات كانت مدفونة في نهاية ترويسة IP، كمجموعة غير مرتبة من مجموعات (النوع ، الطول ، القيمة) أو (type, length, value). بينما يتعامل IPv6 مع الخيارات كترويسات توسّع extension headers التي يجب، إن وجدت، أن تظهر بترتيبٍ معين. هذا يعني أن كل موجهٍ يمكنه تحديد ما إذا كان أي من الخيارات مناسبًا له بسرعة، وفي معظم الحالات لن تكون كذلك، ويمكن تحديد ذلك عادةً من خلال النظر فقط إلى حقل NextHeader. النتيجة النهائية هي أن معالجة الخيارات أكثر كفاءة في الإصدار IPv6، وهو عاملٌ مهم في أداء الموجّه. بالإضافة إلى أن الصيغة الجديدة للخيارات كترويسات توسّع يعني أنها يمكن أن تكون ذات طولٍ عشوائي، بينما في IPv4 كانت محدودةً بطول 44 بايتًا على الأكثر. سنرى كيف تُستخدَم بعض الخيارات أدناه.

كل خيارٍ له نوعٌ خاصٌ به من ترويسة التوسّع. ويُحدَّد نوع كل ترويسةِ توسّعٍ بقيمة حقل NextHeader في الترويسة التي تسبقها، وتحتوي كل ترويسة توسّع على حقل NextHeader لتحديد العنوان الذي يليه. ستُتبع ترويسة التوسّع الأخيرة بترويسةُ طبقة النقل (TCP على سبيل المثال)، وفي هذه الحالة تكون قيمة حقل NextHeader هي نفسها قيمة الحقل Protocol في ترويسة IPv4. وبالتالي يقوم الحقل NextHeader بمهمةٍ مزدوجة، إما أن يحدد نوع ترويسة التوسّع الواجب اتباعها، أو يعمل كمفتاح فك تجميع demux لتحديد بروتوكول الطبقة الأعلى الذي يعمل عبر الإصدار IPv6 في ترويسة التوسّع الأخيرة.

افترض مثال ترويسة التجزئة الموضحة في الشكل السابق. توفّر هذه الترويسة وظائفًا مماثلة لحقول التجزئة في ترويسة IPv4، ولكنها موجودة فقط إذا كانت التجزئة ضرورية. على فرض أنها ترويسة التوسّع الوحيدة الموجودة، فإن حقل NextHeader لترويسة IPv6 ستحتوي على القيمة 44، وهي القيمة المُسنَدة للإشارة إلى ترويسة التجزئة. يحتوي حقل NextHeader لترويسة التجزئة نفسها على قيمة تصِف الترويسة التي تليها. فقد يكون العنوان التالي هو ترويسة TCP بافتراض عدم وجود ترويسات توسّعٍ أخرى، مما ينتج عنه القيمة 6 للحقل NextHeader، كما يفعل حقل Protocol في IPv4 تمامًا. إذا لحقت بترويسة التجزئة ترويسةُ استيثاق على سبيل المثال، سيَحتوي حقل NextHeader لترويسة التجزئة عندئذٍ على القيمة 51.

كان الدافع الأساسي وراء تطوير الإصدار IPv6 هو دعم النمو المستمر للإنترنت كما ذُكر في بداية هذا القسم. كان الباب مفتوحًا لمجموعة متنوعة من التغييرات الأخرى بمجرد تغيير ترويسة IP عند تغيير العناوين، لكن يتضمن الإصدار IPv6 العديد من الميزات الإضافية، مثل التنقل والأمن وجودة الخدمة quality-of-service التي سننُاقشها لاحقًا. من المثير للاهتمام أن نلاحظ أنه أصبحت إمكانات الإصدارات IPv4 و IPv6 غير قابلة للتمييز فعليًا في معظم هذه المجالات، بحيث يبقى المحرك الرئيسي للإصدار IPv6 هو الحاجة إلى عناوينٍ أكبر.

كان نمو الإنترنت أمرًا مثيرًا للإعجاب، ولكن أحد العوامل التي حالت دون قبولٍ أسرع للتقنية هو حقيقة أن الاتصال بالإنترنت يتطلب عادةً قدرًا لا بأس به من الخبرة في إدارة النظام. حيث يحتاج كل مضيفٍ متصلٍ بالإنترنت إلى أن يُضبَط باستخدام حدٍ أدنى معين من المعلومات، مثل عنوان IP صالح وقناع شبكة فرعية subnet mask للرابط الذي يتصل به وعنوان خادم الأسماء name server، وبالتالي لم يكن ممكنًا توصيل حاسوبٍ جديد بالإنترنت دون بعض الضبط المسبق preconfiguration. لذلك يتمثل أحد أهداف الإصدار IPv6 في توفير الدعم للضبط التلقائي، والذي يشار إليه أحيانًا بعملية التوصيل والتشغيل مباشرةً plug-and-play.

إن الضبط التلقائي ممكنٌ للإصدار IPv4، لكنه يعتمد على وجود خادمٍ ضُبِط لتوزيع العناوين ومعلومات الضبط الأخرى لعملاء بروتوكول ضبط المضيف ديناميكيًّا Dynamic Host Configuration Protocol أو اختصارًا DHCP. تساعد صيغة العنوان الأطول في الإصدار IPv6 على توفير شكلٍ جديد ومفيد من الضبط التلقائي يسمى الضبط التلقائي عديم الحالة stateless autoconfiguration، والذي لا يتطلب خادمًا.

تذكر أن عناوين IPv6 أحادية البث وهرمية، وأن الجزء الأقل أهمية هو معرّف الواجهة interface ID. وبالتالي يمكن تقسيم مشكلة الضبط التلقائي إلى قسمين:

• الحصول على معرّف واجهةٍ فريد من نوعه على الرابط الذي يرتبط المضيف به.
• الحصول على بادئة العنوان الصحيحة لهذه الشبكة الفرعية.

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

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

كانت القدرة على تضمين embed عناوين على مستوى الرابط بطول 48 بتًا في عناوين IPv6 هو أحد أسباب اختيار مثل هذا الحجم الكبير للعنوان. لا تسمح 128 بتًا هذه بالتضمين embedding فقط، ولكنها تترك مساحة كبيرة للتسلسل الهرمي متعدد المستويات للعناوين التي ناقشناها سابقًا.

ترويسة التوجيه routing header هي ترويسة من بين ترويسات توسّع الإصدار IPv6 الأخرى. ويختلف توجيه IPv6 قليلًا عن توجيه IPv4 ضمن توجيه CIDR في حالة عدم وجود هذه الترويسة. تحتوي ترويسة التوجيه على قائمةٍ بعناوين IPv6 التي تمثّل العقد أو مناطق مخطط الشبكة التي يجب أن تزورها الرزمة في مسارها إلى وجهتها. وقد تكون المنطقةُ الهيكلية topological area عبارة عن شبكةَ مزود رئيسية على سبيل المثال. سيكون تحديدُ أن الرزم يجب أن تزور هذه الشبكة طريقةً لتطبيق اختيار المزود على أساس كل رزمة على حدى. وبالتالي يمكن للمضيف أن يقول إنه يريد أن تمر بعضُ الرزم عبر مزودٍ رخيص، والبعض الآخر من خلال مزودٍ يوفر وثوقيةً عالية، والبعض الآخر من خلال مزودٍ يثق به المضيف لتوفير الأمن.

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

ترجمة -وبتصرّف- للقسم IP Version 6 من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach.

• المقال السابق: التشبيك المتقدم Advanced Internetworking في الشبكات الحاسوبية
• شبكة الإنترنت باستخدام بروتوكول IP
• الشبكات الفرعية والعناوين والأخطاء في بروتوكول IP

مشكلة التوسع إلى المليارات Scaling to Billions لقد رأينا الآن كيفية بناء شبكةٍ متشابكة internetwork تتكون من عدة شبكاتٍ ذات أنواعٍ مختلفة. أي أننا تعاملنا مع مشكلة عدم التجانس heterogeneity. المشكلة الحرجة الثانية في التشبيك internetworking، ويمكن القول أنها المشكلة الأساسية لجميع الشبكات، هي التوسّع scale. يجدر النظر في نمو الإنترنت لفهم مشكلة توسّع شبكة، حيث تضاعف حجم الإنترنت تقريبًا كلَّ عام خلال 30 عامًا. يدفعنا هذا النوع من النمو إلى مواجهة عدة تحديات.

ومن أهم هذه التحديات كيفية بناء نظام توجيه يمكنه التعامل مع مئات الألوف من الشبكات ومليارات العقد النهائية. تعتمد معظم الطرق لمعالجة قابلية التوسّع في التوجيه على استخدام الهرمية hierarchy كما سنرى في هذا الفصل. يمكن تقديم الهرمية في شكل مناطق areas داخل نطاق domain، حيث نستخدم أيضًا الهرمية لتوسيع نظام التوجيه بين النطاقات interdomain. بروتوكول التوجيه بين النطاقات الذي مكّن الإنترنت من التوسع إلى حجمه الحالي هو بروتوكول BGP. سنلقي نظرة على كيفية عمل بروتوكول BGP، وعلى التحديات التي يواجهها مع استمرار نمو الإنترنت.

ترتبط مشكلة العنونة ارتباطًا وثيقًا بقابلية التوسع، إذ أصبح من الواضح أن مخطط العنونة 32 بت للإصدار 4 (IP version 4) من بروتوكول IP لن يستمر بعد عقدين من الزمن، وقد أدى ذلك إلى تعريف إصدارٍ جديد من بروتوكول IP، وهو الإصدار 6 (IP version 6)، حيث اُستخدم الإصدار 5 في تجربة سابقة. يوسّع IPv6 حيز العناوين بشكل أساسي ولكنه يضيف أيضًا عددًا من الميزات الجديدة، والتي عُدِّل بعضها تحديثًا للإصدار IPv4.

طالما أن الإنترنت يستمر في النمو من حيث الحجم، فإنه يحتاج أيضًا إلى تطوير وظائفه. تغطّي الأقسام الأخيرة من هذا الفصل بعض التحسينات الهامة لإمكانات الإنترنت. التحسين الأول هو البث المتعدد multicast والذي هو تحسين لِنموذج الخدمة الأساسية. سنوضح كيفية دمج البث المتعدد، وهو القدرة على توصيل نفس الرزم إلى مجموعة من المستقبلات بكفاءة، ضمن الإنترنت، وسنشرح العديد من بروتوكولات التوجيه التي طُوِّرت لدعم البث المتعدد. التحسين الثاني هو تبديل التسمية متعددة البروتوكولات Multiprotocol Label Switching أو اختصارًا MPLS الذي يعدّل آلية تمرير شبكات IP. وقد أتاح هذا التعديل إجراء بعض التغييرات في طريقة تنفيذ توجيه IP وفي الخدمات التي تقدمها شبكات IP. أخيرًا، سننظر في تأثيرات التنقّل mobility على التوجيه ووصف بعض التحسينات على بروتوكول IP لدعم المضيفين والموجّهات المتنقلة. لا تزال قضايا قابلية التوسع مهمةً لكلٍّ من هذه التحسينات.

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

نحتاج إلى صورةٍ عامة في أذهاننا لما يبدو عليه الإنترنت العالمي قبل الوصول إلى هذه التقنيات. إنه ليس مجرد توصيلٍ عشوائي من شبكات الإيثرنت، ولكنه يتخذ شكلًا يعكس حقيقة أنه يربط بين العديد من المنظمات المختلفة. يعطي الشكل السابق وصفًا بسيطًا لحالة الإنترنت في عام 1990، وقد نما هيكل topology شبكة الإنترنت بصورةٍ أعقد مما يوحي إليه هذا الشكل منذ ذلك الوقت. سنقدم صورةً أدق للإنترنت الحالي في قسمٍ لاحق.

تتمثل إحدى سمات هذا الهيكل البارزة في أنه يتكون من مواقع المستخدم النهائي end-user sites، كَجامعة ستانفورد Stanford University على سبيل المثال، التي تتصل بشبكات مزود الخدمة (كانت شبكة BARRNET عبارةً عن شبكة مزود خدمة المواقع في منطقة خليج سان فرانسيسكو على سبيل المثال). خدّم العديد من مزوّدي الخدمة منطقةً جغرافية محدودة في عام 1990، وبالتالي عُرفوا باسم الشبكات الإقليمية regional networks. ارتبطت الشبكات الإقليمية، بدورها، بشبكة رئيسية وطنية nationwide backbone، حيث موّلت مؤسسة العلوم الوطنية National Science Foundation أو اختصارًا NSF هذه الشبكة في عام 1990، وبالتالي كانت تُسمى NSFNET backbone.

أفسحت شبكة NSFNET الطريق لشبكة Internet2، التي لا تزال تدير الشبكة الرئيسية backbone هذه نيابة عن مؤسسات البحث Research والتعليم Education في الولايات المتحدة (توجد شبكات R & E مماثلة لها في بلدان أخرى)، ولكن بالطبع يحصل معظم الناس على اتصالهم بالإنترنت من مزودي الخدمات التجاريين. تُبنى شبكات المزود الأكبر اليوم (يطلق عليها المستوى 1 وبالأجنبية tier-1) عادةً من عشرات الموجّهات المتطورة الموجودة في مناطق المدينة الرئيسية (يشار إليها بالعامية باسم مدن NFL) المتصلة بواسطة روابط من نقطة لنقطة (غالبًا بسعة 100 جيجابت في الثانية). لا يكون كل موقع مستخدمٍ نهائي عادةً شبكةً واحدة، ولكنه يتكون بدلًا من ذلك من شبكات فيزيائية متعددة متصلة بواسطة مبدّلات switches وموجّهات routers.

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

يمكن استخدام حقيقة أن الإنترنت لديه بنية واضحة لصالحنا أثناء معالجة مشكلة قابلية التوسع. ولكن نحن بحاجة إلى التعامل مع مسألتين مرتبطتين بمشكلة التوسّع scaling. المسألة الأولى هي قابلية توسّع التوجيه. حيث نحتاج إلى إيجاد طرقٍ لتقليل عدد أرقام الشبكة التي تُنقَل في بروتوكولات التوجيه وتُخزَّن في جداول التوجيه الخاصة بالموجّهات. أمّا المسألة الثانية فهي استخدامية العناوين، أي التأكد من عدم استهلاك حيز عناوين IP بسرعة كبيرة.

نرى استخدام مبدأ الهرمية hierarchy مرارًا وتكرارًا في هذا الكتاب لتحسين قابلية التوسُّع. وقد رأينا في الفصل السابق كيف يمكن لبنية عناوين IP الهرمية تحسين قابلية التوسع في التوجيه، وخاصةً مع المرونة التي يوفرها التوجيه بين النطاقات عديم التصنيف Classless Interdomain Routing أو اختصارًا CIDR والشبكات الفرعية. وسنرى لاحقًا استخدامات أخرى لِلهرمية، وشريكها التجميع aggregation، لتوفير أكبر قابليةٍ للتوسُّع، أولًا في نطاقٍ domain واحد ثم بين النطاقات. ثم سنناقش الإصدار 6 من بروتوكول IP، والذي كان اختراعه نتيجة مخاوف قابلية التوسع إلى حدٍ كبير.

كمثالٍ أول على استخدام الهرمية لتوسيع نظام التوجيه، سنَفحص كيفية استخدام بروتوكولات توجيه حالة الرابط link-state (مثل بروتوكولي OSPF و IS-IS) لتقسيم نطاق التوجيه إلى نطاقات فرعية تسمى مناطق areas. (تختلف المصطلحات إلى حدٍ ما بين البروتوكولات، ولكن سنستخدم مصطلحات بروتوكول OSPF هنا). فيمكن للنطاقات النمو بصورةٍ أكبر من خلال إضافة هذا المستوى الإضافي من الهرمية دون إنهاك بروتوكولات التوجيه أو اللجوء إلى بروتوكولات التوجيه بين النطاقات interdomain routing protocols الأعقد التي سنوضّحها لاحقًا.

المنطقة area عبارة عن مجموعة من الموجّهات المضبوطة إداريًا لتبادل معلومات حالة الرابط مع بعضها بعضًا. هناك منطقة خاصة واحدة هي المنطقة الرئيسية backbone area، والمعروفة أيضًا بالمنطقة 0. يوضح الشكل الآتي مثالًا عن نطاق توجيهٍ مُقسمٍ إلى مناطق. الموجّهات R1 و R2 و R3 هي أعضاء في المنطقة الرئيسية وأعضاءٌ أيضًا في منطقة واحدة ليست منطقة رئيسية على الأقل، حيث الموجه R1 هو في الواقع عضو في كلٍّ من المنطقة 1 والمنطقة 2. يُعرَف الموجّه العضو في كلٍ من المنطقة الرئيسية ومنطقة ليست بمنطقة رئيسية nonbackbone area بموجّه منطقةٍ حدودي area border router أو اختصارًا ABR. لاحظ أن هذه الموجّهات تختلف عن الموجّهات الموجودة على حافة نظام AS، والتي يُشار إليها باسم موجهات حدود AS للتوضيح.

يتم التوجيه داخل منطقةٍ واحدة بالضبط كما هو مّوضح في الفصل السابق. ترسِل جميع الموجّهات في المنطقة إعلانات حالة الرابط لبعضها بعضًا، وبالتالي فهي تطوّر خارطةً كاملة ومستقرة للمنطقة. ولكنّ لا تترك إعلانات حالة الرابط الخاصة بالموجّهات التي ليست موجّهات منطقةٍ حدودية المنطقةَ التي نشأت فيها. هذا له تأثير في جعل عمليات حساب المسار route calculation والإغراق flooding أكثر قابلية للتوسع بصورة كبيرة. فلن يرى الموجّه R4 مثلًا الموجود في المنطقة 3 أبدًا إعلان حالة رابطٍ من الموجه R8 الموجود في المنطقة 1. ولذلك لن يعرف شيئًا عن الهيكل topology التفصيلي لِلمناطق المغايرة لِمنطقته.

إذًا كيف يحدّد الموجّه في منطقةٍ ما عقدة توجيه القفزة التالية next hop الصحيحة للرزمة الموجّهةِ إلى شبكةٍ في منطقة أخرى؟ تصبح الإجابة عن هذا السؤال واضحةً إذا تخيلنا أن مسار الرزمة التي يجب أن تنتقل من منطقةٍ ليست منطقة رئيسية إلى منطقة أخرى مقسَّمٌ إلى ثلاثة أجزاء. أولًا، تنتقل الرزمة من الشبكة المصدر إلى المنطقة الرئيسية، ثم تعبر المنطقة الرئيسية، وتنتقل منها إلى الشبكة الوِجهة. تلخّص موجّهات المنطقة الحدودية، لإنجاز هذا العمل، معلوماتِ التوجيه التي تعلّمتها من منطقةٍ ما وتُتيحَها ضمن إعلاناتها إلى مناطق أخرى. يتلقى الموجّه R1 على سبيل المثال إعلانات حالة الرابط من جميع الموجّهات في المنطقة 1 وبالتالي يمكنه تحديد تكلفة الوصول إلى أي شبكة في المنطقة 1. يعلن الموجّه R1 عن تكاليف الوصول إلى الشبكات في المنطقة 1 عندما يرسل إعلانات حالة الرابط إلى المنطقة 0، كما لو كانت جميع هذه الشبكات متصلةً مباشرة بالموجه R1. يتيح ذلك لجميع الموجّهات في المنطقة 0 معرفة تكلفة الوصول إلى جميع الشبكات في المنطقة 1. ثم تلخّص موجهات المنطقة الحدودية هذه المعلومات وتعلن عنها في المناطق الغير الرئيسية، وبالتالي تتعلم جميع الموجّهات كيفية الوصول إلى جميع الشبكات في النطاق domain.

لاحظ أنه في حالة المنطقة 2، يوجد موجهان ABR، وبالتالي يتعين على الموجّهات في المنطقة 2 أن تختار أي موجهٍ ستستخدم للوصول إلى المنطقة الرئيسية. هذا سهل بما فيه الكفاية، نظرًا لأن كلًا من الموجهين R1 و R2 سَيُعلِنان عن تكاليف الوصول إلى شبكاتٍ مختلفة، لذلك سيتضح أيهما هو الخيار الأفضل لأن موجهات المنطقة 2 تشغّل خوارزمية المسار الأقصر shortest-path algorithm. فمن الواضح جدًا أن الموجّه R1 سيكون خيارًا أفضل من الموجّه R2 للوِجهات في المنطقة 1.

يُجري مسؤول administrator الشبكة مقايضة بين قابلية التوسُّع والتوجيه الأمثل عند تقسيم نطاقٍ إلى مناطق. يُجبِر استخدامُ المناطق جميعَ الرزم التي تنتقل من منطقة إلى أخرى على المرور عبر المنطقة الرئيسية حتى لو كان المسار الأقصر متاحًا. فلن تتدفق الرزم بين الموجهين R4 و R5 على سبيل المثال حتى لو كانا متصلين مباشرةً لأنهما موجودان في منطقتين مختلفتين وغير رئيسيتين. اتضح أن الحاجة إلى قابلية التوسع غالبًا تكون أهم من الحاجة إلى استخدام المسار الأقصر على الإطلاق.

هذا يوضح مبدأً مهمًا في تصميم الشبكات. حيث يكون هناك مقايضةٌ بين قابلية التوسُّع scalability ونوعٍ من الأمثلية optimality. تُخفى المعلومات من بعض العقد في الشبكة عند استخدام الهرمية، مما يعيق قدرتها على اتخاذ قرارات مثالية. ولكنّ إخفاء المعلومات أمرٌ ضروريّ لتوسيع نطاق الحل، لأنه يحفظ جميع العقد من امتلاك معرفةٍ عالمية. من الصحيح دائمًا أن قابليةَ التوسع هي هدفُ تصميمٍ أكثر إلحاحًا من اختيار المسار الأمثل في الشبكات الكبيرة.

أخيرًا، نلاحظ أن هناك خدعة يمكن من خلالها لمسؤولي الشبكة أن يقرروا بصورةٍ أكثر مرونة أي موجهاتٍ تذهب في المنطقة 0. حيث تستخدم هذه الخدعة فكرة الرابط الافتراضي virtual link بين الموجّهات. يمكن الحصول على هذا الرابط الافتراضي عن طريق ضبط موجهٍ غير متصلٍ مباشرةً بالمنطقة 0 لتبادل معلومات توجيه المنطقة الرئيسية مع هذا الموجّه. حيث يمكن ضبط رابطٍ افتراضي من الموجّه R8 إلى الموجّه R1 على سبيل المثال، مما يجعل الموجّه R8 جزءًا من المنطقة الرئيسية، وسيشارك الموجه R8 الآن في إغراق الموجهات الأخرى في المنطقة 0 بإعلان حالة الرابط. تحدَّد تكلفة الرابط الافتراضي من الموجّه R8 إلى الموجّه R1 من خلال تبادل معلومات التوجيه التي تحدث في المنطقة 1، ويمكن أن تساعد هذه التقنية في تحسين التوجيه الأمثلي.

تحدّثنا عن فكرة أن الإنترنت منظمٌ ضمن أنظمةٍ مستقلة في بداية هذا الفصل، ويكون كل نظامٍ منها تحت سيطرة كيانٍ إداري منفصل. قد تكون الشبكة الداخلية المعقّدة لشركةٍ ما عبارةً عن نظام مستقل AS واحد، كما هو الحال بالنسبة للشبكة الوطنية لأي مزود خدمة إنترنت ISP. يوضح الشكل التالي شبكة بسيطة ذات نظامَين مستقلين autonomous systems:

هدف هذه الأنظمة المستقلة هو توفير طريقة إضافية لتجميع معلومات التوجيه بصورةٍ هرمية في شبكة إنترنت كبيرة، وبالتالي تحسين قابلية التوسُّع. نقسِّم الآن مشكلة التوجيه إلى جزأين: التوجيه داخل نظام مستقل واحد والتوجيه بين الأنظمة المستقلة. نشير إلى جزأي مشكلة التوجيه بالتوجيه بين النطاقات interdomain routing والتوجيه داخل النطاق intradomain routing، حيث يُطلق اسمٌ آخر على الأنظمة المستقلة في الإنترنت هو نطاقات التوجيه routing domains. بالإضافة إلى تحسين قابلية التوسع، يفصل نموذجُ النظام المستقل AS التوجيهَ داخل النطاق الذي يحدث في أحد الأنظمة المستقلة عن ذلك الذي يحدث في نظامٍ مستقل آخر. وبالتالي يمكن لكل نظامٍ مستقل تشغيلَ أي بروتوكولات توجيه يختارها داخل النطاق. ويمكنه استخدام بروتوكولات مساراتٍ ثابتة static routes أو بروتوكولات متعددة، إذا رغب في ذلك. وعندئذٍ تكون مشكلة التوجيه بين النطاقات هي مشكلة مشاركة أنظمةٍ مستقلة مختلفة لمعلومات إمكانية الوصول لبعضها بعضًا، وهذه المعلومات هي توصيف مجموعة عناوين IP التي يمكن الوصول إليها عبر نظامٍ مستقل معين.

ربما يكون التحدي الأهم للتوجيه بين النطاقات اليوم، هو حاجة كل نظامٍ مستقل لتحديد سياسات policies التوجيه الخاصة به. قد يبدو مثالٌ بسيط عن سياسة التوجيه المطبَّقة في نظامٍ مستقل معين كما يلي: "أُفضّلُ إرسال حركة مرور البيانات عبر النظام المستقل X بدلًا من النظام المستقل Y كلما أمكن ذلك، لكنني سأستخدم النظام المستقل Y إذا كان المسار الوحيد، ولا أريد مطلقًا نقل حركة مرور البيانات من النظام المستقل X إلى النظام المستقل Y أو العكس". ستكون مثل هذه السياسة نموذجية عندما تدفع المال لكل من النظامين المستقلين X و Y لتوصيل نظامك المستقل ببقية الإنترنت، والنظام المستقل X هو مزوّد الاتصال المفضل لديك، ويكون النظام المستقل Y هو البديل. لن تتوقع مساعدة النظامين المستقلين X و Y لنقل حركة المرور بينهما عبر شبكتك، وهذا ما يسمى بحركة المرور العابرة transit traffic. نظرًا لأنك ترى كلًا منهما كمزوّدَين (ومن المفترض أنك دفعت المال مقابل أداء هذا الدور). كلما زادت الأنظمة المستقلة التي تتصل بها، زادت السياسات المعقّدة التي قد تتبعها، خاصة عندما تفكر في مزوّدي الشبكة الرئيسية، الذين قد يتواصلون مع العشرات من مزوّدي الخدمة الآخرين ومئات العملاء ولديهم ترتيبات اقتصادية مختلفة (تؤثر على سياسات التوجيه) مع كل مزوّد.

يتمثل أحد أهداف التصميم الرئيسية للتوجيه بين النطاقات في أن السياسات مثل تلك المُبينة في المثال أعلاه، والسياسات الأعقد، يجب أن يدعمها نظام التوجيه بين النطاقات. ولِجعل المشكلة أكثر صعوبةً تحتاج إلى أن تكون قادرًا على تنفيذ مثل هذه السياسة دون أي مساعدة من أنظمة مستقلة أخرى، وأن تكون قادرًا على مواجهة الضبط الخاطئ misconfiguration المحتمل أو السلوك الضار الذي تسلكه أنظمة مستقلة أخرى. علاوةً على ذلك، تكون هناك غالبًا رغبةٌ في إبقاء السياسات خاصة، لأن الكيانات التي تدير الأنظمة المستقلة، والتي معظمها هم مزودو خدمة الإنترنت ISP، غالبًا ما تكون في منافسة مع بعضها بعضًا ولا تريد إعلان ترتيباتها الاقتصادية على الملأ.

كان هناك بروتوكولين رئيسيين للتوجيه بين النطاقات في تاريخ الإنترنت. الأول كان بروتوكول البوابة الخارجية Exterior Gateway Protocol أو اختصارًا EGP، الذي احتوى على عدد من القيود، ربما كان أشدها تقييدًا على هيكل topology شبكة الإنترنت بصورة كبيرة. صُمِّم بروتوكول EGP عندما كان للإنترنت هيكلٌ يشبه الشجرة كما هو موضح في الشكل الآتي، ولم يُسمح للهيكل أن يصبح أعم. لاحظ أنه في هذه البنية البسيطة الذي تشبه الشجرة، يوجد شبكة رئيسية وحيدة، والأنظمة المستقلة متصلة فقط كآباء وأبناء وليس كنظراء peers.

لقد كان بديل بروتوكول EGP هو بروتوكول البوابة الحدودية Border Gateway Protocol أو اختصارًا BGP، والذي تكرر من خلال أربعة إصدارات BGP-4. يُنظر إلى بروتوكول BGP غالبًا على أنه واحد من أكثر أجزاء الإنترنت تعقيدًا، لذلك سنغطي بعض أهم نقاطه هنا.

لا يقدم بروتوكول BGP، على عكس بروتوكول EGP، أي افتراضات تقريبًا حول كيفية اتصال الأنظمة المستقلة، فهو يشكّل رسمًا بيانيًا عشوائيًا. من الواضح أن هذا النموذج عام بما يكفي لاستيعاب الشبكات المتشابكة غير المبنيّة على أساس الشجرة non-tree-structured internetworks، مثل الصورة المبسَّطة لإنترنت متعدّد المزودين كما هو موضح في الشكل الآتي. (اتّضح أنه لا يزال هناك نوع آخر لبنية الإنترنت، كما سنرى لاحقًا، لكنها لا تشبه بساطة بنية الشجرة، ولا يضع بروتوكول BGP أي افتراضات حول هذه البنية).

يتكون الإنترنت اليوم، على عكس الإنترنت المبني على أساس الشجرة الموضحة في بداية هذا الفصل أو حتى الصورة البسيطة إلى حدٍ ما في الشكل السابق، من مجموعة غنية من الشبكات المترابطة، تديرها في الغالب شركات خاصة، أو مزودو خدمة الإنترنت ISP بدلًا من الحكومات. يقدم العديد من مزودي خدمة الإنترنت هذه الخدمة إلى "المستهلكين consumers"، أي الأفراد الذين لديهم حواسيب في منازلهم، بينما يقدم مزودو خدمةٍ آخرون شيئًا يشبه خدمة الشبكة الرئيسية القديمة، ويربطون بين مزودي الخدمة الآخرين وأحيانًا بين الشركات الكبيرة. ويُرتِّب العديد من مزودي الخدمة للترابط مع بعضهم بعضًا في نقطة تناظر peering point واحدة.

يمكننا البدء بتحديد بعض المصطلحات للحصول على فكرةٍ أفضل عن كيفية إدارة التوجيه بين هذا الترابط المُعقد للأنظمة المستقلة. نحدّد حركة المرور المحلية local traffic على أنها حركة المرور التي تنشأ عند العقد داخل النظام المستقل أو تنتهي عندها، وحركة المرور العابرة transit traffic على أنها حركة مرور تمر عبر نظامٍ مستقل. يمكن تصنيف الأنظمة المستقلة إلى ثلاثة أنواع:

• نظام مستقل جذري Stub AS: وهو نظام AS يحتوي على اتصال واحد فقط مع نظام AS آخر، فلن يحمل مثل هذا النظام المستقل سوى حركة المرور المحلية. الشركة الصغيرة في الشكل السابق هي مثال على نظام AS جذري.
• نظام مستقل متعدد طرق الاتصال Multihomed AS: هو نظام AS له اتصالات بأكثر من نظام AS آخر ولكنه يرفض نقل حركة المرور العابرة، مثل الشركة الكبيرة في الجزء العلوي من الشكل السابق.
• نظام مستقل عابر Transit AS :هو نظام AS له اتصالات بأكثر من نظام AS آخر وهو مصمم لنقل حركة المرور العابرة والمحلية، مثل مزودي الشبكة الرئيسية في الشكل السابق.

إن أهداف التوجيه بين النطاقات أعقد من إيجاد المسارات المثلى للتوجيه استنادًا إلى تقليل نوعٍ من مقياس الرابط link metric والتي تم تسليط الضوء عليها في فصل سابق. أولًا، من الضروري إيجاد مسار إلى الوجهة المقصودة خالٍ من الحلقات. ثانيًا، يجب أن تكون المسارات متوافقة مع سياسات الأنظمة المستقلة المختلفة على طول المسار، وكما رأينا بالفعل، قد تكون هذه السياسات معقدة على نحوٍ كيفي. يركّز التوجيه بين النطاقات interdomain على إيجاد مسار خالٍ من الحلقات non-looping ومتوافق مع السياسة وهي مشكلة أعقد للتحسين، بينما يُركِّز التوجيه داخل النطاق intradomain على مشكلة محددة جيدًا لتحسين تكلفة المسار القياسية.

هناك عوامل إضافية تجعل التوجيه بين النطاقات interdomain routing صعبًا. العامل الأول هو ببساطة مسألة التوسّع. يجب أن يكون موجّه الشبكة الرئيسية قادرًا على تمرير أي رزمةٍ متجهة إلى أي مكان على الإنترنت. وهذا يعني وجود جدول توجيه يوفر تطابقًا لأي عنوان IP صالح. ساعد توجيه CIDR في التحكم في عدد البادئات المميزة التي تُنقَل في توجيه الإنترنت الرئيسي، فهناك حتمًا الكثير من معلومات التوجيه التي يجب تمريرها والتي وصل عددها إلى ما يقارب 700,000 بادئة في منتصف عام 2018.

ينشأ تحدٍ آخر في التوجيه بين النطاقات من الطبيعة المستقلة للنطاقات. لاحظ أن كل نطاقٍ يمكنه تشغيل بروتوكولات التوجيه الداخلية الخاصة به واستخدام أي مخططٍ يختاره لإسناد المقاييس للمسارات. وهذا يعني أنه من المستحيل حساب تكاليف المسار الموجَّه لمسارٍ يعبر أنظمة مستقلة متعددة. قد تعني التكلفة 1000 عبر مزودٍ واحد مسارًا رائعًا، ولكن قد يعني ذلك مسارًا سيئًا وغير مقبول لمزودٍ آخر. ولذلك يعلن التوجيه بين النطاقات عن إمكانية الوصول reachability فقط. مفهوم قابلية الوصول هو في الأساس بيانٌ يقول "يمكنك الوصول إلى هذه الشبكة من خلال هذا النظام المستقل AS". هذا يعني أن التوجيه بين النطاقات لاختيار المسار الأمثل أمر مستحيل أساسًا.

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

ترتبط مسألة الثقة أيضًا بالحاجة إلى دعم السياسات المعقدة. فمثلًا قد تكون على استعداد للثقة بمزودٍ معين فقط عندما يعلن عن إمكانية الوصول إلى بادئات معينة، وبالتالي سيكون لديك سياسة تقول "استخدم النظام المستقل X للوصول إلى البادئات p و q فقط، إذا وفقط إذا أعلن النظام المستقل X عن إمكانية الوصول إلى تلك البادئات ".

يحتوي كل نظام AS على موجهٍ حدودي border router واحد أو أكثر تدخل وتغادر الرزمُ من خلاله النظام المستقل. حيث أن الموجّهات R2 و R4 في مثالنا البسيط في الشكل الآتي هي موجّهات حدودية. (عُرفت الموجّهات على مر السنين أحيانًا باسم البوابات gateways، ومن هنا جاءت أسماء البروتوكولَين BGP و EGP). الموجّه الحدودي هو ببساطة موجّه IP مكلَّفٌ بمهمة تمرير الرزم بين الأنظمة المستقلة.

يجب أن يكون لكل نظام AS مشاركٍ في بروتوكول BGP أيضًا متحدّثٌ speaker خاصٌ ببروتوكول BGP واحد على الأقل، وهو موجّه "يتحدّث speaks" ببروتوكول BGP إلى متحدّثي بروتوكول BGP آخرين في أنظمة مستقلة أخرى. من الشائع أن تجد أن الموجّهات الحدودية هي أيضًا متحدثات بروتوكول BGP، لكنه ليس واجبًا.

لا ينتمي بروتوكول BGP إلى أي من الصنفين الرئيسيتين لبروتوكولات التوجيه، وهما متّجه المسافة distance-vector وحالة الرابط link-state. يعلن بروتوكول BGP، على عكس هذه البروتوكولات، عن مسارات كاملة كقائمة معدودة من الأنظمة المستقلة للوصول إلى شبكة معينة، حيث يُسمى أحيانًا بروتوكول متّجه المسار path-vector لهذا السبب. يُعد الإعلان عن المسارات الكاملة ضروريًا لتمكين أنواع قرارات السياسة، الموضحة سابقًا، من أن تُتّخَذ وفقًا لرغبات نظام AS معين. كما أنه يُمكِّن من اكتشاف حلقات التوجيه بسهولة.

افترض مثال الشبكة البسيط الموضح في الشكل السابق لمعرفة كيفية عمل ذلك، وافترض أن مزودي الخدمة هم شبكات عابرة transit networks، بينما شبكات العملاء هي شبكات جذريّة stubs. يمكن لمتحدثِ بروتوكول BGP لنظام AS للمزود A (في الشكل هو AS 2) أن يعلن عن معلومات قابلية الوصول لكلٍ من أرقام الشبكة المُسندة للعملاء P و Q. وبالتالي سيقول "أن الشبكات 128.96 و 192.4.153 و 192.4.32 و 192.4.3 يمكن الوصول إليها مباشرةً من النظام المستقل AS 2". وعند تلّقي هذا الإعلان، يمكن للشبكة الرئيسية الإعلان عن أنه "يمكن الوصول إلى الشبكات 128.96 و 192.4.153 و 192.4.32 و 192.4.3 على طول المسار (AS 1 , AS 2)". وبالمثل، يمكنها الإعلان عن أنه "يمكن الوصول إلى الشبكات 192.12.69 و 192.4.54 و 192.4.23 على طول المسار (AS 1 , AS 3)".

تتمثل إحدى الوظائف المهمة لبروتوكول BGP في منع إنشاء مسارات الحلقات. افترض وجود الشبكة الموضحة في الشكل السابق. وهي تختلف عن الشبكة الموضَّحة في الشكل الذي قبله فقط في إضافة رابطٍ إضافي بين النظامين المستقلين AS 2 و AS 3، ولكن التأثير الآن هو أن الرسم البياني للأنظمة المستقلة يحتوي على حلقةٍ فيه. لنفترض أن النظام المستقل AS 1 تعلّم أنه يمكنه الوصول إلى الشبكة 128.96 من خلال النظام المستقل AS 2، لذلك يعلن عن هذه الحقيقة للنظام المستقل AS 3، والذي بدوره يعلن عنها مرة أخرى إلى النظام المستقل AS 2. يمكن للنظام المستقل AS 2 الآن تحديد أن النظام المستقل AS 3 هو المسار المفضل للرزم الموجهة للشبكة 128.96 في حالة عدم وجود أية آلية لمنع الحلقة. إذا بدأ النظام المستقل AS 2 في إرسال رزمٍ، موجهةٍ إلى الشبكة 128.96، إلى النظام المستقل AS 3 ، فإن النظام المستقل AS 3 سيُرسلها إلى النظام المستقل AS 1، وبالتالي سيعيد النظام المستقل AS 1 تلك الرزم إلى النظام المستقل AS 2، وستدور في حلقةٍ إلى الأبد. يُمنع حدوث ذلك عن طريق حمل مسار النظام المستقل الكامل في رسائل التوجيه. بالتالي سيحوي الإعلان عن المسار في هذه الحالة إلى الشبكة 128.96 الذي استلمه النظام المستقل AS 2 من النظام المستقل AS 3 على مسار النظام المستقل (AS 3 , AS 1 , AS 2 , AS 4). يرى النظام المستقل AS 2 نفسه في هذا المسار، وبالتالي يستنتج أن هذا ليس مسارًا مفيدًا لاستخدامه.

من الواضح أن أرقام AS المحمولة في بروتوكول BGP يجب أن تكون فريدة لكي تعمل تقنية منع الحلقة هذه. فيمكن للنظام المستقل AS 2 التعرف على نفسه فقط في مسار AS في المثال أعلاه إذا لم يعرّف نظام مستقلٌ آخر نفسه بنفس الطريقة. يبلغ طول أرقام AS الآن 32 بتًا، وتُسندها سلطة مركزية لضمان هذا التفرُّد uniqueness.

سيعلن نظامٌ مستقل عن المسارات التي يراها جيدةً بما يكفي لنفسه فقط. إذا كان متحّدث بروتوكول BGP قادرًا على الاختيار من بين عدة مسارات مختلفة إلى وجهةٍ ما، سيختار أفضلها وفقًا لسياساته المحلية الخاصة، ثم سيكون هذا هو المسار الذي يعلن عنه. إن متحدّث بروتوكول BGP غير ملزمٍ بالإعلان عن أي مسار إلى أية وجهة، حتى لو كان لديه مسار. هذه هي الطريقة التي يمكن بها لِلنظام المستقل تنفيذ سياسة عدم توفير عبور not providing transit من خلال رفض الإعلان عن مسارات البادئات غير الواردة في هذا النظام المستقل، حتى لو كان يعرف كيفية الوصول إليها.

يجب أن يكون متحدثو بروتوكول BGP قادرين على إلغاء المسارات التي أُعلِن عنها مسبقًا عند فشل الروابط وتغيير السياسات. ويحدث ذلك باستخدام شكلٍ من أشكال الإعلان السلبي يُعرف باسم المسار المسحوب withdrawn route. تُنقل معلومات قابلية الوصول الإيجابية والسلبية في رسالة تحديث BGP، ويعرض الشكل التالي صيغة هذه الرسالة. (لاحظ أن الحقول في هذا الشكل هي من مضاعفات 16 بت، على عكس صيغ الرزم الأخرى في هذا الفصل):

يُعرَّف بروتوكول BGP، على عكس بروتوكولات التوجيه الموصوفة في الفصل السابق، للتشغيل فوق بروتوكول TCP، وهو بروتوكول النقل الموثوق. يجب عدم إرسال معلومات مُرسلة من متحدِّثٍ إلى آخر مرةً أخرى، نظرًا لأن متحدثي بروتوكول BGP يمكنهم الاعتماد على بروتوكول TCP ليكونوا موثوقين. وبالتالي طالما لم يتغير شيء، يمكن لمتحدّث بروتوكول BGP ببساطة إرسال رسالة تنشيط اتصال keepalive عرَضية تقول "ما زلت هنا ولم يتغير شيء". إذا تعطل هذا الموجّه أو انفصل عن نظيره، سيقف عن إرسال رسائل تنشيط الاتصال، وستَفترِض الموجّهات الأخرى التي تعلمت المسارات منه أن هذه المسارات لم تعد صالحة.

تبين أن هناك عددًا قليلًا من السياسات المشتركة التي تعكس العلاقات المشتركة بين الأنظمة المستقلة. يوضح الشكل التالي العلاقات الأكثر شيوعًا:

العلاقات الثلاث المشتركة والسياسات التي تتماشى معها هي:

• المزوِّد - العميل Provider-Customer: يعمل المزودون على توصيل عملائهم ببقية الإنترنت. قد يكون العميل شركة، أو قد يكون مزود خدمة إنترنت أصغر (الذي قد يكون له عملاء خاصين به). لذا فإن السياسة الشائعة هي الإعلان عن جميع المسارات التي تعرفها لعميلك، والإعلان عن المسارات التي تتعلمها من عميلك إلى الجميع.
• العميل - المزوّد Customer-Provider: يريد العميل في الاتجاه الآخر توجيه حركة المرور إليه (وعملائه، إذا كان لديه) بواسطة مزوده، ويريد أن يكون قادرًا على ارسال حركة المرور إلى بقية الإنترنت من خلال مزوّده. لذا فإن السياسة الشائعة في هذه الحالة هي الإعلان عن البادئات والمسارات الخاصة بك التي تعلّمتها من عملائك إلى مزود الخدمة الخاص بك، والإعلان عن المسارات التي تعلمتها من مزود الخدمة إلى عملائك، ولكن لا تعلن عن المسارات التي تعلّمتها من مزودٍ إلى مزودٍ آخر. والسبب في الجزء الأخير هو التأكد من أن العميل لا يجد نفسه عاملًا في مجال نقل حركة المرور من مزود إلى آخر، وهذا ليس في مصلحته إذا كان يدفع لمزودي الخدمة لنقل حركة المرور نيابة عنه.
• النظير peer: الخيار الثالث هو التناظر المتماثل symmetrical peering بين الأنظمة المستقلة. يكون مزودي الخدمة الذين يعدّون أنفسهم متساوين ونظائر، بحيث يمكنهم الوصول إلى عملاء بعضهم بعضًا دون الحاجة للدفع لمزوّد آخر. تتمثل السياسة المعتادة هنا في الإعلان عن المسارات التي تعلمتها من عملائك إلى نظيرك peer، والإعلان عن المسارات التي تعلمتها من نظيرك إلى عملائك، ولكن لا تعلن عن المسارات من نظيرك إلى أي مزود أو العكس.

شيء واحد يجب ملاحظته حول هذا الأسلوب وهو إعادته بعض الهيكلة إلى شبكة الإنترنت التي تظهر أنّها غير مُنظّمة unstructured. لدينا الشبكات الجذرية stub networks في الجزء السفلي من التسلسل الهرمي، وتُمثّل هذه الشبكات عملاءٌ لمزودٍ واحد أو أكثر، ونرى مع تقدمنا في التسلسل الهرمي مزوّدي الخدمة الذين لديهم مزودين آخرين كعملاءٍ لهم. لدينا في الجزء العلوي مزودون لديهم عملاء ونظائر ولكنهم ليسوا عملاء لأي شيء، ويُعرف هؤلاء المزوّدون بمزودي الطبقة الأولى Tier-1.

لنعد إلى السؤال الحقيقي: كيف يساعدنا كل هذا في بناء شبكات قابلة للتوسّع؟ أولًا، يكون عدد العقد المشاركة في بروتوكول BGP بترتيب عدد الأنظمة المستقلة، وهو أصغر بكثير من عدد الشبكات. ثانيًا، إن العثور على مسار جيد بين النطاقات هو فقط مسألة إيجاد مسار إلى الموجه الحدودي الصحيح، والذي لا يوجد سوى عدد قليل منه لكل نظام AS. وبالتالي قسّمنا مشكلة التوجيه بدقة إلى أجزاءٍ يمكن التحكم فيها، باستخدام مستوٍ جديد من التسلسل الهرمي لزيادة قابلية التوسُّع. أصبح تعقيد التوجيه بين النطاقات الآن من رتبة عدد الأنظمة المستقلة، كما أن تعقيد التوجيه داخل النطاق يكون من رتبة عدد الشبكات في نظام AS واحد.

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

لنبدأ بموقف بسيط جدًا، وهو أيضًا شائع جدًا. من الواضح أن الموجّه الحدودي والذي يتصل فقط بالأنظمة المستقلة الأخرى عند نقطة واحدة، هو الخيار الوحيد لجميع المسارات خارج نظام AS في حالة نظام مستقل جذري stub. يمكن لهذا الموجّه حقن مسارٍ افتراضي default route في بروتوكول التوجيه داخل النطاق، وهذا بيانٌ مفاده أن أية شبكة لم يعلن عنها صراحةً في بروتوكول النطاق الداخلي يمكن الوصول إليها من خلال الموجّه الحدودي. تذكّر، من تمرير بروتوكول IP، أنّ المدخلة الافتراضية default entry في جدول التمرير تأتي بعد كل المدخلات الأكثر تحديدًا، وهي تقابل أي شيءٍ فشلَ في مطابقة مدخلةٍ محددة.

تتمثل الخطوة التالية في التعقيد في جعل الموجّهات الحدودية تضخ مساراتٍ معينة تعّلمتها من خارج نظام AS. افترض، على سبيل المثال، الموجّه الحدودي لنظام AS الذي يتصل بعميل AS. يمكن لهذا الموجّه معرفة أن بادئة الشبكة 192.4.54 / 24 موجودة داخل عميل AS، إما من خلال بروتوكول BGP أو بسبب ضبط المعلومات في الموجه الحدودي، ويمكنه حقن مسارٍ لهذه البادئة في بروتوكول التوجيه الذي يعمل داخل مزود AS. سيكون هذا إعلانًا من النوع: "لدي رابطٌ بالبادئة 192.4.54 / 24 بتكلفة X". قد يتسبب ذلك في معرفة الموجّهات الأخرى في مزود AS أن هذا الموجّه الحدودي هو المكان المناسب لإرسال الرزم المخصَّصة لتلك البادئة.

يأتي المستوى الأخير من التعقيد في الشبكات الرئيسية، التي تتعلم الكثير من معلومات التوجيه من بروتوكول BGP بحيث يصبح حقنها في بروتوكول داخل النطاق مكلفًا للغاية. إذا أراد الموجه الحدودي، على سبيل المثال، حقن 10000 بادئة تعلّمها من نظام AS آخر، فسيتعيّن عليه إرسال رزم حالة رابط كبيرة جدًا إلى الموجهات الأخرى في نظام AS، وستصبح حسابات المسار الأقصر معقدةً للغاية. لذلك تستخدم الموجّهات في الشبكة الرئيسية متغيرًا من بروتوكول BGP يسمى BGP الداخلي interior BGP أو اختصارًا iBGP لإعادة توزيع المعلومات التي تعلّمتها باستخدام متحدّثي بروتوكول BGP على حواف نظام AS إلى جميع الموجهات الأخرى في نظام AS بفعالية. (يعمل البديل الآخر لبروتوكول BGP بين الأنظمة المستقلة ويُسمى BGP الخارجي exterior BGP أو اختصارًا eBGP. يمكّن بروتوكول iBGP أي موجهٍ في نظام AS من التعرف على أفضل موجهٍ حدودي لاستخدامه عند إرسال رزمةٍ إلى أي عنوان، ويتتبع كل موجه في نظام AS في الوقت نفسه كيفية الوصول إلى كل موجهٍ حدودي باستخدام بروتوكول تقليدي داخل النطاق بدون معلوماتٍ محقونة. يكون كل موجهٍ في نظام AS قادرًا على تحديد العقدة التوجيهية التالية المناسبة لجميع البادئات من خلال الجمع بين هاتين المجموعتين من المعلومات.

افترض شبكة المثال البسيط التي تمثل نظامًا مستقلًا واحدًا في الشكل السابق. تتحدَث الموجّهات الحدودية الثلاثة، A و D و E، بروتوكول eBGP مع أنظمة مستقلة أخرى وتتعلّم كيفية الوصول إلى البادئات المختلفة. تتواصل الموجّهات الحدودية الثلاثة هذه مع الموجهات الأخرى ومع الموجّهات الداخلية B و C من خلال إنشاء شبكة من جلسات iBGP بين جميع الموجّهات في النظام المستقل. دعنا نركز الآن على كيفية بناء الموجّه B لرؤيته الكاملة لكيفية تمرير الرزم إلى أية بادئة. انظر إلى الجزء العلوي الأيسر من الشكل الآتي، والذي يعرض المعلومات التي يتعلّمها الموجّه B من جلسات iBGP الخاصة به. يتعلم أنه من الأفضل الوصول إلى بعض البادئات عبر الموجّه A، والبعض الآخر عبر الموجّه D، والبعض الآخر عبر الموجّه E. وفي الوقت نفسه، تعمل جميع الموجّهات في النظام المستقل أيضًا على تشغيل بعض بروتوكولات التوجيه داخل النطاق مثل بروتوكول معلومات التوجيه Routing Information Protocol أو اختصارًا RIP أو بروتوكول OSPF. (المصطلح العام لبروتوكولات داخل النطاق هو بروتوكول بوابة داخلية interior gateway protocol أو اختصارًا IGP). يتعلم الموجّه B كيفية الوصول إلى العقد الأخرى داخل النطاق من هذا البروتوكول المنفصل تمامًا، كما هو موضح في أعلى الجدول الأيمن من الشكل الآتي. يحتاج الموجه B إلى إرسال رزمٍ إلى الموجّه C للوصول إلى الموجّه E على سبيل المثال. أخيرًا في الجدول السفلي، يجمع الموجه B الصورة بأكملها معًا، ويجمّع المعلومات حول البادئات الخارجية التي تعلمها من iBGP مع المعلومات حول المسارات الداخلية إلى الموجهات الحدودية المتعلَّمة من بروتوكول IGP. وبالتالي إذا أمكن الوصول إلى بادئة مثل 18.0 / 16 عبر الموجه الحدودي E، وكان أفضل مسار داخلي إلى الموجه E هو عبر الموجه C، فسيترتّب عن ذلك إعادة توجيه أية رزمة مخصَّصة للبادئة 18.0 / 16 إلى الموجه C، ويمكن بهذه الطريقة لأي موجهٍ في النظام المستقل إنشاء جدول توجيه كامل لأية بادئةٍ يمكن الوصول إليها عبر بعض موجهات الحدود في النظام المستقل.

ترجمة -وبتصرّف- للقسم Global Internet من فصل Advanced Internetworking من كتاب Computer Networks: A Systems Approach.

• المقال السابق: تطبيق مبدلات وموجهات الشبكات الحاسوبية برمجيا وعتاديا
• التشبيك Internetworking بين أنواع مختلفة من الشبكات الحاسوبية
• شبكة الإنترنت باستخدام بروتوكول IP