أساسيات الشبكات الإصدار السادس من بروتوكول IP

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

المنظور التاريخي Historical Perspective

بدأت منظمة 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 × 10³⁸ عقدة بافتراض كفاءة 100%، في حين أن الإصدار 4 يمكن أن يعالج 4 مليارات عقدة إذا وصلت كفاءة إسناد العناوين إلى 100%. كما رأينا وعلى الرغم من ذلك، فإن الكفاءة بنسبة 100% في إسناد العناوين أمرٌ غير محتمل. أظهرت بعضُ التحليلات لمخططات العنونة الأخرى، مثل تلك الخاصة بشبكات الهاتف الفرنسية والأمريكية وكذلك تحليلات الإصدار IPv4، بعضَ الأرقام التجريبية لكفاءة إسناد العناوين. من المتوقع أن يوفر حيز عناوين IPv6، استنادًا إلى أكثر تقديرات الكفاءة تشاؤمًا المستمدة من هذه الدراسة، أكثر من 1500 عنوان لكل قدم مربع من سطح الأرض، وهذا بالتأكيد سيخدمنا جيدًا حتى عندما يكون للأجهزة على كوكب الزهرة عناوين IP.

تخصيص Allocation حيز العناوين

إن عناوين 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.

صيغة العنوان Address Notation

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

47CD:1234:4422:ACO2:0022:1234:A456:0124

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

47CD:0000:0000:0000:0000:0000:A456:0124

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

47CD::A456:0124

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

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

::FFFF:128.96.33.81

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

عناوين البث الأحادي العالمية Global Unicast Addresses

إن أهم نوعٍ من العناوين التي يجب أن يوفرها 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.

صيغة الرزمة Packet Format

إن صيغة ترويسة 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 هو الحاجة إلى عناوينٍ أكبر.

الضبط التلقائي Autoconfiguration

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

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

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

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

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

numref”Table %s <fig-v6tab> (1111 1110 10)

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

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

التوجيه المباشر من المصدر Source-Directed Routing

ترويسة التوجيه 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