الرئيسيةعريقبحث

بروتوكول الإنترنت (الإصدار السادس)

هو بروتوكول تشبيك يعمل في طبقة الشبكة حسبَ نموذج الاتصالات المعياري، يُستعمل هذا البروتوكول في شبكات البيانات ويقدم خدمات العنونة والتقطيع وإدارة حركة البيانات

☰ جدول المحتويات

هذه المقالة عن بروتوكول الإنترنت (الإصدار السادس). لتصفح عناوين مشابهة، انظر بروتوكول الإنترنت (توضيح).

الإصدار السادس من بروتوكول الإنترنت (Internet Protocol Version 6 اختصاراً IPv6)‏ هو بروتوكول تشبيك يعمل في طبقة الشبكة حسبَ نموذج الاتصالات المعياري، يُستعمل هذا البروتوكول في شبكات البيانات ويقدم خدمات العنونة والتقطيع وإدارة حركة البيانات. طوِّر الإصدار السادس في عام 1995م على يد مجموعة مهندسي الإنترنت بصفته حلاً نهائياً لمشكلة استنفاد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت.[2]

الإصدار السادس من بروتوكول الإنترنت
Internet Protocol version 6
IPv6 header-ar.svg
ترويسة الإصدار السادس من بروتوكول الإنترنت
اختصار IPv6
الوظيفة بروتوكول تشبيك
المُطوِّر مجموعة مهندسي الإنترنت
التاريخ ديسمبر 1995م
حل محل بروتوكول الإنترنت (الإصدار الرابع) 
أثر بـ الإصدار الرابع من بروتوكول الإنترنت
طبقة نموذج الاتصال المعياري طبقة الشبكة
وثيقة طلب التعليقات RFC 8200[1]

يُعرِّف البروتوكول ترويسة ثابتة الطول: 40 بايتاً، تضاف إلى جميع رزم البيانات التي يُنشئها، وهناك أيضاً مجموعة من ترويسات التوسعة التي يمكن استخدامها بشكل اختياري حسب الحاجة عند أداء وظائف معينة مثل التقطيع والتوجيه. يمكن أن تحتوي رزمة بيانات الإصدار السادس على أكثر من ترويسة توسعة تلي ترويسة البروتوكول.[3]

يُعرِّف البروتوكول فضاءً من العناوين يضم 3.4x1038 حوالي عنواناً طول كل منها 128 بتاً.[4] يُقسَّم الفضاء رياضياً إلى فضاء البث فريد الوجهة وإلى فضاء البث المجموعاتي، وتدير هيئة العناوين المُخصصة كلا الفضاءَين. يدعم البروتوكول ثلاثة أنماط من العنونة هي العنونة فريدة الوجهة وعنونة البث نحو الأقرب وعنونة البث المجموعاتي، ولا يدعم البث العام.[5]

تصف مُحددات البروتوكول آليةً لتقطيع رزم البيانات في مصادرها فقط، وذلك لأن البروتوكول يدعم أيضاً آليةً لاكتشاف حجم وحدة النقل العظمى لمسار رزمة بيانات ما قبل إرسالها، فيختار طول رزمة متوافقاً معه، ولا يعود هناك حاجة لإجراء التقطيع في عقد الشبكة الموجودة على المسار كما هو الحال في الإصدار الرابع من البروتوكول. في الوجهة النهائية، تحصل عملية إعادة التجميع، وفيها يعاد تشكيل الرزمة الأصلية انطلاقاً من القطع المُستقبلة.[6]

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

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

نبذة تاريخية

أصناف عناوين البث فريد الوجهة في الإصدار الرابع من بروتوكول الإنترنت وبنية عناوينها.
خط زمني لتطوُّر البروتوكولات الرئيسة في حزمة بروتوكولات الإنترنت
خط زمني للمعايير الناظمة للإصدار السادس من بروتوكول الإنترنت والبروتوكولات الرديفة له.

بدءاً من سبعينيات القرن العشرين، ابتدأ نمو وانتشار شبكة بيانات حول العالم، كانت نقطة الانطلاق من المراكز البحثية والجامعات في الولايات المتحدة الأمريكية، وسُميت هذه الشبكة بالأربانت في بداياتها. اعتمدت هذه الشبكة على مجموعة من البروتوكولات التي طورتها وكالة مشاريع البحوث المتطورة الدفاعية، ومنها الإصدار الرابع من بروتوكول الإنترنت الذي استخدم لعنونة التجهيزات المُتصلة مع الشبكة بصورة فريدة عالمياً.[11] في مطلع التسعنيات، بدأ استخدام الإنترنت تجارياً، وأصبح من الشائع تقديم الخدمات أو بيع المُنتجات عبر الإنترنت، وسبب هذا نمواً سريعاً للشبكة خاصة في الولايات المُتحدة الأمريكية.[12]

اعتمد الإصدار الرابع من بروتوكول الإنترنت على نظام عنونة مبني على فضاء يبلغ طول العنوان فيه 32 بتاً، وُقسِّم هذا الفضاء إلى أصناف، خُصصت ثلاثٌ منها لعنونة البث فريد الوجهة، وهي الصنف A وعدد أفضيته 128 صنفاً، وهو أكبر الأصناف حجماً (224 عنواناً في كل صنف)، والصنف B وضمَّ الفضاء 214 صنفاً في كل منها 216 عنواناً، والصنف C وهو أكثر الأصناف عدداً بواقع 221 صنفاً، ولكنها أصغرها حجماً، حيث يضمّ كل صنف 28 عنواناً.[13][14] وخُصص فضاء رابع للبث المجموعاتي، وسمي الصنف D.[15]

في شهر نوفمبر من العام 1991م، شكَّلت مجموعة مهندسي الإنترنت، وهي الهيئة الناظمة لتطوير معايير الإنترنت، مجموعة عمل التوجيه والعنونة والمعروفة اختصاراً باسم رُوْد (Routing and Addressing اختصاراً ROAD)‏ بهدف معالجة هذه المشكلة، وعرَّفت هذه المجموعة ثلاثَ مُشكلات رئيسيَّة تعيق نمو الإنترنت:[16]

  1. استنفاد فضاء عناوين الصنف B، وهذه هي نتيجة لغياب فضاء عناوين يناسب منظمة متوسطة الحجم، ففضاء الصنف C صغير الحجم، وهو ما يدفع هذه المنظمات لاستعمال فضاء من الصنف B، على الرغم من أن حجم الفضاء يزيد بكثير عن حاجة المنظمة.
  2. نمو جداول التوجيه في موجهات الإنترنت لتصبح بجاجة إلى قدرات معالجة غير متوافرة بالبرمجيات أو المعدات المتوافرة.
  3. الاستنفاد النهائي لفضاء عناوين الإصدار الرابع.

لقد كانت المشكلتان الأولى والثانية وشيكتا الحصول، وكان يتوقع حصول أيٍّ منهما بدءاً من العام 1993م.[17] نتيجة لذلك، طوِّرت الحلول ضمن إستراتيجيتان، تشمل الأولى حلولاً سريعة التطبيق قصيرة الأمد، وهي تستهدف المشكلتان الأولى والثانية، أمَّا الثانية، فتُعنى بحلٍ نهائيٍّ دائمٍ طويل الأمد.[18] في إطار الإستراتيجية الأولى، طوِّر التوجيه غير الصنفي بين النطاقات في العام 1992م،[16] وتلاه تقنية ترجمة عنوان الشبكة في العام 1994م [19]. نجحت حلول الإستراتيجية قصيرة الأمد في إطالة عمر الإصدار الرابع من بروتوكول الإنترنت من خلال إبطاء استنفاد الفضاء.[20] ولكن وعلى أي حال، فبعد أكثر من عقد من الزمن، وتحديداً في شهر يناير من العام 2011م، استُنفد فضاء عناوين الإصدار الرابع من بروتوكول الإنترنت على المستوى العالمي تماماً.[21]

فيما يخص الإستراتيجية طويلة الأمد، فقد بدأت مجموعة مهندسي الإنترنت في العمل منذ مطلع التسعينات على تطوير إصدار جديد من بروتوكول الإنترنت. في العام 1993م، كان التوجه العام هو طرح نظام عنونة جديد موسع في إصدار جديد من بروتوكول الإنترنت، ولذلك طلبت المجموعة اقتراحات في هذا الشأن مع نهاية تلك السنة.[22] في نهاية العام 1993م أيضاً، شُكِّلت المجموعة نطاق عمل جديد سمته الجيل التالي من بروتوكول الإنترنت (IP Next Generation اختصاراً IPng)‏،[23] وعمل 15 مهندساً من اختصاصات متنوعة على مراجعة ودراسة الاقتراحات لصياغة حل شامل.[24]

في شهر ديسمبر من العام 1995، صدر المعيار الأصلي للإصدار السادس من بروتوكول الإنترنت تحت الاسم الرمزي RFC 1883.[2] وصدر معه أيضاً المعياران الأصليان لمُحددات بنية العناوين في الإصدار السادس ولبروتوكول رسائل التحكم للإصدار السادس، وحملت وثائق طلب التعليقات الخاصة بهما الاسمان الرمزيان RFC 1884 وRFC 1885 على الترتيب.[25][26] لاحقاً في شهر أغسطس من العام التالي، صدر المعياران الأصليان لبروتوكول اكتشاف الجيران ولآلية التهيئة الذاتية الآلية، وحملا الاسمان الرمزيان على RFC 1970 وRFC 1971 على الترتيب.[27][28]

في ديسمبر من العام 1998م، صدرت مجموعة تحديثات جديدة تضمنت أربعة وثائق طلب تعليقات تمتد أسماؤها الرمزية من RFC 2460 حتى RFC 2463 وشملت معاييرَ جديداً للإصدار السادس، ولبروتوكول رسائل التحكم الخاص به ولبروتوكول اكتشاف الجيران ولآلية التهيئة الذاتية الآلية.[29][30][31][32] واستمرت التحديثات بالصدور منفصلة أو بشكل مجموعات، فصدرت ثلاث معايير متتابعة لبنية عناوين الإصدار السادس، آخرها في فبراير من العام 2006م، وحمل الاسم الرمزي RFC 4291،[33] وصدر معيارٌ ثالث لبروتوكول رسائل التحكم للإصدار السادس في مارس من العام 2006م أيضاً، وحمل الاسم الرمزي RFC 4443،[34] وصدر زوجٌ ثالث لبروتوكول اكتشاف الجيران ولآلية التهيئة الذاتية الآلية في فبراير 2007م وحملا الاسمان الرمزيان على RFC 4861 وRFC 4862 على الترتيب.[35][36] وأخيراً صدر المعيار الحالي للإصدار السادس من بروتوكول الإنترنت في يونيو من العام 2017م وحمل الاسم الرمزي RFC 8200.[1]

مبدأ العمل

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

بشكل مشابه للإصدار الرابع، يقدم الإصدار السادس خدمتي العنونة والتقطيع.[39] فيما يخص العنونة فإن الإصدار السادس من بروتوكول الإنترنت يُعرِّف فضاء عناوين يضم 2128 عنواناً، ويدعم ثلاث أنماط من العنونة: هي عنونة البث فريد الوجهة، وعنونة البث المجموعاتي وعنونة البث نحو الأقرب ، أما البث العام فهو غير مدعوم في هذا البروتوكول.[5] فيما يخص التقطيع، يمكن للبروتوكول أن يقطع رزم بيانات الإصدار السادس في مصدرها فقط، وأن يعيد تجميع القطع في وجهتها النهائية فقط، ولا حاجة لتقطيع الرزم على طول المسار، وذلك لامتلاك مصدر رزم البيانات آليةً للتعرف على حجم وحدة النقل العظمى للمسار قبل البدء بالإرسال، ما يسمح له باختيار الحجم المناسب وتقطيع رزمة البيانات على أساسه.[40]

أما فيما يخص إدارة حركة البيانات، يدعم البروتوكول آليتين منفصلتين هما الإدارة باستعمال تدفق البيانات والإدارة باستعمال صنف الخدمة. فيما يخص إنشاء تدفقات رزم البيانات، فهي آلية يدعمها للبروتوكول تسمح بتعريف مجموعة محددة رزم البيانات التي تُنقل بين مصدر لرزم البيانات ووجهة واحدة لها على الأقل. وتُعرِّف هذه الآلية التدفق بأنّه مجموعة من كلُ رزم البيانات التي تنتقل في اتجاه واحد عبر قناة اتصال مُحددة . ولا يلزم أن يكون المضيف الوجهة فريداً فيمكن لهذه الآلية أن تدعم بالإضافة لرزم البث فريد الوجهة رزمَ البث المجموعاتي ورزمَ البث نحو الأقرب.[41] تساعد عملية إنشاء تدفقات الرزم على تصنيف حركة البيانات وتقديم الخدمة المناسبة لها اعتماداً على ترويسة بروتوكول الإصدار السادس فقط بدون الحاجة لترويسات الطبقات العليا.[7] أما فيما يخص استعمال صنف الخدمة، فهي آلية مشابهة لما طُبِّق في الإصدار الرابع من البروتوكول، وفيها يُستعمل حقل صنف الخدمة لتعريف أصناف مختلفة من الخدمات المطلوبة، ويُصار بعدها إلى معالجة كل رزمة وتقديم الخدمات إليها بحسب قيمة هذا الحقل فيها.[8]

بالإضافة لذلك، تُعرِّف مُحددات البروتوكول المُصطلحات التالية وتستخدمها وثائق طلب التعليقات ذات الصلة:[42]

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

الترويسات

أمثلة متنوعة عن تتابع الترويسات في الإصدار السادس من بروتوكول الإنترنت.

تتابع الترويسات

يُضيف الإصدار السادس من بروتوكول الإنترنت ترويسة خاصة به في عملية التغليف عند إنشاء رزمة البيانات، وطول هذه الترويسة ثابت وهو 40 بايت دائماً.[43] يمكن أيضاً أن تضاف معلومات أخرى تخصّ طبقة الشبكة في ترويسات خاصة تُسمَّى ترويسات التوسعة، تضاف بشكل اختياري بعد ترويسة بروتوكول الإصدار السادس، وقبل ترويسة بروتوكول الطبقة العليا. ولترويسات التوسعة أنواع هي: ترويسة خيارات المسار وترويسة القطعة وترويسة خيارات الوجهة وترويسة التوجيه وترويسة التحقق من الهوية وترويسة تغليف الحمل الأمني.[44]

لكل نوع ترويسة مُعرِّف مُحدد، وتحتوي الترويسات جميعها، بما في ذلك ترويسة الإصدار السادس، على حقل مُخصص ليضم قيمة مُعرِّف نوع الترويسة التالية، ويسمح ذلك بإمكانية إنشاء تتابع من الترويسات، حيث تشير قيمة حقل المُعرِّف في كل ترويسة إلى نوع الترويسة التالية،[43] في حين تُخصص القيمة 59 للإشارة إلى عدم وجود ترويسة تالية وتستعمل في الترويسة الموجودة في نهاية التتابع.[45][46] تدير هيئة أرقام الإنترنت المُخصصة ضبط القيم المعيارية لمُعرفات أنواع الترويسة.[47] وإذا وردت عدة ترويسات، فتكون بالترتيب التالي:[48](1)

  1. ترويسة بروتوكول الإنترنت
  2. ترويسة خيارات المسار
  3. ترويسة خيارات الوجهة (للخيارات التي ستعالج في الوجهة الأولى على المسار أو أي وجهة بينية أخرى مُحددة بترويسة التوجيه ما خلا الوجهة النهائية)
  4. ترويسة التوجيه
  5. ترويسة القطعة
  6. ترويسة تغليف الحمل الأمني
  7. ترويسة خيارات الوجهة (للخيارات التي ستُعالج في الوجهة النهائية فقط)
  8. ترويسة بروتوكول الطبقة العليا

