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

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

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

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

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

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

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

نبذة تاريخية

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

خط زمني لتطوُّر البروتوكولات الرئيسة في حزمة بروتوكولات الإنترنت

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

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

اعتمد الإصدار الرابع من بروتوكول الإنترنت على نظام عنونة مبني على فضاء يبلغ طول العنوان فيه 32 بتاً، وُقسِّم هذا الفضاء إلى أصناف، خُصصت ثلاثٌ منها لعنونة البث فريد الوجهة، وهي الصنف A وعدد أفضيته 128 صنفاً، وهوأكبر الأصناف حجماً (2²⁴ عنواناً في جميع صنف)، والصنف B وضمَّ الفضاء 2¹⁴ صنفاً في جميع منها 2¹⁶ عنواناً، والصنف C وهوأكثر الأصناف عدداً بواقع 2²¹ صنفاً، ولكنها أصغرها حجماً، حيث يضمّ جميع صنف 2⁸ عنواناً. وخُصص فضاء رابع للبث المجموعاتي، وسمي الصنف D.

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

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

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

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

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

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

مبدأ العمل

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

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

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

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

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

الترويسات

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

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

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

لكل نوع ترويسة مُعرِّف مُحدد، وتحتوي الترويسات جميعها، بما في ذلك ترويسة الإصدار السادس، على حقل مُخصص ليضم قيمة مُعرِّف نوع الترويسة التالية، ويسمح ذلك بإمكانية إنشاء تتابع من الترويسات، حيث تشير قيمة حقل المُعرِّف في جميع ترويسة إلى نوع الترويسة التالية، في حين تُخصص القيمة 59 للإشارة إلى عدم وجود ترويسة تالية وتستعمل في الترويسة الموجودة في نهاية التتابع. تدير هيئة أرقام الإنترنت المُخصصة ضبط القيم المعيارية لمُعهدات أنواع الترويسة. وإذا وردت عدة ترويسات، فتكون بالترتيب التالي:⁽¹⁾

ترويسة بروتوكول الإنترنت
ترويسة خيارات المسار
ترويسة خيارات الوجهة (للخيارات التي ستعالج في الوجهة الأولى على المسار أوأي وجهة بينية أخرى مُحددة بترويسة التوجيه ما خلا الوجهة النهائية)
ترويسة التوجيه
ترويسة البترة
ترويسة تغليف الحمل الأمني
ترويسة خيارات الوجهة (للخيارات التي ستُعالج في الوجهة النهائية فقط)
ترويسة بروتوكول الطبقة العليا

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

فيما خلا ترويسة خيارات المسار، لا تُعالَج أي ترويسة على طول مسار رزمة، ولا تضاف أي ترويسة لرزمة البيانات أوتحذف منها حتى تبلغ الرزمة العنوان المحدد بعنوان الوجهة في ترويسة البروتوكول.⁽²⁾ إنَّ وجود ترويسات التوسعة في رزمة بيانات ما مسألة اختيارية، أما دعمها فهوإلزامي في أي تطبيق للإصدار السادس من البروتوكول، ولكن هناك ترويسات أخرى مُعرَّفة لأغراض خاصة، لا يلزم حتى تكون مدعومة في جميع تطبيق، منها على سبيل المثال ترويسة خيارات الحركة ترويسة بروتوكول هوية المضيف .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يبلغ طول ترويسة البترةثمانية بايت، وتتألف منستة حقول دائمة، هي وفقاً لترتيب وردوها:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الوظائف

العنونة

تعاريف

تُعرِّف محددات البروتوكول فضاءً للعناوين، ويبلغ طول العنوان فيه 128 بتاً، ومعنى ذلك حتى الفضاء يضمّ 2¹²⁸ عنواناً أي ما يقارب 3.4x10³⁸ عنواناً. تُمنح عناوين الإصدار السادس للمنافذ، لا للعقد، ويمكن للمنفذ حتى يستضيف أكثر من عنوان في الوقت نفسه. يدعم الإصدار السادس من بروتوكول الإنترنت ثلاثة أنماط لعنونة المنافذ هي عنونة البث فريد الوجهة، وعنونة البث المجموعاتي وعنونة البث نحوالأقرب ، ولا يدعم البروتوكول نمط عنونة البث العام. في عنونة البث فريد الوجهة، يستضيف منفذ ما عنواناً فريداً، ويجري توجيه الرزم المُرسلة نحوهذا العنوان إلى المنفذ الذي يستضيفه. أما في عنونة البث المجموعاتي، فتَستضيف مجموعة من المنافذ عنواناً ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحوذلك العنوان إلى المنافذ التي تستضيفه جميعُها. أما في عنونة البث الأقرب، فتستضيف مجموعة من المنافذ عنواناً ما في الوقت نفسه، ويجري توجيه الرزم المُرسلة نحوهذا العنوان إلى أقرب منفذ يستضيفه.⁽⁵⁾ إذا كان للعقدة منفذٌ وحيدٌ فقط يستضيف عنوان بثٍ فريد الوجهة فقط، يجوز حتى يُستعمل العنوان كمُعرِّف للعقدة.

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

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

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

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

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

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

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

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

تمثيل العناوين والأقنعة

أمثلة عن اختصار عناوين الإصدار السادس من بروتوكول الإنترنت
العنوان المُكتمل	العنوان المختصر
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

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

التمثيل المكتمل: وفيه يخط العنوان كاملاً بالشكل #:#:#:#:#:#:#:#، حيث يُمثل الرمز # أربع مراتب ستة عشرية. ومثاله العنوان:0123:4567:89ab:cdef:0123:4567:89ab:cdef.
التمثيل المُختصر: وفيه تختصر أجزاء من العنوان بالشكل التالي:

كانت المرتبة الأعلى أهميةً في رباعية ما صفرية لوحدها أوصفرية مع أكثر من مرتبة متتابعة معها، تهمل الأصفار وتُسقط من الكتابة وتمثل X عندها المراتب الست عشرية غير الصفرية فقط، فمثلاً الرباعية 0123 تُخط بالشكل 123 والرباعية 0011 تخط بالشكل 11.
إذا كانت المراتب الست عشرية في رباعية ما صفريَّة القيمة جميعها، تمثل الرباعية بصفر واححدة، أي 0000 تُخط: 0.
إذا اجتمعت أكثر من رباعية صفرية متتالية، أمكن اختزالها والتعويض عنها بمحرفي نقطتين رأسيتين متتاليتين. فمثلاً العنوان:1234:0:0:0:0:0:0:1111 يُخط اختصاراً: 1111::1234
إذا عثر أكثر من تتابع رباعيات صفرية في عنوان واحد، فلا يجوز اختزال إلا تتابع واحد منها فقط، ويلزم حتىقد يكون التتابع المُختصر هوالتتابع الأطول، فمثلاً العنوان: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:#:#:#:#:#:#، حيث يُمثِّل الرمز # رباعيةً مكونة من أربعة خانات ست عشرية غير صفرية، وتطبق قواعد الاختصار إذا وجدت خانات صفرية، أمَّا المحرف d فيُمثِّل خانة من خانات عنوان الإصدار الرابع من بروتوكول الإنترنت مكتوبة بالنظام العشري المُنقَّط ، ومثال هذا التمثيل العنوان: 1111:0:0:0:0:0:200.100.10.1 والذي يمكن حتى يخط بعد الاختصار بالشكل التالي: 200.100.10.1::1111.

تمثيل البادئات

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

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

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

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

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

64/::1111:0:0:2222

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

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

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

بثّ عام

بث مجموعاتي

بث نحوالأقرب

بث جغرافي

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

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

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

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

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

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

