stanford-oval/wikipedia huggingface dataset:
بروتوكول الإنترنت (الإصدار السادس)
الوظائف > العنونة > إدارة فضاء العناوين: التحصيص والمنح

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

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

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

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

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

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

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

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

| بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت>  | بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت>  |
| --- | --- |
اختصار: ICMPv6
الوظيفة: بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت
المُطوِّر: مجموعة مهندسي الإنترنت
تاريخ التطوير: ديسمبر 1995
مبني على: بروتوكول رسائل التحكم في الإنترنت
طبقة نموذج OSI: طبقة الشبكة
وثيقة طلب التعليقات RFC: RFC 4443
تعديل مصدري - تعديل  : تعديل مصدري - تعديل  
بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت (بالإنجليزية: Internet Control Message Protocol for IPv6 اختصارًا ICMPv6)‏ هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت وجزءٌ مدمج منه، طُوِّر هذا البروتوكول بالتوازي مع الإصدار السادس من بروتوكول الإنترنت وصدر معياره الأصلي في شهر ديسمبر من العام 1995م ووصف في وثيقة طلب التعليقات RFC 1885.
تستعمل العقد التي تُشغِّل الإصدار السادس من بروتوكول الإنترنت بروتوكول رسائل التحكم للتبليغ عن الأخطاء الحاصلة في أثناء معالجة رزم البيانات ولأداء وظائف أخرى مرتبطة بطبقة الشبكة مثل تشخيص المُشكلات باستعمال أمر التحقق من المسار، ويلزم أن يكون مدعومًا بشكل كامل في العقد التي تشغل الإصدار السادس من بروتوكول الإنترنت جميعِها.
يُعرِّف البروتوكول ترويسة خاصة به طولها 4 بايت، تُضاف بعد ترويسة الإصدار السادس. ولهذه الترويسة مُعرِّف مميز هو 58، يلزم أن يُشار إليه في حقل الترويسة التالية في داخل الترويسة التي تسبق ترويسة هذا البروتوكول. بالإضافة لذلك، يُعرِّف المعيار الأصلي للبروتوكول 4 رسائل أخطاء وثلاث رسائل استعلام. ولكن أضيفت العديد من الرسائل لاحقًا لخدمة وظائف مختلفة مثل رسائل التماس الموجه التي أضافها بروتوكول اكتشاف الجيران وغير ذلك.
في شهر ديسمبر من العام 1998 صدر تحديث جديد للبروتوكول في وثيقة طلب التعليقات RFC 2463، وبعدها بثمانية سنوات صدرت الوثيقة RFC 4443 وهي المعيار الحالي للبروتوكول وهي تتضمن تفصيلًا إضافيًّا عن الثغرات الأمنية التي يمكن استعماها لشن هجمات عبر البروتوكول وكيفية الوقاية منها ومجموعة من الاعتبارات اللازمة لهيئة أرقام الإنترنت المُخصصة من أجل تعريف أنواع رسائل جديدة.
بروتوكولات رديفة > بروتوكول اكتشاف الجيران