يجب أن يكون طول ترويسة التوسعة عدداً صحيحاً من مضاعفات 8 بايت، أي 16 و24 و32 إلخ ... وذلك ضروريٌ لمحاذاة الترويسات المتتابعة، وتضم بعض الترويسات عدداً من الخيارات التي يكون لها بنية محددة أيضاً بحيث تصطف وتُحاذَى تلقائيَّاً داخل الترويسة.[44]

فيما خلا ترويسة خيارات المسار، لا تُعالَج أي ترويسة على طول مسار رزمة، ولا تضاف أي ترويسة لرزمة البيانات أو تحذف منها حتى تبلغ الرزمة العنوان المحدد بعنوان الوجهة في ترويسة البروتوكول.[49](2) إنَّ وجود ترويسات التوسعة في رزمة بيانات ما هو مسألة اختيارية، أما دعمها فهو إلزامي في أي تنفيذ للإصدار السادس من البروتوكول،[44] ولكن هناك ترويسات أخرى مُعرَّفة لأغراض خاصة، لا يلزم أن تكون مدعومة في كل تنفيذ، منها على سبيل المثال ترويسة خيارات الحركة [50] ترويسة بروتوكول هوية المضيف .[51]

بنى الترويسات

ترويسة البروتوكول

ترويسة الإصدار السادس من بروتوكول الإنترنت.

يبلغ طول ترويسة الإصدار السادس 40 بايت، وتتكون من ثمانية حقول هي وفقاً لترتيب وردوها:[52]

  • حقل رقم الإصدار: وطوله 4 بت، ويمثل رقم الإصدار، وقيمته هي 6 دائماً في ترويسة الإصدار السادس من بروتوكول الإنترنت.
  • حقل صنف حركة البيانات: وطوله 8 بت، ويحتوي على مُعرِّف رقمي يمكن ضبطه لتحديد جودة الخدمة التي ستحصل عليها رزمة البيانات.
  • حقل لافتة التدفق: وطوله 20 بت، ويحتوي على مُعرِّف رقمي يُحدد التدفق الذي تنتمي إليه رزمة البيانات، ويمكن أن تستعمل هذه القيمة في تحديد كيفية معالجة الرزمة في الموجهات التي تعالج الرزمة على طول المسار نحو وجهتها.
  • حقل طول الحمولة: وطوله 16 بت، ويحتوي عدد صحيح موجب يمثل طول حمولة الرزمة التي توجد فيها الترويسة مُقدراً بالبايت، يشمل ذلك ترويسات التوسعة جميعها والتي تلي ترويسة الإصدار السادس.
  • حقل الترويسة التالية: وطوله 8 بت، ويحدد نوع الترويسة التالية، التي تلي هذه الترويسة، إذا كانت الترويسة مغايرة لترويسات التوسعات، فإن قيم هذه الحقل مُطابقة للقيم المُستعملة في الإصدار الرابع من البروتوكول.[53]
  • حقل عدد القفزات: وطوله 8 بت، ويحتوي عدداً صحيحاً موجباً. يقوم كل موجه يُعالج ويُوجِّه رزمة البيانات بإنقاص قيمة واحد من هذه القيمة. يفحص كل موجه يستقبل رزمة البيانات قيمة هذا الحقل أولاً، إذا كانت مساوية للصفر، فإنه يتخلص منه. إذا استقبلت الوجهة النهائية الرزمة بقيمة صفرية لهذا الحقل، لا تتخلص منها بل تقوم بمعالجتها.
  • حقل عنوان المصدر: وطوله 128 بت، عنوان العقدة المصدر التي ولدت رزمة البيانات.
  • حقل عنوان الوجهة: وطوله 128 بت، عنوان وجهة الرزمة. قد يحتوي عنوان الوجهة الأخيرة، أو عنوان المُستقبل التالي للرزمة إذا كانت ترويسة التوجيه موجودة بعد ترويسة البروتوكول.

ترويسة خيارات المسار

بنية ترويسة خيارات المسار

تستعمل ترويسة خيارات المسار (Hop-by-hop options header)‏ لحمل معلومات لخيارات يُمكن فحصها أو معالجة محتواها في كل مُوجِّه تمر به الرزمة عبر مسارها إلى وجهتها النهائية. إن قيمة النوع الخاصة بهذه الترويسة هي 0، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[54]

طول ترويسة خيارات المسار مُتغيِّرٌ، وهي تتكون من حقلين ثابتي الطول يليهما حقل واحد مُتغيِّر الطول، وهذه الحقول هي وفقاً لترتيب ورودها:[54]

  • حقل الترويسة التالية: طوله 8 بت، ويحتوي على قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
  • حقل طول ترويسة التوسعة: وطوله 8 بت، ويحتوي على عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 بايت، دونَ احتساب البايتات الثمانية الأولى. مثلاً إذا كان طول الترويسة هو 16 بايت، فإن قيمة هذا الحقل هي 1، وإذا كان طول الترويسة هو 32 بايت فإن قيمة هذا الحقل هو 3.
  • حقل الخيارات: مُتغيِّر الطول، يضم خياراً واحد أو أكثر من خيارات المسار، ويلزم يكون طول هذا القسم متوافقاً مع واحدة 8 بايت، أي من المقبول أن يكون الطول: 8 أو 16 أو 24 بايت ... إلخ.

ترويسة التوجيه

بنية ترويسة التوجيه

يستعمل مصدر رزمة بيانات للإصدار السادس من بروتوكول الإنترنت ترويسة التوجيه (Routing header)‏ لتحديد مسارها أو جزءاً منه من خلال إضافة قائمة تضم عناوين العقد الوسيطية التي يلزم أن تزورها الرزمة عبر مسارها وصولاً إلى وجهتها.[55] تتشابه وظيفة هذه الترويسة مع وظيفة خيار المسار الحرّ من المصدر في الإصدار الرابع من بروتوكول الإنترنت.[56] إن قيمة النوع الخاصّ بترويسة التوجيه هي 43، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[57]

ترويسة التوجيه متعيرة الطول، وهي تتكون من أربعة حقول ثابتة الطول يليها حقل وحيد متغير الطول، وهذه الحقول هي وفقاً لترتيب ورودها:[57]

  • حقل الترويسة التالية: طوله 8 بت، ويحتوي على قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
  • حقل طول ترويسة التوسعة: طوله 8 بت، ويحتوي على عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 بايت، دونَ احتساب البايتات الثمانية الأولى.
  • حقل نوع التوجيه: طوله 8 بت، ويضمّ مُعرفاً يُحدد نوع التوجيه، وتحدد هيئة أرقام الإنترنت المُخصصة قائمة المُعرفات المدعومة من قبل البروتوكول ومعاني كلٍّ منها.[58] اعتمد النوع ذو القيمة 0 في المعيار الأصلي، لكنه أُبطل لأسباب أمنية.(3)[59]
  • حقل القطاعات المتبقية:طوله 8 بت، ويضمّ معرِّفاً رقمياً لعدد قطاعات الشبكة الوسيطية(4) التي يلزم زيارتها قبل الوصول إلى الوجهة النهائية، ولكنَّها لما تُزر بعدُ.
  • حقل بيانات مُرتبطة بالنوع: مُتغيِّر الطول، ويحتوي على مجموعة واحدة أو أكثر من هياكل البيانات التي يكون طولها متوافقاً مع واحدة 8 بايت، لتكون نهايتها عند نهاية الترويسة دائماً، أما بنية الهياكل، فهي تتحدد بتوع التوجيه.

هناك حالتان مرتبطتان بترويسة التوجيه تستوجبان إرسال رسائل أخطاء خاصَّة ببروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت ، وهما:[60]

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

ترويسة القطعة

بنية ترويسة القطعة

تضاف ترويسة القطعة (Fragment header)‏ إلى جميع القطع الناتجة عن عملية تقطيع رزمة بيانات.[61] إنَّ قيمة النوع الخاصة بهذه الترويسة هي 44، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[62]

يبلغ طول ترويسة القطعة 8 بايت، وتتألف من 6 حقول دائمة، هي وفقاً لترتيب وردوها:[63]

  • حقل الترويسة التالية: طوله 8 بت، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية.
  • حقل محجوز طوله 8 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال.
  • حقل إزاحة القطعة: طوله 13 بت، يحتوي على موقع حمولة القطعة النسبي ضمن حمولة الرزمة الأصلية، وتعبر قيمة الرقم الموجود عن الإزاحة بواحدة هي 8 بايت، فإذا كانت قيمة هذا الحقل مثلاً هي 2، فإن إزاحة القطعة الحقيقية هي 16 بايت.
  • حقل محجوز طوله 2 بت، يُضبط إلى قيمة صفرية في مصدر الرزمة عند الإرسال.
  • علم المزيد من القطع: طوله 1 بت، ويستخدم للإشارة إلى القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني أن هناك قطع لاحقة نتجت عن عملية التقطيع، أما إذا كانت قيمته 0 فذلك يعني بأنَّ هذه القطعة هي القطعة الأخيرة.
  • حقل مُعرّف القطعة 32 بت، وهي يحتوي قيمة فريدة تُميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. هناك عدة خوارزميات لاختيار قيمة المعرّف بحيث يكون فريداً وآمناً، وهي موصوفة في وثيقة طلب التعليقات RFC 7739.[64]

ترويسة خيارات الوجهة

بنية ترويسة خيارات الوجهة.

تُستخدم ترويسة خيارات الوجهة (Destination Options Header)‏ لحمل الخيارات التي تُعالجها الوجهة النهائية للرزمة فقط. إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 60، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[65]

ترويسة خيارات الوجهة مُتعيَّرة الطول، وهي تتكون من حقلين ثابتي الطول يليهما حقل وحيد متغير الطول، وهذه الحقول هي وفقاً لترتيب ورودها:.[65]

  • حقل الترويسة التالية: طوله 8 بت، ويحتوي على قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
  • حقل طول ترويسة التوسعة: وطوله 8 بت، ويحتوي على عدد صحيح موجب يمثل طول ترويسة خيارات المسار بواحدة 8 بايت، دونَ احتساب البايتات الثمانية الأولى.
  • حقل الخيارات: متغيِّر الطول، يضم خياراً واحد أو أكثر من خيارات الوجهة، ويلزم يكون طول هذا القسم متوافقاً مع واحدة 8 بايت، أي من المقبول أن يكون الطول: 8 أو 16 أو 24 بايت ... إلخ.

ترويسة التحقق من الهوية

بنية ترويسة التحقق من الهوية.

تُؤَمِّن ترويسة التحقق من الهوية (Authentication Header)‏ آليةً للتحقق من سلامة رزم البيانات المنقولة عبر اتصال يجري عبر قناة غير مُهيَّأة وتحققاً من هوية مصدر هذه الرزمة. تسمح آلية التحقق من السلامة بمنع تلاعب وسيط ما برزم البيانات عند حركتها بين مصدرها ووجهتها، وتستخدم في التصدي لهجمات الوسيط.[66] إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 51، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[67]

ترويسة خيارات الوجهة مُتغيَّرة الطول، وهي تتكون من ستة حقول، خمسةٌ منها ثابتة الطول يليها حقل وحيد متغير الطول، وهذه الحقول هي وفقاً لترتيب ورودها:[68]

  • حقل الترويسة التالية: طوله 8 بت، ويحتوي على قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
  • حقل طول الحمولة: طوله 8 بت، ويحتوي على طول ترويسة التوسعة بواحدة 32 بت، أو 4 بايت، منقوصاً منها بايتان. أي إذا كان طول الترويسة هو 100 بايت، فإن قيمة هذا الحقل هي 2-(100/4)= 2-25 = 23.
  • حقل محجوز: بطول 16 بت.
  • حقل فهرس وسائط الأمن: بطول 32 بت، ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها.
  • حقل رقم التتابع: بطول 32 بت، يحتوي على عداد تضبط قيمته في المصدر إلى قيمة محددة مع بدء الجلسة الآمنة، ثم قيمة التتابع بمقدار واحد مع كل رزمة بيانات تُرسل في الجلسة.
  • حقل قيمة التحقق من السلامة: متغيِّر الطول، ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة رياضية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. في العقدة الوجهة، لا يمكن الحصول على قيمة حقل التحقق من السلامة نفسِها إلا إذا كانت محتويات الرزمة هي نفسُها، أي أنها وصلت من المصدر إلى الوجهة دونَ تلاعب فيها.

ترويسة تغليف الحمل الأمني

بنية ترويسة تغليف الحمل الأمني.

تُستعمل ترويسة تغليف الحمل الأمني (Encapsulating Security Payload header)‏ لتأمين مجموعة من خدمات الأمن التي تشمل: سرية البيانات وللتحقق من هوية مصدرها ولسلامة الاتصال عبر القنوات غير المُهيَّأة وللحماية من هجمات إعادة الإرسال (Anti-replay attacks)‏[69]. إنَّ قيمة النوع الخاصّ بترويسة التوجيه هي 50، وإذا وردت هذه الترويسة في رزمة بيانات، فيجب أن تُوضع هذه القيمة في حقل الترويسة التالية الموجود داخل الترويسة السابقة.[70]

ترويسة تغليف الحمل الأمني مُتغيَّرة الطول، وهي تتكون من سبعة حقول، أربعة منها ثابتة الطول. وحقول هذه الترويسة هي وفقاً لترتيب ورودها:[71]

  • حقل فهرس وسائط الأمن: بطول 32 بت. ويحتوي مُعرِّف الجلسة الآمنة، وهي قيمة عشوائية يضيفها المصدر إلى الترويسة وتُستخدم من قبل الوجهة لتمييز الجلسة الآمنة التي أرسلت الرزمة عبرها.
  • حقل رقم التتابع: بطول 32 بت. يحتوي على عداد تضبط قيمته الابتدائية في المصدر إلى قيمة محددة عند بدأ الجلسة الآمنة، ثم تُزاد قيمة التتابع بمقدار واحد مع كل رزمة بيانات يُرسلها مصدر الرزم في تلك الجلسة.
  • حقل بيانات الحمولة: مُتغير الطول، يحتوي على المعلومات التي يجري تشفيرها من أجل حمايتها.
  • حقل الحشو: متغير الطول يتراوح طوله بين 0 و 255 بايت، يحتوي على بايتات إضافية مُلحقة بالحمولة. يُضاف حقل الحشو لسببين:
  1. قد يلزم حد أدنى أو قيم محددة لطول البيانات المُراد تشفيرها. مثلاً، مضاعفات 4 أو 8 أو 16 بايت ... إلخ، وعندها تضاف بايتات الحشو لإكمال طول البيانات حتى القيمة اللازمة.
  2. قد يلزم إضافة عدة بايتات لجعل نهاية الحقلين التاليين تقع عند مضاعفات 4 بايت، وعندها تُضاف بايتات حشو حسب الحاجة لتحقيق ذلك.
  • حقل طول الحشو: طوله 8 بت، ويحتوي على عدد البايتات المُضافة في قسم الحشو.
  • حقل الترويسة التالية: طوله 8 بت، ويحتوي على قيمة تُعرِّف نوع الترويسة الموجودة مباشرةً بعد هذه الترويسة.
  • حقل قيمة التحقق من السلامة: متغيِّر الطول ويلزم أن يكون طوله من مضاعفات 32 بت، ويُضمُّ قيمة عددية تُحسب في العقدة المصدر من أجل محتويات رزمة البيانات التي لا تتغير خلال عبورها الشبكة. يعاد حساب هذه القيمة في العقدة الوجهة، ولا يمكن الحصول على القيمة نفسِها لحقل التحقق من السلامة إلا إذا كانت محتويات الرزمة هي نفسُها دون تغيير، ومعنى ذلك أنها وصلت من المصدر إلى الوجهة دونَ تلاعبٍ فيها.