العنوان غير المُحدد (بالإنجليزية: The Unspecified Address)‏: هوالعنوان الصفريّ، أي 0:0:0:0:0:0:0:0 أواختصاراً ::. يُستعمل للدلالة إلى عدم استضافة المنفذ لعنوان من الإصدار السادس من بروتوكول إنترنت رغم وجود دعم للبروتوكول فيه، لذلك لا يجب حتى يُمنح هذا العنوان لأي منفذ. لا يُستعمل هذا العنوان كعنوان وجهة لرزم البيانات، ويلزم حتى تتخلص المُوجِّهات أي رزمة مُوجَّهة نحوهذا العنوان.
عنوان الحلقة العكسية (بالإنجليزية: The Loopback Address)‏: وهوالعنوان 0:0:0:0:0:0:0:1 أواختصاراً 1::، ويُمكن حتى يستخدم من قبل أي عقدة لإرسال رزم بيانات إلى نفسها، لذلك لا يجب حتى يُمنح هذا العنوان لأي منفذ مادي. لا يُستعمل هذا العنوان كعنوان مصدر للرزم التي ستغادر عقدة ما، ولا يجب حتى تُوجَّه الرزم التي تكون وجهتها عنوان الحلقة العكسية نحوخارج العقدة. ويلزم حتى تتخلص الموجهات أي رزمة موجهة نحوعنوان الحلقة العكسية.
عناوين البث فريد الوجهة العالمي (بالإنجليزية: Global Unicast Address)‏: وتُستخدم لعنونة منفذ ما على الإنترنت بشكلٍ فريدٍ على مستوى العالم. يتكون العنوان من ثلاثة حقول: حقل بادئة التوجيه العالمية، وهي تمنح للمسقط الذي يُشغل المنفذ بحسب هرمية تحصيص رباعية المستويات تديرها هيئة أرقام الإنترنت المُخصصة، وحقل مُعهد الشبكة الجزئية والذي يَضبطه مشغلوالمسقط، حيث يوجدالمنفذ، وذلك بهدف تجزئة الفضاء الممنوح إلى أفضية جزئية أصغر حجماً لأغراض إدارية أوتنظيمية.

في عناوين البث فريد الوجهة العالمية التي لا تكون قيمة البتات ذات الأهمية العليا فيها ₂(000)،قد يكون مجموع طولي حقلي بادئة التوجيه العالمية ومُعرِّف الشبكة الجزئية 64 بت، ما يهجر 64 بتاً لمُعهد المنفذ، وبهذا تتوافق بنية هذه العناوين مع آلية التهيئة الذاتية الآلية. أما العناوين التي تكون قيمة البتات ذات الأهميةً العليا فيها ₂(000) فهي لا تُلزَم بالبنية السابقة. وفيما يأتي مثالٌ عن هذا العنوان:

1::2001:1111:2222:3333

عناوين البث فريد الوجهة في الوصلة المحلية (بالإنجليزية: Link-Local Unicast Address)‏: ويشغل الفضاء fe80::/10، تُستخدم عناوين هذا الفضاء على مستوى الوصلة المحلية فقط، وهي مصممة لتخدم أغراضاً مثل التهئية الآلية للعنوان واكتشاف الجيران. لا يجب على المُوجِّهات توجيه أي رزمة بياناتقد يكون عنوان مصدرها أووجهتها عنوان وصلة محلية.

يتكون عنوان الوصلة المحلية من ثلاثة حُقول: الحقل الأول هومُعرِّف فضاء عناوين الوصلة المحلية، وطولهعشرة بتات وقيمته ₂(1111111010)، أما الحقل الثاني فهوحقل صفري يبلغ طوله 54 بتاً، والحقل الثالث هوحقل مُعهد المنفذ، ويُستخدم لتمييز المنفذ بشكل فريد على مستوى الوصلة المحلية. وفيما يأتي مثالٌ عن هذا العنوان:

fe80::1ff:fe01:101

عناوين البث فريد الوجهة الفريد المحلي (بالإنجليزية: Unique Local IPv6 Unicast Addresses)‏: حُجر له الفضاء fc00::/7، ويُستخدم من أجل عنونة منفذ بشكل فريد على المستوى العالمي، ولكن من أجل إنشاء اتصالات محلية فقط، ولذلك لا يمكن توجيه الرزم المعنونة بهذه العناوين خارج المسقط الذي ولِّدت فيه.

يتألف العنوان الفريد المحلي منخمسة حقول، أولها هوحقل البادئة وطولهسبعة بتات وقيمته هي ₂(1111110) دائماً، ويليه بت المحلية، ويُضبط إلى القيمة 1 دائماً للإشارة إلى حتى العنوان قد وُلِّد محلياً،⁽⁸⁾ ثُمَّ حقل البادئة العالمية وطوله 40 بتاً، وهومُعرِّف فريد على مستوى العالم يضبط محلياً إلى قيمة عشوائية، ثُمّ حقل مُعرِّف الشبكة الجزئية طوله 16 بت، وهوحقل مخصص لمديري الشبكة لإتاحة إمكانية إنشاء شبكات جزئية، وأخيراً مُعرِّف المنفذ وطوله 64 بتاً، ويميز جميع منفذ على حدته بشكل فريد. وفيما يأتي مثالٌ عن هذا العنوان: مرجع

fdf8:f53b:82e4::53

عناوين البث فريد الوجهة المحلي في المسقط (بالإنجليزية: Site-Local Unicast Address)‏: وهوصنف مُبطَل من عناوين البث فريد الوجهة. طُوِّر في الأصل ليَخدُم غرض العنونة داخل مسقط ما دون الحاجة لبادئات عالمية. حُجر له الفضاء fec::/10، كانت بنية هذه العناوين مكونة من ثلاثة حقول: الحقل الأول هومعهد فضاء العناوين المحلية في المسقط، وطولهعشرة بتات وقيمته ₂(1111111011)، أما الحقل الثاني فهومُعرِّف الشبكة الجزئية، ويضبطه مشرفوالمسقط حسب الحاجة، وأما الحقل الثالث فهومُعرِّف المضيف ويبلغ طوله 64 بتاً. وفيما يأتي مثالٌ عن هذا العنوان:
fec0::1234:5678:9abc
عناوين البث فريد الوجهة التي تتضمن عناوين من الإصدار الرابع: هناك عنوانان من عناوين البث فريد الوجهة في الإصدار السادس يحملان في البتات الاثنين والثلاثين ذات الأهمية الدنيا عناوين من الإصدار الرابع من بروتوكول الإنترنت وهما:

عناوين البث فريدة الوجهة المُتوافِقة مع الإصدار الرابع (بالإنجليزية: IPv4-Compatible Unicast Address)‏: عُرِّفت هذه العناوين في الأصل لتساهم في دعم عملية الانتنطق من استعمال الإصدار الرابع إلى الإصدار السادس من بروتوكول الإنترنت. يتكون هذا العنوان بدءاً من الخانة الأكثر أهمية من 80 صفراً يليها عنوان الإصدار الرابع من بروتوكول الإنترنت الذي يلزم حتىقد يكون فريداً عالمياً.

تُستخدم الطريقة العجينة لتمثيل هذه العناوين. أبطلت طريقة الانتنطق التي تستعمل هذه العناوين، ولذلك لم تعد هذه العناوين قيد الاستخدام. وفيما يأتي مثالٌ عن هذا العنوان:

200.100.10.1::

عناوين البث فريدة الوجهة المُقترنة مع الإصدار الرابع (بالإنجليزية: IPv4-Mapped Unicast Address)‏ وتستعمل لحمل عنوان الإصدار الرابع من بروتوكول الإنترنت الذي تستضيفه العقدة التي تدعم الإصدار السادس أيضاً. وصفت طريقة استعمال هذا العنوان في وثيقة طلب التعليقات RFC 4038، وهويتكون من ثلاث حقول بدءاً من الخانة الأكثر أهمية هي 80 صفراً متتالياً في الحقل الأول، يليها 16 واحداً متتالياً في الحقل الثاني، ثُمَّ عنوان الإصدار الرابع من بروتوكول الإنترنت. وفيما يأتي مثالٌ عن هذا العنوان:
ffff:192.0.2.47::

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

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

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

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

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

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

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

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