| بروتوكول اكتشاف الجيران>  | بروتوكول اكتشاف الجيران>  |
| --- | --- |
اختصار: NDP
الوظيفة: بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت
المُطوِّر: مجموعة مهندسي الإنترنت
تاريخ التطوير: أغسطس 1996
مبني على: بروتوكول رسائل التحكم في الإنترنت
طبقة نموذج OSI: طبقة الشبكة وطبقة الوصلة
وثيقة طلب التعليقات RFC: RFC 4861
تعديل مصدري - تعديل  : تعديل مصدري - تعديل  
المقالة الرئيسة: بروتوكول اكتشاف الجيران
بروتوكول اكتشاف الجيران (بالإنجليزية: Neighbor Discovery Protocol)‏ هو بروتوكول مساعد للإصدار السادس من بروتوكول الإنترنت، يعمل بين الطبقتين الثانية والثالثة وفقًا نموذج الربط البيني للأنظمة المفتوحة، ويقدم خدمات التعرف على الموجهات والتعرف على الجيران وإعادة التوجيه. طرح المعيار الأصلي للبروتوكول في أغسطس من العام 1996 ووصف في وثيقة طلب التعليقات RFC 1970.
يُعرِّف هذا البروتوكول 5 رسائل من بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت هن: رسالة إعادة التوجيه وزوجين من الرسائل لاكتشاف عناوين الموجهات في الشبكة المحلية، هما رسالة التماس الموجه ورسالة الإعلان عن الموجه، وزوجين لاكتشاف عناوين الجيران، هما رسالة التماس الجار ورسالة الإعلان عن الجار اللتان أدى بهما البروتوكول مع الإصدار السادس وظيفة اقتران العناوين بين الطبقتين الثالثة والثانية، وهي الوظيفة نفسها التي يؤديها بروتوكول اقتران العناوين مع الإصدار الرابع من بروتوكول الإنترنت.
طُوِّرت أشكال متنوعة مشتقة من هذا البروتوكول، منها بروتوكول اكتشاف الجيران العكسيّ (بالإنجليزية: Inverse Neighbor Discovery Protocol)‏ الذي يؤدي وظيفة اقتران العناوين العكسية بين الطبقتين الثانية والثالثة والذي وصف في الوثيقة RFC 3122 على أنه توسعة لبروتوكول اكتشاف الجيران، وأيضًا بروتوكول اكتشاف الجيران الآمن (بالإنجليزية: SEcure Neighbor Discovery Protocol  اختصارًا SEND)‏ الذي يُعرِّف آلياتٍ آمنة لتبادل بيانات الشبكة وفق بروتوكول اكتشاف الجيران، وقد وُصِف في وثيقة طلب التعليقات RFC 3971.
صدر تحديث جديد للمعيار في ديسمبر من العام 1998م، وحملت الوثيقة الاسم الرمزي RFC 2461. ثم صدرت الوثيقة RFC 4861 في شهر سبتمبر من العام 2007م، وهي المعيار الحالي لبروتوكول اكتشاف الجيران.
بروتوكولات رديفة > بروتوكول اكتشاف مستمعي البث المجموعاتي