بنية الخيارات

بنية الخيار العامة في الإصدار السادس من بروتوكول الإنترنت.

يُمكن لترويستان من الترويسات التي تُعرِّفها محددات البروتوكول أن تحمل خياراتٍ مُختلفة العدد والحجم، وهما ترويستا خيارات المسار وخيارات الوجهة. إن بنية خيارات البروتوكول ثلاثية الحقول، وهي تتكون من البنية التالية:[72][73]

  • حقل النوع: طوله 8 بت، ويحتوي على مُعرِّف رقمي يحدد نوع الخيار.
  • حقل الطول: طوله 8 بت، ويحتوي طول الخيار مُقدراً بالبايت.
  • حقل القيمة: مُتغيِّر الطول، وتكون بنيته ومعاني القيم فيها مرتبطة بنوع الخيار.

تُحدد قيمة البتان الأكثر أهمية في حقل النوع سلوك العقدة التي تُعالج الخيار إذا فشل في التَّعرُّف على نوعه، فإذا كانت قيمتهما 2(00) فعلى العقدة تخطي الخيار واستكمال معالجة الترويسة. وإذا كانت قيمتهما 2(01) فعلى العقدة التخلُّص من الرزمة. وإذا كانت قيمتهما 2(10) فعلى العقدة التخلص من الرزمة والاعتماد على بروتوكول رسائل التحكم للإصدار السادس لإرسال رسالة خطأ يُشير فيها إلى عدم إمكانية التعرف على نوع الخيار، وذلك بغض النظر عن كون مصدر الرزمة عنوان بث فريد الوجهة أو عنوان بث مجموعاتي. أما إذا كانت قيمتهما 2(11) فعلى العقدة تنفيذ ما سبق فقط إذا لم يكن عنوان مصدر الرزمة عنوان بثِّ مجموعاتي.[73] أما البت الثالث من حيث الأهمية، فإن قيمته تحدد فيما إذا كان محتوى الخيار يتغير أثناء انتقال الرزمة عبر الشبكة. فإن كان المحتوى مُتغيراً، كانت قيمة البت هي 1، وإن كان ثابتاً كانت قيمته 0.[74]

على الرعم من أن مُحددات البروتوكول تقدم دليلاً إرشادياً لتبيان كيفية تصميم خيارات للإصدار السادس من بروتوكول الإنترنت،[75] إلا أن وثيقة مُحددات البروتكول لا تُعرِّف إلا خيارين اثنين فقط، هما خيار حشو بايتٍ واحد (Pad1 option)‏، وخيار حشو N بايت (PadN option)‏. ويُستخدمان لمحاذاة نهاية الخيار مع واحدة طول الترويسة، وهي 4 بايت. أي إذا كان طول الخيار مثلاً 11 بايتاً، فيضاف خيار حشو بايت وحيدٍ في النهاية، وإن كان 13 بايتاً يُضاف خيار حشوٍ لثلاث بايتات. وخيار حشو بايت واحد هو الخيار الوحيد الذي لا يتبع بنية الخيارات السابقة، بل يتكون من بايت وحيد صفريّ البتات.[76]

  • بنية خيار حشو بايت واحد

  • بنية خيار حشو N بايت

الوظائف

العنونة

تعاريف

تُعرِّف محددات البروتوكول فضاءً للعناوين، ويبلغ طول العنوان فيه 128 بتاً، ومعنى ذلك أن الفضاء يضمّ 2128 عنواناً أي ما يقارب 3.4x1038 عنواناً.[4] تُمنح عناوين الإصدار السادس للمنافذ، لا للعقد، ويمكن للمنفذ أن يستضيف أكثر من عنوان في الوقت نفسه. يدعم الإصدار السادس من بروتوكول الإنترنت ثلاثة أنماط لعنونة المنافذ هي عنونة البث فريد الوجهة، وعنونة البث المجموعاتي وعنونة البث نحو الأقرب ، ولا يدعم البروتوكول نمط عنونة البث العام. في عنونة البث فريد الوجهة، يستضيف منفذ ما عنواناً فريداً، ويجري توجيه الرزم المُرسلة نحو هذا العنوان إلى المنفذ الذي يستضيفه. أما في عنونة البث المجموعاتي، فتَستضيف مجموعة من المنافذ عنواناً ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو ذلك العنوان إلى المنافذ التي تستضيفه جميعُها. أما في عنونة البث الأقرب، فتستضيف مجموعة من المنافذ عنواناً ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحو هذا العنوان إلى أقرب منفذ يستضيفه.(5) إذا كان للعقدة منفذٌ وحيدٌ فقط يستضيف عنوان بثٍ فريد الوجهة فقط، يجوز أن يُستعمل العنوان كمُعرِّف للعقدة.[5]

التمثيل الرياضي

مسرد للمصطلحات المُستعملة في عناوين الإصدار السادس من بروتوكول الإنترنت

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

جدول تحويل مباشر بين قيم نظامي العد الثنائي وستة العشري[77]
قيمة البتات الأربعة
بنظام العد الثنائي		 القيمة الموافقة بنظام
العد ست العشري		 قيمة البتات الأربعة
بنظام العد الثنائي		 القيمة الموافقة بنظام
العد ست العشري
0000 0 1000 8
0001 1 1001 9
0010 2 1010 a(6)
0011 3 1011 b
0100 4 1100 c
0101 5 1101 d
0110 6 1110 e
0111 7 1111 f
البنية العامة لعنوان بث فريد الوجهة في الإصدار السادس من بروتوكول الإنترنت.

تُسمَّى كل أربع خانات ستة عشرية متتالية رباعيةً (Quartet)‏،(7) ويُفصل بين كل رباعيتين متتاليتين محرف النقطتين الرأستين، أي :، وتكون الرباعية الواقع في أقصى اليسار هي الأعلى أهمية.[77] مثلاً العنوان التالي هو مثال عن عنوان من الإصدار السادس من بروكول الإنترنت:

0123:4567:89ab:cdef:0123:4567:89ab:cdef

في عناوين البث فريد الوجهة، يتكون كل عنوان من قسمين، هما مُعرِّف الشبكة ومُعرِّف المنفذ. يكون مُعرِّف الشبكة مُشترَكاً بين جميع العناوين التي تنتمي للفضاء الجزئي نفسه، أما مُعرِّف المنفذ فيكون مميزاً لكل منفذٍ على حدته. يُشتق كل عنوان بث فريد الوجهة انطلاقاً من بادئة ما، ويُستعمل طول تلك البادئة لتحديد الحد الفاصل مُعرِّف الشبكة ومُعرِّف المنفذ، فإذا كان طول بادئة ما 64 بتاً، فهذا يعني أن مُعرِّف الشبكة يمتد على أربعٍ وستين بتاً متتابعاً بدءاً من البت ذي الأهمية العليا وبشكلٍ غير مُنقطع، في حين يمتد مُعرِّف المنفذ على البتات الأربعة والستين المتبقية.[78] تصف وثيقة طلب التعليقات RFC 5952 الممارسات المُتبعة لتمثيل عناوين الإصدار السادس من بروتوكول الإنترنت بالشكل السليم، وتلخص عدداً من المُشكلات التي ترتبط بالمسألة مثل حالة الحروف كبيرة أو صغيرة واستعمال النقطين الرأسيتين وغير ذلك وتطرح حلولاً لها.[79]

تمثيل العناوين والأقنعة
أمثلة عن اختصار عناوين الإصدار السادس من بروتوكول الإنترنت [80]
العنوان المُكتمل العنوان المختصر
2340:0:10:100:1000:abcd:101:1010 2340:0000:0010:0100:1000:abcd:0101:1010
30A0:abcd:ef12:3456:0ABC:B0B0:9999:9009 30A0:abcd:ef12:3456:ABC:B0B0:9999:9009
3210:0000:0000:0000:0000:0000:0000:0000 ::3210
0000:0000:0000:0000:0000:0000:0000:1 1::
34ba:000b:000b:0000:0000:0000:0020 34ba:b:b::20

يمكن تمثيل عنوان الإصدار السادس من بروتوكول الإنترنت بثلاثة طرق:[81][82]

  • التمثيل المكتمل: وفيه يكتب العنوان كاملاً بالشكل #:#:#:#:#:#:#:#، حيث يُمثل الرمز # أربع مراتب ستة عشرية. ومثاله العنوان:0123:4567:89ab:cdef:0123:4567:89ab:cdef.
  • التمثيل المُختصر: وفيه تختصر أجزاء من العنوان بالشكل التالي:
  1. كانت المرتبة الأعلى أهميةً في رباعية ما صفرية لوحدها أو صفرية مع أكثر من مرتبة متتابعة معها، تهمل الأصفار وتُسقط من الكتابة وتمثل X عندها المراتب الست عشرية غير الصفرية فقط، فمثلاً الرباعية 0123 تُكتب بالشكل 123 والرباعية 0011 تكتب بالشكل 11.
  2. إذا كانت المراتب الست عشرية في رباعية ما صفريَّة القيمة جميعها، تمثل الرباعية بصفر واححدة، أي 0000 تُكتب: 0.
  3. إذا اجتمعت أكثر من رباعية صفرية متتالية، أمكن اختزالها والتعويض عنها بمحرفي نقطتين رأسيتين متتاليتين. فمثلاً العنوان:1234:0:0:0:0:0:0:1111 يُكتب اختصاراً: 1111::1234
  4. إذا وجد أكثر من تتابع رباعيات صفرية في عنوان واحد، فلا يجوز اختزال إلا تتابع واحد منها فقط، ويلزم أن يكون التتابع المُختصر هو التتابع الأطول، فمثلاً العنوان:1234:0:0:0:2222:0:0:1111 يُكتب اختصاراً: 2222:0:0:1111::1234 ولا يكتب 1111::2222::1234 أو1111::2222:0:0:0:1234.وأمَّا إذا كان طول التتابعين متساوياً، أمكن اختزال أحدهما دون تمييز.
  • التمثيل المُختلط: وهو تمثيل يُستعمل في الشبكات التي يستضيف المضيفون فيها عناوين من الإصدارين الرابع والسادس معاً، ويكون شكل العنوان d.d.d.d:#:#:#:#:#:#، حيث يُمثِّل الرمز # رباعيةً مكونة من 4 خانات ست عشرية غير صفرية، وتطبق قواعد الاختصار إذا وجدت خانات صفرية، أمَّا المحرف d فيُمثِّل خانة من خانات عنوان الإصدار الرابع من بروتوكول الإنترنت مكتوبة بالنظام العشري المُنقَّط ، ومثال هذا التمثيل العنوان: 1111:0:0:0:0:0:200.100.10.1 والذي يمكن أن يكتب بعد الاختصار بالشكل التالي: 200.100.10.1::1111.
تمثيل البادئات

البادئة (Prefix)‏ هي فضاء جزئي من الفضاء الكلي لعناوين البروتوكول، وتُمثَّل كل بادئة بعنوان يُسمى عنوان البادئة. ويتشابه تمثيل البادئات في الإصدار السادس من بروتوكول الإنترنت مع تمثيلها في الإصدار الرابع، والذي أُقِرَّ بعد اعتماد آلية التوجيه غير الصنفي بين النطاقات.[83] تتكون كل بادئة من جزئين، هما عنوان من الإصدار السادس من بروتوكول الإنترنت وطول البادئة، أي عدد البتات فيها، ويكون شكل البادئة:[84]

طول البادئة/عنوان الإصدار السادس

يمكن اختصار العنوان الموجود في البادئة وفقاً لقواعد اختصار عناوين الإصدار السادس نفسها. فمثلاً، ما سيأتي هو أمثلة عن بادئات مكتوبة بشكل صحيح:[84]

1111:0000:0000:2222:0000:0000:0000:0000/64
1111:0:0:2222:0:0:0:0/64
64/::1111:0:0:2222

بنى العناوين وفقاً لنمط التوجيه

أنماط التوجيه

Cast.svg

بث فريد الوجهة

Unicast.svg

بثّ عام

Broadcast.svg

بث مجموعاتي

Multicast.svg

بث نحو الأقرب

Anycast.svg

بث جغرافي

Geocast.svg

يُعرِّف الإصدار السادس من بروتوكول الإنترنت فضاءً يضمُّ 2128 عنواناً فيه، ويدعم ثلاثة أنماط من العنونة هي العنونة هي عنونة البث الفريد الوجهة وعنونة البث المجموعاتي وعنونة البث نحو الأقرب.[5] يُخصص فضاء محجوز للبث المجموعاتي، ويُحجز فضاء خاص أيضاً لعناوين البث فريد الوجهة الوصلة المحلية، وفيما يخصص العنوان الصفري ليكون العنوان غير المُحدد والعنوان الذي يليه ليكون عنوان الحلقة العكسية، وفيما خلا ذلك، فما تبقى من الفضاء مُخصص لفضاء عناوين البث فريد الوجهة العالمي. ويبين الجدول التالي العناوين المحجوزة والأفضية الجزئية في الإصدار السادس من بروتوكول الإنترنت:[85]

أقسام فضاء عناوين الإصدار السادس من بروتوكول الإنترنت [85]
الاسم البادئة (طول البادئة [بت]) تمثيل الفضاء
العنوان غير المُحدد
0 ... 00 (128)
128/::
عنوان الحلقة العكسية
1 ... 00 (128)
1/128::
فضاء البث المجموعاتي
11111111 (8)
ff00::/8
فضاء البث فريد الوجهة في الوصلة المحلية
1111111010 (10)
fe80::/10
فضاء البث فريد الوجهة العالمي كل ما تبقى من الفضاء

يجب الانتباه إلى أن عناوين البث نحو الأقرب تقتطع من أي فضاء من عناوين البث فريد الوجهة، لذلك لا يمكن التمييز بين عناوين الفضاءين رقميَّاً، بل من حيث بنية العنوان ووظيفته.[85]

عناوين البث فريد الوجهة