حقل بادئة البث المجموعاتي: طولهثمانية بت، ويحتوي على القيمة ₂(11111111) أو₁₆(FF)، وهي تميز عناوين فضاء البث المجموعاتي جميعها.
حقل الأعلام: طوله أربعة بت، تُثبَّت قيمة البت الأعلى أهمية فيه إلى القيمة 0، وأما البتات الثلاثة اللاحقة في وفقاً فقاً لترتيب ورودها من الخانة الأعلى أهمية:

فهم الالتقاء: ويحدد فيما إذا كان العنوان يتضمن عنوان نقطة الالتقاء أم لا، فهوكذلك إذا كان واحدياً، أما إذا كان صفرياً فهوبخلاف ذلك.

فهم البادئة: ويحدد فيما إذا كان منح العنوان قد جرى على أساس بادئة الشبكة فريدة الوجهة حيث سيُستضاف العنوان، فإذا كان الفهم واحدياً فإن العنوان قد منح على أساس البادئة وإلا فإنه لم يُمنح على ذلك الأساس.

فهم الديمومة: وإذا كان صفرياً فإن العنوان ممنوح بشكل دائم من قبل أيانا ومعروفٌ في شبكة الإنترنت كاملةً، أما إذا كانت قيمته واحدية، فالعنوان ليس دائماً ويكون ذا معنى في مجال مُحدد بحقل المجال.

حقل المجال: طوله أربعة بت، ويضم رمزاً يحدد المجال الطوبولوجي الذي تمتد عليه المجموعة كما في الجدول التالي:

قيمة حقل المجال بنظام العد الثنائي	اسم المجال	امتداد المجال
0000	محجوز	-
0001	مجال المنفذ	يضم هذا المجال منفذاً واحداً في عقدة واحدة، ويستعمل هذا المجال في تطبيقات الحلقة العكسية.
0010	مجال الوصلة المحلية	يمتد المجال ليغطي الشبكة المحلية بشكلٍ متوافق مع شبكة عناوين البث فريد الوجهة المُستخدَمة محلياً.
0011	محجوز	-
0100	مجال الإشراف المحلي	يمتد المجال على جزء من الشبكة يقوم مشرفوها بتحديده، وهوأصغر مجال يمكن تحديده إشرافياً.
0101	مجال المسقط المحلي	يمتد المجال ليغطي مسقطاً محلياً واحداً، قد يضم عدة شبكات محلية، ولكنَّها تعود لمنظمة واحدة.
0101	مجال المنظمة المحلي	يمتد المجال على عدة مواقع محلية لمنظمة واحدة.
0101	المجال العالمي	يضم المجال الإنترنت كاملة.
1111	محجوز	-

تكون قيم المجال غير المحجوزة وغير المُخصصة لمجال معين متاحة للاستخدام من قبل مشرفي الشبكة المحلية لتعريف مجالات فرعية تلائم أغراضهم الخاصة.

حقل مُعهد المجموعة، وطوله 112 بت، ويضم مُعهداً رقمياً يميز المجموعة ضمن المجال المُحدد بحقل المجال.

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

أفضية محجوزة

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

أفضية البث فريد الوجهة والبث نحوالأقرب

جدول بأفضية العناوين الجزئية المحجوزة من فضاء عناوين الإصدار السادس من بروتوكول الإنترنت
فضاء العناوين	تاريخ الحجز	ملاحظات
128/::	فبراير 2006	العنوان غير المُحدد
1/128::	فبراير 2006	عنوان الحلقة العكسية
ff9b::/96	أوكتوبر 2010	مخصص لمترجمات العناوين بين الإصدارين الرابع والسادس
ffff:0:0/96::	فبراير 2006	فضاء العناوين المقترنة مع الإصدار الرابع
64/::100	يونيو2012	بادئة الاستبعاد (بالإنجليزية: Discard Prefix)‏، وفي بادئة تستعمل في عملية التوجيه والترشيح للتخلص من رزم البيانات
23/::2001	سبتمبر 2000	مخصص لعملية تطوير إرشادات لمنح أفضية الإصدار السادس من بروتوكول الإنترنت
32/::2001	فبراير 2006	مخصص لدعم تقنية تيريدو للانتنطق من الإصدار الرابع نحوالإصدار السادس من بروتوكول الإنترنت
1/48::2001:1	أكتوبر 2015	عنوان مُخصص للبث نحوالأقرب لبروتوكول التحكم بالمنافذ
2/48::2001:1	فبراير 2017	عنوان مُخصص للبث نحوالأقرب بروتوكول تخطي الترجمة باستعمال المُرحلات TURN
48/::2001:2	أبريل 2008	فضاء مخصص لعملية المقارنة المرجعية
32/::2001:3	ديسمبر 2014	فضاء مخصص للإنشاء الآلي لأنفاق البث المجموعاتي
48/::2001:4:112	ديسمبر 2014	فضاء مخصص لمشروع النظام المستقل رقم 112 (بالإنجليزية: AS112 project)‏
28/::2001:10	أبريل 2007⁽⁹⁾	فضاء مخصص لبادئة معهدات التجزئة المُشفرة المتراكبة القابلة للتوجيه، المعروفة اختصاراً بالاسم الرمزي: أوركيد ORCHID
28/::2001:20	يوليو2014	فضاء مخصص للإصدار الثاني لبادئة معهدات التجزئة المُشفرة المتراكبة القابلة للتوجيه، المعروفة اختصاراً بالاسم الرمزي: أوركيد 2
2001:0db8::/32	يوليو2004	فضاء مخصص لعملية التوثيق
16/::2002	فبراير 2001	فضاء مخصص لدعم تقنيةستة إلى أربعة (بالإنجليزية: 6to4)‏ للانتنطق من الإصدار السادس نحوالإصدار الرابع من بروتوكول الإنترنت
2620:4f:8000::/48	مايو2001	فضاء مخصص لخدمة التفويض المباشر في مشروع النظام المستقل رقم 112
fc00::/7	أكتوبر 2005	مخصص لفضاء عناوين البث فريد الوجهة الفريد المحلي
fe80::/10	أكتوبر 2005	مخصص لفضاء عناوين البث فريد الوجهة في الوصلة المحلية

فضاء البث المجموعاتي

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

جميع العناوين ذات البنية 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 من أجل مجموعة جميع الموجهات التي تشغل بروتوكول التوجيه الداخلي المحسن بين البوابات وغير ذلك.

عناوين ملزمة

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

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

أمَّا المُوجِّه، فيلزم حتى يميز العناوين السابقة التي يميزها المضيف، وأيضاً العناوين التالية، بوصفها مُعهدات ذاتية:

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

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

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

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

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

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

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

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

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

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

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

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

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

التجزئة

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

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

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

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

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

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

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

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

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

التقطيع

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

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

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

التقطيع

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

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

الترويسات التي ستوضع في البتر كلها: تضم هذه الترويسات ترويسة الإصدار السادس وترويسات التوسعة التالية لها حتى ترويسة التوجيه، إذا وجدت، وإلا فحتى ترويسة خيارات المسار، إذا وجدت، فإن غابت الترويستان السابقتان ضمَّ هذا الجزء ترويسة الإصدار السادس فقط.
ترويسات التوسعة والطبقات العليا: وتضم جميع ترويسات التوسعة الأخرى التي لم تُضم في القسم السابق، أما ترويسات الطبقات العليا فتضم جميع الترويسات التي ليست ترويسات توسعة مثل ترويسات بروتوكول التحكم بالنقل وبروتوكول حزم بيانات المستخدم أوترويسة بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت.⁽¹²⁾
الحمولة: وهي القسم الذي يفترض أن يُقطَّع، ويبدأ بعد ترويسات الطبقات العليا.

تجري عملية التقطيع وفق المراحل التالية:

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

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

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

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

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

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

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

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

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

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

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

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

المُشكلات

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