| بروتوكول اكتشاف مستمعي البث المجموعاتي>  | بروتوكول اكتشاف مستمعي البث المجموعاتي>  |
| --- | --- |
الوظيفة: إدارة مجموعة البث المجموعاتي في الإصدار السادس من بروتوكول الإنترنت
المُطوِّر: مجموعة مهندسي الإنترنت
تاريخ التطوير: 2004
طبقة نموذج OSI: طبقة الشبكة
وثيقة طلب التعليقات RFC: RFC 3810
تعديل مصدري - تعديل  : تعديل مصدري - تعديل  
بروتوكول اكتشاف مستمعي البث المجموعاتي (بالإنجليزية: 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. في هذا السياق، تُستثنى ترويسة تأمين الحمولة بالتغليف وتعامل معاملة ترويسة الطبقات العليا مع أنها من أنها ترويسة توسعة للإصدار السادس من البروتوكول.
وصلات خارجية

الإصدار السادس من بروتوكول الإنترنت للجميع كتيب من إعداد مجتمع الإنترنت.
التقطيع في الإصدار السادس من بروتوكول الإنترنت، مقالة من جيف هوستِن.
اكتشاف الجيران والتهيئة الذاتية الآلية في الإصدار السادس من بروتوكول الإنترنت، مقالة من توماس نارتِن.
أمن الإصدار السادس من بروتوكول الإنترنت، أسئلة متكررة، مقالة من مجتمع الإنترنت.
أمن الشبكات، أمن الإصدار السادس لمهندسي الإصدار الرابع، مقالة من مجتمع الإنترنت.
| ع ن الإصدار السادس من بروتوكول الإنترنت | ع ن الإصدار السادس من بروتوكول الإنترنت |
| --- | --- |
عام:  بروتوكول الإنترنت  الإصدار الرابع (IPv4)  الإصدار السادس (IPv6)  الجوَّال  العنونة في الإصدار السادس من بروتوكول الإنترنت  رزمة البيانات 
الانتشار:  الانتشار ‏  اليوم العالمي لإطلاق الإصدار ‏  الدعم في أنظمة التشغيل ‏ 
ذات صلة بالإصدار الرابع:  استنفاد فضاء الإصدار الرابع  آليات الانتقال للإصدار السادس ‏ 
بروتوكولات رديفة:  بروتوكول التهيئة الآلية لمضيفي الإصدار السادس من بروتوكول الإنترنت ‏ (DHCPv6)  بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت (ICMPv6) بروتوكول اكتشاف الجيران (NDP)  بروتوكول اكتشاف مستمعي البث المجموعاتي ‏ (MLD)  بروتوكول اكتشاف الجيران الآمن ‏ 
| 0 | 1 |
| --- | --- |
ضبط استنادي: وطنية : الملف الاستنادي المتكامِل (GND) قاعدة البيانات الوطنية التشيكية (NLCR AUT)
بوابة إنترنت
بوابة اتصال عن بعد
بوابة تقانة المعلومات
بوابة علم الحاسوب
أصناف عناوين البث فريد الوجهة في الإصدار الرابع من بروتوكول الإنترنت وبنية عناوينها.
خط زمني لتطوُّر البروتوكولات الرئيسة في حزمة بروتوكولات الإنترنت
خط زمني للمعايير الناظمة للإصدار السادس من بروتوكول الإنترنت والبروتوكولات الرديفة له.
أمثلة متنوعة عن تتابع الترويسات في الإصدار السادس من بروتوكول الإنترنت.
ترويسة الإصدار السادس من بروتوكول الإنترنت.
بنية ترويسة خيارات المسار
بنية ترويسة التوجيه
بنية ترويسة القطعة
بنية ترويسة خيارات الوجهة.
بنية ترويسة المصادقة.
بنية ترويسة تأمين الحمولة بالتغليف.
بنية الخيار العامة في الإصدار السادس من بروتوكول الإنترنت.
مسرد للمصطلحات المُستعملة في عناوين الإصدار السادس من بروتوكول الإنترنت
البنية العامة لعنوان بث فريد الوجهة في الإصدار السادس من بروتوكول الإنترنت.
بنية عنوان البث المجموعاتي.
هرمية تحصيص فضاء عناوين بروتوكول الإنترنت رباعية المستويات.
مثال عن مستويات التحصيص في الإصدار السادس من بروتوكول الإنترنت.
جدول لأطوال بادئة التوجيه غير الصنفي بين النطاقات في الإصدار السادس من بروتوكول الإنترنت وأعداد الشبكات الجزئية الموافقة لكل منها وعدد بتات قسم مُعرف المنفذ.
حالات حدود معرف الشبكة الجزئية (SID) في الإصدار السادس من بروتوكول الإنترنت.
المبدأ العام للتقطيع في الإصدار السادس من بروتوكول الإنترنت.
مخطط تدفقي يبين خوارزمية عملية التقطيع في الإصدار السادس من بروتوكول الإنترنت.
بنية رزمة بيانات الإصدار السادس من بروتوكول الإنترنت الناتجة عن إعادة تجميع القطع في المضيف الوجهة.
بنية حقل صنف حركة البيانات في ترويسة الإصدار البروتوكول.
معركة يبنة

| ع ن حروب فاطمية صليبية  (1099–1169) | ع ن حروب فاطمية صليبية  (1099–1169) |
| --- | --- |
 حصار القدس  عسقلان الأولى  الرملة الأولى  الرملة الثانية  يافا  عكا  الرملة الثالثة  بيروت  يبنة  عسقلان الثانية  مصر (البابين) :  حصار القدس  عسقلان الأولى  الرملة الأولى  الرملة الثانية  يافا  عكا  الرملة الثالثة  بيروت  يبنة  عسقلان الثانية  مصر (البابين) 
معركة يبنة عام 1123، حملة صليبية بقيادة أوستاس كرنييه سحقت الجيش الفاطمي الذي أرسله من مصر الوزير المأمون البطائحي بين عسقلان ويافا.
خلفية

بعدما استولى الحملة الصليبية الأولى من الفاطميين على بيت المقدس، أرسل الوزير الفاطمي الأفضل شاهنشاه سلسلة من الغزوات «سنوياً تقريباً» من عام 1099 حتى 1107 على مملكة بيت المقدس حديثة التأسيس. خاضت الجيوش المصرية ثلاث معارك كبرى الرملة 1101، 1102، و1105، لكنها لم تنجح في نهاية المطاف. بعد هذه المعارك، أقنع الوزير نفسه بإطلاق غارات متكررة على أراضي الفرنجة من قلعته الساحلية في عسقلان. عام 1121، أُغتيل الأفضل. في الوقت نفسه، كانت بيت المقدس ضعيفة بعد أسر الأراتقة لبلدوين الثاني في شمال سوريا؛ كانت المملكة في ذلك الوقت تحت حكم الوصي على العرش أوستاس گرنييه.
المعركة

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