عناوين البث فريد الوجهة هي العناوين التي تُمّيز منفذاً محدداً. إذا كان عنوان وجهة رزمة ما هو عنوان بث فريد الوجهة، فستُوجَّه الرزمة نحو المنفذ الذي يستضيف هذا العنوان. تمتاز عناوين هذا الفضاء بإمكانية تجميعها معاً وتمثيلها كأفضية جزئية باستعمال تدوين البادئة بشكل مُشابه لتمثيل الأفضية الجزئية في الإصدار الرابع من بروتوكول الإنترنت.[85]

هناك عدة أنواع لعناوين الفضاء فريد الوجهة منها، هي:

  • العنوان غير المُحدد (The Unspecified Address)‏: هو العنوان الصفريّ، أي 0:0:0:0:0:0:0:0 أو اختصاراً ::. يُستعمل للدلالة إلى عدم استضافة المنفذ لعنوان من الإصدار السادس من بروتوكول إنترنت رغم وجود دعم للبروتوكول فيه، لذلك لا يجب أن يُمنح هذا العنوان لأي منفذ. لا يُستعمل هذا العنوان كعنوان وجهة لرزم البيانات، ويلزم أن تتخلص المُوجِّهات أي رزمة مُوجَّهة نحو هذا العنوان.[86]
  • عنوان الحلقة العكسية (The Loopback Address)‏: وهو العنوان 0:0:0:0:0:0:0:1 أو اختصاراً 1::، ويُمكن أن يستخدم من قبل أي عقدة لإرسال رزم بيانات إلى نفسها، لذلك لا يجب أن يُمنح هذا العنوان لأي منفذ مادي. لا يُستعمل هذا العنوان كعنوان مصدر للرزم التي ستغادر عقدة ما، ولا يجب أن تُوجَّه الرزم التي تكون وجهتها عنوان الحلقة العكسية نحو خارج العقدة. ويلزم أن تتخلص الموجهات أي رزمة موجهة نحو عنوان الحلقة العكسية.[86]
  • عناوين البث فريد الوجهة العالمي (Global Unicast Address)‏: وتُستخدم لعنونة منفذ ما على الإنترنت بشكلٍ فريدٍ على مستوى العالم. يتكون العنوان من ثلاثة حقول: حقل بادئة التوجيه العالمية، وهي تمنح للموقع الذي يُشغل المنفذ بحسب هرمية تحصيص رباعية المستويات تديرها هيئة أرقام الإنترنت المُخصصة، و حقل مُعرف الشبكة الجزئية والذي يَضبطه مشغلو الموقع، حيث يوجدالمنفذ، وذلك بهدف تجزئة الفضاء الممنوح إلى أفضية جزئية أصغر حجماً لأغراض إدارية أو تنظيمية.[86]
في عناوين البث فريد الوجهة العالمية التي لا تكون قيمة البتات ذات الأهمية العليا فيها 2(000)، يكون مجموع طولي حقلي بادئة التوجيه العالمية و مُعرِّف الشبكة الجزئية 64 بت، ما يترك 64 بتاً لمُعرف المنفذ، وبهذا تتوافق بنية هذه العناوين مع آلية التهيئة الذاتية الآلية. أما العناوين التي تكون قيمة البتات ذات الأهميةً العليا فيها 2(000) فهي لا تُلزَم بالبنية السابقة.[87] وفيما يأتي مثالٌ عن هذا العنوان:
1::2001:1111:2222:3333
  • عناوين البث فريد الوجهة في الوصلة المحلية (Link-Local Unicast Address)‏: ويشغل الفضاء fe80::/10،[88] تُستخدم عناوين هذا الفضاء على مستوى الوصلة المحلية فقط، وهي مصممة لتخدم أغراضاً مثل التهئية الآلية للعنوان واكتشاف الجيران. لا يجب على المُوجِّهات توجيه أي رزمة بيانات يكون عنوان مصدرها أو وجهتها عنوان وصلة محلية.[89]
يتكون عنوان الوصلة المحلية من ثلاثة حُقول: الحقل الأول هو مُعرِّف فضاء عناوين الوصلة المحلية، وطوله 10 بتات وقيمته 2(1111111010)، أما الحقل الثاني فهو حقل صفري يبلغ طوله 54 بتاً، والحقل الثالث هو حقل مُعرف المنفذ، ويُستخدم لتمييز المنفذ بشكل فريد على مستوى الوصلة المحلية.[89] وفيما يأتي مثالٌ عن هذا العنوان:
fe80::1ff:fe01:101
  • عناوين البث فريد الوجهة الفريد المحلي (Unique Local IPv6 Unicast Addresses)‏: حُجر له الفضاء fc00::/7،[90] ويُستخدم من أجل عنونة منفذ بشكل فريد على المستوى العالمي، ولكن من أجل إنشاء اتصالات محلية فقط، ولذلك لا يمكن توجيه الرزم المعنونة بهذه العناوين خارج الموقع الذي ولِّدت فيه.[91]
يتألف العنوان الفريد المحلي من 5 حقول، أولها هو حقل البادئة وطوله 7 بتات وقيمته هي 2(1111110) دائماً، ويليه بت المحلية، ويُضبط إلى القيمة 1 دائماً للإشارة إلى أن العنوان قد وُلِّد محلياً،(8) ثُمَّ حقل البادئة العالمية وطوله 40 بتاً، وهو مُعرِّف فريد على مستوى العالم يضبط محلياً إلى قيمة عشوائية، ثُمّ حقل مُعرِّف الشبكة الجزئية طوله 16 بت، وهو حقل مخصص لمديري الشبكة لإتاحة إمكانية إنشاء شبكات جزئية، وأخيراً مُعرِّف المنفذ وطوله 64 بتاً، ويميز كل منفذ على حدته بشكل فريد.[92] وفيما يأتي مثالٌ عن هذا العنوان: مرجع
fdf8:f53b:82e4::53
  • عناوين البث فريد الوجهة المحلي في الموقع (Site-Local Unicast Address)‏: وهو صنف مُبطَل من عناوين البث فريد الوجهة.[93] طُوِّر في الأصل ليَخدُم غرض العنونة داخل موقع ما دون الحاجة لبادئات عالمية. حُجر له الفضاء fec::/10،[90] كانت بنية هذه العناوين مكونة من ثلاثة حقول: الحقل الأول هو معرف فضاء العناوين المحلية في الموقع، وطوله 10 بتات وقيمته 2(1111111011)، أما الحقل الثاني فهو مُعرِّف الشبكة الجزئية، ويضبطه مشرفو الموقع حسب الحاجة، وأما الحقل الثالث فهو مُعرِّف المضيف ويبلغ طوله 64 بتاً.[89] وفيما يأتي مثالٌ عن هذا العنوان:
    fec0::1234:5678:9abc
  • عناوين البث فريد الوجهة التي تتضمن عناوين من الإصدار الرابع: هناك عنوانان من عناوين البث فريد الوجهة في الإصدار السادس يحملان في البتات الاثنين والثلاثين ذات الأهمية الدنيا عناوين من الإصدار الرابع من بروتوكول الإنترنت وهما:
  • عناوين البث فريدة الوجهة المُتوافِقة مع الإصدار الرابع (IPv4-Compatible Unicast Address)‏: عُرِّفت هذه العناوين في الأصل لتساهم في دعم عملية الانتقال من استعمال الإصدار الرابع إلى الإصدار السادس من بروتوكول الإنترنت. يتكون هذا العنوان بدءاً من الخانة الأكثر أهمية من 80 صفراً يليها عنوان الإصدار الرابع من بروتوكول الإنترنت الذي يلزم أن يكون فريداً عالمياً.[87]
تُستخدم الطريقة العجينة لتمثيل هذه العناوين. أبطلت طريقة الانتقال التي تستعمل هذه العناوين، ولذلك لم تعد هذه العناوين قيد الاستخدام.[87] وفيما يأتي مثالٌ عن هذا العنوان:
200.100.10.1::
  • عناوين البث فريدة الوجهة المُقترنة مع الإصدار الرابع ( IPv4-Mapped Unicast Address)‏ وتستعمل لحمل عنوان الإصدار الرابع من بروتوكول الإنترنت الذي تستضيفه العقدة التي تدعم الإصدار السادس أيضاً.[87] وصفت طريقة استعمال هذا العنوان في وثيقة طلب التعليقات RFC 4038،[94] وهو يتكون من ثلاث حقول بدءاً من الخانة الأكثر أهمية هي 80 صفراً متتالياً في الحقل الأول، يليها 16 واحداً متتالياً في الحقل الثاني، ثُمَّ عنوان الإصدار الرابع من بروتوكول الإنترنت.[89] وفيما يأتي مثالٌ عن هذا العنوان:
    ffff:192.0.2.47::

  • بنية عنوان البث فريد الوجهة العالمي.

  • بنية عنوان البث فريد الوجهة في الوصلة المحلية.

  • بنية عنوان البث فريد الوجهة في الفريد المحلي.

  • بنية عنوان البث فريد الوجهة المحلي في الموقع.

  • بنية عنوان البث فريد الوجهة المُتوافِق مع الإصدار الرابع من بروتوكول الإنترنت.

  • بنية عنوان البث فريد الوجهة المُقترن مع الإصدار الرابع من بروتوكول الإنترنت.

عناوين البث نحو الأقرب

عنوان البث نحو الأقرب في الإصدار السادس من بروتوكول الإنترنت (IPv6 anycast address)‏ هو عنوان بث فريد الوجهة يُمنح لأكثر من منفذ في الوقت عينه، وغالباً ما تكون في هذه المنافذ في عقد متمايزة. إذا أُرسلت رزمة بيانات ما إلى عنوان بث نحو الأقرب، فإنها تُرسل إلى أقرب(5) عقدة تستضيف ذلك العنوان. تُحصص عناوين البث نحو الأقرب من فضاء البث فريد الوجهة، بدون أي قيود إضافية، لذلك لا يمكن تمييز عناوين البث نحو الأقرب عن عناوين البث فريد الوجهة رياضياً. بعبارة أخرى، إذا مُنح عنوان بث فريد الوجهة إلى أكثر من منفذ في الوقت عينه فإنَّه يًصبح عنوان بثٍّ نحو الأقرب، ويجب تهيئة العقد بشكل صريح لتكون على دراية بذلك.[95]

يتكون عنوان البث نحو الأقرب من قسمين، يمُثل الأول بادئة الشبكة الجزئية، وهي مُعرِّف رقمي طوله n بت، يُحدد جزءاً من الطوبولوجيا حيث توجد جميع عناوين البث نحو الأقرب، أما القسم الآخر من العنوان فهو ذو قيمة صفرية.[95]

يجب أن تقوم المُوجِّهات بتمييز عنوان البث نحو الأقرب ببند فريد في جداول التوجيه ضمن جزء الطوبولوجيا الذي توجد فيه العناوين، ولكن خارج هذا الجزء، يمكن تجميع العنوان مع مسارات أخرى ولا داعٍ لتمييزه ببند فريد. هناك حالة خاصة يلزم أن يكون فيه بند عنوان البث نحو الأقرب فريداً على مستوى الإنترنت كلها ولا يجوز تجميه هذا البند مع أي بند آخر، وتحصل هذه الحالة عند استعمال بادئة غير مُحدَدة طوبولوجياً (null prefix)‏، أي أنها يمكن أن تمنح للمنافذ في أي موقع في الإنترنت.[96]

عناوين البث المجموعاتي
بنية عنوان البث المجموعاتي.

عنوان البث المجموعاتي هو مُعرِّف رقمي يُميِّز مَجموعة محددة من المنافذ التي تستضيفه. إن إرسال أي رزمة بيانات إلى عنوان بث مجموعاتي ما سيؤدي إلى توجيهها إلى جميع أعضاء المجموعة المميزة بذلك العنوان.[97] يتكون عنوان البث المجموعاتي من أربعة حقول هي وفقاً لترتيب ورودها من الخانة الأعلى أهمية:[96]

  • حقل بادئة البث المجموعاتي: طوله 8 بت، ويحتوي على القيمة 2(11111111) أو 16(FF)، وهي تميز عناوين فضاء البث المجموعاتي جميعها.
  • حقل الأعلام: طوله 4 بت، تُثبَّت قيمة البت الأعلى أهمية فيه إلى القيمة 0، وأما البتات الثلاثة اللاحقة في وفقاً فقاً لترتيب ورودها من الخانة الأعلى أهمية:
علم الالتقاء: ويحدد فيما إذا كان العنوان يتضمن عنوان نقطة الالتقاء أم لا، فهو كذلك إذا كان واحدياً، أما إذا كان صفرياً فهو بخلاف ذلك.[98]
علم البادئة: ويحدد فيما إذا كان منح العنوان قد جرى على أساس بادئة الشبكة فريدة الوجهة حيث سيُستضاف العنوان، فإذا كان العلم واحدياً فإن العنوان قد منح على أساس البادئة وإلا فإنه لم يُمنح على ذلك الأساس.[99]
علم الديمومة: وإذا كان صفرياً فإن العنوان ممنوح بشكل دائم من قبل أيانا ومعروفٌ في شبكة الإنترنت كاملةً، أما إذا كانت قيمته واحدية، فالعنوان ليس دائماً ويكون ذا معنى في مجال مُحدد بحقل المجال.[96]
  • حقل المجال: طوله 4 بت، ويضم رمزاً يحدد المجال الطوبولوجي الذي تمتد عليه المجموعة كما في الجدول التالي:[100]
قيمة حقل المجال
بنظام العد الثنائي		 اسم المجال امتداد المجال
0000 محجوز -
0001 مجال المنفذ يشمل هذا المجال منفذاً واحداً في عقدة واحدة، ويستعمل هذا المجال في تطبيقات الحلقة العكسية.
0010 مجال الوصلة المحلية يمتد المجال ليغطي الشبكة المحلية بشكلٍ متوافق مع شبكة عناوين البث فريد الوجهة المُستخدَمة محلياً.
0011 محجوز -
0100 مجال الإشراف المحلي يمتد المجال على جزء من الشبكة يقوم مشرفوها بتحديده، وهو أصغر مجال يمكن تحديده إشرافياً.
0101 مجال الموقع المحلي يمتد المجال ليغطي موقعاً محلياً واحداً، قد يشمل عدة شبكات محلية، ولكنَّها تعود لمنظمة واحدة.
0101 مجال المنظمة المحلي يمتد المجال على عدة مواقع محلية لمنظمة واحدة.
0101 المجال العالمي يشمل المجال الإنترنت كاملة.
1111 محجوز -
تكون قيم المجال غير المحجوزة وغير المُخصصة لمجال معين متاحة للاستخدام من قبل مشرفي الشبكة المحلية لتعريف مجالات فرعية تلائم أغراضهم الخاصة.[101]
  • حقل مُعرف المجموعة، وطوله 112 بت، ويضم مُعرفاً رقمياً يميز المجموعة ضمن المجال المُحدد بحقل المجال.

هناك بنى عناوين بث مجموعاتي أكثر تخصصاً، ومنها مثلاً ما تُعرِّفه الوثيقة RFC 3306،[102] وفيه يُقسم مُعرف المجموعة إلى ثلاثة أربعة حقول تتضمن مُعرِّفاً للمجموعة بطول 32 بت فقط، وحقلاً لبادئة شبكة البث فريد الوجهة الذي يُمنح العنوان على أساسها. وتصف الوثيقة RFC 7371 بنى عناوين البث المجموعاتي في الإصدار السادس وحالاتها المُختلفة ومعاني كلٍ منها.[103]