هوامش

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

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

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

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

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

6. يلزم حتى تُخط الحروف اللاتينية بالحالة الصغيرة لا الكبيرة، أي a لا A.

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

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

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

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

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

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

انظر أيضا

في كومنز صور وملفات عن: بروتوكول الإنترنت

بروتوكول الإنترنت
الإصدار الرابع من بروتوكول الإنترنت

المراجع

فهرس المراجع

↑ RFC 8200, P.1
↑ Deering, S.; Hinden, R. (ديسمبر 1995). "RFC 1883, Internet Protocol, Versionستة (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1883. مؤرشف من الأصل في 21 ديسمبر 2019. اطلع عليه بتاريخ 30 مايو2018.
^ RFC 8200, P.7-10
↑ Cisco CCENT/CCNA ICND1, P.579
↑ RFC 4291, P.2-3
↑ RFC 8200, P.17-19
↑ RFC 6437, P.1
↑ RFC 2474, P.1-2
↑ Atlasis, Antonios (2002). "Attacking IPv6 Implementation Using Fragmentation" (PDF). Black-Hat Europe. مؤرشف من الأصل (PDF) في 25 مارس 2020.
↑ RFC 2474, P.15
^ RFC 791, P.1
^ Cisco CCENT/CCNA ICND1, P.611
^ RFC 791, P.7
^ Cisco CCENT/CCNA ICND1, P.296
^ Deering, S. (أغسطس 1989). "RFC 1112, Host Extensions for IP Multicasting". The Internet Society (باللغة الإنجليزية). صفحة 3. doi:10.17487/RFC1112. مؤرشف من الأصل في 03 فبراير 2020. اطلع عليه بتاريخخمسة سبتمبر 2019.
↑ RFC 4632, P.4
^ Fuller, V.; Li, T.; Yu, J.; Varadhan, K. (سبتمبر 1993). "RFC 1338, Supernetting: an Address Assignment and Aggregation Strategy" (باللغة الإنجليزية). doi:10.17487/RFC1338. مؤرشف من الأصل في 20 يناير 2020.
^ 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.
^ Egevang, K.; Francis, P. (مايو1994). "RFC 1631, The IP Network Address Translator (NAT)" (باللغة الإنجليزية). doi:10.17487/RFC1631. مؤرشف من الأصل في 25 يناير 2020. اطلع عليه بتاريخ 12 يناير 2020.
^ Cisco CCENT/CCNA ICND1, P.612
^ "Free Pool of IPv4 Address Space Depleted". Number Resource Organization (باللغة الإنجليزية). ثلاثة فبراير 2011. مؤرشف من الأصل فيخمسة مارس 2020. اطلع عليه بتاريخستة مارس 2019.
^ Bradner, S.; Mankin, A. (ديسمبر 1993). "RFC 1550, IP: Next Generation (IPng) White Paper Solicitation" (باللغة الإنجليزية). doi:10.17487/RFC1550. مؤرشف من الأصل في 04 ديسمبر 2019.
^ RFC 1752, P.2
^ RFC 1752, P.45
^ Hinden, R.; Deering, S. (ديسمبر 1995). "RFC 1884, IP Versionستة Addressing Architecture" (باللغة الإنجليزية). doi:10.17487/RFC1884. مؤرشف من الأصل في 06 مارس 2020.
↑ RFC 1885, P.1
^ Narten, T.; Nordmark, E.; Simpson, W. (أغسطس 1996). "RFC 1970, Neighbor Discovery for IP Versionستة (IPv6)" (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC1970. مؤرشف من الأصل في 04 ديسمبر 2019.
^ Thomson, S.; Narten, T. (ديسمبر 1995). "RFC 1971, IPv6 Stateless Address Autoconfiguration" (باللغة الإنجليزية). doi:10.17487/RFC1971. مؤرشف من الأصل في 12 ديسمبر 2019.
^ RFC 2460, P.1
^ Narten, T.; Nordmark, E.; Simpson, W. (ديسمبر 1998). "RFC 2461, Neighbor Discovery for IP Versionستة (IPv6)" (باللغة الإنجليزية). doi:10.17487/RFC2461. مؤرشف من الأصل في 13 مارس 2020.
^ Thomson, S.; Narten, T. (ديسمبر 1998). "RFC 2462, IPv6 Stateless Address Autoconfiguration" (باللغة الإنجليزية). doi:10.17487/RFC2462. مؤرشف من الأصل في 07 مايو2020.
↑ Conta, A.; Deering, S. (ديسمبر 1998). "RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Versionستة (IPv6) Specification" (باللغة الإنجليزية). doi:10.17487/RFC2463. مؤرشف من الأصل في 16 مارس 2020.
^ "RFC 4291, P.1
↑ RFC 4443, P.1
↑ RFC 4861, P.1
^ RFC 4862, P.1
^ (باللغة الإنجليزية) (الطبعة الثانية). Javvin Technologies Inc. 2005. صفحة 67. مؤرشف من الأصل (PDF) في 28 مايو2020.
^ RFC 8200, P.4
↑ TCP/IP Illustrated, P.184
^ 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.
^ RFC 6437, P.3
↑ RFC 8200, P.5
↑ RFC 8200, P.7
↑ RFC 8200, P.9
^ TCP/IP Illustrated, P.194
^ RFC 8200, P.24
^ "Internet Protocol Versionستة (IPv6) Parameters - Next Header Types" (باللغة الإنجليزية). مؤرشف من الأصل في 28 فبراير 2020. اطلع عليه بتاريخ 23 مايو2020.
↑ RFC 8200, P.10
^ RFC 8200, P.8
^ Perkins, Ed., C.; Johnson, D.; Arkko, J. (يوليو2011). "RFC 6275, Mobility Support in IPv6" (باللغة الإنجليزية). صفحة 49. doi:10.17487/RFC6275. ISSN 2070-1721. مؤرشف من الأصل في 11 مارس 2020.
^ 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.
^ RFC 8200, P.6-7
^ "Assigned Internet Protocol Numberss" (باللغة الإنجليزية). مؤرشف من الأصل في 13 فبراير 2020. اطلع عليه بتاريخ 23 مايو2020.
↑ RFC 8200 P.13
↑ TCP/IP Illustrated, P.200
^ RFC 791, P.16
↑ RFC 8200, P.14
^ "Internet Protocol Versionستة (IPv6) Parameters" (باللغة الإنجليزية). مؤرشف من الأصل فيسبعة مايو2020. اطلع عليه بتاريخ 23 مايو2020.
^ 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 مايو2020. اطلع عليه بتاريخ 23 مايو2020.
^ RFC 8200, P.15
^ RFC 8200, P.19
^ "Protocol Numbers". IANA (باللغة الإنجليزية). مؤرشف من الأصل في أربعة يناير 2018. اطلع عليه بتاريخ 18 يوليو2018.
^ RFC 8200, P.15-16
^ Gont, F. (فبراير 2016). "RFC 7739, Security Implications of Predictable Fragment Identification Values". The Internet Society (باللغة الإنجليزية). ISSN 2070-1721. مؤرشف من الأصل في 28 مايو2020. اطلع عليه بتاريخ 17 يوليو2018.
↑ RFC 8200, P.23
^ RFC 4302, P.3
^ RFC 4302, P.4
^ RFC 4302, P.5-9
^ RFC 4303 P.1
^ RFC 4303 P.5
^ RFC 4303 P.10-17
^ TCP/IP Illustrated, P.196
↑ RFC 8200, P.11
^ RFC 8200, P.12
^ RFC 8200, P.36-38
^ RFC 8200, P.12-13
↑ Cisco CCENT/CCNA ICND1, P.617
^ RFC 4291 P.7
^ RFC 5952 P.2
^ Cisco CCENT/CCNA ICND1, P.619
^ Cisco CCENT/CCNA ICND1, P.617-618
^ RFC 4291, P.4-5
^ RFC 4632, P.5
↑ RFC 4291, P.5
↑ RFC 4291, P.6
↑ RFC 4291, P.9
↑ RFC 4291, P.10
^ Cisco CCENT/CCNA ICND1, P.634
↑ RFC 4291, P.11
↑ Cisco CCENT/CCNA ICND1, P.632
^ RFC 4193, P.2
^ RFC 4193, P.3-4
^ Huitema, C.; Carpenter, B. (سبتمبر 2004). "RFC 3879, Deprecating Site Local Addresses" (باللغة الإنجليزية). doi:10.17487/RFC3879. مؤرشف من الأصل في 07 مايو2020.
^ 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.
↑ RFC 4291, P.12
↑ RFC 4291, P.13
^ Peter Dyson; Kevin Shafer (1999). (باللغة الإنجليزية) (الطبعة الثالثة). SYBEX Inc. صفحة 1999. ISBN . مؤرشف من الأصل في 28 مايو2020.
^ Savola, P.; Haberman, B. (نوفمبر 2004). "RFC 3956, Application Aspects of IPv6 Transition" (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC3956. مؤرشف من الأصل في 24 يناير 2020. اطلع عليه بتاريخ 25 مايو2020.
^ RFC 3306, P.3
^ Droms, R. (أغسطس 2014). "RFC 7346, IPv6 Multicast Address Scopes" (باللغة الإنجليزية). صفحة 3. doi:10.17487/RFC7346. ISSN 2070-1721. مؤرشف من الأصل في 24 يناير 2020. اطلع عليه بتاريخ 25 مايو2020.
^ RFC 4291, P.14
^ RFC 3306, P.1
^ Boucadair, M.; Venaas, S. (سبتمبر 2014). "RFC 7371, Updates to the IPv6 Multicast Addressing Architecture" (باللغة الإنجليزية). doi:10.17487/RFC7371. ISSN 2070-1721. مؤرشف من الأصل في 24 يناير 2020. اطلع عليه بتاريخ 25 مايو2020.
^ 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.
↑ "IANA IPv6 Special-Purpose Address Registry". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 2 يناير 2020. اطلع عليه بتاريخ 25 مايو2020.
^ 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. مؤرشف من الأصل فيعشرة مايو2020.
^ 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.
^ 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.
^ 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.
^ 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.
^ 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.
^ 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.
^ Bumgardner, G. (فبراير 2015). "RFC 7450, Automatic Multicast Tunneling". The Internet Society (باللغة الإنجليزية). صفحة 78. doi:10.17487/RFC7450. ISSN 2070-1721. مؤرشف من الأصل في 16 أبريل 2020.
^ 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.
^ 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.
^ 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.
^ 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.
^ Carpenter, B.; Moore, K. (فبراير 2001). "RFC 3056, Connection of IPv6 Domains via IPv4 Clouds". The Internet Society (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC3056. مؤرشف من الأصل في 12 مايو2020.
^ Abley, J.; Sotomayor, W. (مايو2015). "RFC 7534, AS112 Nameserver Operations". The Internet Society (باللغة الإنجليزية). صفحة 6. doi:10.17487/RFC7534. ISSN 2070-1721. مؤرشف من الأصل في 16 أبريل 2020.
↑ RFC 4193, P.3
↑ "IPv6 Multicast Address Space Registry". IANA (باللغة الإنجليزية). مؤرشف من الأصل فيسبعة مايو2018. اطلع عليه بتاريخ 25 مايو2020.
^ RFC 4291, P.16-17
↑ RFC 4291, P.17
^ RFC 4862, P.3
^ RFC 4862, P.11-12
↑ RFC 4862, P.12
^ RFC 4862, P.17-21
↑ "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)" (PDF). IEEE (باللغة الإنجليزية). ثلاثة أغسطس 2017. صفحة 9-10. مؤرشف من الأصل (PDF) في 28 فبراير 2020. اطلع عليه بتاريخثمانية مارس 2020.
^ 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.
^ 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.
^ "Internet Assigned Numbers Authority (IANA) Policy For Allocation of IPv6 Blocks to Regional Internet Registries (Ratifiedسبعة September 2006)". icann.org (باللغة الإنجليزية). مؤرشف من الأصل في 28 فبراير 2020. اطلع عليه بتاريخثمانية مارس 2020.
^ RFC 4291, P.7
^ "IPv6 Global Unicast Address Assignments". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 16 فبراير 2020. اطلع عليه بتاريخثمانية مارس 2020.
^ "Understanding IP Addressing and CIDR Charts". RIPE NCC (باللغة الإنجليزية). مؤرشف من الأصل في 15 فبراير 2020. اطلع عليه بتاريخثمانية مارس 2020.
^ "IPv6 Global Unicast Address Assignments". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 22 فبراير 2018. اطلع عليه بتاريخ 2 سبتمبر 2018.
^ "Understanding IP Addressing and CIDR Charts". RIPE (باللغة الإنجليزية). أربعة يناير 2011. مؤرشف من الأصل في 23 سبتمبر 2018. اطلع عليه بتاريخ 23 سبتمبر 2018.
^ Cisco CCENT/CCNA ICND1, P.639
^ Charles M. Kozierok (2005). (PDF) (باللغة الإنجليزية). William Pollock. صفحة 464. ISBN .
^ RFC 8200, P.15-22
^ Hinden, R. (أغسطس 1999). "RFC 2675, IPv6 Jumbograms". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC2675. مؤرشف من الأصل في 03 مايو2020.
↑ RFC 8200, P.17
^ RFC 8200, P.20
^ RFC 6437, P.4
^ RFC 6437, P.5
^ RFC 2460, P.25
^ RFC 2460, P.29-30
^ RFC 2474, P.7
^ RFC 2474, P.11
^ RFC 2474, P.13
^ Krishnan, S. (فبراير 2016). "RFC 5722, Handling of Overlapping IPv6 Fragments". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 11 مايو2020. اطلع عليه بتاريخ 21 يوليو2018.
^ RFC 8200, P.31
^ Gont, F. (مايو2013). "RFC 6946, Processing of IPv6 "Atomic" Fragments". The Internet Society (باللغة الإنجليزية). ISSN 2070-1721. مؤرشف من الأصل في 11 مارس 2020. اطلع عليه بتاريخ 21 يوليو2018.
^ RFC 6437, P.9
^ RFC 6437, P.10
^ Gont, F. (12 مارس 2012). "Security Assessment of the IPv6 Flow Label draft-gont-6man-flowlabel-security-03" (باللغة الإنجليزية). مؤرشف من الأصل في 20 مايو2020.
^ RFC 6437, P.8
^ RFC 4443, P.3
^ RFC 1885, P.2
^ "Internet Control Message Protocol versionستة (ICMPv6) Parametersry". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 28 فبراير 2020. اطلع عليه بتاريخ 28 مايو2020.
^ RFC 4861, P.11
^ Conta, A. (يونيو2001). "RFC 3122, Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" (باللغة الإنجليزية). doi:10.17487/RFC3122. مؤرشف من الأصل في 12 ديسمبر 2019.
^ Arkko, J.; Kempf, J.; Zill, B.; Nikander, P. (مارس 2005). "RFC 3971, SEcure Neighbor Discovery (SEND)" (باللغة الإنجليزية). doi:10.17487/RFC3971. مؤرشف من الأصل في 28 أبريل 2020.
^ R. Vida; B. Cain; L. Costa (يونيو2004). "RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6 Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 17 فبراير 2005. اطلع عليه بتاريخستة مارس 2017.
^ TCP-IP Illustrated, P.451-453
^ Rami Rosen (2013). Linux Kernel Networking: Implementation and Theory (Expert's Voice in Open Source) (باللغة الإنجليزية). Apress. صفحة 230. ISBN .
^ S. Deering; W. Fenner; B. Haberman (أوكتوبر 1999). "RFC 2710, Multicast Listener Discovery (MLD) for IPv6 Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 25 مارس 2020. اطلع عليه بتاريخستة مارس 2017.
^ {R. Vida; B. Cain; L. Costa (يونيو2004). "RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6 Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 17 فبراير 2005. اطلع عليه بتاريخستة مارس 2017.
^ H. Holbrook; B. Cain; B. Haberman (أغسطس 2006). "RFC 4604, Using Internet Group Management Protocol Version ثلاثة (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 11 أغسطس 2012. اطلع عليه بتاريخستة مارس 2017.
^ "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.
^ RFC 5952, P.10
^ 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 ديسمبر 2019. اطلع عليه بتاريخ 22 يناير 2020.

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

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

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

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

Postel, J. (سبتمبر 1981). "RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC0791. مؤرشف من الأصل في 12 فبراير 2020.
Rekhter, Y.; Li, T. (سبتمبر 1993). "RFC 1518, An Architecture for IP Address Allocation with CIDR" (باللغة الإنجليزية). doi:10.17487/RFC1518. مؤرشف من الأصل في 09 يناير 2020. اطلع عليه بتاريخ 15 سبتمبر 2019.
Bradner, S.; Mankin, A. (يناير 1995). "RFC 1752, The Recommendation for the IP Next Generation Protocol" (باللغة الإنجليزية). doi:10.17487/RFC1752. مؤرشف من الأصل في 02 مايو2020.
Conta, A.; Deering, S. (ديسمبر 1995). "RFC 1885, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Versionستة (IPv6) Specification" (باللغة الإنجليزية). doi:10.17487/RFC1885. مؤرشف من الأصل في 25 يناير 2020.
Deering, S.; Hinden, T. (ديسمبر 1998). "RFC 2460, Internet Protocol, Versionستة (IPv6) Specification" (باللغة الإنجليزية). doi:10.17487/RFC2460. مؤرشف من الأصل في 07 مايو2020.
Nichols, K.; Blake, S.; Baker, F.; Black, D. (ديسمبر 2017). "RFC 2474, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" (باللغة الإنجليزية). doi:10.17487/RFC2474. مؤرشف من الأصل في 07 مايو2020.
Haberman, B.; Thaler, D. (أغسطس 2002). "RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses" (باللغة الإنجليزية). doi:10.17487/RFC3306. مؤرشف من الأصل في 07 مايو2020. اطلع عليه بتاريخ 25 مايو2020.
Hinden, R.; Deering, S. (فبراير 2006). "RFC 4291, IP Versionستة Addressing Architecture" (باللغة الإنجليزية). doi:10.17487/RFC4291. مؤرشف من الأصل في 13 مايو2020.
Hinden, R.; Haberman, B. (أكتوبر 2005). "RFC 4193, Unique Local IPv6 Unicast Addresses" (باللغة الإنجليزية). doi:10.17487/RFC4193. مؤرشف من الأصل في 07 مايو2020.
Kent, S. (ديسمبر 2005). "RFC 4302, IP Authentication Header". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC4302. مؤرشف من الأصل في 11 مارس 2020. اطلع عليه بتاريخ 23 مايو2020.
Kent, S. (ديسمبر 2005). "RFC 4303, IP Encapsulating Security Payload (ESP)". The Internet Society (باللغة الإنجليزية). صفحة 3. doi:10.17487/RFC4303. مؤرشف من الأصل في 28 أبريل 2020. اطلع عليه بتاريخ 23 مايو2020.
Fuller, V.; Li, T. (أغسطس 2006). "RFC 4632, Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC4632. مؤرشف من الأصل في 16 فبراير 2020.
Narten, T.; Nordmark, E.; Simpson, W.; Soliman, H. (سبتمبر 2007). "RFC 4861, Neighbor Discovery for IP versionستة (IPv6)" (باللغة الإنجليزية). doi:10.17487/RFC4861. مؤرشف من الأصل فيعشرة مايو2020.
Thomson, S.; Narten, T.; Jinmei, T. (سبتمبر 2007). "RFC 4862, IPv6 Stateless Address Autoconfiguration" (باللغة الإنجليزية). doi:10.17487/RFC4862. مؤرشف من الأصل في 07 مايو2020.
Kawamura, S.; Kawashima, M. (أغسطس 2010). "RFC 5952, A Recommendation for IPv6 Address Text Representation". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC5952. مؤرشف من الأصل في 12 مايو2020.
Amante, S.; Carpenter, B.; Jiang, S.; Rajahalme, J. (نوفمبر 2011). "RFC 6437, IPv6 Flow Label Specification" (باللغة الإنجليزية). doi:10.17487/RFC6437. مؤرشف من الأصل في 02 مايو2020.
Deering, S.; Hinden, R. (يوليو2017). "RFC 8200, Internet Protocol, Versionستة (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC8200. مؤرشف من الأصل في 11 ديسمبر 2019. اطلع عليه بتاريخ 30 مايو2019.

وصلات خارجية

الإصدار السادس من بروتوكول الإنترنت للجميع كتيب من إعداد مجتمع الإنترنت.
التقطيع في الإصدار السادس من بروتوكول الإنترنت، منطقة من جيف هوستِن.
اكتشاف الجيران والتهيئة الذاتية الآلية في الإصدار السادس من بروتوكول الإنترنت، منطقة من توماس نارتِن.
أمن الإصدار السادس من بروتوكول الإنترنت، أسئلة متكررة، منطقة من مجتمع الإنترنت.
أمن الشبكات، أمن الإصدار السادس لمهندسي الإصدار الرابع، منطقة من مجتمع الإنترنت.

[RFC-24-1] RFC 8200, P.1

[RFC-11-2] Deering, S.; Hinden, R. (ديسمبر 1995). "RFC 1883, Internet Protocol, Versionستة (IPv6) Specification". The Internet Society (باللغة الإنجليزية). doi:10.17487/RFC1883. مؤرشف من الأصل في 21 ديسمبر 2019. اطلع عليه بتاريخ 30 مايو2018.

[RFC-138-3] RFC 8200, P.7-10

[Book-11-4] Cisco CCENT/CCNA ICND1, P.579

[RFC-26-5] RFC 4291, P.2-3

[RFC-113-6] RFC 8200, P.17-19

[RFC-29-7] RFC 6437, P.1

[RFC-30-8] RFC 2474, P.1-2

[JOU-2-9] Atlasis, Antonios (2002). "Attacking IPv6 Implementation Using Fragmentation" (PDF). Black-Hat Europe. مؤرشف من الأصل (PDF) في 25 مارس 2020.

[RFC-127-10] RFC 2474, P.15

[RFC-1-11] RFC 791, P.1

[Book-1-12] Cisco CCENT/CCNA ICND1, P.611

[RFC-2-13] RFC 791, P.7

[Book-2-14] Cisco CCENT/CCNA ICND1, P.296

[RFC-3-15] Deering, S. (أغسطس 1989). "RFC 1112, Host Extensions for IP Multicasting". The Internet Society (باللغة الإنجليزية). صفحة 3. doi:10.17487/RFC1112. مؤرشف من الأصل في 03 فبراير 2020. اطلع عليه بتاريخخمسة سبتمبر 2019.

[RFC-4-16] RFC 4632, P.4

[RFC-5-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.

[RFC-6-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.

[RFC-7-19] Egevang, K.; Francis, P. (مايو1994). "RFC 1631, The IP Network Address Translator (NAT)" (باللغة الإنجليزية). doi:10.17487/RFC1631. مؤرشف من الأصل في 25 يناير 2020. اطلع عليه بتاريخ 12 يناير 2020.

[Book-3-20] Cisco CCENT/CCNA ICND1, P.612

[Web-1-21] "Free Pool of IPv4 Address Space Depleted". Number Resource Organization (باللغة الإنجليزية). ثلاثة فبراير 2011. مؤرشف من الأصل فيخمسة مارس 2020. اطلع عليه بتاريخستة مارس 2019.

[RFC-8-22] Bradner, S.; Mankin, A. (ديسمبر 1993). "RFC 1550, IP: Next Generation (IPng) White Paper Solicitation" (باللغة الإنجليزية). doi:10.17487/RFC1550. مؤرشف من الأصل في 04 ديسمبر 2019.

[RFC-9-23] RFC 1752, P.2

[RFC-10-24] RFC 1752, P.45

[RFC-12-25] Hinden, R.; Deering, S. (ديسمبر 1995). "RFC 1884, IP Versionستة Addressing Architecture" (باللغة الإنجليزية). doi:10.17487/RFC1884. مؤرشف من الأصل في 06 مارس 2020.

[RFC-13-26] RFC 1885, P.1

[RFC-14-27] Narten, T.; Nordmark, E.; Simpson, W. (أغسطس 1996). "RFC 1970, Neighbor Discovery for IP Versionستة (IPv6)" (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC1970. مؤرشف من الأصل في 04 ديسمبر 2019.

[RFC-15-28] Thomson, S.; Narten, T. (ديسمبر 1995). "RFC 1971, IPv6 Stateless Address Autoconfiguration" (باللغة الإنجليزية). doi:10.17487/RFC1971. مؤرشف من الأصل في 12 ديسمبر 2019.

[RFC-16-29] RFC 2460, P.1

[RFC-17-30] Narten, T.; Nordmark, E.; Simpson, W. (ديسمبر 1998). "RFC 2461, Neighbor Discovery for IP Versionستة (IPv6)" (باللغة الإنجليزية). doi:10.17487/RFC2461. مؤرشف من الأصل في 13 مارس 2020.

[RFC-18-31] Thomson, S.; Narten, T. (ديسمبر 1998). "RFC 2462, IPv6 Stateless Address Autoconfiguration" (باللغة الإنجليزية). doi:10.17487/RFC2462. مؤرشف من الأصل في 07 مايو2020.

[RFC-19-32] Conta, A.; Deering, S. (ديسمبر 1998). "RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Versionستة (IPv6) Specification" (باللغة الإنجليزية). doi:10.17487/RFC2463. مؤرشف من الأصل في 16 مارس 2020.

[RFC-20-33] "RFC 4291, P.1

[RFC-21-34] RFC 4443, P.1

[RFC-22-35] RFC 4861, P.1

[RFC-23-36] RFC 4862, P.1

[Book-4-37] (باللغة الإنجليزية) (الطبعة الثانية). Javvin Technologies Inc. 2005. صفحة 67. مؤرشف من الأصل (PDF) في 28 مايو2020.

[RFC-25-38] RFC 8200, P.4

[Book-21-39] TCP/IP Illustrated, P.184

[RFC-27-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.

[RFC-28-41] RFC 6437, P.3

[RFC-31-42] RFC 8200, P.5

[RFC-32-43] RFC 8200, P.7

[RFC-33-44] RFC 8200, P.9

[Book-6-45] TCP/IP Illustrated, P.194

[RFC-34-46] RFC 8200, P.24

[Web-2-47] "Internet Protocol Versionستة (IPv6) Parameters - Next Header Types" (باللغة الإنجليزية). مؤرشف من الأصل في 28 فبراير 2020. اطلع عليه بتاريخ 23 مايو2020.

[RFC-35-48] RFC 8200, P.10

[RFC-36-49] RFC 8200, P.8

[RFC-37-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.

[RFC-38-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.

[RFC-44-52] RFC 8200, P.6-7

[Web-3-53] "Assigned Internet Protocol Numberss" (باللغة الإنجليزية). مؤرشف من الأصل في 13 فبراير 2020. اطلع عليه بتاريخ 23 مايو2020.

[RFC-39-54] RFC 8200 P.13

[Book-7-55] TCP/IP Illustrated, P.200

[RFC-42-56] RFC 791, P.16

[RFC-40-57] RFC 8200, P.14

[Web-4-58] "Internet Protocol Versionستة (IPv6) Parameters" (باللغة الإنجليزية). مؤرشف من الأصل فيسبعة مايو2020. اطلع عليه بتاريخ 23 مايو2020.

[RFC-41-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 مايو2020. اطلع عليه بتاريخ 23 مايو2020.

[RFC-43-60] RFC 8200, P.15

[RFC-45-61] RFC 8200, P.19

[Web-5-62] "Protocol Numbers". IANA (باللغة الإنجليزية). مؤرشف من الأصل في أربعة يناير 2018. اطلع عليه بتاريخ 18 يوليو2018.

[RFC-47-63] RFC 8200, P.15-16

[RFC-46-64] Gont, F. (فبراير 2016). "RFC 7739, Security Implications of Predictable Fragment Identification Values". The Internet Society (باللغة الإنجليزية). ISSN 2070-1721. مؤرشف من الأصل في 28 مايو2020. اطلع عليه بتاريخ 17 يوليو2018.

[RFC-48-65] RFC 8200, P.23

[RFC-49-66] RFC 4302, P.3

[RFC-50-67] RFC 4302, P.4

[RFC-51-68] RFC 4302, P.5-9

[RFC-52-69] RFC 4303 P.1

[RFC-53-70] RFC 4303 P.5

[RFC-54-71] RFC 4303 P.10-17

[Book-10-72] TCP/IP Illustrated, P.196

[RFC-55-73] RFC 8200, P.11

[RFC-56-74] RFC 8200, P.12

[RFC-57-75] RFC 8200, P.36-38

[RFC-58-76] RFC 8200, P.12-13

[Book-12-77] Cisco CCENT/CCNA ICND1, P.617

[RFC-59-78] RFC 4291 P.7

[RFC-60-79] RFC 5952 P.2

[Book-13-80] Cisco CCENT/CCNA ICND1, P.619

[Book-14-81] Cisco CCENT/CCNA ICND1, P.617-618

[RFC-61-82] RFC 4291, P.4-5

[RFC-66-83] RFC 4632, P.5

[RFC-63-84] RFC 4291, P.5

[RFC-64-85] RFC 4291, P.6

[RFC-67-86] RFC 4291, P.9

[RFC-68-87] RFC 4291, P.10

[Book-16-88] Cisco CCENT/CCNA ICND1, P.634

[RFC-69-89] RFC 4291, P.11

[Book-15-90] Cisco CCENT/CCNA ICND1, P.632

[RFC-70-91] RFC 4193, P.2

[RFC-71-92] RFC 4193, P.3-4

[RFC-72-93] Huitema, C.; Carpenter, B. (سبتمبر 2004). "RFC 3879, Deprecating Site Local Addresses" (باللغة الإنجليزية). doi:10.17487/RFC3879. مؤرشف من الأصل في 07 مايو2020.

[RFC-75-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.

[RFC-73-95] RFC 4291, P.12

[RFC-74-96] RFC 4291, P.13

[Book-17-97] Peter Dyson; Kevin Shafer (1999). (باللغة الإنجليزية) (الطبعة الثالثة). SYBEX Inc. صفحة 1999. ISBN . مؤرشف من الأصل في 28 مايو2020.

[RFC-77-98] Savola, P.; Haberman, B. (نوفمبر 2004). "RFC 3956, Application Aspects of IPv6 Transition" (باللغة الإنجليزية). صفحة 5. doi:10.17487/RFC3956. مؤرشف من الأصل في 24 يناير 2020. اطلع عليه بتاريخ 25 مايو2020.

[RFC-78-99] RFC 3306, P.3

[RFC-80-100] Droms, R. (أغسطس 2014). "RFC 7346, IPv6 Multicast Address Scopes" (باللغة الإنجليزية). صفحة 3. doi:10.17487/RFC7346. ISSN 2070-1721. مؤرشف من الأصل في 24 يناير 2020. اطلع عليه بتاريخ 25 مايو2020.

[RFC-81-101] RFC 4291, P.14

[RFC-79-102] RFC 3306, P.1

[RFC-82-103] Boucadair, M.; Venaas, S. (سبتمبر 2014). "RFC 7371, Updates to the IPv6 Multicast Addressing Architecture" (باللغة الإنجليزية). doi:10.17487/RFC7371. ISSN 2070-1721. مؤرشف من الأصل في 24 يناير 2020. اطلع عليه بتاريخ 25 مايو2020.

[RFC-83-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.

[Web-6-105] "IANA IPv6 Special-Purpose Address Registry". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 2 يناير 2020. اطلع عليه بتاريخ 25 مايو2020.

[RFC-85-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. مؤرشف من الأصل فيعشرة مايو2020.

[RFC-86-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.

[RFC-87-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.

[RFC-88-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.

[RFC-89-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.

[RFC-90-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.

[RFC-91-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.

[RFC-92-113] Bumgardner, G. (فبراير 2015). "RFC 7450, Automatic Multicast Tunneling". The Internet Society (باللغة الإنجليزية). صفحة 78. doi:10.17487/RFC7450. ISSN 2070-1721. مؤرشف من الأصل في 16 أبريل 2020.

[RFC-93-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.

[RFC-94-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.

[RFC-95-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.

[RFC-96-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.

[RFC-97-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.

[RFC-98-119] Abley, J.; Sotomayor, W. (مايو2015). "RFC 7534, AS112 Nameserver Operations". The Internet Society (باللغة الإنجليزية). صفحة 6. doi:10.17487/RFC7534. ISSN 2070-1721. مؤرشف من الأصل في 16 أبريل 2020.

[RFC-99-120] RFC 4193, P.3

[Web-7-121] "IPv6 Multicast Address Space Registry". IANA (باللغة الإنجليزية). مؤرشف من الأصل فيسبعة مايو2018. اطلع عليه بتاريخ 25 مايو2020.

[RFC-100-122] RFC 4291, P.16-17

[RFC-101-123] RFC 4291, P.17

[RFC-102-124] RFC 4862, P.3

[RFC-103-125] RFC 4862, P.11-12

[RFC-104-126] RFC 4862, P.12

[RFC-105-127] RFC 4862, P.17-21

[Web-8-128] "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)" (PDF). IEEE (باللغة الإنجليزية). ثلاثة أغسطس 2017. صفحة 9-10. مؤرشف من الأصل (PDF) في 28 فبراير 2020. اطلع عليه بتاريخثمانية مارس 2020.

[RFC-106-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.

[RFC-108-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.

[Web-9-131] "Internet Assigned Numbers Authority (IANA) Policy For Allocation of IPv6 Blocks to Regional Internet Registries (Ratifiedسبعة September 2006)". icann.org (باللغة الإنجليزية). مؤرشف من الأصل في 28 فبراير 2020. اطلع عليه بتاريخثمانية مارس 2020.

[RFC-109-132] RFC 4291, P.7

[Web-10-133] "IPv6 Global Unicast Address Assignments". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 16 فبراير 2020. اطلع عليه بتاريخثمانية مارس 2020.

[Web-11-134] "Understanding IP Addressing and CIDR Charts". RIPE NCC (باللغة الإنجليزية). مؤرشف من الأصل في 15 فبراير 2020. اطلع عليه بتاريخثمانية مارس 2020.

[Web-12-135] "IPv6 Global Unicast Address Assignments". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 22 فبراير 2018. اطلع عليه بتاريخ 2 سبتمبر 2018.

[Web-63-136] "Understanding IP Addressing and CIDR Charts". RIPE (باللغة الإنجليزية). أربعة يناير 2011. مؤرشف من الأصل في 23 سبتمبر 2018. اطلع عليه بتاريخ 23 سبتمبر 2018.

[Book-18-137] Cisco CCENT/CCNA ICND1, P.639

[Book-19-138] Charles M. Kozierok (2005). (PDF) (باللغة الإنجليزية). William Pollock. صفحة 464. ISBN .

[RFC-110-139] RFC 8200, P.15-22

[RFC-111-140] Hinden, R. (أغسطس 1999). "RFC 2675, IPv6 Jumbograms". The Internet Society (باللغة الإنجليزية). صفحة 1. doi:10.17487/RFC2675. مؤرشف من الأصل في 03 مايو2020.

[RFC-112-141] RFC 8200, P.17

[RFC-114-142] RFC 8200, P.20

[RFC-115-143] RFC 6437, P.4

[RFC-116-144] RFC 6437, P.5

[RFC-117-145] RFC 2460, P.25

[RFC-118-146] RFC 2460, P.29-30

[RFC-119-147] RFC 2474, P.7

[RFC-120-148] RFC 2474, P.11

[RFC-121-149] RFC 2474, P.13

[RFC-122-150] Krishnan, S. (فبراير 2016). "RFC 5722, Handling of Overlapping IPv6 Fragments". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 11 مايو2020. اطلع عليه بتاريخ 21 يوليو2018.

[RFC-129-151] RFC 8200, P.31

[RFC-123-152] Gont, F. (مايو2013). "RFC 6946, Processing of IPv6 "Atomic" Fragments". The Internet Society (باللغة الإنجليزية). ISSN 2070-1721. مؤرشف من الأصل في 11 مارس 2020. اطلع عليه بتاريخ 21 يوليو2018.

[RFC-124-153] RFC 6437, P.9

[RFC-125-154] RFC 6437, P.10

[RFC-128-155] Gont, F. (12 مارس 2012). "Security Assessment of the IPv6 Flow Label draft-gont-6man-flowlabel-security-03" (باللغة الإنجليزية). مؤرشف من الأصل في 20 مايو2020.

[RFC-126-156] RFC 6437, P.8

[RFC-132-157] RFC 4443, P.3

[RFC-133-158] RFC 1885, P.2

[Web-13-159] "Internet Control Message Protocol versionستة (ICMPv6) Parametersry". IANA (باللغة الإنجليزية). مؤرشف من الأصل في 28 فبراير 2020. اطلع عليه بتاريخ 28 مايو2020.

[RFC-135-160] RFC 4861, P.11

[RFC-136-161] Conta, A. (يونيو2001). "RFC 3122, Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification" (باللغة الإنجليزية). doi:10.17487/RFC3122. مؤرشف من الأصل في 12 ديسمبر 2019.

[RFC-137-162] Arkko, J.; Kempf, J.; Zill, B.; Nikander, P. (مارس 2005). "RFC 3971, SEcure Neighbor Discovery (SEND)" (باللغة الإنجليزية). doi:10.17487/RFC3971. مؤرشف من الأصل في 28 أبريل 2020.

[ietf-35-163] R. Vida; B. Cain; L. Costa (يونيو2004). "RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6 Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 17 فبراير 2005. اطلع عليه بتاريخستة مارس 2017.

[Book-23-164] TCP-IP Illustrated, P.451-453

[Book-98-165] Rami Rosen (2013). Linux Kernel Networking: Implementation and Theory (Expert's Voice in Open Source) (باللغة الإنجليزية). Apress. صفحة 230. ISBN .

[RFC-130-166] S. Deering; W. Fenner; B. Haberman (أوكتوبر 1999). "RFC 2710, Multicast Listener Discovery (MLD) for IPv6 Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 25 مارس 2020. اطلع عليه بتاريخستة مارس 2017.

[RFC-131-167] {R. Vida; B. Cain; L. Costa (يونيو2004). "RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6 Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 17 فبراير 2005. اطلع عليه بتاريخستة مارس 2017.

[RFC-134-168] H. Holbrook; B. Cain; B. Haberman (أغسطس 2006). "RFC 4604, Using Internet Group Management Protocol Version ثلاثة (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast". The Internet Society (باللغة الإنجليزية). مؤرشف من الأصل في 11 أغسطس 2012. اطلع عليه بتاريخستة مارس 2017.

[JOU-1-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.

[RFC-65-170] RFC 5952, P.10

[RFC-107-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 ديسمبر 2019. اطلع عليه بتاريخ 22 يناير 2020.