أفضية محجوزة

هناك أفضية عناوين محجوزة من أجل بروتوكولات محددة أو من أجل استعمالات خاصة، ولا يجوز استعمال عناوين من هذه الأفضية من أجل عنونة المُضيفين في شبكة الإنترنت. تشرف هيئة تعيين أرقام الإنترنت على حفظ وإدارة هذه الأفضية.[104]

أفضية البث فريد الوجهة والبث نحو الأقرب
جدول بأفضية العناوين الجزئية المحجوزة من فضاء عناوين الإصدار السادس من بروتوكول الإنترنت[105]
فضاء العناوين تاريخ الحجز ملاحظات مرجع
128/:: فبراير 2006 العنوان غير المُحدد [86]
1/128:: فبراير 2006 عنوان الحلقة العكسية [86]
ff9b::/96 أوكتوبر 2010 مخصص لمترجمات العناوين بين الإصدارين الرابع والسادس [106]
ffff:0:0/96:: فبراير 2006 فضاء العناوين المقترنة مع الإصدار الرابع [86]
64/::100 يونيو 2012 بادئة الاستبعاد (Discard Prefix)‏، وفي بادئة تستعمل في عملية التوجيه والترشيح للتخلص من رزم البيانات [107]
23/::2001 سبتمبر 2000 مخصص لعملية تطوير إرشادات لمنح أفضية الإصدار السادس من بروتوكول الإنترنت [108]
32/::2001 فبراير 2006 مخصص لدعم تقنية تيريدو للانتقال من الإصدار الرابع نحو الإصدار السادس من بروتوكول الإنترنت [109]
1/48::2001:1 أكتوبر 2015 عنوان مُخصص للبث نحو الأقرب لبروتوكول التحكم بالمنافذ [110]
2/48::2001:1 فبراير 2017 عنوان مُخصص للبث نحو الأقرب بروتوكول تخطي الترجمة باستعمال المُرحلات TURN [111]
48/::2001:2 أبريل 2008 فضاء مخصص لعملية المقارنة المرجعية [112]
32/::2001:3 ديسمبر 2014 فضاء مخصص للإنشاء الآلي لأنفاق البث المجموعاتي [113]
48/::2001:4:112 ديسمبر 2014 فضاء مخصص لمشروع النظام المستقل رقم 112 (AS112 project)‏ [114]
28/::2001:10 أبريل 2007(9) فضاء مخصص لبادئة معرفات التجزئة المُشفرة المتراكبة القابلة للتوجيه، المعروفة اختصاراً بالاسم الرمزي: أوركيد ORCHID [115]
28/::2001:20 يوليو 2014 فضاء مخصص للإصدار الثاني لبادئة معرفات التجزئة المُشفرة المتراكبة القابلة للتوجيه، المعروفة اختصاراً بالاسم الرمزي: أوركيد 2 [116]
2001:0db8::/32 يوليو 2004 فضاء مخصص لعملية التوثيق [117]
16/::2002 فبراير 2001 فضاء مخصص لدعم تقنية 6 إلى 4 (6to4)‏ للانتقال من الإصدار السادس نحو الإصدار الرابع من بروتوكول الإنترنت [118]
2620:4f:8000::/48 مايو 2001 فضاء مخصص لخدمة التفويض المباشر في مشروع النظام المستقل رقم 112 [119]
fc00::/7 أكتوبر 2005 مخصص لفضاء عناوين البث فريد الوجهة الفريد المحلي [120]
fe80::/10 أكتوبر 2005 مخصص لفضاء عناوين البث فريد الوجهة في الوصلة المحلية [89]
فضاء البث المجموعاتي

تدير أيانا فضاء عناوين البث المجموعاتي في الإصدار السادس من بروتوكول الإنترنت، وهو الفضاء الذي يتحدد بالبادئةFF00::/8.[121] هناك مجموعة من العناوين المُعرَّفة المحجوزة التي لا يجب منحها لأي مجموعة في شبكات الإصدار السادس، وهي:[122]

  • جميع العناوين ذات البنية ff0#:0:0:0:0:0:0:0، وعددها 16 عنواناً، حيث # هي مرتبة ستة عشرية تأخذ أي قيمة من المجال {1،2 .. 9} أو{A,B .. F}.
  • عنوانا مجموعتي كل العقد في مجال المنفذ وفي المجال المحلي، وهما على الترتيب: ff01:0:0:0:0:0:0:1 وff02:0:0:0:0:0:0:1.
  • عناوين مجموعات كل الموجهات في مجال المنفذ والمجال المحلي ومجال الموقع، وهذه العناوين هي على الترتيب: ff01:0:0:0:0:0:0:2 وff02:0:0:0:0:0:0:2 وff05:0:0:0:0:0:0:2.
  • عناوين من فضاء الالتماس لعناوين بث فريد الوجهة أو بث نحو الأقرب، ويتحدد هذا الفضاء بالبادئة: ff02:0:0:0:0:1:ff00::/104.
  • أي عناوين مجموعات أخرى محجوزة من قبل هيئة أرقام الإنترنت المُخصصة، مثل مجموعات الموجهات التي تشغل بروتوكولات التوجيه، مثلاً ff02:0:0:0:0:0:0:9 من أجل مجموعة كل الموجهات التي تشغل بروتوكول معلومات التوجيه، وff02:0:0:0:0:0:0:a من أجل مجموعة كل الموجهات التي تشغل بروتوكول التوجيه الداخلي المحسن بين البوابات وغير ذلك.[121]

عناوين ملزمة

تميّز معايير الإصدار السادس من بروتوكول الإنترنت بين المُضيف والمُوجِّه، فالموجه هو عقدة تقوم بعملية التوجيه لرزم بيانات للإصدار السادس من بروتوكول الإنترنت لم تقم بتوليدها. أمَّا المُضيف فهو أي عقدة ما خلا الموجهات.[42] بناءً على ذلك، يلزم على كل مُضيف أن يكون قادراً على تمييز العناوين التالية بصفتها معرفاتٍ ذاتية:[123]

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

أمَّا المُوجِّه، فيلزم أن يميز العناوين السابقة التي يميزها المضيف، وأيضاً العناوين التالية، بوصفها مُعرفات ذاتية:[123]

  • عناوين البث نحو الأقرب للشبكات الجزئية على جميع المنافذ التي هُيِّئت لتعمل بوصفها منافذَ للمُوجه.
  • جميع عناوين البث نحو الأقرب التي جرت تهيئة المُوحِّه بها.
  • جميع عناوين البث المجموعاتي المحجوزة للمُوجِّهات.[121]

التهيئة الذاتية الآلية

التهيئة الذاتية الآلية في الإصدار السادس من بروتوكول الإنترنت (IPv6 Stateless Address Autoconfiguration)‏ هي آلية تحدد الخطوات التي يتخذها مضيفو الإصدار السادس من أجل تهيئة منافذهم ذاتياً بعناوين وصلة محلية أو عناوين عالمية باستعمال معرفات المنفذ المولدة محليَّاً ومعلومات البادئات التي يحصل المُضيف عليها من إعلانات الموجهات في الشبكة المحلية، وتشمل هذه الآلية أيضاًإجراءاتٍ مُحددة لاكتشاف الاستخدام المتكرر للعنوان لضمان فرادته على مستوى الوصلة المحلية. لا تتطلب التهيئة الذاتية أي إعداد يدوي في المضيفين، وإعداد بسيطاً، وقد لا يكون ضرورياً، في الموجهات وهي لا تحتاج لوجود مُخدِّمات. يمكن للمضيف ،في غياب الموجهات، أن يولد عنواناً محلياً في الوصلة ذاتياً دون أي تدخل خارجي.[124]

تحصل عملية التهيئة الذاتية الآلية في المنافذ التي تدعم الإصدار السادس من بروتوكول الإنترنت في أربع حالات هي: تشغيل المنفذ بعد إقلاع النظام، وإعادة تشغيل المنفذ بعد فشل سابق له، واتصال المنفذ مع شبكة ما للمرة الأولى، وإعادة تفعيل المنفذ بعد تعطيل سابق لأسباب إشرافية.[125] تحصل عملية التوليد الذاتية الآلية لعنوان محلي في الوصلة باتباع الخطوات التالية:[126]

  1. تكون بادئة العنوان هي fe80::/10، وتحجز البتات العشرة الأعلى أهمية.
  2. يُملئ باقي العنوان بالأصفار.
  3. يحسب مُعرِّف المنفذ وليكن طوله N بت، وقد يحتوي على عنوان مادي موجود في المنفذ نفسه، ويكون طوله 64 بت في الغالب.
  4. بدءاً من الخانة الأقل أهمية في العنوان يُستبدل N صفراً في العنوان بمُعرف المنفذ.

يمكن أيضاً أن تستخدم الآلية السابقة نفسها في تشكيل عناوين فريدة عالمياً بشكل ذاتي وآلي. ولتحقيق ذلك، يلزم أن يحصل المُضيف على البادئة الفريدة عالمياً باستعمال بروتوكول اكتشاف الجيران سواء عن طريق إرسال رسالة التماس للمُوجهات الموجودة في الشبكة المحلية أو انتظار رسائل الإعلان التي تُرسلها بشكل دوري. بعد ذلك، يستعمل المضيف البادئة التي حصل عليها في الخطوة الأولى من الخوارزمية السابقة بدلاً من بادئة فضاء العناوين المحلية في الوصلة fe80::/10، ثُمَّ يتابع تنفيذ بقية الخطوات كما وردت.[127]

فيما يخص مُعرفات المنافذ، فيمكن توليدها باستعمال العناوين المادية كما في آلية توليد المُعرّف الفريد المُوسّع (EUI) المطورة من قبل معهد مهندسي الكهرباء والإلكترونيات،[128] أو تُولَّد بصورة مستقلة العناوين المادية باعتماد خوارزمية موصوفة في وثيقة طلب التعليقات RFC 7217 وتكون المُعرفات الناتجة عنها آمنة ومستقرة وفريدة على المستويين المحلي والعالمي.[129]

إدارة فضاء العناوين: التحصيص والمنح

هرمية تحصيص فضاء عناوين بروتوكول الإنترنت رباعية المستويات.
مثال عن مستويات التحصيص في الإصدار السادس من بروتوكول الإنترنت.

بشكل مشابه للإصدار الرابع من بروتوكول الإنترنت، تُشرف شركة الإنترنت للأرقام والأسماء الممنوحة المعروفة اختصاراً بالاسم آيكان، عبر هيئة أرقام الإنترنت المُخصصة على تحصيص فضاء عناوين الإصدار السادس من بروتوكول الإنترنت، وتجري عملية التحصيص بحسب هرميةٍ مكونةٍ من المستويات الأربعة نفسها. في هذه الهرمية، يقع العميل الذي يحصل على فضاء جزئي مُخصص في قاعدة هرم التحصيص وهو المستوى الرابع والأخير في الهرمية، أمّا المستويات الثلاثة الأولى، فهي مرتبة بدءاً من رأس الهرم كما يلي: هيئة أرقام الإنترنت المُخصصَة، ثًمَّ سجلات الإنترنت الإقليمية ويليها سجلات الإنترنت المحلية .[130]

وضع آيكان سياسةً تُنظِّم عملية التحصيص، تُلزَم أيانا بموجبها على تقديم حصص من العناوين لسجلات الإنترنت الإقليمية تكفي حاجتها 18 شهراً على الأقل، على أن يكون طول البادئة الأدنى الذي تحصصه أيانا هو البادئة 12/.[131] توفِّر عملية التهيئة الذاتية الآلية (Stateless address autoconfiguration اختصاراً SLAAC)‏ وسيلةً لعنونة المُضيفين آليَّاً باستعمال العناوين المحليَّة دون الحاجة لتدخلٍ يدويٍّ من قبل مدير الشبكة، حيث يجري ملء قسم مُعرِّف المنفذ اعتماداً على مُعرِّفات المنافذ.[126] تحدد وثيقة طلب التعليقات RFC 4291 العلاقة بين طولي البادئة مُعرف المنفذ في عنوان الإصدار السادس الذي يبلغ طوله 128 بتاً، فإذا كان طول البادئة هو n بت، فإن طول مُعرِّف المنفذ الملائم لعملية التهيئة الذاتية الآلية سيكون (128-n) بتاً،[132] وتدعم الشركات المُصنِّعة لبطاقات الشبكة هذا المعيار أو تقدِّم حلولاً متوافقة معه، مثل حل المُعرِّف الفريد المُوسَّع الذي وضعه معهد مهندسي الكهرباء والإلكترونيات لإيجاد التوافق مع العنوان المادي في الإيثرنت الذي يبلغ طوله 48 بتاً فقط.[128] أي يُستحسن أن يكون طول البادئة النهائي هو 64 بتاً لإتاحة الفرصة لعملية التهيئة الذاتية الآلية

نظريَّاً، خلال عمليتي التحصيص والتخصيص(10) لعناوين الإصدار السادس من بروتوكول الإنترنت، يكون طول البادئة محصوراً بين البادئة 12/ وهو الطول الأدنى الذي تحصصه أيانا، والبادئة 64/، وهو الطول الأقصى اللازم لدعم عملية التهيئة الذاتية الآلية. عمليَّاً، قامت أيانا بتحصيص بادئات بأطوال 23/ و12/ لسجلات الإنترنت الإقليمية[133] التي قدمت بدورها حلولاً لمزودات الخدمة أو للعملاء على حد سواء، لمنح أفضية جزئيَّة متنوعة الأحجام ذات بادئات لا يتجاوز طولها البادئة 64/، وعلى سبيل المثال، يَدعم مركز تنسيق شبكة الإنترنت الأوروبي (RIPE NCC)، وهو سجل إنترنت إقليمي، حصصاً لأفضية جزئية ذات بادئات يتراوح طولها بين البادئتين 32/ و64/، ويشير إلى أن الأطوال الأكثر شعبية هي للبادئتين 48/ و56/ وهي تضم على التوالي: 65,536 و256 شبكة جزئية مُحددة بالبادئة 64/.[134]

التجزئة

جدول لأطوال بادئة التوجيه غير الصنفي بين النطاقات في الإصدار السادس من بروتوكول الإنترنت وأعداد الشبكات الجزئية الموافقة لكل منها وعدد بتات قسم مُعرف المنفذ.
حالات حدود معرف الشبكة الجزئية (SID) في الإصدار السادس من بروتوكول الإنترنت.

يُقسّم مجال فضاء العناوين في الإصدار السادس من بروتوكول الإنترنت إلى مجموعة من الأفضية الجزئية بحسب الغرض من الاستخدام.[85] وتدير هيئة أرقام الإنترنت المُخصصة عملية تحصيص الأفضية، ومنها عملية تحصيص فضاء عناوين البث فريد الوجهة، وفيها تجري عملية منح العناوين الفريدة عالمياً على أساس جغرافي، وفق بنية هرمية تسمح باستعمال تقنيات التوجيه غير الصنفي بين النطاقات لاختزال عناوين الأفضية، والغرض من ذلك استقرار جداول التوجيه على المستوى العالمي، تقوم هيئة تعيين أرقام الإنترنت بتخصيص أفضية عناوين لسجلات الإنترنت الإقليمية، عن طريق منحها بادئات بطول 23 بت.[135] بعد ذلك، يقوم كل سجل إنترنت إقليمي بتجزئة فضاء العناوين إلى أفضية عناوين جزئية تمنح لمزودات الخدمة، وقد تحصل عملية المنح على أكثر من مستوى، مثل منح فضاء عناوين لمزود خدمة وطني ليقوم بتجزئته إلى أفضية أصغر تمنح لمزودات الخدمة المحلية.[136]

يحصل المُشتركون على أفضية عناوين جزئية من مزودات الخدمة المحلية، وتكون البادئة عادة بطول 48 بت، في الغالب الأعم يقتطع مديرو الشبكات قسماً يبلغ طوله 16 بت من مُعرف المنفذ، ويُنشؤون قسماً جديداً هو مُعرّف الشبكة الجزئية الذي يُضاف إلى البادئة فيصبح طولها النهائي 64 بت، ويترك ذلك 64 بت لمُعرّف المنفذ، وهو طول ملائم لآلية توليد المُعرّف الفريد المُوسّع.[137]

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

يتكون عنوان الإصدار السادس من بروتوكول الإنترنت من 128 بت، ويكتب بنظام العد الست عشري على شكل عدد مكوّن من 32 مرتبة ست عشرية، ويجري تجميع هذه المراتب ضمن رباعيات عددها 8 يضم كل منها (4) مراتب ست عشرية أو 16 بت.[77] عند تجزئة فضاء عناوين من الإصدار السادس، يجري اقتطاع قسم من مُعرّف المنفذ وإنشاء قسم جديد هو معرف الشبكة الجزئية، يمكن وفقاً لموقع نهاية مُعرّف الشبكة الجزئية ضمن العنوان التمييز بين الحالات التالية:

  1. مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المجموعات الرباعية، ويعني ذلك أن نهاية المُعرّف تكون عند أحد البتات ذوات الفهارس {15,31,47,63,79,95,111,127}.
  2. مُعرّف الشبكة الجزئية ينتهي عند حدود إحدى المراتب الست عشرية ضمن مجموعة رباعية، وهناك 3 حالات ممكنة في كل مجموعة رباعية، مثلاً في المجموعة الأولى هي البتات ذات الفهارس {3,7,11} وفي الثانية {19,23,27} وهكذا..
  3. مُعرّف الشبكة الجزئية ينتهي عند حدود أحد البتات ضمن خانة ست عشرية داخل مجموعة رباعية، وهناك 3 حالات ممكنة في ضمن كل خانة ست عشرية، مثلاً في الخانة الست عشرية الثانية تكون الحدود الممكنة عند البتات ذات الفهارس {4,5,6} وفي الخانة الست عشرية الثالثة عند البتات ذات الفهارس {8,9,10} وهكذا.(11)

أمثلة عن التجزئة في الإصدار السادس من بروتوكول الإنترنت:

  • التجزئة من أجل عدد محدد لأفضية عناوين الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود المجموعة الرباعية.

  • التجزئة من أجل عدد محدد لأفضية عناوين الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود مرتبة ست عشرية.

  • التجزئة من أجل حجم محدد لأفضية عناوين الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود بت ضمن مرتبة ست عشرية.

  • التجزئة من أجل طول محدد لقناع الشبكات الجزئية، حالة معرف الشبكة الجزئية ينتهي عند حدود مرتبة ست عشرية.

التقطيع

المبدأ العام للتقطيع في الإصدار السادس من بروتوكول الإنترنت.

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

نظرياً، يمكن إرسال رزمة بيانات تبلغ من الحجم 65535 بايتاً بدون تقطيعها ولكن غالباً ما يلزم التقطيع للتماشي مع حجم نقل أعظم أقل من هذه القيمة مُحدد سلفاً في طبقة الوصلة، أما حجم رزمة البيانات الأدنى الذي يدعمه البروتوكول فهو 1280 بايت.[39] يدعم البروتوكول أيضاً الرزم العملاقة (Jumbogram)‏، وهي رزم بيانات يتراوح طولها بين 65535 و4294967295 بايت وتستخدم في شبكات بيانات تدعم أحجام نقل عظمى أكبر من 65535.[140]

التقطيع

مخطط تدقفي يبين خوارزمية عملية التقطيع في الإصدار السادس من بروتوكول الإنترنت.

يعامِل المُضيف المصدر رزمة البيانات التي يريد تقطيعها على أنها مكوِّنة من ثلاثة أجزاء:[141]

  1. الترويسات التي ستوضع في القطع كلها: تضم هذه الترويسات ترويسة الإصدار السادس وترويسات التوسعة التالية لها حتى ترويسة التوجيه، إن وجدت، وإلا فحتى ترويسة خيارات المسار، إن وجدت، فإن غابت الترويستان السابقتان ضمَّ هذا الجزء ترويسة الإصدار السادس فقط.
  2. ترويسات التوسعة والطبقات العليا: وتضم جميع ترويسات التوسعة الأخرى التي لم تُشمل في القسم السابق، أما ترويسات الطبقات العليا فتشمل جميع الترويسات التي ليست ترويسات توسعة مثل ترويسات بروتوكول التحكم بالنقل وبروتوكول حزم بيانات المستخدم أو ترويسة بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت.(12)
  3. الحمولة: وهي القسم الذي سوف يُقطَّع، ويبدأ بعد ترويسات الطبقات العليا.

تجري عملية التقطيع وفق الخطوات التالية:[6]

  1. تحديد طول رزمة الإصدار السادس التي ستنتج عن التقطيع.
  2. إنشاء القطعة الأولى، وهي تتضمن ما يأتي وفقاً لتسلسل الورود: الترويسات التي ستوضع في القطع كلها وترويسة القطعة وترويسات التوسعة والطبقات العليا وقطعة من الحمولة، يحدد طولها كما يأتي:
    1. يُحسب مجموع أطوال الترويسات التي ستوضع في القطع كلها وترويسة القطعة وترويسات التوسعة والطبقات العليا.
    2. يُطرح المجموع من طول رزمة الإصدار السادس المُحدد بالخطوة الأولى، والناتج هو طول حمولة القطعة الأولى.
  3. تُقتطع حمولة القطعة الأولى من حمولة الرزمة الأصلية.
  4. تحديد عدد القطع اللازم تقطيعها بتقسيم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، على طول الرزمة المُحدد بالخطوة الأولى، إذا كان الجواب كسرياً، فإن القسم الصحيح هو عدد القطع الوسطى، أي التي تقع بين القطعتين الأولى والأخيرة، وأما الجزء الكسري، فيمثل القطعة الأخيرة.
  5. تقسم حمولة الرزمة الأصلية، بعد اقتطاع حمولة القطعة الأولى، إلى عدد القطع المحددة بالخطوة الرابعة.
  6. إنشاء القطع الوسطى: تتضمن القطع الوسطى الترويسات التي ستوضع في القطع كلها وترويسة القطعة وقطعة من الحمولة الناتجة عن الخطوة الخامسة ما خلا القطعة الأخيرة إذا كان عدد القطع كسرياً.
  7. إنشاء القطعة الأخيرة: وتتضمَّن الترويسات التي ستوضع في القطع كلها وترويسة القطعة والقطعة الأخيرة من الحمولة الناتجة عن الخطوة الخامسة.

إعادة التجميع

بنية رزمة بيانات الإصدار السادس من بروتوكول الإنترنت الناتجة عن إعادة تجميع القطع في المضيف الوجهة.

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

إدارة حركة البيانات

تعريف تدفقات حركة البيانات

يُستعمل حقل لافتة التدفق في ترويسة الإصدار السادس من بروتوكول الإنترنت لتعريف تدفق من رزم البيانات. وفقاً لمعيار البروتوكول، فإن رزم البيانات تنتمي لتدفق محدد إذا تطابقت ثلاثُ قيم فيها: عنوان مصدرها، وعنوان وجهتها وقيمة حقل لافتة التدفق فيها. تصنَّف رزم البيانات في الشبكة وفقاً للتدفق الذي تنتمي إليه، ثُمَّ تعامل على هذا الأساس، ويختص البروتوكول بتعريف آلية لتمييز تدفق الرزم، أما نوعية الخدمات المُقدَّمة للتدفقات فهي خارج نطاق محدداته.[143]

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

تصنيف حركة البيانات

بنية حقل صنف حركة البيانات في ترويسة الإصدار البروتوكول.

وهي آلية للتمييز بين رزم بيانات الإصدار السادس من بروتوكول الإنترنت اعتماداً على قيم حقل صنف حركة البيانات ذي البتات الثمانية في ترويسة البروتوكول، تُضبط هذه القيم هي العقدة المصدر أو في العقد التي تعالج الرزمة على طول المسار. بعد ذلك، تُمنح الخدمات وأولوية المعالجة للرزم بناء على قيمة هذا الحقل.[145] طُبقت آلية مشابهة في الإصدار الرابع من بروتوكول الإنترنت، وسُمي الحقل المختص بها في ترويسة البروتوكول بحقل توع الخدمة، وكان طوله 8 بت أيضاً.[146]

يُقسَّم حقل صنف حركة البيانات إلى قسمين، هما قسم موقع ترميز الخدمات المتمايزة (Differentiated services codepoint)‏ ويشغل البتات الستة الأكثر أهمية من الحقل، وقسم البتات غير المُستعملة ويشمل البتين الأخيرين.[147] وتحدد الوثيقة RFC 2474 بنية محددة لقسم موقع الترميز هي: "xxx000" حيث تُمثِّل x بتاً واحد قد تكون قيمته 0 أو 1، ويسمح ذلك بإنشاء 8 أصناف متمايزة لرزم البيانات.[148] يُحجز الترميز "000000" ليكون القيمة الافتراضية الدائمة لهذا الحقل، أما القيم السبعة الأخرى، أي {"001000"، "010000"، "011000" ... "111000"}، فهي قابلة للتهيئة وفقاً للحاجة ولتعريف مستويات جودة الخدمة المطلوبة.[149]

المُشكلات

مرتبطة بتقطيع البيانات

ينتج عن استخدام التقطيع في الإصدار السادس من بروتوكول الإنترنت عدد من الثغرات أمنيّة التي قد تستخدم لشن هجمات مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وتختلف إمكانية شن الهجمات بحسب نظام التشغيل الذي يستعمل البروتوكول.[9] بشكلٍ مُشابه للإصدار الرابع من بروتوكول الإنترنت، لم تمنع مُحددات الإصدار السادس إنشاء قطع متراكبة عند التقطيع، أي من الممكن أن يتكرار نفس المقطع من الحمولة في أكثر من قطعة، على أن يُعتمد المقطع الوارد في آخر قطعة تمّ استقبالها عند التجميع، يسبب ذلك ثغرة أمنية، ويسمح بتنفيذ هجوم القطع المتراكبة، لاحقاً تمّ التأكيد بوضوح على منع تراكب القطع عند التقطيع في وثيقة طلب التعليقات RFC 5722.[150]

يقبل مُضيف الإصدار السادس من بروتوكول الإنترنت أن تحتوي رزمة البيانات على ترويسة القطعة بدون تكون القطعة ناتجة عن عملية تقطيع، وتسمى هذه القطع بالقطع الذرية (Atomic Fragment)‏ وهي تنتج في حالات خاصة ناقشها المعيار الأصلي للبروتوكول،[151] على الرغم من أن هذه القطع تكون وحداناً، أي لا يجب أن يتم تجميعها مع أي قطع أخرى، فإنّ المُضيف الوجهة يعاملها مُعاملة القطع التي تنتظر التجميع، ما يُسبب ثغرة أمنية، فقد يقوم المهاجم بإرسال قطعة خبيثة مع قيم مُناسبة في ترويسة القطعة، بحيث تكون قطعة ذرية تقبل التجميع مع قطع أخرى خبيثة تُرسل لاحقاً، ناقشت الوثيقة RFC 6946 كيفية معالجة القطع الذرية لتلافي هذا النوع من الهجمات.[152]

مرتبطة بإدارة حركة البيانات

يُمكن تزوير قيمة حقل لافتة التدفق في رزمة بيانات ما من أجل حصولها على خدمة محددة أو معاملة تفضيلية عند معالجتها،[153] وليس هناك طريقة لحماية حقل التدفق في ترويسة البروتوكول من العبث حتى ولو استعملت حزمة بروتوكول الإنترنت الأمنية،[154] ويُشكِّل هذا ثغرة أمنية، ويُستحسن أن تكون قيمة هذا الحقل شبه عشوائية بحيث يصعب على المهاجم تخمين قيمة المعرف المُستعمل.[155] يُمكن أيضاً أن تُستخدم قيمة حقل لافتة التدفق من أجل إجراء تحليل لحركة البيانات في الشبكة، أو لتتبع حركة بيانات مُحددة. وحتى لو جرى تشفير الرسالة، فإن تشفير قيمة ثابتة غير متغيرة قد ينتج قيماً ثابتة في الرسالة المُشفرة تساعد في تحليلها أو في كشف آلية التشفير أو في كشف ترتيب البيانات في الرسالة.[156]

هناك هجوم يُسمى هجوم سرقة الخدمة (Theft of Service)‏ وفيه تُغيَّر قيمة حقل صنف الخدمة في رزمة بيانات ما من أجل زيادة أولويتها أو رفع جودة الخدمة المُقدمة لها، كما يُمكن أن يُشنَّ هجوم حجب الخدمة أيضاً من خلال تغيير قيمة حقل صنف الخدمة، لجعل رزمة أو مجموعة رزم بيانات تحصل على جودة خدمة أقل من الجودة المتوقعة لها، وقد يسبب هذا تأخيراً زمنياً في وصولها إلى هدفها أو التخلص منها في الوجهة.[10]

بروتوكولات رديفة

بروتوكول رسائل التحكم في الإنترنت للإصدار السادس

بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت
Internet Control Message Protocol for IPv6
اختصار ICMPv6
الوظيفة بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت
المُطوِّر مجموعة مهندسي شبكة الإنترنت
التاريخ ديسمبر 1995
مبني على بروتوكول رسائل التحكم في الإنترنت
طبقة نموذج الاتصال المعياري طبقة الشبكة
وثيقة طلب التعليقات RFC 4443[34]

بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت (Internet Control Message Protocol for IPv6 اختصاراً ICMPv6)‏ هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت وجزءٌ مدمج منه، طُوِّر هذا البروتوكول بالتوازي مع الإصدار السادس من بروتوكول الإنترنت وصدر معياره الأصلي في شهر ديسمبر من العام 1995م ووصف في وثيقة طلب التعليقات RFC 1885.[26]

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

يُعرِّف البروتوكول ترويسة خاصة به طولها 4 بايت، تُضاف بعد ترويسة الإصدار السادس. ولهذه الترويسة مُعرِّف مميز هو 58، يلزم أن يُشار إليه في حقل الترويسة التالية في داخل الترويسة التي تسبق ترويسة هذا البروتوكول. بالإضافة لذلك، يُعرِّف المعيار الأصلي للبروتوكول 4 رسائل أخطاء وثلاث رسائل استعلام.[158] ولكن أضيفت العديد من الرسائل لاحقاً لخدمة وظائف مختلفة مثل رسائل التماس الموجه التي أضافها بروتوكول اكتشاف الجيران وغير ذلك.[159]

في شهر ديسمبر من العام 1998 صدر تحديث جديد للبروتوكول في وثيقة طلب التعليقات RFC 2463،[32] وبعدها بثمانية سنوات صدرت الوثيقة RFC 4443 وهي المعيار الحالي للبروتوكول وهي تتضمن تفصيلاً إضافياً عن الثغرات الأمنية التي يمكن استعماها لشن هجمات عبر البروتوكول وكيفية الوقاية منها ومجموعة من الاعتبارات اللازمة لهيئة أرقام الإنترنت المُخصصة من أجل تعريف أنواع رسائل جديدة.[34]

بروتوكول اكتشاف الجيران

بروتوكول اكتشاف الجيران
Neighbor Discovery Protocol
اختصار NDP
الوظيفة بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت
المُطوِّر مجموعة مهندسي شبكة الإنترنت
التاريخ أغسطس 1996
مبني على بروتوكول رسائل التحكم في الإنترنت
طبقة نموذج الاتصال المعياري طبقة الشبكة وطبقة الوصلة
وثيقة طلب التعليقات RFC 4861

بروتوكول اكتشاف الجيران (Neighbor Discovery Protocol)‏ هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت، يعمل بين الطبقتين الثانية والثالثة وفقاً لنموذج الاتصال المعياري، ويقدم خدمات التعرف على الموجهات والتعرف على الجيران وإعادة التوجيه. طرح المعيار الأصلي للبروتوكول في أغسطس من العام 1996 ووصف في وثيقة طلب التعليقات RFC 1970.[35]

يُعرِّف هذا البروتوكول 5 رسائل من بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت هن: رسالة إعادة التوجيه وزوج من الرسائل لاكتشاف عناوين الموجهات في الشبكة المحلية، هما رسالتا التماس الموجه والإعلان الموجه، وزوج لاكتشاف عناوين الجيران، هما رسالتا التماس الجار والإعلان عن الجار اللتان أدى بهما البروتوكول مع الإصدار السادس وظيفة اقتران العناوين بين الطبقتين الثالثة والثانية، وهي الوظيفة نفسها يؤديها بروتوكول اقتران العناوين مع الإصدار الرابع من بروتوكول الإنترنت.[160]

طُوِّرت أشكال متنوعة مشتقة من هذا البروتوكول، منها بروتوكول اكتشاف الجيران العكسيّ (Inverse Neighbor Discovery Protocol)‏ الذي يؤدي وظيفة اقتران العناوين العكسية بين الطبقتين الثانية والثالثة والذي وصف في الوثيقة RFC 3122 على أنه توسعة لبروتوكول اكتشاف الجيران،[161] وأيضاً بروتوكول اكتشاف الجيران الآمن ( SEcure Neighbor Discovery Protocol اختصاراً SEND)‏ الذي يُعرِّف آلياتٍ آمنة لتبادل بيانات الشبكة وفق بروتوكول اكتشاف الجيران، وقد وُصِف في وثيقة طلب التعليقات RFC 3971.[162]

في ديسمبر من العام 1998م، صدر تحديث جديد للمعيار، وحملت الوثيقة الاسم الرمزي RFC 2461. ثم صدرت الوثيقة RFC 4861 في شهر سبتمبر من العام 2007م، وهي المعيار الحالي لبروتوكول اكتشاف الجيران.[35]

بروتوكول اكتشاف مستمعي البث المجموعاتي

بروتوكول اكتشاف مستمعي البث المجموعاتي
Multicast Listener Discovery
الوظيفة إدارة مجموعة البث المجموعاتي في الإصدار السادس من بروتوكول الإنترنت
المُطوِّر مجموعة مهندسي شبكة الإنترنت
التاريخ 2004
طبقة نموذج الاتصال المعياري طبقة الشبكة
وثيقة طلب التعليقات RFC 3810[163]

بروتوكول اكتشاف مستمعي البث المجموعاتي (Multicast Listener Discovery اختصاراً MLD)‏ هو بروتوكول اتصال يعمل على مستوى الطبقة الثالثة وفقاً لنموذج الاتصال المعياري، يقوم بإدارة المجموعات الخاصة بالبث المجموعاتي لرزم الإصدار السادس من بروتوكول الإنترنت، وبشكلٍ خاص اكتشاف أعضاء الجموعات في الشبكات المحلية وتحديد أي المجموعات التي يهتمون باستقبال رزمها.[164]

يُقدّم البروتوكول مفهوماً خاصاً بالإصدار السادس هو مفهوم مُستمع البث المجموعاتي (Multicast Listener)‏، وهو بحسب التعريف، عقدة ترغب في استقبال رزم البث المجموعاتي. إذا استضاف المستمع عنوان مجموعة ما، أصبح عضواً فيها، وبات يهتم باستقبال رزمها. يمكن أن ينضم المستمع إلى أكثر من مجموعة بنفس الوقت. ومن هنا حصل البروتوكول على اسمه، فالبروتوكول يساعد تجهيزات الطبقة الثالثة المُتصلة مع الشبكة المحليّة على اكتشاف وجود المُستمعين فيها. يُوصف البروتوكول أيضاً بأنه غير متناظر (Asymmertic)‏، لأنه يسلك سلوكاً مختلفاً عند تعامله مع المستمعين عن ذلك الذي يتبعه معه تجهيزات الطبقة الثالثة، كالمُوجِّهات.[165]

هناك إصداران لبروتوكول اكتشاف مستمعي الإنترنت، الإصدار الأول منه موصوف في وثيقة طلب التعليقات RFC 2710 [166] وقد طُوّر في العام 1999م، وهو مُكافئ للإصدار الثاني من بروتوكول إدارة مجموعة الإنترنت (IGMPv2) من حيث الوظيفة، أمّا الإصدار الثاني فطوّر في العام 2004م، وهو موصوف بالوثيقة RFC 3810[167] ويُكافئ الإصدار الثالث من بروتوكول إدارة مجموعة الإنترنت (IGMPv3)، ويدعم ميزات إضافية مثل البث المجموعاتي مُحدد المصدر [168].

هوامش

1. لا يُلزم المعيار منفذي البروتوكول اتباعَ الترتيب السابق إلزامياً، ولكنه يستحسن ذلك.[48]

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

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

4. القطاع الشبكي هو اتصال كهربائي مشترك بين منافذ الشبكة.[169]

5. يختلف تفسير معنى كلمة "أقرب" باختلاف بروتوكول التوجيه المُستعمل، فلكل بروتوكول توجيه آلية محددة لقياس وزن المسار، قد تعتمد على عدد القفزات للوجهة، أو على مُعدل النقل في الوصلات أو غير ذلك، ويتحدد المنفذ الأقرب حسبَ هذه الآلية.

6. يلزم أن تُكتب الحروف اللاتينية بالحالة الصغيرة لا الكبيرة، أي a لا A.[170]

7. لا تستخدم محددات البروتوكول كلمة رباعية، ولكن هذه الكلمة شائعة لوصف هذا المفهوم.

8. بسبب كون قيمة بت المحلية ثابتة دائماً على القيمة 1، لعدم وجود استخدام آخر لها حتى الآن، فإن بعض المراجع تشير لبادئة هذا الفضاء بالشكل fd::/8 بدلاً من fc::/7، وهذا خطأ شائع لا يجوز، لأن المعيار الرسمي يُشير إلى إمكانية تطوير لاحقة لاستخدامات أخرى لهذا العنوان تكون قيمة بت محلية فيها مساويةً للصفر.[120]

9. حُرر هذا الفضاء في شهر مارس من العام 2014، ولم يعد محجوزاً.[105]

10. للتحصيص (Allocation)‏ وللتخصيص (Assignment)‏ معنيان متمايزان في نظام سجلات عناوين الأنترنت. يُشير الأول، أي التحصيص، إلى تفويض منظمةٍ بالإشراف على فضاءٍ جزئيٍّ من فضاء بروتوكول الإنترنت مع توقعٍ بقيام هذه المنظمة بتجزئة الفضاء وتفويض الأفضية الجزئية الناتجة إلى منظمات أخرى. أمّا الثاني، أي التخصيص، فهو يستعمل عند منح الفضاء إلى الجهات التي تستخدمه مباشرة في عنونة مجموعة من المضيفين.[171]

11. يُستثنى البت رقم (0) من المرتبة الستة عشرية الأولى، ولذلك فحدود نهاية معرّف الشبكة الجزئية الخاصة بها تضمّ البتات ذات الفهارس {1,2} فقط، والسبب في ذلك أن استعماله يعني بادئة شبكة بطول (0) بت، وهي حالة مستحيلة.

12. في هذا السياق، تُستثنى ترويسة تغليف الحمل الأمني وتعامل معاملة ترويسة الطبقات العليا على الرغم من أنها ترويسة توسعة للإصدار السادس من البروتوكول.[141]

مقالات ذات صلة

المراجع

فهرس المراجع

  1. RFC 8200, P.1
  2. Deering, S.; Hinden, R. (ديسمبر 1995). "RFC 1883, Internet Protocol, Version 6 (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1883. مؤرشف من الأصل في 21 ديسمبر 201930 مايو 2018.
  3. RFC 8200, P.7-10
  4. Cisco CCENT/CCNA ICND1, P.579
  5. RFC 4291, P.2-3
  6. RFC 8200, P.17-19
  7. RFC 6437, P.1
  8. RFC 2474, P.1-2
  9. Atlasis, Antonios (2002). "Attacking IPv6 Implementation Using Fragmentation" ( كتاب إلكتروني PDF ). Black-Hat Europe. مؤرشف من الأصل ( كتاب إلكتروني PDF ) في 25 مارس 2020.
  10. RFC 2474, P.15
  11. RFC 791, P.1
  12. Cisco CCENT/CCNA ICND1, P.611
  13. RFC 791, P.7
  14. Cisco CCENT/CCNA ICND1, P.296
  15. Deering, S. (أغسطس 1989). "RFC 1112, Host Extensions for IP Multicasting". The Internet Society (باللغة الإنجليزية). صفحة 3. doi:10.17487/RFC1112. مؤرشف من الأصل في 03 فبراير 20205 سبتمبر 2019.
  16. RFC 4632, P.4
  17. Fuller, V.; Li, T.; Yu, J.; Varadhan, K. (سبتمبر 1993). "RFC 1338, Supernetting: an Address Assignment and Aggregation Strategy" (باللغة الإنجليزية). doi:10.17487/RFC1338. مؤرشف من الأصل في 20 يناير 2020.
  18. Fuller, V.; Li, T.; Yu, J.; Varadhan, K. (سبتمبر 1993). "RFC 1519, Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy" (باللغة الإنجليزية). doi:10.17487/RFC1519. مؤرشف من الأصل في 06 مارس 2020.
  19. Egevang, K.; Francis, P. (مايو 1994). "RFC 1631, The IP Network Address Translator (NAT)" (باللغة الإنجليزية). doi:10.17487/RFC1631. مؤرشف من الأصل في 25 يناير 202012 يناير 2020.
  20. Cisco CCENT/CCNA ICND1, P.612
  21. "Free Pool of IPv4 Address Space Depleted". Number Resource Organization (باللغة الإنجليزية). 3 فبراير 2011. مؤرشف من الأصل في 5 مارس 20206 مارس 2019.
  22. Bradner, S.; Mankin, A. (ديسمبر 1993). "RFC 1550, IP: Next Generation (IPng) White Paper Solicitation" (باللغة الإنجليزية). doi:10.17487/RFC1550. مؤرشف من الأصل في 04 ديسمبر 2019.
  23. RFC 1752, P.2
  24. RFC 1752, P.45
  25. Hinden, R.; Deering, S. (ديسمبر 1995). "RFC 1884, IP Version 6 Addressing Architecture" (باللغة الإنجليزية). doi:10.17487/RFC1884. مؤرشف من الأصل في 06 مارس 2020.
  26. RFC 1885, P.1
  27. Narten, T.; Nordmark, E.; Simpson, W. (أغسطس 1996). "RFC 1970, Neighbor Discovery for IP Version 6 (IPv6)" (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC1970. مؤرشف من الأصل في 04 ديسمبر 2019.
  28. Thomson, S.; Narten, T. (ديسمبر 1995). "RFC 1971, IPv6 Stateless Address Autoconfiguration" (باللغة الإنجليزية). doi:10.17487/RFC1971. مؤرشف من الأصل في 12 ديسمبر 2019.
  29. RFC 2460, P.1
  30. Narten, T.; Nordmark, E.; Simpson, W. (ديسمبر 1998). "RFC 2461, Neighbor Discovery for IP Version 6 (IPv6)" (باللغة الإنجليزية). doi:10.17487/RFC2461. مؤرشف من الأصل في 13 مارس 2020.
  31. Thomson, S.; Narten, T. (ديسمبر 1998). "RFC 2462, IPv6 Stateless Address Autoconfiguration" (باللغة الإنجليزية). doi:10.17487/RFC2462. مؤرشف من الأصل في 07 مايو 2020.
  32. Conta, A.; Deering, S. (ديسمبر 1998). "RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" (باللغة الإنجليزية). doi:10.17487/RFC2463. مؤرشف من الأصل في 16 مارس 2020.
  33. "RFC 4291, P.1
  34. RFC 4443, P.1
  35. RFC 4861, P.1
  36. RFC 4862, P.1
  37. Network Protocols Handbook (باللغة الإنجليزية) (الطبعة الثانية). Javvin Technologies Inc. 2005. صفحة 67. مؤرشف من الأصل ( كتاب إلكتروني PDF ) في 28 مايو 2020.
  38. RFC 8200, P.4
  39. TCP/IP Illustrated, P.184
  40. McCann, J.; Deering, S.; Mogul, J.; Hinden, Ed., R. (يوليو 2017). "RFC 8201, IPv6 Flow Label Specification" (باللغة الإنجليزية). doi:10.17487/RFC8201. ISSN 2070-1721. مؤرشف من الأصل في 11 مارس 2020.
  41. RFC 6437, P.3
  42. RFC 8200, P.5
  43. RFC 8200, P.7
  44. RFC 8200, P.9
  45. TCP/IP Illustrated, P.194
  46. RFC 8200, P.24
  47. "Internet Protocol Version 6 (IPv6) Parameters - Next Header Types" (باللغة الإنجليزية). مؤرشف من الأصل في 28 فبراير 202023 مايو 2020.
  48. RFC 8200, P.10
  49. RFC 8200, P.8
  50. Perkins, Ed., C.; Johnson, D.; Arkko, J. (يوليو 2011). "RFC 6275, Mobility Support in IPv6" (باللغة الإنجليزية). صفحة 49. doi:10.17487/RFC6275. ISSN 2070-1721. مؤرشف من الأصل في 11 مارس 2020.
  51. Moskowitz, Ed, R.; Heer, T.; Jokela, P.; Henderson, T. (أبريل 2015). "RFC 7401, Host Identity Protocol Version 2 (HIPv2)" (باللغة الإنجليزية). صفحة 38. doi:10.17487/RFC7401. ISSN 2070-1721. مؤرشف من الأصل في 05 مايو 2020.
  52. RFC 8200, P.6-7
  53. "Assigned Internet Protocol Numberss" (باللغة الإنجليزية). مؤرشف من الأصل في 13 فبراير 202023 مايو 2020.
  54. RFC 8200 P.13
  55. TCP/IP Illustrated, P.200
  56. RFC 791, P.16
  57. RFC 8200, P.14
  58. "Internet Protocol Version 6 (IPv6) Parameters" (باللغة الإنجليزية). مؤرشف من الأصل في 7 مايو 202023 مايو 2020.
  59. Abley, J.; Savola, P.; Neville-Neil, G. (ديسمبر 2007). "RFC 5095, Deprecation of Type 0 Routing Headers in IPv6". The Internet Society (باللغة الإنجليزية). صفحة 3. doi:10.17487/RFC5095. مؤرشف من الأصل في 02 مايو 202023 مايو 2020.
  60. RFC 8200, P.15
  61. RFC 8200, P.19
  62. "Protocol Numbers". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 4 يناير 201818 يوليو 2018.
  63. RFC 8200, P.15-16
  64. Gont, F. (فبراير 2016). "RFC 7739, Security Implications of Predictable Fragment Identification Values". The Internet Society (باللغة الإنجليزية). ISSN 2070-1721. مؤرشف من الأصل في 28 مايو 202017 يوليو 2018.
  65. RFC 8200, P.23
  66. RFC 4302, P.3
  67. RFC 4302, P.4
  68. RFC 4302, P.5-9
  69. RFC 4303 P.1
  70. RFC 4303 P.5
  71. RFC 4303 P.10-17
  72. TCP/IP Illustrated, P.196
  73. RFC 8200, P.11
  74. RFC 8200, P.12
  75. RFC 8200, P.36-38
  76. RFC 8200, P.12-13
  77. Cisco CCENT/CCNA ICND1, P.617
  78. RFC 4291 P.7
  79. RFC 5952 P.2
  80. Cisco CCENT/CCNA ICND1, P.619
  81. Cisco CCENT/CCNA ICND1, P.617-618
  82. RFC 4291, P.4-5
  83. RFC 4632, P.5
  84. RFC 4291, P.5
  85. RFC 4291, P.6
  86. RFC 4291, P.9
  87. RFC 4291, P.10
  88. Cisco CCENT/CCNA ICND1, P.634
  89. RFC 4291, P.11
  90. Cisco CCENT/CCNA ICND1, P.632
  91. RFC 4193, P.2
  92. RFC 4193, P.3-4
  93. Huitema, C.; Carpenter, B. (سبتمبر 2004). "RFC 3879, Deprecating Site Local Addresses" (باللغة الإنجليزية). doi:10.17487/RFC3879. مؤرشف من الأصل في 07 مايو 2020.
  94. Shin, M-K.; Hong, Y-G.; Hagino, J.; Savola, P.; Castro, E. M. (مارس 2004). "RFC 4038, Application Aspects of IPv6 Transition" (باللغة الإنجليزية). doi:10.17487/RFC4038. مؤرشف من الأصل في 14 أبريل 2020.
  95. RFC 4291, P.12
  96. RFC 4291, P.13
  97. Peter Dyson; Kevin Shafer (1999). Dictionary of Networking (باللغة الإنجليزية) (الطبعة الثالثة). SYBEX Inc. صفحة 1999.  . مؤرشف من الأصل في 28 مايو 2020.
  98. Savola, P.; Haberman, B. (نوفمبر 2004). "RFC 3956, Application Aspects of IPv6 Transition" (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC3956. مؤرشف من الأصل في 24 يناير 202025 مايو 2020.
  99. RFC 3306, P.3
  100. Droms, R. (أغسطس 2014). "RFC 7346, IPv6 Multicast Address Scopes" (باللغة الإنجليزية). صفحة 3. doi:10.17487/RFC7346. ISSN 2070-1721. مؤرشف من الأصل في 24 يناير 202025 مايو 2020.
  101. RFC 4291, P.14
  102. RFC 3306, P.1
  103. Boucadair, M.; Venaas, S. (سبتمبر 2014). "RFC 7371, Updates to the IPv6 Multicast Addressing Architecture" (باللغة الإنجليزية). doi:10.17487/RFC7371. ISSN 2070-1721. مؤرشف من الأصل في 24 يناير 202025 مايو 2020.
  104. Cotton, M.; Vegoda, L.; Bonica, Ed., R.; Haberman, B. (أبريل 2013). "RFC 6890, Special-Purpose IP Address Registries". The Internet Society (باللغة الإنجليزية). صفحة 14-20. doi:10.17487/RFC6890. ISSN 2070-1721. مؤرشف من الأصل في 16 فبراير 2020.
  105. "IANA IPv6 Special-Purpose Address Registry". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 2 يناير 202025 مايو 2020.
  106. Bao, C.; Huitema, C.; Bagnulo, M.; Boucadair, M.; Li, X. (أكتوبر 2010). "RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC6052. ISSN 2070-1721. مؤرشف من الأصل في 10 مايو 2020.
  107. Hilliard, N.; Freedman, D. (أغسطس 2012). "RFC 6666, A Discard Prefix for IPv6". The Internet Society (باللغة الإنجليزية). صفحة 4. doi:10.17487/RFC6666. ISSN 2070-1721. مؤرشف من الأصل في 25 يناير 2020.
  108. Hinden, R.; Deering, S.; Fink, R.; Hain, T. (سبتمبر 2000). "RFC 2928, Initial IPv6 Sub-TLA ID Assignments". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC2928. مؤرشف من الأصل في 27 يناير 2020.
  109. Huitema, C. (فبراير 2006). "RFC 4380, Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)". The Internet Society (باللغة الإنجليزية). صفحة 4. doi:10.17487/RFC4380. مؤرشف من الأصل في 11 مايو 2020.
  110. Kiesel, S.; Penno, R. (يناير 2016). "RFC 7723, Port Control Protocol (PCP) Anycast Addresses". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC7723. ISSN 2070-1721. مؤرشف من الأصل في 07 مايو 2020.
  111. Patil, P.; Reddy, T.; Wing, D. (أبريل 2017). "RFC 8155, Traversal Using Relays around NAT (TURN) Server Auto Discovery". The Internet Society (باللغة الإنجليزية). صفحة 9. doi:10.17487/RFC8155. ISSN 2070-1721. مؤرشف من الأصل في 16 أبريل 2020.
  112. Popoviciu, C.; Hamza, A.; Van de Velde, G.; Dugatkin, D. (مايو 2008). "RFC 5180, IPv6 Benchmarking Methodology for Network Interconnect Devices". The Internet Society (باللغة الإنجليزية). صفحة 11. doi:10.17487/RFC5180. مؤرشف من الأصل في 11 مارس 2020.
  113. Bumgardner, G. (فبراير 2015). "RFC 7450, Automatic Multicast Tunneling". The Internet Society (باللغة الإنجليزية). صفحة 78. doi:10.17487/RFC7450. ISSN 2070-1721. مؤرشف من الأصل في 16 أبريل 2020.
  114. Abley, J.; Dickson, B.; Michaelson, G. (مايو 2015). "RFC 7535, AS112 Redirection Using DNAME". The Internet Society (باللغة الإنجليزية). صفحة 4. doi:10.17487/RFC7535. ISSN 2070-1721. مؤرشف من الأصل في 07 مايو 2020.
  115. Nikander, P.; Laganier, J.; Dupont, F. (أبريل 2007). "RFC 4843, An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC4843. مؤرشف من الأصل في 25 يناير 2020.
  116. Laganier, J.; Dupont, F. (سبتمبر 2014). "RFC 7343, an IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)". The Internet Society (باللغة الإنجليزية). صفحة 6. doi:10.17487/RFC7343. ISSN 2070-1721. مؤرشف من الأصل في 24 يناير 2020.
  117. Huston, G.; Dickson, B.; Lord, A.; Smith, P. (يوليو 2004). "RFC 3849, IPv6 Address Prefix Reserved for Documentation". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC3849. مؤرشف من الأصل في 26 مايو 2020.
  118. Carpenter, B.; Moore, K. (فبراير 2001). "RFC 3056, Connection of IPv6 Domains via IPv4 Clouds". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC3056. مؤرشف من الأصل في 12 مايو 2020.
  119. Abley, J.; Sotomayor, W. (مايو 2015). "RFC 7534, AS112 Nameserver Operations". The Internet Society (باللغة الإنجليزية). صفحة 6. doi:10.17487/RFC7534. ISSN 2070-1721. مؤرشف من الأصل في 16 أبريل 2020.
  120. RFC 4193, P.3
  121. "IPv6 Multicast Address Space Registry". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 7 مايو 201825 مايو 2020.
  122. RFC 4291, P.16-17
  123. RFC 4291, P.17
  124. RFC 4862, P.3
  125. RFC 4862, P.11-12
  126. RFC 4862, P.12
  127. RFC 4862, P.17-21
  128. "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)" ( كتاب إلكتروني PDF ). IEEE (باللغة الإنجليزية). 3 أغسطس 2017. صفحة 9-10. مؤرشف من الأصل ( كتاب إلكتروني PDF ) في 28 فبراير 20208 مارس 2020.
  129. Gont, F. (أبريل 2014). "RFC 7217, A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC7217. ISSN 2070-1721. مؤرشف من الأصل في 08 فبراير 2020.
  130. Housley, R.; Curran, J.; Huston, G.; Conrad, D. (أغسطس 2013). "RFC 7020, The Internet Numbers Registry System" (باللغة الإنجليزية). صفحة 4-5. doi:10.17487/RFC7020. ISSN 2070-1721. مؤرشف من الأصل في 06 مارس 2020.
  131. "Internet Assigned Numbers Authority (IANA) Policy For Allocation of IPv6 Blocks to Regional Internet Registries (Ratified 7 September 2006)". icann.org (باللغة الإنجليزية). مؤرشف من الأصل في 28 فبراير 20208 مارس 2020.
  132. RFC 4291, P.7
  133. "IPv6 Global Unicast Address Assignments". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 16 فبراير 20208 مارس 2020.
  134. "Understanding IP Addressing and CIDR Charts". RIPE NCC (باللغة الإنجليزية). مؤرشف من الأصل في 15 فبراير 20208 مارس 2020.
  135. "IPv6 Global Unicast Address Assignments". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 22 فبراير 20182 سبتمبر 2018.
  136. "Understanding IP Addressing and CIDR Charts". RIPE (باللغة الإنجليزية). 4 يناير 2011. مؤرشف من الأصل في 23 سبتمبر 201823 سبتمبر 2018.
  137. Cisco CCENT/CCNA ICND1, P.639
  138. Charles M. Kozierok (2005). The TCP/IP Guide ( كتاب إلكتروني PDF ) (باللغة الإنجليزية). William Pollock. صفحة 464.  .
  139. RFC 8200, P.15-22
  140. Hinden, R. (أغسطس 1999). "RFC 2675, IPv6 Jumbograms". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC2675. مؤرشف من الأصل في 03 مايو 2020.
  141. RFC 8200, P.17
  142. RFC 8200, P.20
  143. RFC 6437, P.4
  144. RFC 6437, P.5
  145. RFC 2460, P.25
  146. RFC 2460, P.29-30
  147. RFC 2474, P.7
  148. RFC 2474, P.11
  149. RFC 2474, P.13
  150. Krishnan, S. (فبراير 2016). "RFC 5722, Handling of Overlapping IPv6 Fragments". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 11 مايو 202021 يوليو 2018.
  151. RFC 8200, P.31
  152. Gont, F. (مايو 2013). "RFC 6946, Processing of IPv6 "Atomic" Fragments". The Internet Society (باللغة الإنجليزية). ISSN 2070-1721. مؤرشف من الأصل في 11 مارس 202021 يوليو 2018.
  153. RFC 6437, P.9
  154. RFC 6437, P.10
  155. Gont, F. (12 مارس 2012). "Security Assessment of the IPv6 Flow Label draft-gont-6man-flowlabel-security-03" (باللغة الإنجليزية). مؤرشف من الأصل في 20 مايو 2020.
  156. RFC 6437, P.8
  157. RFC 4443, P.3
  158. RFC 1885, P.2
  159. "Internet Control Message Protocol version 6 (ICMPv6) Parametersry". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 28 فبراير 202028 مايو 2020.
  160. RFC 4861, P.11
  161. Conta, A. (يونيو 2001). "RFC 3122, Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" (باللغة الإنجليزية). doi:10.17487/RFC3122. مؤرشف من الأصل في 12 ديسمبر 2019.
  162. Arkko, J.; Kempf, J.; Zill, B.; Nikander, P. (مارس 2005). "RFC 3971, SEcure Neighbor Discovery (SEND)" (باللغة الإنجليزية). doi:10.17487/RFC3971. مؤرشف من الأصل في 28 أبريل 2020.
  163. R. Vida, Ed., B. Cain, L. Costa, Ed. (يونيو 2004). "RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6 Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 17 فبراير 20056 مارس 2017.
  164. TCP-IP Illustrated, P.451-453
  165. Rami Rosen (2013). Linux Kernel Networking: Implementation and Theory (Expert's Voice in Open Source) (باللغة الإنجليزية). Apress. صفحة 230.  .
  166. S. Deering; W. Fenner; B. Haberman (أوكتوبر 1999). "RFC 2710, Multicast Listener Discovery (MLD) for IPv6 Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 25 مارس 20206 مارس 2017.
  167. {R. Vida; B. Cain; L. Costa (يونيو 2004). "RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6 Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 17 فبراير 20056 مارس 2017.
  168. H. Holbrook; B. Cain; B. Haberman (أغسطس 2006). "RFC 4604, Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 11 أغسطس 20126 مارس 2017.
  169. "802.3-2008 - IEEE Standard for Information technology--Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications". IEEE Std 802.3-2008 (Revision of IEEE Std 802.3-2005). IEEE: 35. 2008. doi:10.1109/IEEESTD.2008.4726971. مؤرشف من الأصل في 23 يونيو 2018.
  170. RFC 5952, P.10
  171. Hubbard, K.; Kosters, M.; Conrad, D.; Karrenberg, D.; Postel, J. (نوفمبر 1996). "RFC 2050, INTERNET REGISTRY IP ALLOCATION GUIDELINES". The Internet Society (باللغة الإنجليزية). صفحة 4. doi:10.17487/RFC2050. مؤرشف من الأصل في 11 ديسمبر 201922 يناير 2020.

المعلومات الكاملة للمراجع المُستشهد بها أكثر من مرة

الكتب (مرتبة أبجدياً بحسب العنوان)

  • Wendell Odom (2013). Cisco CCENT/CCNA ICND1 100-101 Official Cert Guide (باللغة الإنجليزية) (الطبعة الأكاديمية). Pearson Education, Inc.  .
  • Kevin R.Fall; W.Richard Stevens (2012). TCP/IP Illustrated Volume 1 ( كتاب إلكتروني PDF ) (باللغة الإنجليزية) (الطبعة الثانية). Pearson Education, Inc.  .

وثائق طلب التعليقات (مرتبة بحسب رقم الوثيقة)

وصلات خارجية

موسوعات ذات صلة :